Здравствуйте, DarkEld3r, Вы писали:
DE>Что значит встроенных? Они не больше "встроены", чем в С++ — так же находятся в стандартной библиотеке.
На сколько я представляю, в Rust реализована дополнительная семантика при работе с (умными) указателями, позволяющая определять многие ошибки по их использованию еще на этапе компиляции. Я не думаю, что это могло бы работать, если бы компилятор просто использовал умные указатели подобно обычным классам из каких-то библиотек. А если они не более встроены, чем в C++, то весь смысл теряется, лучше бы разработчики потратили время на добавление более строгой семантики по работе с указателями и borrowing в C++.
DE>так что "франкенштейн" — это как раз не раст
Никто не спорит, что C++ — это всем франкенштейнам франкенштейн. Однако за 30 лет он доказал свою силу и жизнеспособность. А во что превратится Rust — это еще вопрос. Особенно если учесть, что из других языков он заимствует не только фичи, но и их проблемы. Любимые всеми Undefined Behaviour и dangling pointers тут как тут.
DE>Скажем, для С++ так и нет и вряд ли будет общая система сборки или "менеджер пакетов". В расте оно идёт из коробки.
Общая система сборки, менеджеры пакетов — это хорошо, но если язык наберет популярность, то наверняка найдется масса желающих ликвидировать фатальный недостаток.
DE>Лично мне раст нравится пока что: неплохой синтаксис
Вот как по мне, так синтаксис в нем не менее безобразен, чем в С++, некоторые конструкции вообще жесть:
static LANGUAGE: &'static str = "Rust";
Единственно отсутствие инклюдов и лаконичное let объявление переменных неизменяемыми по-умолчанию импонирует. Ну и некоторые другие мелочи.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
VTT>На сколько я представляю, в Rust реализована дополнительная семантика при работе с (умными) указателями
Но это не так. В язык "встроены" только лайфтаймы. А на их основе уже всё работает. Так что никто не мешает писать свои смарт-поинтеры — работать будут аналогично.
VTT>Любимые всеми Undefined Behaviour и dangling pointers тут как тут.
И разумеется будут примеры? Потому что в безопасном коде нам как раз обещают отсутствие этих вещей.
VTT>Общая система сборки, менеджеры пакетов — это хорошо, но если язык наберет популярность, то наверняка найдется масса желающих ликвидировать фатальный недостаток.
Дык, в С++ этот недостаток "ликвидирован", в итоге у нас есть autotools, CMake, SCons, Qbs и много других. Для библиотек так толком ничего общего и не придумали. Прекрасно понимаю, что и без этого жить можно, но обучение оно облегчает, да и потом удобно.
VTT>Вот как по мне, так синтаксис в нем не менее безобразен, чем в С++, некоторые конструкции вообще жесть:
Долго искал пример? Статики часто в коде видеть не придётся. Вроде, есть предложение упростить синтаксис для них, а именно добавить вывод типов. Тогда будет просто:
static LANGUAGE = "Rust";
Ещё то, что (практически) всё является выражением тоже весьма удобно.
Что действительно "страшно" выглядит — так это макросы.
Здравствуйте, VTT, Вы писали:
VTT>Скорее в Rust безопасным называется тот код, в котором эти вещи удается предотвратить.
Дык, там написано "Type checking provides the guarantee that these issues are never caused by safe code". То есть как раз то, что я и написал — в безопасном (без использования unsafe блоков) не будет никакого УБ и "висячих ссылок".
VTT>Этот пример из официального руководства.
В курсе, но это не та вещь, которой будешь часто пользоваться. У меня тоже пару придирок есть, например, в дженериках с where на тип приходится ссылаться три раза. Но на мой взгляд, всё это мелочи.
Запутанно. Но это, скорее, из-за недоработанных технологий. Они там АСТ вручную разбирают. Уровень плинтуса.
C>Со сложностью, в принципе, не всё так плохо. Но вот уход в процедурные макросы ("compiler extensions") и прочие края — это уже верная смерть для языка.
Несогласен. Пользователей языка никто не заставляет ими пользоваться. Правда только, то что код макросов запутанный.
C>А ещё ведь хотят добавить и HKT — вообще полная Скала получится.
Что такое HKT?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VTT, Вы писали:
VTT> Я не вижу никаких основополагающих принципов, способных сделать из кучки разноплановых фич (по большей части уже в лучшем виде реализованных в других языках) под новым соусом синтаксисом нечто большее. Как C/C++ разработчик, я могу сказать, что наличие в языке встроенных умных указателей меня вовсе не прельщает. Ведь память — это далеко не единственный ресурс, а умные указатели — не единственный способ контроля за памятью. В Rust к тому же все равно придется иметь дело с зоопарком С/С++ библиотек и системных API, о порядке владения сущностями из которых компилятор не будет иметь ни малейшего понятия, а никаких средств для описания такого рода вещей язык не предусматривает.
Напрасно ты так. Все же встроенный borrow checker и завязанное на него все-все — это очень большой шаг вперед (или вбок) от других языков. Он и для ресурсов, и для канкарренси пригождается, обеспечивая намного больше статических гарантий, чем умные указатели. Читать-вдохновляться тут: http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html
А умные указатели там наоборот источник проблем, могут приводить к ликам, как и в С++.
Здравствуйте, kaa.python, Вы писали:
KP>Я подчеркнул главное. Сложные – ну не надо писать. unsafe – ну не надо использовать. Шаренная память – ну используйте отправку сообщений вместо. При этом доподлинно известно, что если что-то можно сделать через жопу, то очень многие разработчики выберут именно этот путь. А потом уже будет "теория разбитых окон" в действии. На C++ годами, даже скорее десятилетиями, вырабатывали правильный подход к разработке. А в случае с новым языком, будут сплошной поход по граблям, благо грабли разложены и готовы к работе
Не факт. В C#, например, unsafe крайне редко используется на практике.
Здравствуйте, D. Mon, Вы писали:
DM>А умные указатели там наоборот источник проблем, могут приводить к ликам, как и в С++.
Тут "указатели" с подсчётом ссылок имеются в виду или что?
Потому что в расте несколько другая терминология, чем в С++.
Здравствуйте, D. Mon, Вы писали:
DM>Все же встроенный borrow checker и завязанное на него все-все — это очень большой шаг вперед (или вбок) от других языков.
Никто не спорит, что borrow checker — интересная и (потенциально) полезная концепция. Однако необходимость регулярно вылезать за рамки safe кода, взаимодействуя с разными системными API и сторонними библиотеками, потенциально может сводить на нет все преимущества от дополнительных статических проверок. Еще мне совсем не понятно, что именно будет происходить на границах safe-unsafe? Вдруг там будет 100500 рантайм проверок — получим тормоза, или наоборот, никаких рантайм проверок — получим еще более сложные в нахождении баги, чем в C++. Язык конечно новый, но примеров и статей по нему явно не хватает для получения полной картины. Причем те, что есть — стремительно устаревают (когда я интересовался им в предыдущий раз синтаксис с указателями был какой-то другой, и шла речь про отдельные кучи для разных потоков или что-то подобное). Ну и сугубо позитивный тон, полное отсутствие контрпримеров или упоминания потенциальных проблем очень настораживает.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, DarkEld3r, Вы писали:
DM>>А умные указатели там наоборот источник проблем, могут приводить к ликам, как и в С++. DE>Тут "указатели" с подсчётом ссылок имеются в виду или что?
Здравствуйте, VTT, Вы писали:
VTT>Никто не спорит, что borrow checker — интересная и (потенциально) полезная концепция. Однако необходимость регулярно вылезать за рамки safe кода, взаимодействуя с разными системными API и сторонними библиотеками, потенциально может сводить на нет все преимущества от дополнительных статических проверок.
Да, этот вопрос с системными API и сторонними библиотеками — вечный источник проблем, разрушающий стеклянные замки сборщиков мусора, умных указателей и пр. Я только в одном месте видел достойное решение — описание дополнительной семантики системных и библиотечных вызовов на языке доказательств в ATS.
VTT>Еще мне совсем не понятно, что именно будет происходить на границах safe-unsafe? Вдруг там будет 100500 рантайм проверок — получим тормоза, или наоборот, никаких рантайм проверок — получим еще более сложные в нахождении баги, чем в C++.
Как я понял, в Расте принято делать для этого маленькие кусочки unsafe, безопасность поведения которых оценивать на глазок, а снаружи они имеют safe интерфейс, и из основной программы уже используются безопасно. При условии, конечно, что внутри кусочка корректность была оценена верно. Лишних рантайм проверок не делают, и на 100% от багов не защищены.
Здравствуйте, VladD2, Вы писали:
C>>Вопрос на засыпку — что делает вот этот макрос: https://github.com/gfx-rs/gfx_macros/blob/master/src/shader_param.rs ? VD>Запутанно. Но это, скорее, из-за недоработанных технологий. Они там АСТ вручную разбирают. Уровень плинтуса.
У них есть и макросы на квазицитировании, но они специально обрезанные.
C>>Со сложностью, в принципе, не всё так плохо. Но вот уход в процедурные макросы ("compiler extensions") и прочие края — это уже верная смерть для языка. VD>Несогласен. Пользователей языка никто не заставляет ими пользоваться. Правда только, то что код макросов запутанный.
Проблема в том, что потом неминуемо придётся отлаживать код, который написали Кумары Брахмабухалсамы после прочтения книги "Современное программирование на Rust++".
C>>А ещё ведь хотят добавить и HKT — вообще полная Скала получится. VD>Что такое HKT?
Возможность делать фабрики _типов_.
Здравствуйте, D. Mon, Вы писали:
DM>Да, именно они. Вот тут длинный пост про утечки с ними: DM>http://smallcultfollowing.com/babysteps/blog/2015/04/29/on-reference-counting-and-leaks/
DM>GC они выбросили, борьба с циклическими ссылками теперь на совести программиста, а это ненадежно.
В курсе, статью по ссылке читал, она действительно неплоха.
Сказать хотел немного другое: в С++ у нас есть именно смарт-поинтеры в которые можно поместить что-то отличное от указателей, но это не слишком удобно и редко практикуется. В расте же отдельно отдельно тип для размещения в хипе, отдельно тип для подсчёта ссылок.
Здравствуйте, Cyberax, Вы писали:
C>Проблема в том, что потом неминуемо придётся отлаживать код, который написали Кумары Брахмабухалсамы после прочтения книги "Современное программирование на Rust++".
Я не уверен, что это проблема. Вон в С++ буст пишут, по идее, не индусы, но разбираться там (особенно в некоторых местах) то ещё "удовольствие". Тем не менее, в большинстве случаев, он "просто работает" и в потроха лезть не надо.
И наоборот — "традиционный говнокод", с которым приходилось дело иметь, редко изобиловал "новомодными фичами".
Здравствуйте, DarkEld3r, Вы писали:
VTT>>Вот как по мне, так синтаксис в нем не менее безобразен, чем в С++, некоторые конструкции вообще жесть: DE>Долго искал пример? Статики часто в коде видеть не придётся. Вроде, есть предложение упростить синтаксис для них, а именно добавить вывод типов. Тогда будет просто: DE>
DE>static LANGUAGE = "Rust";
DE>
Напротив, строковые константы встречаются достаточно часто. Вот мне интересно. Вроде уже и релиз через пару недель, а такие базовые фичи только на стадии "есть предложение".
Здравствуйте, uncommon, Вы писали:
U>Напротив, строковые константы встречаются достаточно часто. Вот мне интересно. Вроде уже и релиз через пару недель, а такие базовые фичи только на стадии "есть предложение".
Просто строковые константы выглядят вот так:
let language = "Rust";
Ничего ужасного. А статик — это немного другое.
А насчёт релиза — такие вещи можно потом сделать и не поломать совместимость, вполне логично, что решили отложить. Ведь это просто сахар.
Так-то у них даже нет дефолтных аргументов для функций или функций с переменным количеством аргументов. По моему, это более нужные фичи. Но так релиз можно бесконечно откладывать.
Здравствуйте, DarkEld3r, Вы писали:
C>>Проблема в том, что потом неминуемо придётся отлаживать код, который написали Кумары Брахмабухалсамы после прочтения книги "Современное программирование на Rust++". DE>Я не уверен, что это проблема. Вон в С++ буст пишут, по идее, не индусы, но разбираться там (особенно в некоторых местах) то ещё "удовольствие". Тем не менее, в большинстве случаев, он "просто работает" и в потроха лезть не надо.
Достаточно часто надо было, из-за чего многие и не использовали Буст.
Интересно, а где можно почитать про систему типов в Rust, а то в документации самые интересные главы References and Borrowing, Lifetimes ещё не написаны.
