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
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.