Жизнь не стоит на месте, и вот в «O'Reilly» задумались об издании первой фундаментальной книги о языке программирования Rust:
Заинтересовавшись этой темой, мы решили вынести на обсуждение перевод обзорной статьи о языке Rust, вышедшей в декабре 2014 года. Статья немного сокращена с учетом того, что некоторые ее отрывки уже устарели, однако автор хорошо рассматривает этот язык в контексте существующих альтернатив, подчеркивает его (безусловные) достоинства и (условные) недостатки.
Впрочем, чтобы было еще интереснее, оставим в комментарии к этой статье ссылку на другую статью о Rust, опубликованную в одном из наших любимых русскоязычных блогов по программированию. Для начала — заходите под кат.
Дисклеймер: Вкус к языкам программирования – дело очень субъективное, как и этот пост. Воспринимайте его со здоровым скептицизмом.
Недавно появилось несколько новых языков программирования. Среди них меня особенно заинтересовал Rust. Ниже я поделюсь моими впечатлениями о Rust и сравню его с несколькими другими языками программирования.
Барьер при изучении Rust
Я познакомился с Rust не с первой попытки. При изучении этого языка существует несколько барьеров, в частности:
- Язык стремительно меняется. В Rust нет «великодушного пожизненного диктатора». Язык развивается благодаря вкладу участников основной команды и сообщества.
- Учитывая первый пункт, учебные материалы по Rust очень скудны. Есть руководство, другая официальная документация и сайт Rust by Example – это отличные ресурсы. Однако Rust гораздо сложнее. Зачастую приходится штудировать RFC, блоги и даже комментарии на Github, чтобы отыскать нужную информацию, причем если даже эта информация появилась буквально вчера, все равно в ней нет полной уверенности. Жду хорошей, авторитетной книги по Rust, хотя, готов поспорить, она будет объемистой.
- Система владения и механизм проверки заимствования в Rust может смутить новичков. Для обеспечения безопасности памяти без сборки мусора в Rust задействуется затейливая система заимствования и владения. Зачастую она отпугивает неофитов.
- Компилятор Rust очень строгий. Я называю Rust дисциплинирующим языком. Все, что не является для компилятора Rust вполне очевидным, вы должны указывать самостоятельно, причем о некоторых своих намерениях вы и сами поначалу не догадываетесь. Этот барьер обучения, вкупе со всеми остальными, зачастую приводит к тому, что первое впечатление от Rust оказывается обескураживающим.
Достоинства
У Rust много достоинств. Некоторые из них уникальны.
Безопасность памяти без сборки мусора
Пожалуй, это наиважнейшее достижение Rust. В низкоуровневых языках программирования, допускающих непосредственную манипуляцию с памятью, такие ошибки, как использование освобожденной памяти (use-after-free) или утечки памяти во время исполнения довольно накладны. В современном языке C++ возможности борьбы с такими вещами улучшились, однако они предполагают строгую техническую дисциплину (читай: программисты продолжают выполнять небезопасные операции). Соответственно, на мой взгляд, в целом С++ не может принципиально и надежно решить эту проблему.
Действительно, Rust-программисты могут писать небезопасный код в блоке unsafe, но (1) это делается осознанно и (2) блоки unsafe могут составлять лишь очень малую долю всей базы кода, при этом они строго контролируются.
Сборщик мусора — самый обычный инструмент, обеспечивающий безопасность памяти. Если вы ладите с GC, то вариантов у вас не мало. Однако система владения, применяемая в Rust, обеспечивает не только безопасность памяти, но и безопасность данных и ресурсов (см. ниже)
RAII и ресурсы
RAII (получение ресурса есть инициализация) — странный термин, но хорошо передает заложенную в нем идею. В Википедии читаем, что RAII работает с объектами, выделяемыми в стеке. Система владения Rust позволяет применять этот принцип и с объектами, выделяемыми в куче. Благодаря этому автоматическое высвобождение ресурсов – например, памяти, файлов, сокетов — становится хорошо предсказуемым и гарантированным во время компиляции.
В динамических языках вроде Python или Ruby есть подобные возможности, но они не сравнятся по мощности с Rust IMO.
Конкурентность без гонок данных
Rust обеспечивает безопасность данных при конкурентном программировании — то есть, гарантирует, что в любой конкретный момент времени обратиться к данным могут лишь множество считывателей или один «записыватель».
Алгебраический тип данных
Кроме обычных типов (кортежи и структуры) в Rust также предоставляются перечислимые типы (здесь они называются «типы-суммы» или «вариантные типы») и сравнение с шаблоном. Удивительно, что у языка для системного программирования такая развитая система типов.
Композиция приоритетнее наследования
В Rust композиция типов явно предпочитается наследованию. Я отношусь к тому лагерю, где этот факт считается выигрышным. При поддержке обобщенных типов в Rust ключевая роль отводится типажам.
Недостатки (условные)
Все должно быть предельно четко
Rust — дисциплинирующий язык. Компилятору необходимо все сообщать предельно четко, либо он будет ругаться, пока не останется никаких невыясненных моментов. Как правило, это идет на пользу качеству кода, но может быть избыточно, если речь идет о быстром прототипировании или одноразовых задачах.
В итоге: приходится писать на Rust более качественный и четкий код. Как только это усвоишь, шероховатости могут более или менее сойти на нет.
Сборка мусора вторична
В Rust есть простейший сборщик мусора: Rc, подсчет ссылок и Arc, атомарный подсчет ссылок без циклического обнаружения. Однако эти возможности не действуют в языке по умолчанию, и вам придется чаще использовать стандартные механизмы управления памятью в Rust (стек, & и Box). Если проблемы с памятью в вашем приложении несущественны, то вам придется потерпеть Rust-овскую модель безопасности памяти, где не применяется сборщик мусора.
Выразительность — не самоцель
Язык Rust не заморачивается о выразительности и красоте кода. В этом отношении он определенно неплох, но не так чудесен, как, возможно, вы бы хотели.
Сравнительно высокий входной барьер
В принципе, Rust — не из тех языков, которые можно быстро освоить и уже через несколько недель писать профессиональный код. Пожалуй, Rust компактнее С++, но определенно больше, чем многие языки программирования. По сравнению с другими языками его не назовешь слишком доступным. Это может оказаться проблемой, если ваш приоритет — скорость освоения языка.
Rust и другие языки
Динамические языки
Динамические (сценарные) языки находятся на противоположном от Rust конце спектра языков программирования. По сравнению с Rust, писать код на динамических языках обычно быстрее и проще. Думаю, динамические языки выигрывают у Rust в таких ситуациях:
- Быстрое прототипирование или одноразовые задачи
- Код не для продакшена, либо такой, где ошибка во время исполнения — небольшая проблема
- Собственный (индивидуальный) проект
- Полуавтоматическая работа (напр. парсинг/анализ логов, пакетная обработка текста)
- Т.д.
В таких случаях не стоит стараться все сделать идеально. Напротив, Rust, на мой взгляд, лучше подойдет для:
- Работы в средней или крупной команде
- Кода, ориентированного на долгосрочное использование в продакшене
- Кода, который будет использоваться долго, предполагает регулярную поддержку и/или рефакторинг
- Код, для обеспечения безопасности которого вы бы написали много модульных тестов
В общем, когда критично качество кода. Динамические языки помогают писать код быстрее на начальном этапе, однако впоследствии работа тормозится: приходится писать больше тестов, нарушается линия разработки или даже возникают перебои при работе в продакшене. Компилятор Rust вынуждает вас делать многие вещи правильно уже во время компиляции, когда не столь накладно выявлять и фиксить баги.
Go
Сравнение двух этих языков – отличный повод поспорить, но, поскольку я некоторое время изучал Go, все-таки поделюсь здесь моими субъективными впечатлениями о нем. По сравнению с Rust, вот что мне нравится в Go:
- легковесность – язык маленький (и простой, при этом очень мощный)
- утилита gofmt – значительно снижает умственную нагрузку при программировании
- goroutine/channel
- Мгновенная компиляция
Почему я завязал с Go:
- Он слишком минималистичен. Система типов и сам язык не слишком расширяемы
- Программирование на Go кажется мне немного сухим. Напоминает дни, когда я программировал на Java: хорошо подходит для корпоративной разработки, механистично и… не так интересно (напоминаю: о вкусах не спорят)
- Популярность Go сохраняется благодаря поддержке Google, но это вызывает у меня некоторый скепсис. Когда интересы сообщества и компании не совпадают, первыми могут пожертвовать. Разумеется, любая компания преследует прежде всего собственные интересы. В этом нет ничего плохого. Это просто… немного раздражает. (Многие языки и фреймворки, продвигаемые корпорациями, сталкиваются с подобной проблемой. Mozilla хотя бы не зависит от биржевых котировок).
Nim
Nim (раньше назывался Nimrod) — очень интересный язык. Он компилируется в C, поэтому производительность у него весьма хорошая. Внешне он напоминает Python — язык, программировать на котором мне всегда нравилось. Это язык со сборкой мусора, однако в нем предоставляется мягкая поддержка в реальном времени, и само поведение сборщика мусора более предсказуемое. В нем интересная система эффектов. В принципе, этот язык мне очень нравится.
Самая большая проблема в его случае — незрелость экосистемы. Сам язык хорошо сработан и относительно стабилен, но в настоящее время этого далеко не достаточно, чтобы язык программирования преуспел. Документация, стандартные библиотеки, репозитории пакетов, поддерживающие фреймворки, участие сообщества и сторонних разработчиков… довести все это до готовности к продакшену нелегко.
Без специалистов, которые бы занимались доработкой языка на фултайме, этот последний этап может быть очень изнурительным. Среди новых языков программирования Nim пока не может похвастаться серьезной поддержкой.
При этом, я желаю ему успеха и по-прежнему слежу за ним.
Прочие
Есть и другие языки вроде Julia и D. Julia — динамический язык с хорошей производительностью и гладкими вызовами в стиле C. (Если вы любите динамические языки и REPL — обратите внимание). Julia привлек всеобщее внимание, благодаря своим числовым и научным полям. Хотя он и может стать языком общего назначения, мне кажется, что на развитие этого языка значительно влияет сообщество его зачинателей.
D, как минимум, изначально, представлял собой попытку создать «C++, только лучше». Его версия 1.0 вышла в 2007 году, поэтому данный язык не такой уж и новый. Это хороший язык, но по объективным причинам он до сих пор не прижился: дело и в расколе на Phobos/Tango на раннем этапе, и в обеспечении безопасности памяти в первую очередь через сборку мусора, и в изначальном позиционировании в качестве замены для C++.
Почему я считаю, что шансы у Rust довольно высоки
В наше время появляется так много новых языков программирования. Чем же, на мой взгляд, среди них выделяется Rust? Приведу следующие доводы:
Настоящий язык для системного программирования
Встраиваемость — нелегкая задача. Пожалуй, она решается буквально на нескольких языках, а то и всего на двух: C и C++. (Возможно, именно поэтому Skylight выбрала Rust для разработки расширения для Ruby, хотя это и было крайне рискованно.) Примечательно, насколько хорошо Rust удалось избавиться от издержек времени исполнения. Это открывает перед Rust уникальные перспективы.
Без Null
Null-объект/указатель (так называемая "ошибка на миллиард долларов") — распространенный источник ошибок времени исполнения. Существует лишь несколько языков программирования, в которых отсутствует null, в основном это функциональные языки. Дело в том, что для избавления от null требуется очень продвинутая система типов. Как правило, чтобы справиться с этим на синтаксическом уровне языка, требуется алгебраический тип данных и сравнение с шаблоном.
Низкоуровневый язык с продвинутыми высокоуровневыми конструкциями
Будучи вплоть до ядра «языком на голом металле» (как минимум, теоретически), Rust также предлагает множество относительно высокоуровневых возможностей, в том числе, алгебраический тип данных, сравнение с шаблоном, типаж, выведение типов и т.д.
Сильное сообщество и практическая востребованность
Сообщество Rust очень дружелюбное и активное. (Разумеется, это субъективное впечатление). Кроме того, Rust использовался в некоторых серьезных практических проектах — речь, в частности, о компиляторе Rust, Servo, Skylight и т.д. еще на этапе разработки языка.
До сих пор — без крупных ошибок
Временами разработка языка или фреймворка, ведущаяся в рамках компании, может случайно зайти в тупик. К счастью, основная команда Rust пока отлично справляется со своими задачами. Так держать, Rust!
Rust для веб-разработки
Если Rust – язык для системного программирования, подойдет ли он для веб-разработки? Я ищу ответ и на этот вопрос.
Библиотеки и фреймворки
В первую очередь, для этого должны быть готовы некоторые HTTP-библиотеки. (Об этом рассказано на сайте «Are we web yet»). Первая библиотека rust-http уже устарела; ее потенциальная наследница Teepee практически в анабиозе. К счастью, Hyper кажется хорошей кандидатурой. Она уже принята в Servo, симбиотическом проекте Rust, я расцениваю это как благословление на роль HTTP-библиотеки для Rust.
Стандартная библиотека Rust пока не поддерживает асинхронный ввод/вывод. Для этой цели можно использовать внешнюю библиотеку mio, обеспечивающую неблокирующий сокетный ввод/вывод. Поддержка зеленых потоков была упразднена в рамках упрощения I/O.
Активно разрабатывается несколько веб-фреймворков для Rust, в их числе — Iron и nickel.rs. Может потребоваться время, прежде чем ситуация с ними уляжется.
Rust – язык для веба?
Когда-нибудь библиотеки и фреймворки будут готовы. Вопрос в том, подходит ли Rust как таковой для веб-разработки? Не слишком ли сложны низкоуровневые возможности Rust, связанные с управлением памятью и обеспечением безопасности?
Думаю, в конечном итоге все зависит от того, чего вы ожидаете от проекта. Выше, сравнивая Rust с динамическими языками в краткосрочных проектах, я упоминал, что в таких случаях сложность Rust может быть неоправданной. Но если вы рассчитываете, что продукт просуществует достаточно долго – скажем, полгода и более — то Rust может быть неплохим вариантом.
Годится ли Rust для веб-стартапов?
Что насчет стартапов? На них требуется быстрое прототипирование и циклы разработки. Это более неоднозначный вопрос, но я остаюсь при своем мнении: если вы рассчитываете на долгосрочный проект, то важно правильно подобрать язык программирования, и Rust заслуживает особого внимания. С точки зрения бизнеса язык, обеспечивающий быстрое прототипирование, дает существенные преимущества, а рефакторинг и устранение узких мест всегда можно оставить на потом. Инженерная реальность такова, что стоимость работ по рефакторингу обычно выше, чем кажется, и даже если вы перетряхнете массу элементов вашей системы, то код, написанный когда-то давно, все равно сохранится в каком-нибудь уголке. На долгие годы.
Попробуйте Rust!
Все-таки, рекомендую познакомиться с Rust. Пока с ним возможны шероховатости, но я уверен, что вскоре они исчезнут.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (43)
EvilsInterrupt
18.09.2015 17:45+41. Меня всегда интересовали электронные версии книг. В них легче искать ответы на возникающие вопросы. Почему нет варианта «Купил бы электронную версию книги»?
2. А чем эта книга лучше этой: doc.rust-lang.org/book?
Yuuri
19.09.2015 11:54Книга по ссылке – скорее сжатый референсный справочник, нежели полноценный учебник. Да, он разбирает практически все языковые фичи, но в стиле «а ещё под нашу музыку можно делать вот так!» и почти не показывает, как ими на практике-то пользоваться, а ведь многие из них очень нетривиальны. Я вот её прочёл и теперь знаю систему заимствования, трейты, макросы и много других страшных слов, но ни реальной одной программы написать с ними не смогу.
EvilsInterrupt
19.09.2015 21:32Что-то я ее нагуглить не могу. Это я плохо гуглю или ее действительно нет в гугле? ;)
Yuuri
20.09.2015 22:24Что, простите? Кого нагуглить? По «rust language book» лично у меня первой выдаётся эта ссылка.
yar3333
18.09.2015 18:56+2Тоже почитал углублённо про Rust и тоже думаю, что это хорошая альтернатива Си. По крайней мере, дух Rust очень близок к Си (в сравнении с Nim и Go), поэтому шанс стать заменой Си у данного языка неплохой.
Xlab
18.09.2015 19:35+1Заменой Си он стать не сможет by design, а вот C++ — вероятно.
Googolplex
18.09.2015 21:13+6Ну полной заменой C стать не сможет ничто, но писать достаточно низкоуровневые программы, в том числе для микроконтролеров, на Rust вполне возможно)
grossws
18.09.2015 21:33В этом плане интересно смотрится zinc.rs. Пока приглядываюсь.
Из моих экспериментов с rust в контексте bare metal arm (на cortex-m3/m4f) есть некоторая боль, связанная с тем, что llvm пока требует ручной работы с соответствующими binutils.
farcaller
19.09.2015 11:35+1Да, кросс-сборка у rust недалеко ушла от C/C++. В этом плане Go смотрится просто в разы лучше.
grossws
19.09.2015 16:49+1Это пока общая проблема llvm, которая на clang проявляется точно также. А как вы представляете написание на go под bare metal? Т. е. не под arm-linux-gnueabi, а под arm-none-eabi?
farcaller
19.09.2015 20:11+1Пишут, на самом деле, там есть возможность работы с минимальным рантаймом, правда тогда и плюшки Go почти все пропадают. Я не нашел оригинальный проект который мне понравился, но вот есть например такое — github.com/tgascoigne/goose.
В контексте кросс-сборки я не имел в виду embedded на самом деле. Я очень пытаюсь использовать rust для общего «devops»-программирования, и Go там пока что смотрится намного лучше, особенно с «разработка на OS X, деплой на Linux». Собрать статический elf на OS X можно имея на руках только тулчейн go. Rust в этом плане сложнее (у меня очень много практического опыта сборки, благо zinc что не неделя то ломается).grossws
19.09.2015 20:51+2Пишут, на самом деле, там есть возможность работы с минимальным рантаймом, правда тогда и плюшки Go почти все пропадают. Я не нашел оригинальный проект который мне понравился, но вот есть например такое — github.com/tgascoigne/goose.
Это PoC, с multiboot bootstrap для x86 на ассемблере. Это чуток не то, что делается в случае использования gcc/clang+llvm/rustc+llvm, т. к. по сути является не кросс-сборкой, а портированием некого куска рантайма на другую платформу (x86 bare metal в данном случае).
И если не портированы, как минимум, управление памятью, зеленые треды/каналы, всякие вещи типа select, то это вообще ни о чём. Это даже не затрагивая всякую работу с файлами, сокетами и т. п. высокоуровневое. Получится недо-С на котором ничего не сделаешь (нет работы с памятью, например).
Если говорить про пример по ссылке, то там не используется даже GC (функция __go_register_gc_roots — no-op).
Rust в этом плане сложнее (у меня очень много практического опыта сборки, благо zinc что не неделя то ломается).
В этом плане сложнее всё, что более-менее близко к native, т. к. native так или иначе содержит платформозависимые куски. С go всё хорошо, пока вы не используете cgo и какие-нибудь платформозависимые библиотеки, там огребёте тех же проблем с кроссплатформенной сборкой.
Про zinc очень хорошо говорит их же readme:Zinc is an experimental attempt to write an ARM stack that would be similar to CMSIS or mbed in capabilities but would show rust's best safety features applied to embedded development.
И ожидать от него какой-либо стабильности сейчас — несколько странно.farcaller
19.09.2015 20:58+2пока вы не используете cgo и какие-нибудь платформозависимые библиотеки
так же как большая часть cargo не применима в zinc, где нет alloc::boxed::HEAP.
И ожидать от него какой-либо стабильности сейчас — несколько странно.
Я — автор этого куска readme, мой комментарий следовало читать не как «не могу использовать zinc в своем проекте», а как «как же удержать его от поломок с nightly rust». И проблем будет еще больше и больше, пока что вот наcore::ops::Placerоблизываюсь.grossws
19.09.2015 21:23так же как большая часть cargo не применима в zinc, где нет alloc::boxed::HEAP
Это вполне ожидаемо. Не думаю, что кто-либо надеялся, что на нём будет, например, работать libstd.
мой комментарий следовало читать не как «не могу использовать zinc в своем проекте», а как «как же удержать его от поломок с nightly rust»
Неправильно вас понял. А с чем связанно использование nightly, а не стабильной 1.2.0? Хочется что-то из bleading edge функций для метапрограммирования?farcaller
19.09.2015 21:29+1Да, там все начинает дружно дохнуть на stable начиная с platform tree и заканчивая кодом в ISR.
splav_asv
18.09.2015 21:53+6А собственно почему? Что в нём такого, что бы ему принципиально не позволило заменить C?
NeoCode
18.09.2015 19:17+16Купил бы, если это будет действительно серьезная книга. С подробнейшим изложением таких вопросов, как техники работы с памятью, все виды умных указателей, всякие «dynamically sized types» и «lifetime specifiers», метапрограммирование и макросы в rust, и т.д. В том числе с описанием алгоритмов работы компилятора в некоторых случаях.
Но ведь не будет… будет обычное введение в язык, которое можно получить и из официальной документации.Googolplex
18.09.2015 21:15+9Кстати, если вас интересуют более глубокие вопросы относительно Rust'а, то вы можете почитать Rustonomicon — ещё одну официальную книгу по Rust. Она пока ещё не закончена, но работы идут.
SerafimArts
18.09.2015 22:35Купил бы однозначно. Новые языки всегда интересны, особенно вокруг которых ажиотаж, пусть даже и заниматься серьёзно не буду (просто негде, сфера иная), да и если даже он очень сырой. Новые подходы и идеи, хотя бы ради саморазвития — это всегда хорошо.
beduin01
19.09.2015 08:05-10Как вы прототипировать на Rust собрались то? Давайте уж на C чистом прототипы писать. Чего уж тут.
> Nim… Самая большая проблема в его случае — незрелость экосистемы
У Rust тоже самое, только синтаксис до кучи еще ломают.
Nim на фоне Rust смотрится каким-то чемпионом победителем. Приятный, простой синтаксис, никаких пустых изгибов и сложных концепций, понятных лишь избранным. Большинство примеров на Nim читаются без знания языка в отличие от того же Rust.
>Кроме того, Rust использовался в некоторых серьезных практических проектах — речь, в частности, о компиляторе Rust, Servo, Skylight
Ага, еще забыли реализацию утилиты ls добавить.
> D… по объективным причинам он до сих пор не прижился: дело и в расколе на Phobos/Tango на раннем этапе, и в обеспечении безопасности памяти в первую очередь через сборку мусора, и в изначальном позиционировании в качестве замены для C++
А у Rust что-то не так? Он себя не как замена С++ позиционирует?
В реальных проектах, а не синтетических тестах, сборщик мусора делают автоматическую оптимизацию (сборку, копирование, уплотнение объектов в памяти), что повышает производительность, а unmanaged код заставляет тоже самое делать вручную, причем в большинстве своем у программистов нет ресурсов/квалификации повторить тоже самое.
WYCOR
19.09.2015 08:22+7Как вы прототипировать на Rust собрались то? Давайте уж на C чистом прототипы писать. Чего уж тут.
В статье же прямо написано — прототипировать лучше на динамических языках.
Ага, еще забыли реализацию утилиты ls добавить.
Либо у меня сломался парсер сарказма, либо Вы не считаете браузерный движок достаточно серьезным проектом? А что же тогда будет достаточно серьезным?
burjui
22.09.2015 16:59Да ладно, каждый школьник же делает домашки по браузерным движкам и компиляторам в свободное от гуляния по ЦЕРНу время.
withkittens
19.09.2015 15:42+3У Rust тоже самое, только синтаксис до кучи еще ломают.
Интересно, сколько ещё времени люди будут вспоминать про ломающийся синтаксис?
Официально ничего не ломается уже 4 месяца (с выхода 1.0). Фактически — на несколько месяцев ещё больше. Синтаксис ломали, когда Rust был в 0.хх версиях. Ну так извините, язык только разрабатывали, изучали, какие фичи выстрелят, какие нет. Имели на то право. А сейчас обратная совместимость внутри мажорных версий (1.хх, 2.хх) — один из столпов языка.
grossws
19.09.2015 16:53+4В реальных проектах, а не синтетических тестах, сборщик мусора делают автоматическую оптимизацию (сборку, копирование, уплотнение объектов в памяти), что повышает производительность, а unmanaged код заставляет тоже самое делать вручную, причем в большинстве своем у программистов нет ресурсов/квалификации повторить тоже самое.
Сколько cpu это сожрёт на контроллере, работающем на 8 MHz?
Сколько памяти из имеющихся, например, 2k SRAM?
А если вообще нет региона под кучу и динамического выделения памяти, то можно ли открутить GC за ненадобностью?
beduin01
19.09.2015 08:43-6>В статье же прямо написано — прототипировать лучше на динамических языках.
Вы это как-то странно написали. По статье складывается впечатление, что вы Rust для прототипирования рекомендуете.
«На них требуется быстрое прототипирование и циклы разработки. Это более неоднозначный вопрос, но я остаюсь при своем мнении: если вы рассчитываете на долгосрочный проект, то важно правильно подобрать язык программирования, и Rust заслуживает особого внимания.
С точки зрения бизнеса язык, обеспечивающий быстрое прототипирование, дает существенные преимущества, а рефакторинг и устранение узких мест всегда можно оставить на потом.»
>А что же тогда будет достаточно серьезным?
Servo в настоящий момент единственный серьезный проект. Еще не факт, что взлетит кстати. Вот когда мы увидим статьи и массовые переходы на Rust тогда уже можно будет что-то говорить.
withkittens
19.09.2015 15:43+3Вот когда мы увидим статьи и массовые переходы на Rust тогда уже можно будет что-то говорить.
Ну вот. Но вы-то начали говорить уже сейчас ;)
Alexeyco
19.09.2015 12:23Кто там упрекал Go-сообщество в отсутствии внятных примеров и наличии кучи субъективных неофитских восторгов. Получите, распишитесь. При этом, фразочки типа «то код [старый], написанный когда-то давно, все равно сохранится в каком-нибудь уголке» и «если вы рассчитываете, что продукт просуществует достаточно долго – скажем, полгода и более» заставляют задуматься — так ли автор хорошо понимает, что полгода для энтерпрайза — это вообще не срок.
А что, хороший код — это код, написанный вчера? И непременно на чем-то новом? Бизнес мыслит издержками и выгодами. Мне, например, как программисту осточертел текущий язык программирования (не буду называть его, чтобы не травмировать никого). Но не весь, а именно его карма. Именно то, с чем я сталкиваюсь. То, что мы поддерживаем, было написано в 2003 году любителем, который очень отдаленно понимал… да вообще все. Он даже не знал о существовании COUNT в SQL, т.к. когда мы заглубились в недра, нашли там буквально все, что можно прочитать на говнокоде.ру. Если смотреть на все это моими глазами — конечно, резать к чертовой матери. Убить и забыть как страшный сон, и переписать все заново на чем-то, подходящем к задачам. Но глазами бизнеса это все видится иначе. Вот чаша весов, вот на ней старый код, который шевелится. Да плевать они хотели на то, что там что-то выполнено неадекватно. Оно работает и ладно. А вот другая чаша весов — изнурительная погоня за тем же самым результатом, потенциально, более вменяемым, но за дополнительные суммы и дополнительное время. В долгосрочной перспективе последнее лучше. Но в краткосрочной… Это вот настоящий случай из энтерпрайза. Какие полгода, я вас умоляю. Если и считать, то перспективы хотя бы лет на 5 вперед.
По поводу какашек в коде. А что, так ли уж нельзя напрудить зловонную лужу в любом, даже самом аккуратном языке? Я вот для своих нужд пару раз писал кое-что на go. Небольшое. Каждый раз, когда я это дописывал, я вносил изменения, делающие, на мой взгляд, код гораздо более расширяемым. И доброжелательным к программисту. То есть, ко мне. Совершенству нет предела. На php можно написать библиотеку, которая будет совершенна в своем роде и своей нише. На rust или go или на чем угодно можно навертеть треша, и участие языка в этом вопросе будет только косвенным. Если на примере go: gofmt не делает из какашки красоту. Она ее просто правильно форматирует. Если прокладка между клавиатурой и стулом заинтересована в том, чтобы написать какашку, она это сделает при любых раскладах.
Однако же я лично отношусь очень спокойно к подобным воодушевленным постам. В конце концов, что плохого, если кто-то попробовал что-то новое и от этого в восторге. Это же супер!
ctrlok
01.10.2015 05:41Если честно, ваш комментарий похож на стокгольмский синдром:)
Для бизнеса выбор технологии тоже достаточно часто важен, так как часто даёт конкурентное преимущество.
potan
19.09.2015 18:01+1Из языков, с которыми стоит сравнивать, можно назвать еще crystal. Близкий по возможностям н nim, но на мой взгляд удобнее и более зрелый.
RAII я считаю скорее недостатком, так как оно мешает выполнять оптимизацию хвостовых вызовов. Используя систему владения, Rust мог бы освобождать ресурсы не дожидаясь конца области видимости. Пришлось бы отказаться от мьютиксов в стиле C++, но в Rust они и не нужны — есть более надежные механизмы: блокировка данных и межпроцессные каналы.
Но книгу куплю при первой возможности :-).
potan
19.09.2015 18:02Из языков, с которыми стоит сравнивать, можно назвать еще crystal. Близкий по возможностям н nim, но на мой взгляд удобнее и более зрелый.
RAII я считаю скорее недостатком, так как оно мешает выполнять оптимизацию хвостовых вызовов. Используя систему владения, Rust мог бы освобождать ресурсы не дожидаясь конца области видимости. Пришлось бы отказаться от мьютиксов в стиле C++, но в Rust они и не нужны — есть более надежные механизмы: блокировка данных и межпроцессные каналы.
Но книгу куплю при первой возможности :-).
phozzy
23.09.2015 09:56Как я понял, Rust можно использовать и для написания ядер ОС. На сколько трудозатратно написать на нем ядро L4? А для полного фарша провести верификацию кода как в SeL4?
burjui
23.09.2015 15:52Ответить на этот вопрос можно, только реализовав идею. Но всем, кто хочет написать на Rust что-нибудь достаточно объёмное, я предлагаю подождать починки borrow checker во избежание порчи впечатлений: github.com/rust-lang/rfcs/pull/1211
Всё-таки, это раздражает, когда компилятор в очевидных случаях не даёт вызвать один метод из другого или сделать match, мотивируя это «занятостью» ссылки. А всё из-за лексических lifetime.
ozkriff
23.09.2015 16:06Сейчас вполне можно жить, просто надо аккуратней с мутабельностью.
burjui
23.09.2015 19:38Жить-то можно, но нужно ли? Я всего лишь хотел потестировать крутые фишки Rust вроде pattern matching, написав то, что уже неоднократно писал на C, C++ и D — парсер (и, возможно, компилятор) игрушечного ЯП. Везде вызов одного метода парсера из другого прекрасно работал, а тут компилятор Rust втирает мне какую-то дичь. Я два часа копался в документации, читал блоги и писал хеллоуворлды, пока не понял, что дурак в данном случае — компилятор, а не я. И после этого я должен посидеть ещё часок и придумать, как его обвести вокруг пальца (не вышло, кстати), при том, то я написал от силы 1/5 часть парсера.
Мне кажется, это просто не стоит потраченного времени, т.к. это проблема компилятора, а не моего кода. Инструмент не доделан, разработчики работают над этим — стало быть, мне незачем пытаться пробить стену головой, если эту стену скоро уберут. Тем более, изучение Rust — это моё хобби, а не работа.ozkriff
29.09.2015 10:40+2Это не «C, C++ и D», это другой язык, тут есть свои особенности. Относительно безопасная работа с памятью без сборки мусора не может быть совсем бесплатной, нужны ограничения. И никого, думаю, не удивит, что на каком-нибудь хаскеле не выйдет написать точно так же, как в плюсах.
Может, все-таки стоит разобраться, а не говорить «у меня не вышло написать как на <подставить язык>, rust явно поломан»? Есть, хотя и небольшое, русскоязычное сообщество, где будут рады помочь новичку.
Работа с памятью уже фатально меняться не будет. Нелексические одалживания, наверное, немного упростят код, но только немного. И я бы не сказал, что работа в этом направлении является какой-то особенно приоритетной для команды — совсем не факт, что это все сделают в ближайшее время.burjui
30.09.2015 11:14Вы приписываете мне свои домыслы:
Может, все-таки стоит разобраться, а не говорить «у меня не вышло написать как на <подставить язык>, rust явно поломан»?
Я такого не утверждал. Вот мои слова:
Инструмент не доделан
Смысл этого высказывания казался мне очевидным в контексте этой нити обсуждения, но, по-видимому, я ошибался. Я писал про компилятор, а не про язык. Это компилятор не может понять, что match Option<T> в ветке None не должен ничего занимать. Язык тут ни при чём, это ограничение компилятора. В этом RFC чётко написано, какие проблемы он решает, среди которых и лексические одалживания. Следовательно, разработчики согласны, что это — проблема, и что её можно решить введением нового временного представления кода (MIR) в компиляторе. Мне не важно какой у этого RFC приоритет, и какие есть способы сделать за компилятор его работу (data flow analysis). Меня никто не заставляет писать код на Rust, так что у меня есть куча времени, пока RFC не реализуют. Когда это сделают, я вернусь к изучению Rust и сэкономлю кучу времени как на изучении языка, так и на изучении библиотек, которые за это время, несомненно, улучшатся, а в исходниках некоторых ещё и не будет костылей, связанных с лексическими одалживаниями, что позволит мне почувствовать дух идиоматического Rust.
Надеюсь, на этот раз я достаточно ясно выразил свои мысли.deko
01.10.2015 17:04Когда это сделают, я вернусь к изучению Rust и сэкономлю кучу времени
Зачем ждать? Почему бы не принять участие в доработке Rust, если знаете как решить проблему? Там точно всегда рады помощникам. По-моему прелесть Rust как раз в серьёзной ориентации на комьюнити, безо всяких там диктаторов, которых периодически нам навязывает корпорация «добра».burjui
02.10.2015 10:47Знать-то знаю — в теории, но не умею. В данный момент я тренируюсь «на кошках»: пишу компилятор игрушечного функционального ЯП (пока в RISC-подобный байт-код). Пока реализовал только целые числа, строки, переменные, функции и одну ровно одну оптимизацию — свёртку и распространение констант (constant folding and propagation). Боюсь, с такими навыками от меня будет больше вреда, чем пользы. Пусть уж лучше пилят эксперты в этой области, а я пока подтяну свои знания математики (алгебры, для начала), ибо с нынешними разрабатывать компиляторы уж больно тяжко.
ph_piter
Первый комментарий: eax.me/kolkhoz-doctrine