LINUX.ORG.RU

Rust всемогущий: ищу истории успеха

 ,


1

6

Всем привет!

Помнится тут на ЛОРе мелькала библиотечка про SVG, что на расте уделывала имеющиеся аналоги. Интересно, есть ли ещё подобные случаи – из тех что вам попадались на глаза или обсуждались здесь ранее. Если с реальными бенчмарками и цифрами – то вообще отлично!

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

★★★★★

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

Моя мечта вместо std::list всю жизнь писать вот этот трэш

А зачем тебе для этого ООП? С тем, что сишечка – днище и не может в типы, я даже не спорю. Это факт.

Алсо, почитай man 7 queue уже.

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

У него пригорело от того, что unsafe-блоке пришлось делать работу бороучекера руками.

Ну то есть буквально от того, что происходит, как только ты пишешь unsafe{} - выход за пределы загончика с проверками.

Вот пример его БОЛИ

«я взямл укмазатель и потерял где его испомльзовмал». Я в целом даже знаю решение его проблемы… smart pointer! Но он ведь именно для того чтобы не использовать(A)Rc он вышел в unsafe. задумчивыйсмайлик.gif

Интресно, можно ли сделать это корректно в библиотеке, которую будут использовать третьи лица, и не уронить производительность ниже плинтуса?

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

Вот читаю растоманские сказки про серебряные пули.

Ты читаешь чем-то не тем. Нет там серебрянной пули. Есть местами сильное улучшение надёжности продукта кодосодержащего, за счёт значительного усложнения процесса написания компилируемого кода. Если кратко - тебе компилятор батареей по рукам постоянно кидается. СЛАВА РОБОТАМ!

Задач, в которых нужно применить Раст пока не было и в обозримом будущем не предвидится.

https://www.ivankapcov.ru/paulgraham/avg/

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

Я бы сказал, что мы сравниваем лапти с новой блестящей инвалидной каталкой.

Скорее уж мы сравниваем олдовый токарно-винторезный станок, с ЧПУ фрезеровочной машиной тогда уж.

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

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

Скорее уж мы сравниваем олдовый токарно-винторезный станок, с ЧПУ фрезеровочной машиной тогда уж.

Да нет. Сишка – это бабушкин деревянный член-самотык с занозами, погрызенный термитами и порядком сгнивший местами.

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

Этот самотык ещё нас переживёт.

Да не. Как и с другими убожествами, он умрёт когда программисты на нём умрут. А они в основном старые уже, большинству за 40 вроде по опросам было. Ещё лет 15 и будет как с COBOL сегодня.

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

Роб Пайк с Томпсоном спроектировали один из лучших языков для промышленной разработки, есличо. Если не лучший для своих задач.

Но ты слишком экзальтирован умными и прикольными штуками, чтобы это понять.

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

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

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

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

Да, я так и понял, что это замена Java. Позволю себе привести пару цитат в защиту моей точки зрения:

Java is designed to be understandable by brain-damaged people.

@vsl

If you think your users are idiots, only idiots will use it.

Лойнос Торовалтос

Но на самом деле, golang – это просто Пайк пропихнул наконец в гугел свой Limbo, который до этого никак не мог 20 лет никуда пристроить. Ничего особо выдающегося в этом языке нет.

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

If you think your users are idiots, only idiots will use it.

Оглянись вокруг, тащемта. Те кто «ЯНЕИДИОТ» будут писать на лишпе, хачкеле, рачте и прочих окамлах. Те кому надо сделать от забора и до обеда - возьмут жаву, шарп, го или питон.

Пайк пропихнул наконец в гугел свой Limbo

Как будто это что-то плохое

Ничего особо выдающегося в этом языке нет.

Именно в этом его выдающесть и заключается. Это скучный язык, который за десять лет сильно сломали только один раз - когда модули ввели.

То что там CSP под капотом, выхлоп в нативный код, нормальная кросс-компиляция в одно движение, разумный набор батареек прям в комплекте - это всё мелочи, на которые "ЯНЕИДИОТ"ы внимания не обращают, им не до того, они стройные системы зависимых типов выстраивают.

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

