Разработчики systemd рассматривают возможность внедрения Rust

Это gdm такой кривой.

gdm тут не при чём, виноват тот кто писал скрипт для FreeBSD и вероятно вся init система FreeBSD в целом. Я вообще не очень понимаю зачем нужен BSD после открытия Solaris с нормальной init системой.

то есть ты такой: вот опенсолярис! и все бросили то, чем они занимались и на чем специализировались и начали изучать внутренности новой ОС?

Их компьютеры медленные, прошлого поколения. Не осиляют компиляцию Rust за приемлемое для них время.

> pkg info openjdk15
openjdk15-15.0.2+7.1_1
Name           : openjdk15
Version        : 15.0.2+7.1_1
Installed on   : Wed May 26 20:57:28 2021 MSK
Origin         : java/openjdk15
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : devel java
Licenses       : GPLv2
Maintainer     : java@FreeBSD.org
WWW            : https://openjdk.java.net/projects/jdk/15/
Comment        : Java Development Kit 15
Shared Libs required:
	libXtst.so.6
	libpng16.so.16
	libXext.so.6
	libgif.so.7
	libXrender.so.1
	libfreetype.so.6
	libjpeg.so.8
	libfontconfig.so.1
	libasound.so.2
	libXi.so.6
	liblcms2.so.2
	libX11.so.6
Shared Libs provided:
	libattach.so
	libsaproc.so
	librmi.so
	libmanagement.so
	libjava.so
	libjli.so
	libextnet.so
	libawt_headless.so
	libverify.so
	libdt_socket.so
	libzip.so
	libjvm.so
	libmlib_image.so
	libnet.so
	libjimage.so
	libjawt.so
	libsctp.so
	libjavajpeg.so
	libjaas.so
	libjsig.so
	libprefs.so
	libmanagement_ext.so
	libjsound.so
	libinstrument.so
	libsunec.so
	libfontmanager.so
	liblcms.so
	libawt_xawt.so
	libj2gss.so
	libsplashscreen.so
	libjdwp.so
	libj2pkcs11.so
	libj2pcsc.so
	libnio.so
	libmanagement_agent.so
	libawt.so
Annotations    :
	FreeBSD_version: 1300505
Flat size      : 325MiB
Description    :
An open-source implementation of the Java Platform, Standard Edition,

WWW: https://openjdk.java.net/projects/jdk/15/

и

> pkg info rust
rust-1.52.1
Name           : rust
Version        : 1.52.1
Installed on   : Wed May 12 21:30:35 2021 MSK
Origin         : lang/rust
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : lang
Licenses       : MIT, APACHE20
Maintainer     : rust@FreeBSD.org
WWW            : https://www.rust-lang.org/
Comment        : Language with a focus on memory safety and concurrency
Options        :
	DOCS           : off
	GDB            : off
	SOURCES        : off
	WASM           : off
Shared Libs required:
	libcurl.so.4
Annotations    :
	FreeBSD_version: 1300504
Flat size      : 386MiB
Description    :
Rust is an open-source systems programming language that runs blazingly
fast, prevents almost all crashes, and eliminates data races.
Some of its features:

  - Algebraic data types, type inference
  - Pattern matching and closures
  - Concurrency without data races
  - Guaranteed memory safety
  - Optional garbage collection
  - Zero-cost abstractions
  - Minimal runtime
  - Efficient C bindings

WWW: https://www.rust-lang.org/

Чего такого в Rust, что он жирнее Java JDK?!

До кучи:

> pkg info librsvg2-rust
librsvg2-rust-2.50.3_3
Name           : librsvg2-rust
Version        : 2.50.3_3
Installed on   : Fri May 28 11:08:41 2021 MSK
Origin         : graphics/librsvg2-rust
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : gnome graphics
Licenses       : LGPL20
Maintainer     : desktop@FreeBSD.org
WWW            : http://live.gnome.org/LibRsvg
Comment        : Library for parsing and rendering SVG vector-graphic files
Shared Libs required:
	libpangoft2-1.0.so.0
	libglib-2.0.so.0
	libgobject-2.0.so.0
	libpango-1.0.so.0
	libharfbuzz.so.0
	libfreetype.so.6
	libcairo.so.2
	libxml2.so.2
	libpng16.so.16
	libintl.so.8
	libcairo-gobject.so.2
	libfontconfig.so.1
	libgdk_pixbuf-2.0.so.0
	libgio-2.0.so.0
	libpangocairo-1.0.so.0
