LINUX.ORG.RU

Вышел Rust 1.0

 , ,


12

10

15 мая 2015 года, в соответствии с планом, вышел публичный релиз Rust 1.0 - языка программирования общего назначения, разрабатываемого Mozilla совместно с сообществом. Язык ориентирован на разработку безопасных и эффективных приложений, имеет развитую систему типов, оптимизирующий кодогенератор на основе llvm и предоставляет расширенные гарантии потокобезопасности и безопасного доступа к памяти без использования сборщика мусора. В частности, Mozilla использует Rust для разработки браузерного движка следующего поколения servo.

Выход релиза 1.0 означает стабилизацию языка и стандартной библиотеки, их дальнейшее развитие будет происходить с сохранением обратной совместимости. В то же время, выход релиза не означает остановки развития языка - одновременно с релизом 1.0 разработчики выпустили бета-версию Rust 1.1, и в дальнейшем планируют выпускать новую версию каждые 6 недель. Среди ожидаемых изменений - заметное уменьшение времени компиляции и дальнейшее расширение стандартной библиотеки.

Перед релизом сообществом была проделана большая работа по обновлению пакетов в официальном репозитории crates.io , где подавляющее большинство из 2000 пакетов приведены в соответствие с версией 1.0. Онлайн-компилятор play.rust-lang.org претерпел редизайн и теперь позволяет выбирать между версиями компилятора. Менеджер пакетов и система сборки cargo так же получил ряд улучшений. Большинство популярных редакторов уже имеют полноценную поддержку языка, с подсветкой ошибок и автодополнением на основе racer, дополнительно вчера вышел Visual Rust 0.1 - расширение для поддержки Rust в Visual Studio. Официальная документация (The Book, The Rust Reference, Rust By Example и документация стандартной библиотеки) была приведена в соответствие со стабильным релизом, сегодня же стала доступна для предзаказа книга Programming Rust издательства O'Reilly, выход которой ожидается в ноябре 2015 года.

Некоторые изменения со времени альфа-версии, вышедшей в феврале:

Официальный сайт: http://rust-lang.org/.

Примечания к релизу: https://github.com/rust-lang/rust/blob/master/RELEASES.md.

Ссылка на скачивание: http://www.rust-lang.org/install.html.

Официальная документация: http://doc.rust-lang.org/stable/.

>>> Подробности



Проверено: maxcom ()
Ответ на: комментарий от anonymous

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

А зачем тебе двусвязный список? Это одна из самых худших структур данных по всем параметрам, которую только можно придумать. Лучше используй вектор.

Legioner ★★★★★ ()
Ответ на: комментарий от anonymous

Во-первых, цель такого компилятора только в том, чтобы превратить сложный синтаксис C++ в более простой. Не меняя очень мощной семантики плюсов.

В каком месте у плюсов сложный синтаксис? Как его можно упростить?

Во-вторых, для нового языка очень важно иметь хорошую совместимость с чем-то уже популярным, поэтому «новый C++» должен быть совместим с существующим чуть ли не на уровне исходников.

Ну назови мне хоть один популярный язык, который на старте был совместим с чем-то популярным.

ya-betmen ★★★★★ ()
Ответ на: комментарий от ya-betmen

В каком месте у плюсов сложный синтаксис?

Я не считаю, что у плюсов сложный синтаксис, но моя исходная идея компилятора C++ с более простым синтаксисом появилась в результате моих размышлений на тему, как упростить синтаксис, оставив совместимость под давлением нытья, что у C++ сложный синтаксис. Я решил, что это никому не нужно, т.к. никто толком даже не попытался это сделать.

Ну назови мне хоть один популярный язык, который на старте был совместим с чем-то популярным.

C++

anonymous ()
Ответ на: комментарий от Legioner

А зачем тебе двусвязный список? Это одна из самых худших структур данных по всем параметрам, которую только можно придумать.

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

Лучше используй вектор.

Тогда уж Deque, он по всем параметрам лучше либо не хуже чем вектор (да и перемещение элементов при расширении/сжатии делать не нужно), кроме совместимости с сишным char* по расположению данных в памяти. Ой, тоже нельзя, Он тоже может быть через список реализован...

anonymous ()
Ответ на: комментарий от anonymous

C++

Угу, а теперь ещё один и сравни с числом популярных языков без подобной совместимости.

ya-betmen ★★★★★ ()
Ответ на: комментарий от ya-betmen

Угу, а теперь ещё один и сравни с числом популярных языков без подобной совместимости.