как с COBOL сегодня.

пару лет назад зарплата на кобол из того что в открытую от безысходности предлагали, начиналась от десятки грина в месяц. А обещания джавистов «мы всё перепишем!» я слышал ещё лет 15 назад в начале программистского пути.

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

Как будто это что-то плохое

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

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

Где? В США? Так это не слишком много по их меркам, уровень среднего индуса. И это без учёта того, что писать на коболе – крест на карьере. Примерно как на PHP, только ещё хуже, потому что с твоими навыками ты будешь нужен хорошо если пяти конторам. Соваться в это хорошая идея только если тебе до пенсии 10 лет, и кроме кобола ты больше ничего не можешь.

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

Потому что можно было сделать гораздо лучше

Если бы у бабушки, да было бы…

Где? В США?

Один там банк даже в РФ искал и был на удалёнку согласен.

И это без учёта того, что писать на коболе – крест на карьере.

Оставаться программистом - это в принципе крест на карьере. Рост только в управление людьми, есличо. Нужна ли такая карьера - другой вопрос.

Примерно как на PHP

охлол. Тут комментировать только портить.

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

При том что эти «пять контор» ворочают, значительной долей, американского бабла - не самый плохой вариант.

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

Один там банк даже в РФ искал и был на удалёнку согласен.

Вау! Целый один!

охлол. Тут комментировать только портить.

Ну раз тебе нечего сказать, то и молчи. Кстати, я забавную штуку заметил: голанг любят в основном бывшие пхпшники. Всякие сишники, на которых он казалось бы ориентирован, наоборот его сторонятся.

При том что эти «пять контор» ворочают, значительной долей, американского бабла - не самый плохой вариант.

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

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

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

Да уж, привести корректную аналогию могут не только лишь все…

Токарник - узкоспециализированный станок, на котором делают фигуры вращения.

Фрезерный с ЧПУ - позволяет делать не только фигуры вращения но и много чего ещё.

Хороший 5Д-ЧПУ-фрезер позволяет сделать несколько операций без переустановки заготовки. Он работает медленнее человеков, но за счет того, что заготовку не переставляют, общеее время обработки детали оказывается меньше, а точность выше.

То что ты не видишь - не значит, что применения в этих областях нет.

В данном случае я не говорил об особенностях ЯП. Я говорил о том, что в обозримом будущем использовать Раст в проде - не практично.

Кто это сопровождать потом будет? Сколько сейчас программистов на рынке? Сколько вакансий на Раст сейчас есть?

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

Я решил, что школьнику так понятнее будет. Да и потом, большинство пользователей ЛОРа всё равно долбятся кто куда: кто в глаза, кто в другие отверстия. Не просто же так здесь в модераторы только макоюзеров берут!

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

Да уж, привести корректную аналогию могут не только лишь все…

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

Я говорил о том, что в обозримом будущем использовать Раст в проде - не практично.

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

Кто это сопровождать потом будет? Сколько сейчас программистов на рынке? Сколько вакансий на Раст сейчас есть?

В какой момент мы от обсуждения языка, перешли к бизнесовым вопросам? Но даже если так, то сейчас ситуация лучше чем лет пять назад, когда растоманов приходилось чуть ли не по чатикам вылавливать. Сколько вакансий не интересовался, раньше(судя по glassdoor и сейчас) криптаны в основном были, что отталкивало, встречаются бекендеры на нагруженный веб и железячники но совсем мало.

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

Еще раз, это не может ускорить ни С, ни Rust, потому что это не работает. «Изменений много – значит что-то ускорится» это бред.

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

На всякий случай дополню. Даже если код внутри unsafe является полностью валидным, он может приводить к UB, так как нарушает инварианты safe кода.

При этом составление любого списка UB заведомо провальная идея. UB само по себе есть порождение стандартизации, когда стандарт физически не может (редко – не хочет) что-то требовать от реализаций, потому что это вне их сил.