Shared Libs provided:
	librsvg-2.so.2
	libpixbufloader-svg.so
Annotations    :
	FreeBSD_version: 1300505
Flat size      : 10.5MiB
Description    :
The librsvg library is a lightweight library for parsing and rendering
vector-graphic files in SVG format (like the ones made by sodipodi).  It also
includes functions that render anti-aliased fonts using freetype, including
caching of glyphs.  It is used by Nautilus for drawing vector icons and
anti-aliased text.

This is a rustified version of LibRsvg.

WWW: http://live.gnome.org/LibRsvg

С clang та же проблема. Код он собирает ещё медленнее. И собирается ещё дольше. Но если повезёт, то исполнит код чуть быстрее.

И собирается ещё дольше.

Зато собирается без проблем и без убогих autotools. Кросскомпиляция из коробки. Прямо сейчас страдаю с кросскомпиляцией GCC под Haiku RISC-V, почему-то исключения не работают.

Если я правильно понял, автор librsvg страдал от того, что библиотеки в gnome пишут традиционно на C, а ему хотелось чего-то более высокоуровнего. Vala как вариант был отвергнут по причине того, что за пределами gnome он не видел его применения. И тут ему попалась заметка о возможности постепенной замены кода на C, кодом на Rust. Не знаю,что мешало использовать подобный подход с C++, но в случае с Rust обещали «ноу криминалити». Сюда же наложились его проблемы с тестами для функций на C.

Неправда! У меня комп позапрошлого поколения, а не прошлого!

Да, в обсуждении пул реквеста отметили,что сейчас librsvg занимает 10 мб, а занимал 300 кб. Даже обсуждт можно ли обойтись без его stdlib или можно ли линковать её динамически.

Если мне неё нужно лезть в систему сборки, то мне вообще всё равно,что используется. Хоте нет, вру, мне всё равно даже если нужно в неё лезть.

Этот убогий autotools постоянно сыпется на ровном месте. То требует aclocal-1.15 и только этой версии, то зачем-то берёт системные библиотеки, хотя используется кросскомпиляция. О нормальной инкрементальной сборке можно забыть.

Сборка clang через cmake работает идеально и инкрементальная сборка быстрая.

Интересно, если гццрс подоспеет, им будут собирать?

Они на это надеятся, так как собирать часть на базе gcc, а другую на базе llvm им пока идея не очень нравится.

И это системд, а что будет с ядром?

А гццрс вроде развивается, обсуждают гит-ветку у гцц.

https://www.phoronix.com/scan.php?page=news_item&px=GCC-Rust-May-2021-Progress

Важно понимать, что unsafe не отключает проверку заимствования или любые другие проверки безопасности Rust: если вы используете ссылку в небезопасном коде, она всё равно будет проверена. Единственное, что делает ключевое слово unsafe - даёт вам доступ к этим четырём возможностям, безопасность работы с памятью в которых не проверяет компилятор

https://doc.rust-lang.ru/book/ch19-01-unsafe-rust.html
Хмм…🧐

И-и-и...? Ты хочешь сказать, что там недостаточно способов выстрелить себе в ногу?

С clang та же проблема. Код он собирает ещё медленнее. И собирается ещё дольше. Но если повезёт, то исполнит код чуть быстрее

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

Достаточно. Но не настолько, чтобы утверждать, что Раст никак не защищает в unsafe, вообще. То же самое, на ряд операций наложены послабления. Даже в unsafe Раст продолжает быть более строгим языком, чем С++.

Но не настолько, чтобы утверждать, что Раст никак не защищает в unsafe, вообще

Незначительно больше, чем «защищает» какой-нибудь Си. Естественно, я беру это за ноль, поскольку у языка есть какой-то синтаксис, есть структуры данных, а если написанный код не будет иметь смысла — компилятор ничего не скомпилирует.

Даже в unsafe Раст продолжает быть более строгим языком, чем С++

