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

Kde падает на амдгпу.

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

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

Ну это критично, конечно. У меня встройка, на ней вроде проблем нет.

Это же очевидно.

Да это всё для новых пользователей больше. Я вот знаю, что ripgrep круче и быстрей, но всё равно его не ставлю, я тоже к grep-у привык.

Человек всё равно не успевает с такой скоростью текст читать.

Я про то и.

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

А в случае alacritty мне нет разницы, отрисуется текст, который я никогда не прочитаю, за две секунды или за три с половиной.

А есть в природе транслятор из раста в си, чтобы нормальным компилятором собирать?

Очевидно тут только одно — у тебя есть сильные предубеждения.

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

Есть программы, которые упираются в скорость вывода терминала. Т.е. разница как раз таки у тебя будет в том, за сколько секунд такая программа выполнится в итоге. Но это происходит, если программа выплёвывает гигабайты текста, который по-хорошему надо просто в /dev/null перенаправить. Но если ты не перенаправил, то alacrity тут, вероятно, выиграет.

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

А вообще, я считаю, что терминалы, shell и утилиты было бы неплохо коренным образом переработать.

0. Нормальное современное редактирование вводимого текста. Ну это же бред, почему я не могу мышкой щёлкнуть в любом месте и переместить курсор туда. Почему нет выделения через shift?

1. Машиночитаемый выхлоп –help и автоматические подсказки всего на свете при вводе, подсветки неправильных опций, моментальное отображение релевантных порций мануала при наведении на опцию, например, вот это вот всё.

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

Это только то, что сходу в голову пришло. В общем взять терминал, взять все его плюсы и устранить все его минусы, вызванные дубовым tty из 80-х с помощью GUI.

Микрософт что-то такое пытались сделать с Powershell, но получилось так себе. Но это не значит, что нельзя сделать нормально.

Эмбедщики часто работают с терминалом железки через UART, предлагаешь отравить им жизнь своими нововведениями?

дубовым tty из 80-х

из 60-х

Какие количественные измерения ты предлагаешь? Сделать всякие zlib, libz, openssl, libpng, libjpeg, libicu статическими, пересобрать мир и посмотреть, насколько раздуется /usr/bin ?

Все мои нововведения обратно совместимы. Я же не предлагаю ничего особого, что может поломать что-то.

Как вариант, да.

это в нормальной разработке просто не требуется.

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

Нынче же ЯП достаточно продвинутые, чтобы

городить хтонический ужас на ровном месте.

вводить сахарок для частного случая

Странно, для бесконечного цикла вводить сахаров не поленились: loop

Странно, для бесконечного цикла вводить сахаров не поленились: loop

Скорее for/while это сахар для loop. xD

Перейди на for/while. В левом верхнем углу, возле «Run», нажми на «…» и выбери «HIR».

Эээээ, там какой-то особенный for и while? В чём смысл этих примеров?

В смысле, как это у них реализовано?

Эээээ, там какой-то особенный for и while?

loop низкоуровневая сущность.

for PATTERN in EXPR {
    BODY
}
// for превращается во что-то похожее на
match EXPR.into_iter() {
    mut iter => while let PATTERN = iter.next() {
        BODY
    }
}

while let PATTERN = EXPR {
    BODY
}
// while let превращается во что-то похожее на
loop {
    match EXPR {
        PATTERN => BODY,
        _ => break,
    }
}

for, while let и while синтаксический сахар для частных случаев.

Задачу нужно сначала описать по человечески, описав границы до которых должен вычисляться этот факториал

В примере задан диапазон для n через тип.

Упадет не через 1000, так через 10000 тысяч когда закончится память.

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

Для практического применения - расчёта рядов, наиболее подходящим выбором будет f64, о чём я говорил. Но легко можно посчитать и большие значения. Например, для n в диапазоне u32 (максимум которого больше чем «10000 тысяч») пример мог бы выглядеть так:

use std::ops::MulAssign;

pub struct FactResult{
    significand: u64,
    exponent: u64
}

impl MulAssign<u32> for FactResult {
    fn mul_assign(&mut self, rhs: u32) {
        while (u64::MAX / u64::from(rhs)) < self.significand {
            self.significand /= 10;
            self.exponent += 1;
        }
        self.significand *= u64::from(rhs);
    }
}

pub fn factorial(n: u32) -> FactResult {
    let mut res = FactResult{significand: 1, exponent: 0};
    for i in (1..=n).rev() {res *= i} res
}

Работает во всём заданном диапазоне n. Для u64 кроме экспоненты, вероятно, потребовалось бы ещё заложить экспоненту экспоненты. Но там проблема будет другая. Если для u32::MAX будет считаться несколько минут, то для u64::MAX будет считаться несколько десятков тысячелетий (если считать в лоб, а не воспользоваться формулой Стирлинга).

Но ещё раз повторюсь, что я понимаю, что типы аргументов в примере были выбраны, чтобы показать, что в Расте можно писать как в Лиспе. Только практического применения такой функции я не вижу.

Solana и экосистема вокруг нее пишутся на Rust.

Твой вопрос на самом деле звучит так: «А как мне в Rust выполнить небезопасную операцию, при этом не используя unsafe и не используя внешние библиотеки, которые инкапсулируют этот unsafe и предоставляют safe-API?» Ответ очевиден: «Никак».

https://research.kudelskisecurity.com/2021/06/30/oramfs-resizable-oram-remote...

ЛОЛЧТО???

В этой убогой хрени ещё и нормальной статики нет???

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

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

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

https://doc.rust-lang.org/reference/items/static-items.html

https://doc.rust-lang.org/reference/items/static-items.html#mutable-statics

Для потокобезопасности:

https://doc.rust-lang.org/std/macro.thread_local.html

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