Rust определяется единственным фронтом к LLVM, остальные в зачаточном состоянии. UB в Rust растет именно отсюда – у него нет никакого контроля над тем, что происходит в LLVM после передачи туда кода. Потому что это сугубо вторичный язык. Поэтому в растбуке языка без какого-либо стандарта появляются упоминания UB.

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

Это не вопрос «веры».

Если бы оптимизация по хинту restrict работала, это приносило некоторую пользу в некоторых ситуациях. Небольшую, потому что модель компиляции Rust сходна, например, с крестовыми модулями, и анализатор в состоянии оценить тело функции самостоятельно.

Но она не работает. Она сломана в LLVM, и поэтому отключена в rustc.

И эксклюзивное владение x неэксклюзивное чтение в Rust никакого отношения к restrict не имеют, они появились из-за тотальной немощи borrow checker’а в анализ сколь-нибудь сложной модели владения. Впрочем, если анализатор неспособен выявить &mut borrow на два заведомо разных элемента массива, ему уж точно не до моделей владения.

Еще ты не ответил на вторую часть моего сообщения. Так вот, в Rust по определению нет inplace construction, что приводит к смешным проблемам, в общем случае никак не решающимся, а передача всего и вся по значению приводит к огромному количеству memcpy (3-6% времени исполнения), которое также невозможно соптимизировать, не переделав полностью модель языка.

Количество изменений относительно С никак не гарантирует качество или производительность.

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

Можно было сделать на си, на шелле, на питоне, но наиболее практично, единообразно для пачки линукосых железок и удобно - на расте.

Хорошо. Если работодатель/заказчик на это готов, - не вижу препятствий.

В какой момент мы от обсуждения языка, перешли к бизнесовым вопросам?

В тот мемент, когда меня назвали неосилятором, и я объяснил, что осваиваю инструменты под задачи, а не наоборот.

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

Нас в принципе мало. И тут сплошной unsafe, спидхаки, статическое выделение памяти и кодогенераторы, выдающие «безопасный» код «из коробки».

Rust не даёт значимых преимуществ в таких условиях.

shkolnick-kun ★★★★★
()
Ответ на: комментарий от Siborgium

Но она не работает. Она сломана в LLVM

Она не работает в LLVM.

в Rust

Мой аргумент не про раст. Я подсвечиваю, что от добавления «кто и как владеет данными с той и с другой стороны вызова» не так уж и «странно ждать каких-то ускорений». Без привязки к расту и LLvM, на C и C с другим дефолтом по рестрикту. А ты не можешь поддержать диалог, ты все про раст.

t184256 ★★★★★
()
Ответ на: комментарий от shkolnick-kun

В тот мемент, когда меня назвали неосилятором, и я объяснил, что осваиваю инструменты под задачи, а не наоборот.

Ты перед этим начал рассказывать про то, что «говно ваш раст», а когда тебе намекнули что ты вообще-то Карузо в перепеве Рабиновича только слышал, начал елозить.

Rust не даёт значимых преимуществ в таких условиях.

Он их не даёт на уровне регистросношания. Точнее там тебе сношают мозг unsafe штуками типа DMA - когда не было Pin - отхватить веселья было на раз, если не прибивать буфер гвоздями, что неудобно.

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

Есть ещё подход, с nrf* делали: брали их SDK с софткорами, обмазывали биндингами и вместо того чтобы страдать в железячных деталях - писали логику поверх.

Работа с железом сношанием регистров не ограничивается тащем.

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

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

на хорошо огороженной поляне нужен какой-нить байндинг к Qt, или вроде того, иначе поляна будет ориентирована на консоль.

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

alysnix ★★★
()

слушайте, а если я скомпилял на дебиане-11 через gfortran программу:

print *, "Hello World!"
end
она запускается и работает, а на других ОС она не запустится? например на виндавсе или например в другом линуксе? например в сусе там федоре и т.д.? Мне надо там перекомпилировать её из исходного кода в копиляторе для той системы?
на rust тоже так и на любом другом ЯП?

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

