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 ()
Последнее исправление: cetjs2 (всего исправлений: 14)

Ответ на: комментарий от mbivanyuk

Что ааа? Фредерик Брукс? Считаешь его гуру? Ну ОК.

А ты, видимо считаешь, что такие награды, как: Computer Sciences Distinguished Information Services Award — Information Technology Professionals

Национальная медаль США в области технологий и инноваций

Harry H. Goode Memorial Award — American Federation of Information Processing Societies

Медаль Джона фон Неймана — IEEE Премия Бауэра Премия Тьюринга

и многие прочие не характеризуют Фредерика Брукса, как гуру? Кто же тогда гуру для тебя? Давай угадаю. Твой герой - Скотт Майерс? :-)

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

Вообще JavaScript не к ночи упомянут будет, если тут кого-то C++ не устраивает... лучше него только PHP.

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

А зачем тебе аналог Qt на Go?

Давай ещё раз с самого начала. Человек заявил, что если язык годный, то библиотеки появляются «сами собой и быстро». Я возразил, что «большие» библиотеки без серьёзных вложений не появятся.

Смысл в том что Qt чисто десктопная технология

Уже нет. Под мобилки писать тоже можно.

В любом случае, Gо не чисто «не-десктопный» язык, а вполне себе язык общего назначения. Более того - биндинги к Qt для Gо есть. То есть есть и потребность. Ну и гуи тулкиты лепить на Gо пытаются - даже на лоре где-то тема всплывала. Но очевидно, что до Qt они не дотягивают. Вот собственно, что и хотел сказать.

Про ненужность Gо не было сказано не слова, но ты почему-то уже начал спорить.

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

Да он не слышал не про того, не про другого.

Кстати, по поводу Майерса, а что с ним не так? Я прочитал тут как-то полторы главы его старой книжки, которая ещё до C++14 вышла, и ничего криминального там не нашел. Если бы парочка наших джунов с этим текстом ознакомилась, им бы пошло на пользу.

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

JavaScript гораздо более продуманный и удобный язык, чем C++. С большим-большим потенциалом. А насчёт PHP, так я уверен, что это твой любимый язык. Только ты боишься в этом признаться. :-)

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

В смысле? С ним всяко лучше, чем без него. Параметры передавать, назад типы получать. До этого-то совсем больно было :-(

anonymous
()

Ящитаю, надо предложить Пот*ерингу переписать s*stemd на сабж, иначе не модно, не по-хипстерски, на языке старых пердунов из 1970-х такую инновационную вещь писать :)

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

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

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

Ты такой толстый, что даже тонкий: четко так намек на латентную гомофилию ввернул! Но мимо...

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

Не так сильно, как хотелось бы.

У каждого свои хотелки. По сравнению с C или с Java шаблоны C++ сильно упрощают жизнь.

Ну, например, можете ли Вы сгенерировать строку SQL-запроса во время компиляции программы, в зависимости от того, сколько было задано параметров variadic template'а с помощью шаблонов?

Как эти примеры про SQL забабахали. Хорошо еще, что не потребовалось в compile-time распарсить описание схемы данных и проверить непротиворечие параметров SQL-запроса и схемы данных БД.

Когда приходится плотно работать с RDBMS, то очень быстро выясняется, что SQL-и у всех СУБД разные, и всякие хинты в запросах нужно указывать, и допускать какие-то дополнительные настройки в run-time через конфиги... На этом фоне вопрос генерации SQL в compile-time выглядит как сферический конь в вакууме.

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

На этом фоне вопрос генерации SQL в compile-time выглядит как сферический конь в вакууме.

На этом фоне язык шаблонов C++ выглядит как не пришей кобыле хвост в вакууме :-)

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

не пришей кобыле хвост в вакууме

Ахаха, пожалуйста, шутите больше, у Вас получается, Евгений!

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

Виталь, ты? Здорова! :-) Как дела?

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

не характеризуют Фредерика Брукса, как гуру?

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

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

Ну чего сказать, грустно у вас, или может быть это мне повезло, что у нас такая халява: я свой проект перевел на gcc 5.1 через два дня после его выпуска ;-)

