Релиз Rust 1.0 Alpha

    С удивлением обнаружил, что это ожидаемое многими событие почему-то обошло Хабр стороной. Думаю, что для многих программистов, следящих за этим языком программирования, будет полезно узнать, что тот самый релиз версии Rust 1.0.0 Alpha состоялся 9 января. В этой версии наконец-то стабилизировали ядро языка и большую часть стандартной библиотеки, так что теперь можно начинать писать на Rust'е программы не боясь, что через неделю что-то сломается после обновления компилятора.

    От себя могу добавить, что язык действительно интересный и, как минимум, стоит внимания.
    Поделиться публикацией
    Ой, у вас баннер убежал!

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

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

                    Скрытый текст
                    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, спросил у него. Сообщу, когда узнаю.
            • 0
              Так а что там с грин тредами?
              • +2
                Кранты им. Вместе с asynchronousе IO. Теперь, как в старом добром си — руками использовать libevent-подобную либу. Как по мне, так это эпичнейший фэйл. Как известно, thread based concurrency is broken.
                • 0
                  По настоящему легковесных потоков в Расте никогда и не было. Те что были требовали стек для каждого потока, так что это было не особо лучше обычных потоков.
                  • 0
                    Были были. Использовали segmentsged stack github.com/aturon/rfcs/blob/remove-runtime/active/0000-remove-runtime.md.

                    В общем, они решили не делать конкурента Go а сделать конкурента С и С++ — без толстых абстракций и рантайма.
                    • +1
                      Легкие потоки — это не аттрибут конкурента go, а аттрибут современного языка. У них была потрясная идея делать два рантайма, и это было по-настоящему круто. Пустой рантайм для системщиков и зеленопоточный с шедулером для прикладников. В общем, я негодую, для меня раст с каждой итераций все менее привлекателен по сути, хоть синтаксис чистят в хорошую сторону.
                      • –2
                        Ну вы почитайте ссылку то, там очень подробно расписано почему приняли такое решение. Но в целом меня такое направление движения тоже несколько расстроило. Я надеялся на «Go с нормальной системой типов».

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

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

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое