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

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

sway и чуть меньше чем вся связанная с ним экосистема, например

если ничем не отличается, зачем он тогда нужен? :P

так они i3 переписали)

да почти все

относительно момента создания языка C, ядро Linux - новый проект

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

А что, существует каноничный лисповый способ расстановки скобочек?

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

С по сравнению с ассемблером - язык более высокого уровня, а Раст - приблизительно того же.

С т.з. класса грамматики - да. Но то же самое можно сказать для любого современного ЯП, ссылаясь на первые высокоуровневые ЯП (фортан, лисп, кобол). К тому же, сишка K&R - это то еще г. мамонта, ведь это не тоже самое, что C99. На счет сишки, он решила проблему портабельности, других колоссальных задач он и не собирался решать. Т.е. теперь для любого системного или околосистемного ЯП - поддержка основных пары-тройки аппаратных платформ - это must, и дальше можно другие задачи решать, например, безопасность, для чего и нужен раст.

Ведь можно было бы написать

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

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

Че тогда на асме не разрабатываешь

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

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

Не ради изотерического синтаксиса же новые языки придумывать. Всё авторы — серьёзные люди, вышедшие из Bell Labs, включая автора C и Unix — Томсона, а не клоуны с подворотами и не кукаретики.

А что, существует каноничный лисповый способ расстановки скобочек?

Да, как в моем примере.

есть строки

А ведь в Расте вроде бы тоже есть. Причем много всяких %)

Факт есть фактом, ripgrep быстрее

Быстрее чем что? Машкод, процессор небо, Аллах! ? Быстрее за счёт чего? Аргумент фанатика.

Самое большое отличие в движке регулярных выражений.

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

Не знаю была ли польза от Rust в многопоточности

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

Они и написали кучу файндов и грепов со вкусом банана, ты просто не сечёшь!

@WicherGeralt Harald

https://zaiste.net/posts/shell-commands-rust/

Так и есть, посмотрите и используйте вместо ls, cat и остальных :)

bat is a cat clone with syntax highlighting and Git integration

Звучит как анекдот.

совместимость i3 там маловажная деталь, а главное - написанная с нуля реализация вяленого в виде библиотеки wlroots. Сейчас на нее даже kwin-ft переезжает (форк kwin от в прошлом одного из главных контрибьюторов проекта).

Еще из новых сишных проектов например, s6 активно пилится. Сейчас это просто супервайзер процессов, но в недалеком будущем превратится в полноценную систему инициализации и замену systemd. Кто варил докер-контейнеры с ним тот знает, насколько это крутая вещь.

Еще из новых сишных проектов например, s6 активно пилится. Сейчас это просто супервайзер процессов, но в недалеком будущем превратится в полноценную систему инициализации и замену systemd.

нифига себе новости

ну разраб уже объявил об успешном сборе средств, а судя по его предыдущим проектам и в целом репутации, такие заявления - нифига не шутка

Мне больше понравился tokei:

tokei is a program that displays statistics about your code. It shows the number of files, total lines within those files and code, comments, and blanks grouped by language.

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

#!/bin/sh

texs=`find . -name "*.tex" -exec cat {} \; | wc -l`
if [ -a "metrics.txt" ]; then
   rm "metrics.txt"
fi

printf "Lines in .tex files: %q\n" $texs >> metrics.txt

ms=`find . -name "*.m" -exec cat {} \; | wc -l`
printf "Lines in .m files: %q\n" $ms >> metrics.txt

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

нашел что сравнивать, sh и раст…. по количеству строк кода….

Может прозвучать наивно, но разве в данном случае это не значит, что sh позволят выполнить эту задачу быстрее и за меньшее кол-во кода?

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

Ололо, 4 тысячи строк на такое. Вообще, tokei штука полезная, я как-то собирал. Но не настолько полезная, чтобы я когда-нибудь притащил в систему Rust и собрал его ещё раз.

sway

Можно сказать, что это i3 переписаный с иксов на вейланд, а по критерию Harald это не тру

относительно момента создания языка C, ядро Linux - новый проект

Ну ты намекал в ОП, что раз нет проектов по критерию, то значит Раст не годится. Но если по критерию нет проектов на C тоже, то критерий говно значит и что сишечка может уже не годится, например раньше рулила, а сейчас вытеснена другими ЯП, как случилось с FreeBSD)

Но если по критерию нет проектов на C тоже

mesa, pulseaudio, systemd, pipewire, runc, curl, libsodium… Дальше продолжать?

mesa, pulseaudio, systemd, pipewire, runc, curl, libsodium… Дальше продолжать?

Ну из недавних только pipewire, runc, libsodium, и не сказал бы, что они полезные-известные. Если в тред скинуть подобные проекты на расте, сразу же сказали бы хипсторская фигня) И да, это переписаные другие проекты)

Где новые базы данных, IDE, DE, CAD-ы, графические, видео и аудио

редакторы на расте?

Новое теперь пишут на Go:

