Разработчики Rust прошли долгий путь и 15 мая ожидается выпуск первой версии языка с вечеринкой по случаю новорожденного. Лично я долго ждал этого события, хотя и вызывает оно довольно смешанные чувства. Вроде что-то и родилось, но хочу ли я это что-то использовать и стоит ли оно того? Вот в чем вопрос. Дело в том, что в процессе развития Rust претерпел довольно сильные изменения и теперь это далеко не тот же язык, о котором я писал в 2013
Как бы много изменений не претерпел язык, ряд основных заложенный в него концепций так никуда и не делся. Как и любой C/C++ разработчик я постоянно сталкивался с проблемами в области управления памятью и первое что меня привлекло в Rust несколько лет назад была его идея разделения памяти по пулам с контролем за использованием и передачей объектов на этапе компиляции. К счастью данный механизм из Rust никуда не делся, а только несколько заматерел и обрел форму.
Так же нельзя не отметить используемую модель CSP для взаимодействия между Задачами Rust. Решение получилось практичное и удобное в использовании, само собой куда более низкоуровневое если сравнивать с AKKA из Scala, но для языка системного уровня самое оно.
Говорить про синтаксис и синтаксический сахар я, наверное, не буду. Любой новый современный язык программирования включает в себя множество вещей упрощающих жизнь разработчикам, и Rust не стал исключением в данном вопросе.
Отрицательное
Но не обошлось и без ложки дегтя. Дело в том, что разработчики не осилили зеленые потоки и асинхронную сеть. С учетом того, что язык часто преподносился как Erlang, которые еще и компилируетсая, то выглядит это очень грустно. Официальная позиция по зеленым потокам – используемый для их построения libuv слишком медленный из за большого количества преаллокаций памяти. Хотя больше это похоже на то, что релиз выпускать надо (ну не дело же язык 5 лет пилить) и не критические фичи идут под нож.
Кроме того, у меня серьезные сомнения относительно наличия в языке ключевого слова unsafe и шареной памяти как в RO, так и в RW вариантах. С одной стороны причины их появления понятны и логичны “мы строим язык который не уступит C++ в скорости”. С другой стороны, если ты оставляешь лазейки, то вся красивая и логичная модель, защищающая от ошибок идет под откос. Есть возможность обойти и сделать по старинке? Так и сделаем именно этим способом! Зачем разбираться с чем-то новым? Именно так выглядят изрядное количество вопросов посвященных Rust.
И последний пункт – усложнение языка. По моим ощущениям он все больше и больше начинает напоминать C++ с точки зрения синтаксиса. Множество шаблонов и интерфейсов, разлапистые описания типов (особенно при создании объектов не на стеке), множество макросов. Но C++ уже 30 лет как живет и зачем нужен еще один?
Итого
Несмотря на то, что, казалось бы, язык готов к промышленному использованию у меня есть некоторые сомнения в его целесообразности. В своем текущем виде язык не имеет каких-то сколь нибудь серьезных преимуществ перед C++14. Само собой язык будет развиваться и дальше, но с учетом того, что C++17 не за горами, сказать что данная ситуация изменится в будущем тоже не получается.
И, как это не печально, но для меня размышления на тему выбора языка программирования для нового проекта так и не потеряли своей актуальности. Ничего проще и более подходящего для больших и критичных к производительности проектов кроме C++ как не было, так и не ожидается в ближайшем времени.
Для меня зелёные потоки были большим красным минусом. Во-первых они мне в принципе не нравятся. Кривая абстракция. Во-вторых сложный рантайм очень сильно усложняет взаимодействие. Это как использовать Java-метод из C++. Теоретически можно, но практически проще переписать. Сейчас Rust-овская функция это обычная функция, которую можно просто дёрнуть откуда угодно, не заботясь о рантайме, потоках и тд.
Для быстрого асинхронного IO всегда есть родные средства ОС и есть неплохая обёртка mio над ними.
Про усложнение языка я не согласен. Я язык изучал совсем немного (денёк почитал официальную книжку), но при этом сколько ни лазил в стандартную библиотеку — всегда всё понимал. В C++ и Scala, например, у меня это не всегда получалось.
Здравствуйте, vsb, Вы писали:
vsb>Про усложнение языка я не согласен. Я язык изучал совсем немного (денёк почитал официальную книжку), но при этом сколько ни лазил в стандартную библиотеку — всегда всё понимал. В C++ и Scala, например, у меня это не всегда получалось.
Вопрос на засыпку — что делает вот этот макрос: https://github.com/gfx-rs/gfx_macros/blob/master/src/shader_param.rs ?
Со сложностью, в принципе, не всё так плохо. Но вот уход в процедурные макросы ("compiler extensions") и прочие края — это уже верная смерть для языка. А ещё ведь хотят добавить и HKT — вообще полная Скала получится.
Здравствуйте, Cyberax, Вы писали:
vsb>>Про усложнение языка я не согласен. Я язык изучал совсем немного (денёк почитал официальную книжку), но при этом сколько ни лазил в стандартную библиотеку — всегда всё понимал. В C++ и Scala, например, у меня это не всегда получалось. C>Вопрос на засыпку — что делает вот этот макрос: https://github.com/gfx-rs/gfx_macros/blob/master/src/shader_param.rs ?
Не скажу, плагины к компилятору пока не доводилось писать.
А где эти штуки реализованы лучше? Как на C++ такое реализовать?
Ну и в конце концов это библиотека. Хотя и лучше, чтобы она была читаема всем, но по сути достаточно, чтобы авторы и контрибьюторы могли её пониамть, а для пользователей важно, чтобы использовать было просто.
C>Со сложностью, в принципе, не всё так плохо. Но вот уход в процедурные макросы ("compiler extensions") и прочие края — это уже верная смерть для языка.
Не так часто они встречаются по-моему. Простые макросы уж точно не сложнее, чем в C. Сложные — ну не надо их писать. Метапрограммирование опасная штука, но это не значит, что его надо намеренно усложнять.
Тут ещё нормальной IDE не хватает. Взять и развернуть макрос и всё станет понятным, имхо.
C>А ещё ведь хотят добавить и HKT — вообще полная Скала получится.
В этом я нифига не понимаю, но вроде штука полезная же. Хотя я бы предпочёл, чтобы они сконцентрировались на качестве компилятора после релиза, а фичи пусть потихоньку вызревают.
Здравствуйте, vsb, Вы писали:
vsb>Не так часто они встречаются по-моему. Простые макросы уж точно не сложнее, чем в C. Сложные — ну не надо их писать. Метапрограммирование опасная штука, но это не значит, что его надо намеренно усложнять.
Я подчеркнул главное. Сложные – ну не надо писать. unsafe – ну не надо использовать. Шаренная память – ну используйте отправку сообщений вместо. При этом доподлинно известно, что если что-то можно сделать через жопу, то очень многие разработчики выберут именно этот путь. А потом уже будет "теория разбитых окон" в действии. На C++ годами, даже скорее десятилетиями, вырабатывали правильный подход к разработке. А в случае с новым языком, будут сплошной поход по граблям, благо грабли разложены и готовы к работе
Здравствуйте, kaa.python, Вы писали:
KP>Я подчеркнул главное. Сложные – ну не надо писать. unsafe – ну не надо использовать. Шаренная память – ну используйте отправку сообщений вместо.
А если я хочу именно шаренную память — мне Rust поможет?
Здравствуйте, jazzer, Вы писали:
KP>>Я подчеркнул главное. Сложные – ну не надо писать. unsafe – ну не надо использовать. Шаренная память – ну используйте отправку сообщений вместо. J>А если я хочу именно шаренную память — мне Rust поможет?
Вполне, есть примитивы для разного вида блокировок. Внутри они как раз через unsafe и реализованы, но для прикладного кода это не важно, так как интерфейс у них гарантирует безопасное использование. По крайней мере, для стандартной библиотеки.
Здравствуйте, jazzer, Вы писали:
J>А если я хочу именно шаренную память — мне Rust поможет?
Я не совсем понимаю, какой именно помощи ты ожидаешь. В целом, язык хороший, но не сказать что предложит на много больше безопасности в разработке, чем дает тебе C++ в текущем его состоянии. Интересные концепции в языке сохранились, просто модель защиты поехала из за шареной памяти и unsafe.
В итоге, трата времени в его изучение мне не кажется выгодным вложением как минимум на данный момент. Но, опять таки, все зависит от задач.
Здравствуйте, Cyberax, Вы писали:
C>Со сложностью, в принципе, не всё так плохо. Но вот уход в процедурные макросы ("compiler extensions") и прочие края — это уже верная смерть для языка.
Почему смерть? Это ведь не хуже того, что в С++ на шаблонах пишут. Да и никто не заставляет макросы на каждый чих писать.
Впрочем, бегло читать растовые макросы я так и не научился, хотя и делал несколько подходов.
Сайт http://www.rust-lang.org/ встречает нас длинным списком преимуществ данного языка следующего содержания:
zero-cost abstractions
move semantics
guaranteed memory safety
threads without data races
trait-based generics
pattern matching
type inference
minimal runtime
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Ну а если серьезно, то Rust мне напоминает этакого франкенштейна с крайне туманными перспективами. Сдается мне, что Rust окажется этаким новым D. Я не вижу никаких основополагающих принципов, способных сделать из кучки разноплановых фич (по большей части уже в лучшем виде реализованных в других языках) под новым соусом синтаксисом нечто большее. Как C/C++ разработчик, я могу сказать, что наличие в языке встроенных умных указателей меня вовсе не прельщает. Ведь память — это далеко не единственный ресурс, а умные указатели — не единственный способ контроля за памятью. В Rust к тому же все равно придется иметь дело с зоопарком С/С++ библиотек и системных API, о порядке владения сущностями из которых компилятор не будет иметь ни малейшего понятия, а никаких средств для описания такого рода вещей язык не предусматривает.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, kaa.python, Вы писали:
KP>Кроме того, у меня серьезные сомнения относительно наличия в языке ключевого слова unsafe и шареной памяти как в RO, так и в RW вариантах.
Ну шареная память — ладно, но unsafe чем не угодил? Имхо, совсем без этого язык был бы никому не нужен. Ведь даже FFI через unsafe делается и это выглядит вполне логично.
Меня больше другое напрягает. Недавно обнаружили, что в безопасном коде можно потерять вызов деструктора — задействовав Rc и Cell. Неприятно, но мне больше не нравится как они решили это "исправить": функцию forget, которая как раз заставляет не вызывать деструктор и которая была unsafe, хотят объявить безопасной.
Здравствуйте, DarkEld3r, Вы писали:
DE>Ну шареная память — ладно, но unsafe чем не угодил? Имхо, совсем без этого язык был бы никому не нужен. Ведь даже FFI через unsafe делается и это выглядит вполне логично.
Тем же, чем и шареная память – фактом своего существования. Это крайне не безопасная конструкция, которая дается в использование любому желающему. И само собой найдется куча желающий воспользоваться этой конструкцией только для того, что бы написать как привыкли. Благодаря наличию шареной памяти и unsafe Rust мало чем отличается от того-же C++. Rust предоставляет кучу дополнительных возможностей выстрелить себе в ногу в самом неожиданном месте причем проигрывая по скорости С++ в 2-3 раза и заставляя писать столько же кода в общем случае
В итоге выходит, что для использования в критических к скорости исполнения задачах язык еще медленный, а для написания универсального более-менее быстрого кода такой же как C++, только с отличным синтаксисом, который еще учить надо.
Здравствуйте, VTT, Вы писали:
VTT>по большей части уже в лучшем виде реализованных в других языках
Вот только многие из этих языков подходят как замена С++?
VTT>что наличие в языке встроенных умных указателей меня вовсе не прельщает.
Что значит встроенных? Они не больше "встроены", чем в С++ — так же находятся в стандартной библиотеке.
VTT>Ну а если серьезно, то Rust мне напоминает этакого франкенштейна с крайне туманными перспективами.
В С++ многое из этого уже притащили или планируют плюс ещё приходится старое для совместимости тащить, так что "франкенштейн" — это как раз не раст. Новые языки могут позволить себе более аккуратно фичи реализовать, с оглядкой на прошлый опыт. Разумеется, это идёт в комплекте с отсутствием библиотек, готовых инструментов и т.д.
Впрочем, с инструментами у раста не всё так плохо. Скажем, для С++ так и нет и вряд ли будет общая система сборки или "менеджер пакетов". В расте оно идёт из коробки. В С++ такие вещи исторически идут отдельно и их много разных.
Лично мне раст нравится пока что: неплохой синтаксис и удобные возможности вроде паттерн-матчинга. Ну и главная его фича, имхо, borrow checker. Впрочем, активно язык не применял.
Здравствуйте, DarkEld3r, Вы писали:
DE>Лично мне раст нравится пока что: неплохой синтаксис и удобные возможности вроде паттерн-матчинга. Ну и главная его фича, имхо, borrow checker. Впрочем, активно язык не применял.
Главная фича, из тех "что не выкинули". Но благодаря всемогущему unsafe её крайне легко похерить.
KP>Тем же, чем и шареная память – фактом своего существования. Это крайне не безопасная конструкция, которая дается в использование любому желающему. И само собой найдется куча желающий воспользоваться этой конструкцией только для того, что бы написать как привыкли.
А разве есть вообще практические языки без такой возможности? Всегда есть или аналог ансейфа или возможность сишные функции дёргать, что приводит к тому же результату. Но почему-то я не видел жалоб на шарп или джаву, что они ничего не гарантируют раз там можно позвать С код и расстрелять память.
Насчёт "кучи желающих" — мне кажется, что это какая-то страшилка. Говнокод, в том числе опасный, можно писать на любом языке. Ансейв, по моему, как раз удобен тем, что его легче заметить. В том числе, на ревью.
Можно было бы посмотреть проекты хотя бы на гитхабе, но лень, честно говорят. Хотя и интересно насколько такие опасения оправданы. В любом случае, меня больше заботит практическая сторона: с ансейфом можно писать безопасные абстракции, которые язык не предоставляет. Без него оставалось бы только ждать пока это реализуют разработчики языка.
KP>Rust предоставляет кучу дополнительных возможностей выстрелить себе в ногу в самом неожиданном месте
Это с ансейфом или без? Хотелось бы примеры посмотреть. Мне как раз показалось, что без ансейфа таких мест заметно меньше, чем в С++.
Здравствуйте, kaa.python, Вы писали:
KP>Главная фича, из тех "что не выкинули". Но благодаря всемогущему unsafe её крайне легко похерить.
Я тоже давно следил за языком и периодически изменения изначально расстраивали. Но после чтения их аргументации, как правило, соглашался с доводами. Скажем, по зелёным потокам особо не грущу. По моему, язык всё-таки чаще преподносится как "безопасный С/С++" — с этой точки зрения всё правильно сделали.
Здравствуйте, kaa.python, Вы писали:
KP>Rust предоставляет кучу дополнительных возможностей выстрелить себе в ногу в самом неожиданном месте причем проигрывая по скорости С++ в 2-3 раза и заставляя писать столько же кода в общем случае
Эээ... А почему?
Rust должен уметь работать со скоростью примерно равной или превосходящей С++. Это не считая нескольких проблемных вещей типа zeroing drop, которые в следующей версии удалят.
Здравствуйте, 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 ещё не написаны.
Здравствуйте, Aleх, Вы писали:
A>Интересно, а где можно почитать про систему типов в Rust, а то в документации самые интересные главы References and Borrowing, Lifetimes ещё не написаны.
Актуального описания я не видел, тут нужно код смотреть. Но проще всего почитать заметки Niko Matsakis, он вроде как главный архитектор/идейный вдохновитель системы типов в Rust. Например вот эту, эту и вот эту.
Здравствуйте, Aleх, Вы писали:
A>Интересно, а где можно почитать про систему типов в Rust, а то в документации самые интересные главы References and Borrowing, Lifetimes ещё не написаны.
Прямо сейчас по ссылке вполне себе есть текст. Или подразумевается, что там мало информации?
Помимо предложенных ссылок, можно посмотреть "бета-версию" книги — там информация вполне актуальная, в новом мануале просто расширили и иначе структурировали. Есть ещё книга "Rust by example" — её пишет комьюнити.
Ну и блог можно посмотреть. Например, статья про многопоточность, но там как раз рассказывается как с этим семантика владения помогает.
Здравствуйте, DarkEld3r, Вы писали: DE>Прямо сейчас по ссылке вполне себе есть текст. Или подразумевается, что там мало информации?
Когда писался пост, текста не было.
Здравствуйте, kaa.python, Вы писали:
KP>Но не обошлось и без ложки дегтя. Дело в том, что разработчики не осилили зеленые потоки и асинхронную сеть.
Без зеленых потоков при наличии качественного fork/join фреймворка вполне можно обойтись. А вот отсутствие асинхронного IO по нынешним временам — почти приговор.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Без зеленых потоков при наличии качественного fork/join фреймворка вполне можно обойтись. А вот отсутствие асинхронного IO по нынешним временам — почти приговор.
"Всё что мы не успели стабилизировать до 1.0 ушло под нож". Правда есть mio, который на данный момент UNIX-only, но поддержку Windows обещают, хотя для языка уровня Rust это вообще не критичное требование.
AVK>А вот отсутствие асинхронного IO по нынешним временам — почти приговор.
Оно на уровне языка должно быть штоле?
IMO, один из лучших асинхронных библиотечных интерфейсов что я видел на данный момент имеется в libmicrohttpd. Там пользователь должен передавать библиотеке callback, который вызвается при accept-е нового клиента, клиент должен реализовывать конечный автомат и правильно реагировать на вызовы этого callback-а (он может быть вызван много раз для одного и того же клиента, например когда пришли post данные и потом для того, чтобы получить response). Это все выглядит страшно (callback-с десятком параметров, AFAIR), но зато позволяет прозрачно переключаться между синхронным и асинхронным режимами работы сервера. А всякие асинхронные языковые расширения (вроде async в C#) такой роскоши не позволяют, библиотеки вроде boost.asio — тоже, там ты либо используешь callback лапшу и одни ф-ии, либо пишешь синхронный код с другими ф-ями. В общем, все правильно делают чуваки, IMO.
DE>Ну шареная память — ладно, но unsafe чем не угодил? Имхо, совсем без этого язык был бы никому не нужен. Ведь даже FFI через unsafe делается и это выглядит вполне логично.
AFAIK unsafe неугодил тем, что в расте его нужно вызывать неоправданно часто, для того, чтобы обходить ограничения накладываемые системой типов, например intrusive структуры данных сложно без unsafe сделать на нем, могу ошибаться насчет этого, если не прав — поправьте.
Здравствуйте, ELazin, Вы писали:
EL>например intrusive структуры данных сложно без unsafe сделать на нем, могу ошибаться насчет этого, если не прав — поправьте.
Да, это так. Но иначе и не получилось бы предоставить имеющиеся гарантии для безопасного кода. Ну а структуры данных можно написать один раз и предоставить к ним безопасный интерфейс.
Здравствуйте, kaa.python, Вы писали:
KP>"Всё что мы не успели стабилизировать до 1.0 ушло под нож". Правда есть mio, который на данный момент UNIX-only, но поддержку Windows обещают, хотя для языка уровня Rust это вообще не критичное требование.
По отзывам у людей вообще много проблем под Windows. Некоторые мол даже hello world не смогли скомпилировать. У меня под рукой нет Windows, просто интересно, как там обстоят дела с поддержкой Windows платформы?
Здравствуйте, DemonsInside, Вы писали:
DI>По отзывам у людей вообще много проблем под Windows. Некоторые мол даже hello world не смогли скомпилировать. У меня под рукой нет Windows, просто интересно, как там обстоят дела с поддержкой Windows платформы?
У меня на Win 8.1 hello world собирается без проблем, причем даже не удивление быстро — за полсекунды. А вот какую-то программку, использующую помимо стандартной библиотеки пару-тройку крейтов с crates.io, собрать уже не получилось, ибо они потянули какие-то сишные зависимости, для их сборки нужен был gcc для 64 бит, а его в моем mingw не оказалось. Т.е. одного инсталлятора с rust-lang (и еще одного с LLVM) явно недостаточно для полноценной работы, нужно еще немного повозиться с настройкой окружения для сборки сишных запчастей.
Здравствуйте, DemonsInside, Вы писали:
DI>По отзывам у людей вообще много проблем под Windows. Некоторые мол даже hello world не смогли скомпилировать.
Ну это скорей всего от того, что они IDE не наши в комплекте. Типичный виндузятник от такого в ступор впадает же
Здравствуйте, ELazin, Вы писали:
AVK>>А вот отсутствие асинхронного IO по нынешним временам — почти приговор. EL>Оно на уровне языка должно быть штоле?
На уровне языка должна быть удобная асинхронность, а не борьба с ней при помощи этажерки из объектов или лямбд.
EL>Там пользователь должен передавать библиотеке callback, который вызвается при accept-е нового клиента,
Они чуть менее чем все такие.
EL> клиент должен реализовывать конечный автомат и правильно реагировать на вызовы этого callback-а
Вот вот, о том и речь.
EL>А всякие асинхронные языковые расширения (вроде async в C#) такой роскоши не позволяют
Конкретно async в C# (а точнее не async, а TPL, async просто лапшу из кода убирает) это позволяет штатными средствами. Меняешь контекст на синхронный и вперед. Если, конечно, явно не скажешь, что тебе надо в отдельном потоке.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Iso12, Вы писали:
I>Microsoft планирует поддержку языка Rust в Visual Studio. I>Подробноcти можно почитать здесь.
По ссылке много бреда, похоже это просто сторонний плагин, а автор почему-то заявляет, что делает майкрософт. А я уже успел удивиться и обрадоваться.
Здравствуйте, DarkEld3r, Вы писали:
DE>Здравствуйте, kaa.python, Вы писали:
KP>>Главная фича, из тех "что не выкинули". Но благодаря всемогущему unsafe её крайне легко похерить. DE>Я тоже давно следил за языком и периодически изменения изначально расстраивали. Но после чтения их аргументации, как правило, соглашался с доводами. Скажем, по зелёным потокам особо не грущу. По моему, язык всё-таки чаще преподносится как "безопасный С/С++" — с этой точки зрения всё правильно сделали.
Здравствуйте, omgOnoz, Вы писали:
O>Может тогда лучше С#?
Что значит "тогда"? Я в расте не разочаровывался, наоборот кажется, что он идёт в правильном направлении — развивая, в том числе, всякие низкоуровневые вещи.
С# — это совсем другое.
Статью удалили, скорее не договорились или был просто "пустой выхлоп".
Поэтому я просто выложу здесь линки (этот и этот), где можно скачать расширение VS для Rust.
Visual Studio extension for Rust :
1)Поддержка проекта
2)Поддержка синтакса
3)Интегрирование компилятора
Здравствуйте, DemonsInside, Вы писали:
DI>По отзывам у людей вообще много проблем под Windows. Некоторые мол даже hello world не смогли скомпилировать. У меня под рукой нет Windows, просто интересно, как там обстоят дела с поддержкой Windows платформы?
Есть под Windows кое-какие проблемы, но жить можно, особенно с Rust-msvc-х64. Я, вот, обертку над DX12 сделал. dx12_integration_test
