Comments 47
Первый комментарий: eax.me/kolkhoz-doctrine
Извините, вот так eax.me/cpp-will-never-die будет точнее
1. Меня всегда интересовали электронные версии книг. В них легче искать ответы на возникающие вопросы. Почему нет варианта «Купил бы электронную версию книги»?
2. А чем эта книга лучше этой: doc.rust-lang.org/book?
2. А чем эта книга лучше этой: doc.rust-lang.org/book?
Книга по ссылке – скорее сжатый референсный справочник, нежели полноценный учебник. Да, он разбирает практически все языковые фичи, но в стиле «а ещё под нашу музыку можно делать вот так!» и почти не показывает, как ими на практике-то пользоваться, а ведь многие из них очень нетривиальны. Я вот её прочёл и теперь знаю систему заимствования, трейты, макросы и много других страшных слов, но ни реальной одной программы написать с ними не смогу.
Тоже почитал углублённо про Rust и тоже думаю, что это хорошая альтернатива Си. По крайней мере, дух Rust очень близок к Си (в сравнении с Nim и Go), поэтому шанс стать заменой Си у данного языка неплохой.
Заменой Си он стать не сможет by design, а вот C++ — вероятно.
Ну полной заменой C стать не сможет ничто, но писать достаточно низкоуровневые программы, в том числе для микроконтролеров, на Rust вполне возможно)
В этом плане интересно смотрится zinc.rs. Пока приглядываюсь.
Из моих экспериментов с rust в контексте bare metal arm (на cortex-m3/m4f) есть некоторая боль, связанная с тем, что llvm пока требует ручной работы с соответствующими binutils.
Из моих экспериментов с rust в контексте bare metal arm (на cortex-m3/m4f) есть некоторая боль, связанная с тем, что llvm пока требует ручной работы с соответствующими binutils.
Да, кросс-сборка у rust недалеко ушла от C/C++. В этом плане Go смотрится просто в разы лучше.
Это пока общая проблема llvm, которая на clang проявляется точно также. А как вы представляете написание на go под bare metal? Т. е. не под arm-linux-gnueabi, а под arm-none-eabi?
Пишут, на самом деле, там есть возможность работы с минимальным рантаймом, правда тогда и плюшки Go почти все пропадают. Я не нашел оригинальный проект который мне понравился, но вот есть например такое — github.com/tgascoigne/goose.
В контексте кросс-сборки я не имел в виду embedded на самом деле. Я очень пытаюсь использовать rust для общего «devops»-программирования, и Go там пока что смотрится намного лучше, особенно с «разработка на OS X, деплой на Linux». Собрать статический elf на OS X можно имея на руках только тулчейн go. Rust в этом плане сложнее (у меня очень много практического опыта сборки, благо zinc что не неделя то ломается).
В контексте кросс-сборки я не имел в виду embedded на самом деле. Я очень пытаюсь использовать rust для общего «devops»-программирования, и Go там пока что смотрится намного лучше, особенно с «разработка на OS X, деплой на Linux». Собрать статический elf на OS X можно имея на руках только тулчейн go. Rust в этом плане сложнее (у меня очень много практического опыта сборки, благо zinc что не неделя то ломается).
Пишут, на самом деле, там есть возможность работы с минимальным рантаймом, правда тогда и плюшки 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.И ожидать от него какой-либо стабильности сейчас — несколько странно.
пока вы не используете cgo и какие-нибудь платформозависимые библиотекитак же как большая часть cargo не применима в zinc, где нет alloc::boxed::HEAP.
И ожидать от него какой-либо стабильности сейчас — несколько странно.Я — автор этого куска readme, мой комментарий следовало читать не как «не могу использовать zinc в своем проекте», а как «как же удержать его от поломок с nightly rust». И проблем будет еще больше и больше, пока что вот на
core::ops::Placer облизываюсь.так же как большая часть cargo не применима в zinc, где нет alloc::boxed::HEAPЭто вполне ожидаемо. Не думаю, что кто-либо надеялся, что на нём будет, например, работать libstd.
мой комментарий следовало читать не как «не могу использовать zinc в своем проекте», а как «как же удержать его от поломок с nightly rust»Неправильно вас понял. А с чем связанно использование nightly, а не стабильной 1.2.0? Хочется что-то из bleading edge функций для метапрограммирования?
А собственно почему? Что в нём такого, что бы ему принципиально не позволило заменить C?
Купил бы, если это будет действительно серьезная книга. С подробнейшим изложением таких вопросов, как техники работы с памятью, все виды умных указателей, всякие «dynamically sized types» и «lifetime specifiers», метапрограммирование и макросы в rust, и т.д. В том числе с описанием алгоритмов работы компилятора в некоторых случаях.
Но ведь не будет… будет обычное введение в язык, которое можно получить и из официальной документации.
Но ведь не будет… будет обычное введение в язык, которое можно получить и из официальной документации.
Кстати, если вас интересуют более глубокие вопросы относительно Rust'а, то вы можете почитать Rustonomicon — ещё одну официальную книгу по Rust. Она пока ещё не закончена, но работы идут.
Ещё можно вот это почитать
ссылка съелась
www.oreilly.com/programming/free/files/why-rust.pdf
www.oreilly.com/programming/free/files/why-rust.pdf
Купил бы однозначно. Новые языки всегда интересны, особенно вокруг которых ажиотаж, пусть даже и заниматься серьёзно не буду (просто негде, сфера иная), да и если даже он очень сырой. Новые подходы и идеи, хотя бы ради саморазвития — это всегда хорошо.
Еще хотелось бы упомянуть книгу (в разработке) для легкой миграции после плюсов.
Как вы прототипировать на Rust собрались то? Давайте уж на C чистом прототипы писать. Чего уж тут.
> Nim… Самая большая проблема в его случае — незрелость экосистемы
У Rust тоже самое, только синтаксис до кучи еще ломают.
Nim на фоне Rust смотрится каким-то чемпионом победителем. Приятный, простой синтаксис, никаких пустых изгибов и сложных концепций, понятных лишь избранным. Большинство примеров на Nim читаются без знания языка в отличие от того же Rust.
>Кроме того, Rust использовался в некоторых серьезных практических проектах — речь, в частности, о компиляторе Rust, Servo, Skylight
Ага, еще забыли реализацию утилиты ls добавить.
> D… по объективным причинам он до сих пор не прижился: дело и в расколе на Phobos/Tango на раннем этапе, и в обеспечении безопасности памяти в первую очередь через сборку мусора, и в изначальном позиционировании в качестве замены для C++
А у Rust что-то не так? Он себя не как замена С++ позиционирует?
В реальных проектах, а не синтетических тестах, сборщик мусора делают автоматическую оптимизацию (сборку, копирование, уплотнение объектов в памяти), что повышает производительность, а unmanaged код заставляет тоже самое делать вручную, причем в большинстве своем у программистов нет ресурсов/квалификации повторить тоже самое.
> Nim… Самая большая проблема в его случае — незрелость экосистемы
У Rust тоже самое, только синтаксис до кучи еще ломают.
Nim на фоне Rust смотрится каким-то чемпионом победителем. Приятный, простой синтаксис, никаких пустых изгибов и сложных концепций, понятных лишь избранным. Большинство примеров на Nim читаются без знания языка в отличие от того же Rust.
>Кроме того, Rust использовался в некоторых серьезных практических проектах — речь, в частности, о компиляторе Rust, Servo, Skylight
Ага, еще забыли реализацию утилиты ls добавить.
> D… по объективным причинам он до сих пор не прижился: дело и в расколе на Phobos/Tango на раннем этапе, и в обеспечении безопасности памяти в первую очередь через сборку мусора, и в изначальном позиционировании в качестве замены для C++
А у Rust что-то не так? Он себя не как замена С++ позиционирует?
В реальных проектах, а не синтетических тестах, сборщик мусора делают автоматическую оптимизацию (сборку, копирование, уплотнение объектов в памяти), что повышает производительность, а unmanaged код заставляет тоже самое делать вручную, причем в большинстве своем у программистов нет ресурсов/квалификации повторить тоже самое.
Как вы прототипировать на Rust собрались то? Давайте уж на C чистом прототипы писать. Чего уж тут.
В статье же прямо написано — прототипировать лучше на динамических языках.
Ага, еще забыли реализацию утилиты ls добавить.
Либо у меня сломался парсер сарказма, либо Вы не считаете браузерный движок достаточно серьезным проектом? А что же тогда будет достаточно серьезным?
У Rust тоже самое, только синтаксис до кучи еще ломают.Интересно, сколько ещё времени люди будут вспоминать про ломающийся синтаксис?
Официально ничего не ломается уже 4 месяца (с выхода 1.0). Фактически — на несколько месяцев ещё больше. Синтаксис ломали, когда Rust был в 0.хх версиях. Ну так извините, язык только разрабатывали, изучали, какие фичи выстрелят, какие нет. Имели на то право. А сейчас обратная совместимость внутри мажорных версий (1.хх, 2.хх) — один из столпов языка.
В реальных проектах, а не синтетических тестах, сборщик мусора делают автоматическую оптимизацию (сборку, копирование, уплотнение объектов в памяти), что повышает производительность, а unmanaged код заставляет тоже самое делать вручную, причем в большинстве своем у программистов нет ресурсов/квалификации повторить тоже самое.Сколько cpu это сожрёт на контроллере, работающем на 8 MHz?
Сколько памяти из имеющихся, например, 2k SRAM?
А если вообще нет региона под кучу и динамического выделения памяти, то можно ли открутить GC за ненадобностью?
>В статье же прямо написано — прототипировать лучше на динамических языках.
Вы это как-то странно написали. По статье складывается впечатление, что вы Rust для прототипирования рекомендуете.
«На них требуется быстрое прототипирование и циклы разработки. Это более неоднозначный вопрос, но я остаюсь при своем мнении: если вы рассчитываете на долгосрочный проект, то важно правильно подобрать язык программирования, и Rust заслуживает особого внимания.
С точки зрения бизнеса язык, обеспечивающий быстрое прототипирование, дает существенные преимущества, а рефакторинг и устранение узких мест всегда можно оставить на потом.»
>А что же тогда будет достаточно серьезным?
Servo в настоящий момент единственный серьезный проект. Еще не факт, что взлетит кстати. Вот когда мы увидим статьи и массовые переходы на Rust тогда уже можно будет что-то говорить.
Вы это как-то странно написали. По статье складывается впечатление, что вы Rust для прототипирования рекомендуете.
«На них требуется быстрое прототипирование и циклы разработки. Это более неоднозначный вопрос, но я остаюсь при своем мнении: если вы рассчитываете на долгосрочный проект, то важно правильно подобрать язык программирования, и Rust заслуживает особого внимания.
С точки зрения бизнеса язык, обеспечивающий быстрое прототипирование, дает существенные преимущества, а рефакторинг и устранение узких мест всегда можно оставить на потом.»
>А что же тогда будет достаточно серьезным?
Servo в настоящий момент единственный серьезный проект. Еще не факт, что взлетит кстати. Вот когда мы увидим статьи и массовые переходы на Rust тогда уже можно будет что-то говорить.
UFO just landed and posted this here
Из языков, с которыми стоит сравнивать, можно назвать еще crystal. Близкий по возможностям н nim, но на мой взгляд удобнее и более зрелый.
RAII я считаю скорее недостатком, так как оно мешает выполнять оптимизацию хвостовых вызовов. Используя систему владения, Rust мог бы освобождать ресурсы не дожидаясь конца области видимости. Пришлось бы отказаться от мьютиксов в стиле C++, но в Rust они и не нужны — есть более надежные механизмы: блокировка данных и межпроцессные каналы.
Но книгу куплю при первой возможности :-).
RAII я считаю скорее недостатком, так как оно мешает выполнять оптимизацию хвостовых вызовов. Используя систему владения, Rust мог бы освобождать ресурсы не дожидаясь конца области видимости. Пришлось бы отказаться от мьютиксов в стиле C++, но в Rust они и не нужны — есть более надежные механизмы: блокировка данных и межпроцессные каналы.
Но книгу куплю при первой возможности :-).
Из языков, с которыми стоит сравнивать, можно назвать еще crystal. Близкий по возможностям н nim, но на мой взгляд удобнее и более зрелый.
RAII я считаю скорее недостатком, так как оно мешает выполнять оптимизацию хвостовых вызовов. Используя систему владения, Rust мог бы освобождать ресурсы не дожидаясь конца области видимости. Пришлось бы отказаться от мьютиксов в стиле C++, но в Rust они и не нужны — есть более надежные механизмы: блокировка данных и межпроцессные каналы.
Но книгу куплю при первой возможности :-).
RAII я считаю скорее недостатком, так как оно мешает выполнять оптимизацию хвостовых вызовов. Используя систему владения, Rust мог бы освобождать ресурсы не дожидаясь конца области видимости. Пришлось бы отказаться от мьютиксов в стиле C++, но в Rust они и не нужны — есть более надежные механизмы: блокировка данных и межпроцессные каналы.
Но книгу куплю при первой возможности :-).
UFO just landed and posted this here
Ответить на этот вопрос можно, только реализовав идею. Но всем, кто хочет написать на Rust что-нибудь достаточно объёмное, я предлагаю подождать починки borrow checker во избежание порчи впечатлений: github.com/rust-lang/rfcs/pull/1211
Всё-таки, это раздражает, когда компилятор в очевидных случаях не даёт вызвать один метод из другого или сделать match, мотивируя это «занятостью» ссылки. А всё из-за лексических lifetime.
Всё-таки, это раздражает, когда компилятор в очевидных случаях не даёт вызвать один метод из другого или сделать match, мотивируя это «занятостью» ссылки. А всё из-за лексических lifetime.
Сейчас вполне можно жить, просто надо аккуратней с мутабельностью.
Жить-то можно, но нужно ли? Я всего лишь хотел потестировать крутые фишки Rust вроде pattern matching, написав то, что уже неоднократно писал на C, C++ и D — парсер (и, возможно, компилятор) игрушечного ЯП. Везде вызов одного метода парсера из другого прекрасно работал, а тут компилятор Rust втирает мне какую-то дичь. Я два часа копался в документации, читал блоги и писал хеллоуворлды, пока не понял, что дурак в данном случае — компилятор, а не я. И после этого я должен посидеть ещё часок и придумать, как его обвести вокруг пальца (не вышло, кстати), при том, то я написал от силы 1/5 часть парсера.
Мне кажется, это просто не стоит потраченного времени, т.к. это проблема компилятора, а не моего кода. Инструмент не доделан, разработчики работают над этим — стало быть, мне незачем пытаться пробить стену головой, если эту стену скоро уберут. Тем более, изучение Rust — это моё хобби, а не работа.
Мне кажется, это просто не стоит потраченного времени, т.к. это проблема компилятора, а не моего кода. Инструмент не доделан, разработчики работают над этим — стало быть, мне незачем пытаться пробить стену головой, если эту стену скоро уберут. Тем более, изучение Rust — это моё хобби, а не работа.
Это не «C, C++ и D», это другой язык, тут есть свои особенности. Относительно безопасная работа с памятью без сборки мусора не может быть совсем бесплатной, нужны ограничения. И никого, думаю, не удивит, что на каком-нибудь хаскеле не выйдет написать точно так же, как в плюсах.
Может, все-таки стоит разобраться, а не говорить «у меня не вышло написать как на <подставить язык>, rust явно поломан»? Есть, хотя и небольшое, русскоязычное сообщество, где будут рады помочь новичку.
Работа с памятью уже фатально меняться не будет. Нелексические одалживания, наверное, немного упростят код, но только немного. И я бы не сказал, что работа в этом направлении является какой-то особенно приоритетной для команды — совсем не факт, что это все сделают в ближайшее время.
Может, все-таки стоит разобраться, а не говорить «у меня не вышло написать как на <подставить язык>, rust явно поломан»? Есть, хотя и небольшое, русскоязычное сообщество, где будут рады помочь новичку.
Работа с памятью уже фатально меняться не будет. Нелексические одалживания, наверное, немного упростят код, но только немного. И я бы не сказал, что работа в этом направлении является какой-то особенно приоритетной для команды — совсем не факт, что это все сделают в ближайшее время.
Вы приписываете мне свои домыслы:
Я такого не утверждал. Вот мои слова:
Смысл этого высказывания казался мне очевидным в контексте этой нити обсуждения, но, по-видимому, я ошибался. Я писал про компилятор, а не про язык. Это компилятор не может понять, что match Option<T> в ветке None не должен ничего занимать. Язык тут ни при чём, это ограничение компилятора. В этом RFC чётко написано, какие проблемы он решает, среди которых и лексические одалживания. Следовательно, разработчики согласны, что это — проблема, и что её можно решить введением нового временного представления кода (MIR) в компиляторе. Мне не важно какой у этого RFC приоритет, и какие есть способы сделать за компилятор его работу (data flow analysis). Меня никто не заставляет писать код на Rust, так что у меня есть куча времени, пока RFC не реализуют. Когда это сделают, я вернусь к изучению Rust и сэкономлю кучу времени как на изучении языка, так и на изучении библиотек, которые за это время, несомненно, улучшатся, а в исходниках некоторых ещё и не будет костылей, связанных с лексическими одалживаниями, что позволит мне почувствовать дух идиоматического Rust.
Надеюсь, на этот раз я достаточно ясно выразил свои мысли.
Может, все-таки стоит разобраться, а не говорить «у меня не вышло написать как на <подставить язык>, rust явно поломан»?
Я такого не утверждал. Вот мои слова:
Инструмент не доделан
Смысл этого высказывания казался мне очевидным в контексте этой нити обсуждения, но, по-видимому, я ошибался. Я писал про компилятор, а не про язык. Это компилятор не может понять, что match Option<T> в ветке None не должен ничего занимать. Язык тут ни при чём, это ограничение компилятора. В этом RFC чётко написано, какие проблемы он решает, среди которых и лексические одалживания. Следовательно, разработчики согласны, что это — проблема, и что её можно решить введением нового временного представления кода (MIR) в компиляторе. Мне не важно какой у этого RFC приоритет, и какие есть способы сделать за компилятор его работу (data flow analysis). Меня никто не заставляет писать код на Rust, так что у меня есть куча времени, пока RFC не реализуют. Когда это сделают, я вернусь к изучению Rust и сэкономлю кучу времени как на изучении языка, так и на изучении библиотек, которые за это время, несомненно, улучшатся, а в исходниках некоторых ещё и не будет костылей, связанных с лексическими одалживаниями, что позволит мне почувствовать дух идиоматического Rust.
Надеюсь, на этот раз я достаточно ясно выразил свои мысли.
Когда это сделают, я вернусь к изучению Rust и сэкономлю кучу времени
Зачем ждать? Почему бы не принять участие в доработке Rust, если знаете как решить проблему? Там точно всегда рады помощникам. По-моему прелесть Rust как раз в серьёзной ориентации на комьюнити, безо всяких там диктаторов, которых периодически нам навязывает корпорация «добра».
Знать-то знаю — в теории, но не умею. В данный момент я тренируюсь «на кошках»: пишу компилятор игрушечного функционального ЯП (пока в RISC-подобный байт-код). Пока реализовал только целые числа, строки, переменные, функции и одну ровно одну оптимизацию — свёртку и распространение констант (constant folding and propagation). Боюсь, с такими навыками от меня будет больше вреда, чем пользы. Пусть уж лучше пилят эксперты в этой области, а я пока подтяну свои знания математики (алгебры, для начала), ибо с нынешними разрабатывать компиляторы уж больно тяжко.
У ржавчины, насколько мне известно, нет четкого стандарта языка. Тут как с перлом — ржавчина это то, что может сомпилировать rustc. :)
Конкретно этот RFC нелексические одалживания сам не добавит, он может косвенно подготовить для них почву, ну да не суть.
Про «сэкономлю кучу времени как на изучении языка» — мы точно об одном и том же говорим? Можно пример кода? А то, судя по моему опыту, проблемы, которые должны решить нелексические одалживания, на данный момент решаются или созданием временной переменной или оборачиванием нескольких строчек кода в `{}` и все.
Конкретно этот RFC нелексические одалживания сам не добавит, он может косвенно подготовить для них почву, ну да не суть.
Про «сэкономлю кучу времени как на изучении языка» — мы точно об одном и том же говорим? Можно пример кода? А то, судя по моему опыту, проблемы, которые должны решить нелексические одалживания, на данный момент решаются или созданием временной переменной или оборачиванием нескольких строчек кода в `{}` и все.
Дело тихонько двинулось, кажется: http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/
Sign up to leave a comment.
Rust, дисциплинирующий язык программирования