Какие новые и полезные, известные, или хотя бы красивые программы написаны на Расте?

VLC например?

Нет. Kotlin. https://github.com/videolan/vlc-android

Понятно что это не отдельный проект, он скорее всего использует libvlc с коммуникацией через NDK. Но всё же это не NDK-only приложение.

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

не отслеживаю на чём софт пишут, нафиг такое задротство

А теперь немного D:

ulong factorial (ulong n) {
    return n == 0 ? 1 : iota(1, n + 1).reduce!((a, b) => a * b);
}

Но подожди, это же не Раст. Нельзя писать код не на Расте

Кто скозал?

Священное Писание

В общем, поставил я потыкать этот alacritty,

GPU-accelerated terminal emulator

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

emerge установки дополнительных зависимостей не потребовал, но при емерджинге ебилда оно вдруг резко начало откуда-то качать 100500 каких-то «крейтов», особенно таких нужных, как «winapi» и «ws2_32» (кстати, зачем эмулятору терминала линковаться с библиотекой сокетов винды, оно что, пароли отсылает куда-то?). Почему они все не оформлены как нормальные пакеты репозитория? Опять очередной язычок тянет свой пакетный менеджер и репозиторий, не такой, как у всех.

Конпелялось ожидаемо долго, дольше, чем можно ожидать от сборки эмулятора терминала.

Никаких настроек в гуе не видно, в мане опций настройки конфига тоже нет, красивостей нету, буковками консолечки в 3D посредством ускорения не крутит, ни к полезным, ни к красивым отнести это поделие нельзя. Снёс нафиг.

Это ты сейчас все ЯП со статической типизацией обосрал?)

Статическая типизация тут ни при чём. Никто не ограничивает вас типом u64. Напишите свой тип. И вот зачем они пишут, что n типа u64, если даже для u8 не способны ничего написать? Я уверен, что тот же fsb4000 легко сам напишет факториал, который будет работать до n, равный тысяче, например. На том же Расте. А большинство «растоманов» из этой темы сразу полезли в Интернет за готовым заклинанием.

Далее. Мне тут рассказывали о том, какая в Расте продвинутая система обработки ошибок. А тут выдали пример, который при большинстве входных значений уйдёт в панику. Только unC0Rr увидел эту проблему. Остальных ничего не смутило.

Да что там факториал до 1000. Я думаю, что, например, цикл for, работающий в обратном направлении (от 100 до 0, например) с шагом 5 большинство сами написать не смогут. Ну что это за системный язык, который для такого простого цикла не может обойтись без заклинаний для которого надо идти в Интернет?

Статическая типизация тут ни при чём. Никто не ограничивает вас типом u64.

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

Да что там факториал до 1000. Я думаю, что, например, цикл for, работающий в обратном направлении (от 100 до 0, например) с шагом 5 большинство сами написать не смогут.

https://doc.rust-lang.org/rust-by-example/flow_control/for.html

The for in construct can be used to iterate through an Iterator.

Любой кто умеет читать сможет.

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

И что же помешало так сделать? По заголовку функции получается, что я могу вводить n до 2^64. На деле оказывается, что это далеко не так, но даже никакой assert на это не намекает.

The for in construct can be used to iterate through an Iterator.

То есть мне надо сгенерить коллекцию, с помощью заклинания или другого цикла, а уже затем по нему идти итератором? Красота.

И что же помешало так сделать?

Там был диалог на тему читаемости кода.

То есть мне надо сгенерить коллекцию, с помощью заклинания или другого цикла, а уже затем по нему идти итератором? Красота.

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

Там был диалог на тему читаемости кода.

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

Если тебе нужна экзотическая интерация через хрен пойми что

Но ведь я попросил элементарный цикл, который в си пишется без проблем.

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

Нет, просто в том контексте это не имело смысла.

Но ведь я попросил элементарный цикл, который в си пишется без проблем.

for заточен под итераторы, есть while если с итераторами не привычно.

Но ведь я попросил элементарный цикл, который в си пишется без проблем.

for i in 1..=n {
}

дальше сам

Я думаю, что, например, цикл for, работающий в обратном направлении (от 100 до 0, например) с шагом 5 большинство сами написать не смогут.

Я тоже не знал как, потом погуглил:

fn main() {
    // step_by принимает значения типа usize, то есть >=0
    for x in (0..=100).rev().step_by(5) {
        println!("{}", x);
    }
}

https://rust.godbolt.org/z/fznKezaoa

Почему они все не оформлены как нормальные пакеты репозитория?

В Debian — оформлены как пакеты. Там заморочились возможностью сборки без доступа в интернет.

Конпелялось ожидаемо долго, дольше, чем можно ожидать от сборки эмулятора терминала.

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

свой пакетный менеджер и репозиторий, не такой, как у всех

Почему не такой, как у всех? Примерно такой, как у Emacs. Там тоже свои репозитории, в обход системных.

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

И так для каждой софтинки? Какая деградация. Зачем великие диды компутер-сайенса изобретали статические и динамические библиотеки?

Какая деградация. Зачем великие диды компутер-сайенса изобретали статические и динамические библиотеки?

Зачем? Чтобы преодолеть ограничения машин тех времён. А сейчас всё равно софт собирают с LTO, так что какая разница?

Кстати, ты поддерживаешь какую-нибудь разделяемую библиотеку, у которой с годами немного ломалось ABI? Другими словами, нужно ли было тебе когда-нибудь заморачиваться версиями символов?

А сейчас всё равно софт собирают с LTO, так что какая разница?

Ну как бы существование LTO не требует перекомпиливать все зависимости.