В каком месте unsafe Rust строже, чем C++? Дергай любые функции, крути указателями как хочешь. Внутри unsafe, естественно. Где тут больше гарантий. чем у крестов?

вопрос, на который никто пока не знает ответ: будет больше плюсов от rust или минусов. с одной стороны он может и защитить от memory errors. типа тех, на которые я за полгода дважды наступил, пока смотрел фряху. (не тестировал! не искал специально!)

с другой может и не защитить в unsafe, а размер бинарников и время компиляции вырастет в 10 раз.

Тут зависит от философии прослойки между креслом и монитором. Если для тебя unsafe - это «ууу, пшёл к чёрту, грёбаный борроучекер, сейчас буду разыменовывать все указатели!», то проще сразу взять Си и не заниматься самообманом. Если пациент отказывается от лечения, медицина бессильна.

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

В каком месте unsafe Rust строже, чем C++?

Ну, попробуй взять несколько мутабельных ссылок от одного объекта внутри unsafe. Или transmute-ом поразмахивай, как reinterpret_cast-ом.

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

Ну, попробуй взять несколько мутабельных ссылок от одного объекта внутри unsafe. Или transmute-ом поразмахивай, как reinterpret_cast-ом

Легко:

pub fn somefunc() -> i32 {
    let mut a = 1;
    let b: *mut i32 = &mut a;
    let c: *mut i32 = &mut a;
    unsafe { *b + *c }
}

https://gcc.godbolt.org/z/bdx5bYKMf

Да, ссылки в Rust — это memory-safe функция, в unsafe или вне онного, она накладывает кучу ограничений на код — как и вызов любой другой безопасной функции из unsafe кода.

Хочу здесь подчеркнуть, что арифметика с указателями является полностью безопасной функцией в расте. То есть, можно налепить абсолютно любой дичи в safe фрагменте, а потом «всего-лишь» дернуть unsafe разыменование.

Ну это «смотрите я наипал борроучекер!». Раст страхует от случайных ошибок, от преднамеренных не страхует. Если у тебя отношение к компилятору, как у юнца к parental control, тогда надобности в Раст и вправду нет, пиши на Сях.

Ну это «смотрите я наипал борроучекер!». Раст страхует от случайных ошибок, от преднамеренных не страхует

Не далее как в прошлом растотреде я доказывал ровно обратное: ответственный кодер на крестах дергая только безопасные функции (например, не сохраняя ссылку на string_view) может достичь memory-safety, близкую к растовой. Да, borrow checker-а нет, но при необходимости повышенной безопасности можно пожертвовать производительностью, вроде копирования значения вместо передачи ссылки.

Rust же нужен корпорациям для того, чтобы бить ногами неугодных кодеров, которые скрывают имеющиеся баги под костылями, потенциально создавая уязвимости и нестабильность в работе всей системы. И при этом корпорация не может пожертвовать 20-50% производительности системы после перехода на какую-то жаву — далеко не у каждой фирмы есть такие требования.

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

Все проще - Раст просто офигенный, и многолетнее первое место в опросах на СО это доказывает:)

Кто только принимает участие в этих опросах СО? У людей, занятых реальной работой, на это точно нет времени.

Каких опросах? О_о

https://m.habr.com/ru/company/skillfactory/blog/504194/

ВРЕТИИИИИИИ

Ссылка постом выше, можешь сам ознакомиться.

Все проще - Раст просто офигенный, и многолетнее первое место в опросах на СО это доказывает

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

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

Но ты же эти сотни тысяч строк не в один объектник будешь собирать? С нуля перекомпилировать проект не так уж часто приходится.

Зачем они спрашивают разработчиков stackoverflow? Да ещё и 78% опрошенных не занимаются программированием на работе. И где rust в списке самых используемых языков?

А вот вам ещё статистика

https://dou.ua/lenta/articles/language-rating-jan-2021/, там раст пониже.

Раст просто офигенный, и многолетнее первое место в опросах на СО это доказывает:)

Кстати, а что любители Rust говорят на то, что Rust зависит от libc? На всех ОС, даже в RedosOS. Даже если выбрать static, то всё равно при сборке нужен либо musl(это тоже libc), либо MS libc. То есть зависимость от libc остаётся для сборки. Как можно победить язык от которого зависишь, и без которого не работает даже helloworld?