По моему опыту, у нас ещё очень даже хорошо. (:

Так получается, что это скорее проблема вашей политики.

Причём здесь политика? Это же «не будем обновляться потому что лень тратить время» (хотя это тоже вполне себе аргумент так как время = деньги). А вот когда под какую-нибудь платформу тулчейн надо самому собирать (ну или использовать какой-нибудь древний) и в процессе сложности возникают, то это уже не политика, а вполне себе объективная реальность. Опять же, одно дело когда используем родной для системы GCC и совсем другое mingw, у которого и пользователей меньше и проблем больше.

DarkEld3r ★★★★★
()

Так там же объявления переменных наперекосяк, как в паскале! Закопать немедленно! Жаль язык D помер, тем не менее он был хороший пример как надо развивать язык, сохраняя удачные привычные концепции...

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от DarkEld3r

«большие» библиотеки без серьёзных вложений не появятся.

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

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

языки с высокой скоростью разработки позволяют написать «большие» библиотеки за меньшее время

Как, наверное, хорошо быть наивным и не представлять себе, что же такое разработка «больших» библиотек.

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

Тебе же уже посоветовали к ЕГЭ готовиться, а там глядишь лет через десять подрастешь до человека. Что конечно не факт

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

Эти самые десктопные приложения для доступа к вебу (ОСи, барузеры и так далее) уже написаны, понимаешь?

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

Когда приходится плотно работать с RDBMS, то очень быстро выясняется, что SQL-и у всех СУБД разные,

Да, и, разумеется, любой ORM/FRM/DSL враппер для SQL-запросов про эти различия знает. При этом в случае чего можно, благодаря метапрограммированию, можно писать чистое SQL, сохраняя при этом типобезопасность. Но C++ в это не может, поэтому все это нинужна.

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

Да, и, разумеется, любой ORM/FRM/DSL враппер для SQL-запросов про эти различия знает. При этом в случае чего можно, благодаря метапрограммированию, можно писать чистое SQL, сохраняя при этом типобезопасность. Но C++ в это не может, поэтому все это нинужна.

Ага, расскажи мне про метапрограммирование в Java, например.

http://icdn.lenta.ru/images/0000/0018/000000182326/pic_1358288159.jpg

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

А это модно нынче подгонять задачи под язык, а не наоборот :-) Раз в C++ нельзя, значит задача поставлена некорректно. :-)

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

Поэтому Lisp навсегда :-)

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

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

А вот Петя Сайбель написал книгу, в которой он сказал, что Lisp - годнота. :-) А ты тут «маргинальность», «ненужность». Тебе говорят, годнота, значит, годнота :-)

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

Electron, NW.js как платформа. Плюс какой-нибудь ангуляр (или любой другой фреймворк) как фреймворк. И все — для множества десктопных приложений ничего больше не нужно. И на JS/HTML будет на порядок более богатая экосистема библиотек, чем на Qt. Там, где для Qt есть одна убогая QScintilla, на JS есть полно значительно лучших встраиваемых текстовых редакторов.

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

языки с высокой скоростью разработки позволяют написать «большие» библиотеки за меньшее время

Оно-то более-менее так. Вот только вопрос в том какой выигрыш во времени будет. Да, если взяться писать сайт на С++ (да ещё и без знаний «предметной области») и потом на на подходящем языке, то тут можно и порядки выиграть. В более реальных примерах такой разницы не будет. Не говоря уже о том, что не всякий язык для разных целей подойдёт.

что и подтверждается статистикой новых проектов на гитхабе.

Я надеюсь ты понимаешь, что такая выборка ничего не доказывает? Особенно, если считать именно по репозиториям. Qt с его кучей кода даст нам один «проект» против тысяч бесполезных проектиков с десятком коммитов.

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

Эти самые десктопные приложения для доступа к вебу (ОСи, барузеры и так далее) уже написаны...

и продолжают развиваться, да.

DarkEld3r ★★★★★
()

А где можно почитать про str и String? Чтение доков вызвало недоумение и неуловимый бугурт. Язык сам по себе вроде неплох, но вот это разделение как-то пованивает. Есть такое ощущение что если бы строки были немутабельными, как в питончике или жабке, то двух типов не надо было бы изобретать.

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

Electron, NW.js как платформа.

Это не аналог.

И на JS/HTML будет на порядок более богатая экосистема библиотек, чем на Qt.

Qt - сама по себе библиотека.

Там, где для Qt есть одна убогая QScintilla, на JS есть полно значительно лучших встраиваемых текстовых редакторов.

Да, конечно, ведь нам только и надо, что редакторы встраивать.

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

А я не должен быть курицей, чтобы судить о качестве омлета.

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

тение доков вызвало недоумение и неуловимый бугурт.

Это примерно как char* и std::string в С++. Вот тут всё нормально описывается.

если бы строки были немутабельными, как в питончике или жабке

Именно поэтому в джаве есть String, StringBuffer и StringBuilder?

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

Если просто, то String это std::string, а &str это char* + длинна (в С++17 будет string_view). Первый владеет буфером со строкой, второй - нет, для Rust принципиальное различие, поэтому два разных типа.

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

Там, где для Qt есть одна убогая QScintilla, на JS есть полно значительно лучших встраиваемых текстовых редакторов.

Для Qt есть как минимум еще:

http://api.kde.org/frameworks-api/frameworks5-apidocs/ktexteditor/html/index....

И уровня kate встраиваемых редакторов на JS нет. А всякие codemirror и пр. - как раз прямые аналоги scintilla.

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

Именно поэтому в джаве есть String, StringBuffer и StringBuilder?

И это плюс. Просто таскать везде to_string() копируя(!) байты из дата секции как-то глупо для системного языка.

Более того собирать строки на месте не такая уж частая операция и с мощным синтаксисом раста можно сделать прекрасные буфера.

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

А Петя Нордвиг - вообще директор по исследованиям в Гугле. Кто не знает Петю в мире Лиспа?

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

Это всё понятно. Меня интересует конкретно что меняется на уровне байтов в случае внесения Associated Types.

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