Кстати, ты поддерживаешь какую-нибудь разделяемую библиотеку, у которой с годами немного ломалось ABI? Другими словами, нужно ли было тебе когда-нибудь заморачиваться версиями символов?

Ломаешь ABI - выпускаешь новую мажорную версию, а как ещё

Нашёл тут такое

https://pingcap.com/blog/rust-compilation-model-calamity

The Rust Compilation Model Calamity
The Rust programming language was designed for slow compilation times.

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

и они хотят нас к этому приучить

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

Почему они все не оформлены как нормальные пакеты репозитория?

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

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

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

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

for x in (0..=100).rev().step_by(5)

О_о

Джон Бэкус, они всё просрали!

do i=100, 0, -5

Ну что это за системный язык, который для такого простого цикла не может обойтись без заклинаний для которого надо идти в Интернет?

Я тоже не знал как, потом погуглил

В Debian — оформлены как пакеты. Там заморочились возможностью сборки без доступа в интернет.

В gentoo оно тоже предварительно скачивается и сборка происходит без доступа в интернет. Просто распаковывается в нужное место внутри sandbox.

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

Ну что это за системный язык, который для такого простого цикла не может обойтись без заклинаний для которого надо идти в Интернет?

Я тоже не знал как, потом погуглил

Я не спец по расту :)

Программисты на расте смогли бы и без интернета написать такой цикл for.

Но это всё равно жесть какая-то.

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

А зачем? Это раньше считалось, что циклы идут по числам, поэтому в бейсиках и паскалях был специальный синтаксис для итераций вперёд и назад с произвольным шагом. Нынче же ЯП достаточно продвинутые, чтобы можно было итерироваться прямо по коллекциям, и вводить сахарок для частного случая с числами не имеет никакого смысла. По факту, не припомню ни одного случая за мою пятнадцатилетнюю карьеру, когда бы я написал цикл с шагом, отличным от 1 или -1, это в нормальной разработке просто не требуется.

удобный софт для работы с буфером обмена на wayland

Чувак, ну это же очевидное ненужно для ненужно.

Зачем тебе новые на Расте?

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

не общелисп, подлог

Божечки, на общелиспе это ещё понятнее

[1]> (defun f(n) (apply '* (loop for i from 2 to n collect i)))
F
[2]> (f 5)
120
[3]> (f 100)
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000

Ломаешь ABI - выпускаешь новую мажорную версию, а как ещё

Можно использовать ELF symbol versioning: для символа с одним и тем же именем можно сделать несколько версий с разным кодом так что старые версии программ будут работать. В Haiku это используется, в том числе для ядра.

Внимательно прочитай вопрос. Мне понятно зачем МНЕ новые на Rust и вообще человечеству. Вопрос уже обсудили 100 раз для тех кто реально хотел узнать.

Я спросил, зачем они ЕМУ если его задача просто кривляться на этом форуме.

Далее. Мне тут рассказывали о том, какая в Расте продвинутая система обработки ошибок. А тут выдали пример, который при большинстве входных значений уйдёт в панику. Только unC0Rr увидел эту проблему. Остальных ничего не смутило.

Нашел блин «проблему». Она на поверхности для каждого без лаптей на глазах. Это компромисс - включать эти проверки или нет. Задачу нужно сначала описать по человечески, описав границы до которых должен вычисляться этот факториал. Нету такой задачи чтобы не было границы. Упадет не через 1000, так через 10000 тысяч когда закончится память.

Садись, два.

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

Чувак, ну это же очевидное ненужно для ненужно.

В смысле ненужно?! У меня эта программа среди консольных, наверное, одна из самых популярных. Я скорей awk выкину, чем её.

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

Мне понятно зачем МНЕ новые на Rust и вообще человечеству. Вопрос уже обсудили 100 раз для тех кто реально хотел узнать

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

У меня эта программа

Какой это процент от 1%?

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

Вами бы столько усилий на борьбу с реальными проблемами потратить

зачем так яростно заниматься борьбой

А кто занимается борьбой? Троллинг растоманов это не борьба, а развлечение.

Думаю, в районе 500%.

Ну как бы существование LTO не требует перекомпиливать все зависимости.

Если хочешь воспользоваться преимуществами LTO, то требует. Всё больше и больше софта заморачиваются включением LTO.

Ломаешь ABI - выпускаешь новую мажорную версию, а как ещё

Как ещё? Как в libc6 и libstdc++, например. Никогда не заглядывал в ад, который в символах libstdc++ творится?

Если хочешь воспользоваться преимуществами LTO, то требует. Всё больше и больше софта заморачиваются включением LTO.

Не всем нужна LTO, что ещё сказать. Для кого-то время компиляции важнее.

libc6 и libstdc++

Но ты же не пишешь libc6 и libstdc++. И я не пишу.

Для кого-то время компиляции важнее.

Дебажные сборки и sccache решают эту проблему.

Но ты же не пишешь libc6 и libstdc++. И я не пишу.

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

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

Разница есть, в занимаемой памяти в RAM и сторедже

Круть, вейленд все ближе и ближе к готовности к моему рабочему десктопу

И ты, конечно, проверял.

Мне кто-то доказывал давно что оно типа быстрее вывод пишет.


Я сравнил у себя. На горячем старте 30мб текста судя по time xterm отрисовать быстрее.

Интересно правда почему вообще ультрабыстрый вывод килотонн текста считается большим плюсом.

А чего ещё не хватает?

Лично я ровно один косяк нашёл. Когда я включаю в браузере видео в full screen и переключаюсь на full screen игру, в ней становится 1 FPS. Если видео не разворачивать, то никакого влияния на FPS нет. Но то такое, случайно нашёл, обычно я так не делаю.