Теперь твоя очередь перечислить популярные языки с указанием даты их появления, времени затраченного на их раскрутку, кто этим занимался (стоял за раскруткой языка) и сколько других ресурсов на это было потрачено.

anonymous ()
Ответ на: комментарий от anonymous

Теперь твоя очередь перечислить популярные языки с указанием даты их появления, времени затраченного на их раскрутку, кто этим занимался (стоял за раскруткой языка) и сколько других ресурсов на это было потрачено.

Нет, тем более что это ничего не говорит о влиянии совместимости на популярность языка ибо популярным становится чаще всего язык закрывающий определённую пустующую нишу. А вот его дизайн, синтаксис и прочее совершенно неважно.

ya-betmen ★★★★★ ()
Ответ на: комментарий от ya-betmen

Ну назови мне хоть один популярный язык, который на старте был совместим с чем-то популярным.

с++

anonymous ()

Я мельком посмотрел, и у меня сложилось впечатление, что у этого убийцы C++ FFI из разряда «тебе же не в лом переписать все хедеры».

Я ошибаюсь, или таки надо переписывать?

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от vasily_pupkin

меня сложилось впечатление, что у этого убийцы C++ FFI из разряда «тебе же не в лом переписать все хедеры».

Да. А где FFI сделан по-другому?

tailgunner ★★★★★ ()
Ответ на: комментарий от vasily_pupkin

А где FFI сделан по-другому?

В C++ :]

Си++ - это надмножество Си89, так что там просто нет Cи FFI.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Не хочу спорить по таким вопросам.

Просто печально, что людям не лень написать такой большой компилятор, и лень запилить такую маленькую полезную фичу.

vasily_pupkin ★★★★★ ()
Ответ на: комментарий от vasily_pupkin

Просто печально, что людям не лень написать такой большой компилятор, и лень запилить такую маленькую полезную фичу.

Какую «такую» - поддержку препроцессора и синтаксиса Си для объявления функций и данных? Да уж, «маленькая фича».

Генератор биндингов - вполне нормальный подход.

tailgunner ★★★★★ ()
Ответ на: комментарий от Legioner

А зачем тебе двусвязный список? Это одна из самых худших структур данных по всем параметрам, которую только можно придумать. Лучше используй вектор.

Тем не менее иногда эта структура бывает очень полезна. Кроме того, rust позиционируется как язык для системного программирования, а в системном программировании двусвязанные списки используются чаще: https://github.com/torvalds/linux/blob/master/include/linux/list.h

m0rph ★★★★★ ()
Последнее исправление: m0rph (всего исправлений: 1)
Ответ на: комментарий от m0rph

Реализация двусвязных списков — лишь малая часть всего кода, не вижу проблемы использовать unsafe в реализации и выставить безопасный интерфейс наружу.
А вообще, в стандартной библиотеке же есть уже двусвязный список, незачем пилить велосипеды.

quantum-troll ★★★★★ ()
Ответ на: комментарий от anonymous

Вот плюсисты доморощенные и занимаются только тем, что «выжимают из железа всё» (пепси). :-)

anonymous ()
Ответ на: комментарий от nonimous

Дорогой нонимоус. Не надо сравнивать свой потенциал с потенциалом Гугла. (В части бабла, в первую очередь.) Это раз. А два — одно дело /переписать/ //работающую// систему на C++ или на C с высокоуровневого языка, где программа приняла свой понятный облик, а другое дело зарабатывать геморрой и нервный срыв, ваяя на C++ с самого начала. :-) И я могу понять, когда разработкой занят 1 супер-гениальный и супер-опытный программер, который уже закалён кознями убогого языка с паршивой семантикой, который уже написал кучу этих ваших идиотских фабрик и визиторов, и вот он, будучи 1, имея 1 голову, в которой и будет держать весь свой новый просджект на Цепепе, вот он имеет шанс что-то напЕсать. В командной же разработке всё иначе - люди разной квалификации, разной продуктивности, разной психики, в конце концов, и вот когда эти люди пишут на Цепепе с самого начала, без прототипа, тогда это уже признак сомнительного джедайства, который оканчивается, скорее всего фейлом :-) :-) (терминирующие смайлики).

anonymous ()
Ответ на: комментарий от anonymous

Командная разработка без тимлида - это какой-то особый вид онанизма с элементами мазохизма. Проектированием общей архитектуры должен заниматься один человек, так же как и иметь решающий голос в различных спорных ситуациях. Если в команде есть люди с маленьким опытом уворачивания от граблей, так и вред от их действий будет минимальным, т.к. они не смогут нагадить вне пределов своей зоны ответственности.

