Обновить
Комментарии 40
Ну вот, зря переводил…
Всех с альфа-версией, ждём final.
А чего вы переводили? Публикуйте, все интересно:)
Ту же новость по ссылке. Думаю, дублирующий пост ни к чему. Да и перевод ещё не вычитывал, там есть термины, которых на русском не встречал.
И в подсистеме path: github.com/rust-lang/rfcs/pull/474, и разные другие мелочи. Словом — нет, 100% гарантии стабильности никто не даёт. Поломки будут, хоть и в меньшем количестве.
Поэтому я и написал, что стабилизировали бОльшую часть стандартной библиотеки, а не всю. В любом случае, можно смело использовать компоненты помеченные как «stable», а это теперь подавляющее большинство компонент.
Фраза «релиз версии Rust 1.0.0 состоялся 9 января» вводит заблуждение, это всего лишь альфа версия. Поэтому полной стабильности еще нет.
Стоит отметить, что Rust, который изначально был сделан с уклоном в функциональщину, зелёные потоки и асинхронное IO под капотом, теперь окончательно оформляется в C++ с современной системой типов.
Возможно это и хорошо, т.к. в функциональные языки он ничего особо нового не привнёс бы, а для C давно уже есть необходимость в современных альтернативах.
Так и есть, примерно об этом был мой недавний комментарий:
В то же время, раст выглядит очень привлекательным именно за счет того, за что его ругают функциональщики — если на первых порах он был скорее больше похож на «ML с плюсами», то сейчас всё чаще говорят о «C++ done the right way». Спорить с этим тяжело, ибо история показывает, что императивно-ориентированный синтаксис — очень сильный буст к популярности. (Тут уместно вспомнить ремарки о чутье Гвидо по поводу того, как должен выглядеть питон.)
А где ругающие его функциональщики водятся? Мои знакомые как-то наоборот :)
Мне в C++ не хватает из «функциональщины» pattern matching, поощерения иммутабельности и необезательности return. Все это в Rust есть.
Может пора уже начинать переводить intro к Rust и важные статьи: ownership, lifetimes, вот это все?
Хорошая идея. Попробую узнать у разработчиков, каким образом это лучше делать, возможно они уже предусмотрели переводы.

Статьи по ownership, lifetimes (guides) сейчас объединили в одну The Book (по ссылке упоминается), там один человек усердно пилит документацию. Отписал ему насчёт перевода.
Держите в курсе на счёт перевода, помогу если будет нужна помощь
Да, конечно.
Вот ответ Стива:

Скрытый текст
steveklabnik1[F] sent 1 hour ago

Hey hey!

We want translated docs, but I'm not sure it's time yet. There's still so much to write in English, and things are still changing a bit. I'd want to wait until at least beta, I'd imagine. We don't have any of the build stuff set up yet for i18n either :/

But I also don't want to stop you! Let's talk about it on Discuss so that others can weigh in too, does that sound good?

Не знаю, что такое Discuss, спросил у него. Сообщу, когда узнаю.
Спасибо. С движком я угадал :)
Так а что там с грин тредами?
Кранты им. Вместе с asynchronousе IO. Теперь, как в старом добром си — руками использовать libevent-подобную либу. Как по мне, так это эпичнейший фэйл. Как известно, thread based concurrency is broken.
По настоящему легковесных потоков в Расте никогда и не было. Те что были требовали стек для каждого потока, так что это было не особо лучше обычных потоков.
Легкие потоки — это не аттрибут конкурента go, а аттрибут современного языка. У них была потрясная идея делать два рантайма, и это было по-настоящему круто. Пустой рантайм для системщиков и зеленопоточный с шедулером для прикладников. В общем, я негодую, для меня раст с каждой итераций все менее привлекателен по сути, хоть синтаксис чистят в хорошую сторону.
Ну вы почитайте ссылку то, там очень подробно расписано почему приняли такое решение. Но в целом меня такое направление движения тоже несколько расстроило. Я надеялся на «Go с нормальной системой типов».

А какие ещё современные императивные языки, кроме Go, имеют хорошую поддержку зелёных потоков?
Видимо, все динамические, в них можно встроить любой рантайм, как в ноде.
Ну и мое любимое — хаскелл!
Специально уточнил про «императивные».

Вы всё-же приведите конкретный пример императивного языка с хорошей, использующейся на практике, поддержкой зелёных тредов. Желательно, умеющих самостоятельно расползаться по ядрам CPU.
Erlang? Он более или менее императивный.
Как full-time erlang программист, готов утверждать, что нет. Не императивный.
Это смотря с чем сравнивать =)
Но я не специалист, конечно, на эрланге дальше хелловорлда недалеко ходил.
А так ли уж необходима поддержка зелёных потоков прямо из коробки, если ради этого придётся городить массивный рантайм? Почему бы не переложить эту задачу на сторонние библиотеки, благо язык очень мощный и позволяет при желании реализовывать практически всё, что вам в голову взбредёт если не либами, то плагинами точно.
Почитал про segmented stack, и правда были довольно легковесные потоки, потом их сделали менее легковесными, а потом удалили.
В GHC тоже отдельный стек для грин гредов, однако тут его еще никто не победил.
Альфа или нет, но язык ещё очень сырой. Вчера, например, столкнулся с отсутствием impl specialization.
А разве заявляли что он будет?
Вещь, конечно, полезная, но стабилизация синтаксиса и семантики сейчас важнее.
То, как они переделали интерфейсы для числовых типов мне не понравилось. Возвращаемое значение операции переехало из параметра шаблона трейта в ассоциированный тип. Теперь я не понимаю, как сделать, например, разные операции для умножения однобайтовых чисел — с получением однобайтового или двухдайтового числа. Или наложить ограничение на возвращаемый тип (в своей библиотеке мне потребовалось что-бы результат mul поддерживал Add, и я не смог этого добиться — заменил все на Float).
Хотя в другом проекте ассоциированные типы мне очень пригодятся.
Но событие действительно очень важное. В системном программировании за этим языком будующее — начинать на него переходить надо уже сейчас.
Даже финальная первая версия ожидается не так, как та, в которой, всё-таки, появится нормальная обработка ошибок.
Знать бы какая это будет версия… (
А чем не подходит текущий подход к обработке ошибок? Или вам эксепшены надо?
Полагаю что именно это и имелось в виду, хотя по мне так обработка ошибок в Rust — одна из лучших из императивных языков. В отличие от исключений, ошибки в расте практически невозможно забыть обработать и я считаю, что это замечательно. Вообще никогда не понимал чем так хороши исключения — низкой скоростью и высокой степенью опасности?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.