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)

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

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

Ну почему же - drop можно вызвать самому и в нужный момент.

Проблема в другом - нельзя иметь иммутабельные ссылки (const& в терминах С++) на обьект, если на него есть мутабельная ссылка. Вот и получается, что если у нас будут ссылки не следующий и предыдущий элемент, то им надо быть иммутабельными. Отдать при этом ссылку на обьект наружу для изменения уже будет нельзя.

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

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

Пока что у нас есть другой дурачок-теоретик и это ты.

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

как результат народ будет тыкать unsafe на каждом шагу - в результате получим тотже С/С++ но с другим синтаксисом ....

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

но первоночальное боксирование мне нравилось гараздо больше.

Чем? Лайфтаймы руками всё равно пишутся не так уж часто и не особо мешают.

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

Почему же на тот пост ответил только ты? :-)

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

drop - не освобождение памяти, а вызов деструктора.

Для какого-нибудь Box - это будет всё равно освобождением памяти.

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

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

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

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

Посмотрим, нужно ли.

Нужно. А вот взлетит ли - посмотрим.

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

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

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

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

DarkEld3r ★★★★★
()
$ cargo new --bin helloworld
$ cd helloworld
$ cargo run --release
   Compiling helloworld v0.1.0 (file:///.../helloworld)
     Running `target/release/helloworld`
Hello, world!
$ ls -l target/release/helloworld
-rwxr-xr-x 1 user user 450067 май 17 16:05 target/release/helloworld

Хеллоуворлд весит 500 кБ. И эти люди ещё претендуют на гордое звание «you only pay for what you use».

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

Ну в больших проектах на томже C++ тоже unsafe code минимум

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

но последние изменения желание отбили почти полностью ...

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

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

Какой Раст? Есть такой язык - ассемблер. Пиши на нём и, будет тебе размер порядков на 5-6 меньше, раз для тебя это показатель :-)

anonymous
()
Ответ на: комментарий от anonymous
$ g++ test.cpp -o test
$ ldd test
	linux-vdso.so.1 (0x00007ffe0dd29000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f604321d000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007f6042f18000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f6042d02000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f604295f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f604352c000)
$ ls -l /usr/lib/libstdc++.so.6.0.20 
-rwxr-xr-x 1 root root 1486936 Mar  6 06:29 /usr/lib/libstdc++.so.6.0.20

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

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

Аналогично, меня уже тыкнули в новуб реализацию того что «убрали»

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

Похоже что сейчас в расте просто стандартная (растовая) библиотека линкуется статически, отсюда и такой размер.

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

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

Если что, скрестить cppyy и PyROOT таким образом, чтобы сверху был общий интерфейс решающий «если PyPy, то cppyy, если CPython, то PyROOT» никакой технической проблемы не составляет (как ты, наверное, сам понимаешь), но пока это никому (включая меня) не было нужно.

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

$ ls -l /usr/lib/libstdc++.so.6.0.20

-rwxr-xr-x 1 root root 1486936 Mar 6 06:29 /usr/lib/libstdc++.so.6.0.20

libstdc++ один, а тут каждый бинарник жирный. Кроме того, если стандартная библиотека обновится, то в случае с libstc++ это один файл, а в rust все-все бинарники. Представляешь себе листр на rust - вышла новая версия rust и давай гигабайты качать и переписывать.

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

Java, python, c некоторым ограничением perl и тд ...

Во всех этих языках есть FFI, которым можно отлично расстрелять память в своём процессе.

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

Вот кстати о линковке. Сам компилятор слинкован со своими либами динамически.

$ ll /usr/bin/rustc-1.0.0 
-rwxr-xr-x 1 root root 5984 май 15 21:54 /usr/bin/rustc-1.0.0
$ ldd /usr/bin/rustc-1.0.0 
	linux-vdso.so.1
	librustc_driver-gentoo-1.0.so => ...
	libstd-gentoo-1.0.so => ...
	libc.so.6 => ...
	librustc_trans-gentoo-1.0.so => ...
	librustc_privacy-gentoo-1.0.so => ...
	librustc_borrowck-gentoo-1.0.so => ...
	librustc_typeck-gentoo-1.0.so => ...
	librustc_resolve-gentoo-1.0.so => ...
	librustc_lint-gentoo-1.0.so => ...
	librustc-gentoo-1.0.so => ...
	libsyntax-gentoo-1.0.so => ...
	libgraphviz-gentoo-1.0.so => ...
	libflate-gentoo-1.0.so => ...
	librustc_llvm-gentoo-1.0.so => ...
        ...
	libgcc_s.so.1 => ...
        ...
	libstdc++.so.6 => ...
А как динамически слинковать результат компиляции?

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

ldd /usr/bin/rustc-1.0.0
libstdc++.so.6 =

ололо

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

И эти люди ещё претендуют на гордое звани

Осиль уж "-O -C prefer-dynamic", а потом претендуй на звание очередного умнега )

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

а в rust все-все бинарники. Представляешь себе листр на rust

Для тех, кто не в курсе и не знает, но мнение имеет:

https://github.com/rust-lang/rust/issues/10209

I currently believe there is little hope that Rust libraries can offer any meaningful binary forward compatibility or upgradability. ... perhaps we should prefer static linking by default.

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

Спорное утверждение, в той же Java нужно писать прослойку на С для работы с сишными библиотеками и просто так вызов сишных методов в Java код впихнуть не получится, в отличии от unsafe ...

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

Как-бы ядра ОС на нем тоже пишут - смотри сюда. И это не единственный проект такого рода, остальные лень искать.

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

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