m0rph ★★★★★ ()
Ответ на: комментарий от m0rph

Кстати, если я всё правильно понял, то проблема с двусвязным списком в Rust в следующем.

Списком подразумевается, что управляющими блоками владеет весь контейнер (посредством обязательства вручную освобождать блок, когда все его элементы удаляются из списка), а не левый или правый сосед блока (посредством scoped-ссылки на него, которая при смерти автоматом освобождает объект, на который ссылается).

В Rust в принципе нет понятия ручного освобождения объектов (да?), поэтому для выражения идеи списка приходится или добавлять счётчики ссылок в управляющие блоки, или прибегать к различным способам наеобмануть язык через unsafe, чтобы организовать косвенное ручное освобождение в нужный момент.

Однако, пользователя списка это не касается, для него всё безопасно. Не думаю, что это такая уж и проблема. У той же сишечки тоже полно таких неявных контрактов.

«Нормальным» решением (без «тормозящих» счётчиков ссылок и «небезопасного» ручного удаления) по идее будет только статически-выводимый аналог shared_ptr, что вообще может оказаться невычислимой задачей (а значит, не безопасной). Проблема актуальна, по идее, не только для списка, но и для любой другой структуры данных, где контейнер не имеет ссылок на все управляющие блоки (не знаю, является ли это определением связного списка).

Всё правильно понял?

ilammy ★★★ ()
Ответ на: комментарий от anonymous

Как раз таки семантика C++ - это ужас из ужасов из ужасов. И как раз этот ужасный ужас и является причиной того, что для Цепепе нет ни одной IDE с возможностью качественного рефакторинга, что, учитывая ООП по Страуструпу, где сначала надо думать о классах и об их общости, вместо того, чтобы сначала думать об алгоритмах, является центральной и необходимой функцией IDE для Цепепе. Но, увы, твой любимый Цепепе награждён ужасом-семантикой :-)

anonymous ()
Ответ на: комментарий от m0rph

Ага, и этот «тимлид» (хотя бы он) и должен использовать кроме Цепепе более абстрактные языки, чем Цепепе. Иначе это не тимлид, а дугачок :-)

anonymous ()
Ответ на: комментарий от ilammy

Я не настолько хорошо разбираюсь в расте на текущий момент, чтобы сказать, правильно ли ты все понимаешь, но как по мне, так похоже на правду. И это действительно не проблема - некоторые вещи без обмазывания unsafe'ом нормально не сделать, но эта магия все равно будет скрыта от конечного пользователя, ему использовать unsafe будет необязательно.

m0rph ★★★★★ ()
Ответ на: комментарий от anonymous

Всем нормальным людям наплевать на синтаксис. Внешний облик волнует только безмозглых. Важно содержание - семантика.

anonymous ()
Ответ на: комментарий от tailgunner

Ложь. C++ - надмножество C11. Ты немного устарел. :-)

anonymous ()
Ответ на: комментарий от ilammy

В Rust в принципе нет понятия ручного освобождения объектов (да?),

Нет, есть. https://doc.rust-lang.org/std/mem/fn.drop.html
Суть проблемы куда проще:
* Может существовать только одна владеющая ссылка
* Заимствующие ссылки должны всегда быть корректны, и это проверяется на этапе компиляции
В двусвязного списка две ссылки. Одна из них может быть владеющей, а вот с другой и начинаются проблемы.

quantum-troll ★★★★★ ()
Ответ на: комментарий от ilammy

Вы немного не правильно поняли суть проблемы, проблема не в том как сделать двусвязный список, проблема в философии самого языка. Язык позиционируется как безопасным (по крайней мере по работе с памятью) - но при этом в нем есть костыль в виде «unsafe», и как оказывается без этого костыля нельзя построить такую простую структуру как двусвязный список (а также зацыкленный список, все возможные linked map, B+ деревья и вообще есть глобальная проблема иметь два долгоживущих указателя на один объект). В результате есть опасность что штатный набор фич раста не достаточный для многих задач, как результат народ будет тыкать unsafe на каждом шагу - в результате получим тотже С/С++ но с другим синтаксисом ....

Мне например нравилось его решение со сборщиком мусора (он там был в ранних альфа, но потом его выпилили вместе с механизмом подсщета ссылок и запилили лайф таймы которые полностью ломают читабельность кода), я так и не понял зачем это сделали - мне идея весьма понравилась с 3 типами указателей, в принципе GC можно было и убрать но первоночальное боксирование мне нравилось гараздо больше.

zaz ★★★★ ()
Ответ на: комментарий от anonymous