fn main() {
  println!("Hello\n");
}

Кто-нибудь вообще разбирался насколько сильна зависимость от С у Rust?

Или я пропустил и заменяем только С++, а сишка остаётся, потому что это основа основ?

Вот что нашёл:

https://stackoverflow.com/questions/27723617/why-do-executables-have-a-dependency-on-glibc

Адово медленная компиляция - плата за многие фишки, которых в Си и С++ нет и они не нужны

Исправил.

Например, офигительный вывод типов, с которым Раст местами на скриптоту похож. Rastc не однопроходный, в отличие от

Офигительным он был бы, если бы выводил типы за пределами функций. Но он этого не делает, вывод типов там только локальный. C++ очень близок к аналогичному состоянию. И да, он тоже не однопроходной. И у меня есть сомнения по поводу того, что однопроходность там принципиально недостижима.

Но ты же эти сотни тысяч строк не в один объектник будешь собирать? С нуля перекомпилировать проект не так уж часто приходится

Не так часто, но периодически. Когда это «периодически» начинает занимать часы, то становится совсем не весело.

Кто-нибудь вообще разбирался насколько сильна зависимость от С у Rust?

В данном случае разрабы просто забили на написание собственной прокладки меж языком и системой. Если говорить про то, можно ли без этого, то я бы предложил вспомнить винду, где VC runtime довольно тонкий, а основная трансляция вызовов функций в системные вызовы происходит через kernel32.dll. Которая, на самом деле, сама перекидывает вызовы в ntdll.dll, который уже является нативным интерфейсом оси. В никсах просто-напросто нет подобных уровней трансляции, а вся совместимость закладывается в libc, поскольку, как известно, на никсах не существует никаких языков, кроме Си.

А где надо спрашивать?

И где rust в списке самых используемых языков

Вы находитесь здесь. (с)

Это что?)

Местечковый опрос, да ещё и на совсем другую тему. Ща, пацанам в локалке кину, мы тоже тут всем селом опрос проведём.

Нет, не местечковый. А тема та,

https://habr.com/ru/post/543346/

нашёл перевод.

Пролистайте до индекс предпочтения.

Адово медленная компиляция - плата за многие фишки, которых в Си и С++ нет и они не нужны

Всё, чего нет в С++, нинужно. Как только появляется в С++, сразу становится нужным. Впрочем, ничего нового.

C++ очень близок к аналогичному состоянию.

Ну насмешил, ну затейник))

он тоже не однопроходной.

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

Ну да, все любят rust, но пишут на чём угодно, но не на нём. Ок.

В итоге, какие достижения треда? Побороли Rust раз и навсегда?

P.S. Поттеринг не против вроде. Так что взлетит

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

Ваше право.

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

P.S.: JS, да?(

В итоге, какие достижения треда? Побороли Rust раз и навсегда?

Нашли твоего приятеля из Google, который обеспокоен медленной компиляцией Rust

https://www.youtube.com/watch?v=_prA_EmoBe4&t=3960s (1 минуту посмотреть с этого места)

Кстати, а что любители Rust говорят на то, что Rust зависит от libc?

libc это почти интерфейс к ОС, на деле. Там же сидит например аллокатор (а не в стандартной библиотеке Rust например), что может быть немаловажным если начнешь линковаться с какими-то другими библиотеками.

На практике эта зависимость очень беспроблемная. Кроме того есть musl, тогда libc вообще не видно и он линкуется статически. Стандартная библиотека Rust пользуется libc оборачивая достаточно успешно все это в безопасный интерфейс.

На libc как правило внешние, динамические зависимости заканчиваются потому что почти всему есть Rust альтернатива. Кроме одного исключения - пока что почти любой веб-фреймфорк тянет OpenSSL. Он линкуется динамически, слинковать статически чуть сложнее.

Вот наверно от OpenSSL у меня полыхает. Очень легко в Rust переключиться с glibc на musl при желании. Но очень много работы для OpenSSL если хочешь полностью статический бинарник.

Веб-фреймворки могли бы по чуть-чуть переходить на ring, но как-то с этим туго

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

Там и по мелочам хватает проблем со статической линковкой. Ничего, поборем со временем.