а на других ОС она не запустится

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

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

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

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

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

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

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

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

Но она не работает. Она сломана в LLVM, и поэтому отключена в rustc.

Разве? Вот есть такой пул реквест и он вмержен. Я тоже помню, что в расте эту штуку то включали, то отключали из-за проблем в LLVM, но осталось впечатление, что в итоге починили и включили. Я не прав?

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

Да ладно, там c 2015 можно делать вот так: https://github.com/rust-lang/rust/issues/25860

И тебе за это ничего не будет, конпелятор такое не детектит.

Насколько я понимаю, это и некоторые другие подобные баги вынудили создателей языка написать спецификацию (sic!).

Так глядишь, году к 2030 этот ваш раст выйдет из стадии альфа в стедию бета…

shkolnick-kun ★★★★★
()
Последнее исправление: shkolnick-kun (всего исправлений: 3)
Ответ на: комментарий от Dark_SavanT

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

Нет, бета версия, - это текущее состояние Nim, а раст ещё в альфе.

shkolnick-kun ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Есть ещё подход, с nrf* делали: брали их SDK с софткорами, обмазывали биндингами и вместо того чтобы страдать в железячных деталях - писали логику поверх.

https://tinygo.org/

https://micropython.org/

Что там у нас ещё есть???

А, Да!

https://blog.adacore.com/ada-on-any-arm-cortex-m-device-in-just-a-couple-minutes

shkolnick-kun ★★★★★
()
Последнее исправление: shkolnick-kun (всего исправлений: 2)
Ответ на: комментарий от fluorite

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

А вот, например, программист на плюсах, он как, привыкает? Ну, например, написав Foo foo = Foo("foo1"); когда само удалится Foo* ptr = new Foo("foo1");, когда надо удалить? А то вдруг привыкнет, особенно к этим всяким хипсторским смартпоинтерам и потом вдруг каак забудет delete вызвать!

На самом деле в конфликте раста и плюсов всё просто: оба этих языка используют одну и ту же модель управления ресурсами, владение + RAII. Эта модель требует от разработчика проектирования графа владения ресурсами. Разница только в том, что в плюсах эта информация хранится в голове разработчика + в комментариях или в доке, а в растишке - в самом коде. Нормальный, ответственный программист, естественно, будет рад возможности описать это всё строгим синтаксисом, а не текстом в доке/комментах, и ещё более рад тому, что слежением за полнотой и корректностью будет заниматься электронный болван. А рукожоп, наоборот, будет недоволен тем, что сволочной конпелятор его экзаменует на наличие вот этого самого графа владения да ещё и смеет указывать на противоречия в ней. В принципе есть ситуация, когда это действительно плохо, когда пишется неизвестно что с постоянным переделыванием архитектуры. Все эти новомодные agile и yagni. Для того чтоб это можно было делать на расте, необходима очень умная иде, которая будет прям проходить весь граф вызовов и заменять там ридонли указатель на изменяемый или borrowed ссылку на rc.

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

используют одну и ту же модель управления ресурсами

Ничего подобного. В плюсах можно

  • маллок/фри
  • нью/делит
  • RAII и юникптр
  • шаредптр на всё
  • арены
  • гц
  • не использовать динамическую память
fluorite ★★★★★
()
Ответ на: комментарий от shkolnick-kun

tinygo - глубоченная альфа, причём сам концепт go на контроллеры ложится так себе

micropython - в целом норм, но требует жирного контроллера. eLua и espruino туда же. В целом для быстрого прототипа или поэкспериментировать с какой-нибудь i2c/spi/etc хреновиной - норм тема, если подходящая отладка под рукой имеется.

Ада - это вот прям норм, при этом Adacore как раз занались на пару с Ferrocene пилением раста под mission critical. https://www.adacore.com/ferrocene

Dark_SavanT ★★★★★
()