Любому разработчику в принципе полезно знать и применять несколько языков для разных целей, не ограничиваясь каким-то одним.

m0rph ★★★★★ ()
Ответ на: комментарий от anonymous

C++ - надмножество C11

С++11 - надмножество С11? С++03 его надмножество? Вау.

Ты немного устарел. :-)

Я просто знаю больше тебя. Но да, ты моложе - гордись этим.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

С++11 - надмножество С11? С++03 его надмножество? Вау.

Как понять это? C++ - это язык, последний стандарт которого принят в 2014 году. C - это язык, последний стандарт которого принят в 2011 году. Для всех адекватных, включая Страуструпа, C++ - надмножество C (C11).

Я просто знаю больше тебя. Но да, ты моложе - гордись этим.

Хехе :-)

anonymous ()
Ответ на: комментарий от quantum-troll

Ага... И я так понял, что владеющая ссылка обязана существовать, иначе объект должен быть освобождён как никому не нужный. Поэтому нельзя блоки списка перевязать между собой каким-то невладеющими ссылками и всё делать по-старинке. Правда, не особо понятно, как это сочетается с ручным освобождением в виде Drop.

ilammy ★★★ ()
Ответ на: комментарий от anonymous

С++11 - надмножество С11? С++03 его надмножество? Вау.

Как понять это?

Пойми это правильно. Если можешь.

C++ - надмножество C (C11).

Про Generic тебя уже спросили; я спрошу о _Complex и flexible array.

tailgunner ★★★★★ ()
Ответ на: комментарий от ilammy

И я так понял, что владеющая ссылка обязана существовать, иначе объект должен быть освобождён как никому не нужный.

Да. Владеющая ссылка — объект, по которому оценивается корректность заимствующих ссылок. Пока владеющая ссылка существует и сам объект неизменен, заимствующие ссылки остаются корректными.

quantum-troll ★★★★★ ()
Ответ на: комментарий от anonymous

use RefCell Luke. В расте можно либо безопасно, через RefCell, либо быстро, но через unsafe {}. Два стула кароч. Этот момент в расте слабоват, но преимуществ у него все равно больше.

Aswed ★★★★ ()
Ответ на: комментарий от anonymous

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

В самых первых сборах раста так и делали, кстати. Отключаемый сборщик мусора. Но потом, почему-то, отказались от этой затеи.

Aswed ★★★★ ()
Ответ на: комментарий от tailgunner

Ты не меня спрашивай, а Страуструпа, ведь это именно его заявление:

With minor exceptions, C++ is a superset of C (meaning C11; [C11])

Сказано же тебе, with minor exceptions. Поэтому в вопросах, касаемых C++, я склонен доверять Страуструпу, а не людям с форума ЛОРа :-)

anonymous ()
Ответ на: комментарий от tailgunner

Про Generic тебя уже спросили; я спрошу о _Complex и flexible array.

Он даже не надмножество С99, хотя неполная совместимость с этим стандартом есть.

(другой анонимус)

anonymous ()
Ответ на: комментарий от anonymous

Тебе пропишу читать «Дизайн и эволюция C++».

anonymous ()
Ответ на: комментарий от anonymous

Сказано же тебе, with minor exceptions

Ну если так рассуждать, то C++ всегда будет надмножеством С с «небольшими исключениями» :)

(другой анонимус)

anonymous ()
Ответ на: комментарий от anonymous

Ты не меня спрашивай, а Страуструпа

Детский сад как он есть.

With minor exceptions, C++ is a superset of C

Ну да, Си++ - надмножество подмножества Си, какой сюрприз.

tailgunner ★★★★★ ()
Ответ на: комментарий от anonymous

Именно так его и задумывал Бьерн (или Бьёрн, или Бьярн, или Бьярне, или Бьёрне).

anonymous ()
Ответ на: комментарий от anonymous

Он даже не надмножество С99, хотя неполная совместимость с этим стандартом есть.

Ну да. ЕМНИП, последнй стандарт Си, который был подмножеством Си++ - это C89.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Детский сад как он есть.

Не так трактуешь. Я привык подкреплять свои рассуждения ссылками на официальне источники. :-) А без источников придётся свой базар доказывать, а то сочтут за взвяк. Поэтому, насчёт C++ Страуструп - источник авторитетный :-)

Ну да, Си++ - надмножество подмножества Си, какой сюрприз.

Если Вам так будет угодно :-)

anonymous ()
Ответ на: комментарий от anonymous

Бьерн (или Бьёрн, или Бьярн, или Бьярне, или Бьёрне)

Пиши просто: Страуструп.

quantum-troll ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.