Для тех, кто не в курсе и не знает, но мнение имеет:
I currently believe there is little hope that Rust libraries can offer any meaningful binary forward compatibility or upgradability

И что это меняет? Это еще хуже, это то самое, что погубило D. Уже можно говорить, что rust не будет системным языком.

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

Как раз-таки статическая линковка - это хорошо. Потому что в язычке C++, благодаря такой хай-тек технологии, как name mangling, обновление динамически-линкуемых библиотэк - ещё та проблема для красноглазиков :-)

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

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

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

посмотри на Go, там кажется вообще никаких динамических зависимостей нет, даже к libc не привязываются.

Ну так Go это прежде всего вэб, там совместимость не нужна. Rust же позиционируют как замену С, а замена С без обратной совместимости не нужна по определению

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

Вообще интересно, кто из компилируемых в натив языков линкует свои либы по-умолчанию динамический? Haskell точно по-умолчанию статический линкует.

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

Потому что в язычке C++, благодаря такой хай-тек технологии, как name mangling, обновление динамически-линкуемых библиотэк - ещё та проблема для красноглазиков :-)

У красноглазиков, как раз, уже давно нет с этим проблем.

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

Вообще интересно, кто из компилируемых в натив языков линкует свои либы по-умолчанию динамический?

C и С++, собс-но то, что должен как бы заменять rust.

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

И что это меняет?

Ну да, стат. линковка по умолчанию, а не наоборот - меняет все!

Это еще хуже, это то самое

Что именно хуже чего?

Для неосиляторов аглицкого - сделали чисто из практических соображений. Чтобы то, что уже скомпилированно и работает, продолжало работать и после обновления компилятора или библиотек, с изменением АПИшек и т.д. Хотелось пострадать - "-С prefer-dynamic" никто не отменял. Теперь, с выходом стабильной ветки дефолты можно будет и сменить.

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

проблема для красноглазиков :-)

Вообще то не только - обычно любое обновление такой либы тянет за собой обновление всех зависимых от этой либы приложений.

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

Теперь, с выходом стабильной ветки дефолты можно будет и сменить.

Вряд ли. У Rust пока нет стабильного опубликованного ABI (впрочем, его довольно долго не было и у Си с Си++).

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

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

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

обычно любое обновление такой либы тянет за собой обновление всех зависимых от этой либы приложений

Это где так? У Си++ давно уже стабильный ABI.

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

На оффтопике тот же хеллоуворлд весит 2,3 МБ. и слинкован только с оффтопиковскими либами из system32. Похоже там и libc в сам бинарник зашит.

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

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

Открой свой /usr/lib, /lib и т.п. и внимательно посмотри. Это С и С++. Если rust будет регулярно ломать совместимость на уровне ABI, то в этих директориях ровно ничего не изменится, там все так же будут С и С++. Никто не станет переходить к статичной линковке всего и вся, или пересборке всего софта, тем более, что пересборка может и сфейлится от новых изменений.

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

На оффтопике тот же хеллоуворлд весит 2,3 МБ.

Это нормальный размер для хеллоуворлда в этом десятилетии. Вон, у Qt5 helloworld аж под 50МБ весит. И ничего, кушают.

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

Ну-ну, посмотрим как обновление на GCC 5.1 пройдет, там как раз ABI у libstdc++ сменился.

Для тех кто чисто теоретик - в libstdc++, как и в glibc есть версионирование символов. Так что новый libstdc++ прекрасно себе подойдет под старые бинарники.

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

ого как много, ну точно C++ загибается

Ну, я мелочёвку не упоминал, типа KeePassX. Плюс не упоминал установленные игры, вроде кербалов или wasteland 2. А вообще, это не удивительно, я vm'офоб. :) Стараюсь избегать софта на Java/C#. :)

наверное скоро вынудит переписать движки на C# :)

Ну, вы почти правы. :) Это не переписывание, а «перекомпиляция», но показывающая, что ничего невозможного нет.

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

Ну, я мелочёвку не упоминал, типа KeePassX. Плюс не упоминал установленные игры, вроде кербалов или wasteland 2.

Из всего перечисленного имею только wasteland 2. Так что проверяю его и...

game$ ldd ./WL2
	linux-gate.so.1 =>  (0xf770c000)
	libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf76d7000)
	libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf76ba000)
	librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf76b0000)
	libGLU.so.1 => /usr/lib/i386-linux-gnu/libGLU.so.1 (0xf763d000)
	libGL.so.1 => /usr/lib32/nvidia-340/libGL.so.1 (0xf7526000)
	libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf73db000)
	libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xf73c6000)
	libXcursor.so.1 => /usr/lib/i386-linux-gnu/libXcursor.so.1 (0xf73ba000)
	libXrandr.so.2 => /usr/lib/i386-linux-gnu/libXrandr.so.2 (0xf73af000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7362000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7344000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7189000)
	/lib/ld-linux.so.2 (0xf770d000)
	libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf7082000)
	libnvidia-tls.so.340.76 => /usr/lib32/nvidia-340/tls/libnvidia-tls.so.340.76 (0xf707d000)
	libnvidia-glcore.so.340.76 => /usr/lib32/nvidia-340/libnvidia-glcore.so.340.76 (0xf4ae9000)
	libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf4ac7000)
	libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xf4abb000)
	libXfixes.so.3 => /usr/lib/i386-linux-gnu/libXfixes.so.3 (0xf4ab3000)
	libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf4aaf000)
	libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf4aa8000)

Поздравляю вас, гражданин, соврамши! Mono есть в составе Unity и может и использовалось для скриптов, но сама игра на С++.

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