• Torrent-клинет distribyted, позволяющего обращаться к содержимому торрентов как к части файловой системы с загрузкой данных по мере необходимости
• СУБД immudb 1.0, гарантирующей неизменность и сохранение всех когда-либо добавленных данных
• децентрализованная файловая система IPFS 0.7 (InterPlanetary File System), образующая глобальное версионированное хранилище файлов
• СУБД Dolt, позволяющая манипулировать данными в стиле Git
• SFTPGo 1.0, позволяющий организовать удалённый доступ к файлам при помощи протоколов SFTP, SCP/SSH и Rsync
• LazySSH - специализированный SSH-сервер для запуска временных виртуальных машин
• OpenDiablo2 - игра

И еще сотни другого.

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

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

всё же посмотри

fn factorial(n: u64) -> u64 {
    (1..=n).reduce(|a, b| a * b).unwrap_or(1)
}

Теперь понятно, почему Царь называет Раст скриптухой. Сходу вижу три проблемы:

1. Этот код как-то поймут лисперы и питонщики, которым Раст не нужен. Для сишников или паскалистов, которые могли бы перейти на Раст, это - нечитаемая лапша. Неясно, на кого подобный код рассчитан.
2. Для каждой итерации мы вызываем лямбду и проверяем на ошибку. Неэффективно для системного языка.
3. При n > 65 аналогичный код на Питоне продолжит нормально работать. А этот код, вероятно, нет. То есть это даже не скриптуха, а пародия на скриптуху.

Где новые базы данных, IDE, DE, CAD-ы, графические, видео и аудио редакторы на расте? Игровые движки? Кодеки? Чтобы скептики прониклись мощью и безусловными преимуществами сабжа и уверовали в него?

Интереснее всего было бы, если бы LLVM переписали на Расте.

Для каждой итерации мы вызываем лямбду и проверяем на ошибку. Неэффективно для системного языка.

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

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

вот проверка что функции возвращают одно и тоже:

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

https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/35

Патч висит. Автор не допиливает его, никто другой подхватывать не хочет. Если хочешь - собирай с ним сам. Он работает.

gill_beits он?

Какой то троллфест ИТТ

еды давно не было

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

Кстати, да. Код перестанет нормально работать уже при n > 20. Результат типа числа с плавающей запятой продержится намного дольше.

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

1. Это скорее характеризует «сишников и паскалистов» а не раст.
2. Всё прекрасно инлайнится
3. Этот код вызовет панику. Но подключить какой-нибудь bigint (или uint) крейт и заменить u64 на U512 дело пары минут.

Всё прекрасно инлайнится

fsb4000 показал, что это не так.

заменить u64 на U512 дело пары минут

И продержимся до 99 где-то. f64 в этом смысле лучше, ибо продержится до 170, а затем уйдёт в бесконечность.

Но согласен, что это придирки.

На растовый я даже смотреть не хочу.

всё же посмотри
fn factorial(n: u64) -> u64 {
(1..=n).reduce(|a, b| a * b).unwrap_or(1)

Я уже полоскал косточки расту по этому поводу. Давай для начала посмотрим на факториал в Си:

int64_t factorial(int64_t n)
{
    return n <= 0 ? 1 : n * factorial(n-1);
}

Вопрос: чем здесь Rust удобнее/надежнее/быстрее? Пример очень маленький, потому проблемы раста не развернулись во весь рост, но их видно, тем не менее. Посмотрим на факторил на F#:

let factorial n = [1..n] |> List.reduce (*)

Самые веселые факториалы получаются на хаскеле (4 варианта):

factorial = product . flip take [1..]
factorial n = if n == 0 then 1 else n * fact(n-1)
factorial n = foldl(*) 1 [1..n]
factorial n = product [1..n]

Факториал на Rust так же многословен и негибок, как факториал на Си, те же проблемы с отсутствием вывода типов, и стоящая поперек горла обработка ошибок.

Ты обосрался в каждом замечании

1. ФП уже есть везде и его знают даже в медведи в лесу, и даже последние джависты, а джависты - самые последние люди.

2. Учи матчасть и как работает инлайн

3. Код на Python не эквивалентен. Посмотрим как сработает numpy.uint64

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

На большие библиотеки на расте без слез уже тяжко смотреть. Поскольку они утоплены в многочисленных бесполезных объявлениях — растолюбов это не смущает, поскольку они, в большинстве своем, пришли с С++, где либы тоже такие же многословные и нечитаемые.

А как мне глобальный конфиг в проге без срани с unsafe написать?

В C++, Oberon, Go можно, а в Расте нельзя? Оно какое-то совсем ненужно получается.

В C++, Oberon, Go можно, а в Расте нельзя? Оно какое-то совсем ненужно получается.

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

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

Это скорее про код на Си вроде ядра Линукс и GTK, там надо тонны boilerplate кода для того чтобы руками управлять памятью и делать таблицы виртуальных методов. C++ может сгенерировать тот же машинный код с в разы меньшей длинной исходного кода.

Это скорее про код на Си вроде ядра Линукс и GTK, там надо тонны boilerplate кода для того чтобы руками управлять памятью и делать таблицы виртуальных методов. C++ может сгенерировать тот же машинный код с в разы меньшей длинной исходного кода

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