Pull to refresh

Comments 37

http://www.ncameron.org/blog/rustfmt-changes


Хочу отметить что для своего проекта уже почти месяц как пользуюсь rustfmt-nightly и в целом оно вполне хорошо уже и сейчас работает. А nrc еще и активно его пилит — с каждой новой версией единый стиль форматирования ржавого кода становится все ближе и ближе.




Кстати, с удивлением понимаю что даже в рамках ржавого сообщества совершенно не известна такая отличная штука как cargo-apk, которая сама из обычного графического glutin-приложения собирает apk под андроид. Для ее работы надо или просто поставить sdk/ndk, или использовать стандартный докер-образ. Очень рекомендую ознакомиться :)

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


Ну и #[cfg_attr(rustfmt, rustfmt_skip)] никто не отменял, особенно если требуется еще большие массивы вставить :)

Да меня тоже дефолтный вариант вполне устраивает, а вот rustfmt_skip как раз не особо нравится: его на целую функцию вешать придётся. Можно, конечно, вынести создание массива в отдельную функцию, но это уже много лишних действий. Да и есть опция array_horizontal_layout_threshold, но пока только в "ночном" формате.

Ну я не буквально про всех, конечно) Просто по разговорам понял что многие, кому я говорил о нем в чатиках тут и там, про cargo-apk слышали впервые.

UFO just landed and posted this here
Так там же сам компилятор очень серьёзно статически анализирует код :)
В Расте довольно сложно написать херню.
Очень легко, как минимум в unsafe. А вообще, как вы выразились, «херня» понятие растяжимое.
Очень легко, как минимум в unsafe.

На то он и unsafe.


Но по этому повод есть мысль: в большом проекте на все файлы должно распространяться #![deny(unsafe_code)], а на пару файлов с необходимыми unsafe-абстракциями CI-робот должен требовать r+ от пары старших разработчиков проекта.


А вообще, как вы выразились, «херня» понятие растяжимое.

А так — да, проще всего вспомнить про ту же возможность утечки памяти в безопасном коде.

если ли для него что-то подобное инструментам Frama-C для языка C и SPARK для языка Ada?

про формальную верификацию вот тут — https://brson.github.io/2017/07/10/how-rust-is-tested#s-form — есть актуальные сылки. В частности на rustbelt.


Но, насколько я знаю, это пока все очень сырое.

А, еще из обновок за этот месяц: выкатили альфа версию официального расширения для vscode — rls-vscode. Работает через RLS, само собой, пилится его же авторами. Пользуюсь пока полторы недели: не без шероховатостей (в них обычно виноваты недоработки RLS), но в целом опыт более положительный чем с vscode-rust и выглядит как-то перспективней.

Я последнее время использую плагин от Калиты. В чем отличия и имеет ли смысл перелезать на официальный вариант?

Прямо сейчас может и не имеет особо смысла прыгать. Из мгновенных последствий перехода — с ним RLS чуть реже падает. Но вот в будущем мне верится что rls-vscode станет доминирущим просто из-за официальной поддержки — его пилят те же чуваки что и RLS, так что это расширение с самого начала полностью полагается на RLS, очень тесно с ним интегрировано и фактически является просто тонким клиентом к нему, почти без своей логики на typescript.

В оригинале статьи, если я все правильно понимаю, неточность:


union MyUnion {
    f1: u32,
    f2: f32,
}

fn main() {
    let mut u = MyUnion { f1: 1 };
    u.f1 = 5;
    let value = unsafe { u.f1 };
    println!("value = {}", value);
}

https://play.rust-lang.org/?gist=fd55cfbbcfca58df996eae30fa6446f6


^ запись Copy-полей работает без unsafe, а только такие поля сейчас и разрешены (реддит).

Как-то странно это выглядит. Можно в итоге при записи вытворять поведение которое создаст баги и компилятор в итоге ничего не скажет https://play.rust-lang.org/?gist=f991ba49c62230c6b876a4755ba5ae08&version=stable

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

Ну мне кажется странным то что запись является safe. По факту и то и другое в совокупности является unsafe.
Хотя само чтение уже всё же привлекает внимание что нужно быть осторожным.

Но запись никак не может повредить программе. А вот чтение — очень даже может.

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

UFO just landed and posted this here
Зачем привлекать? Мотивация очень простая: а не то придется писать на плюсах и потом ловить сегментации на проде.
UFO just landed and posted this here
Для системного программирования раст хорош тем, что лучше продуман в плане безопасности. Если си подходит к решению задачи «можно все, но если напортачишь — ты ССЗБ» — то раст подходит к решению этой задачи с обратной стороны. Запрещено все, исключая белый список. Есть проверки выхода за границы массивов и тд. И поэтому ты не напортачишь так чтоб совсем все плохо стало. Вызвать сегментацию или UB можно только используя блок unsafe. И эти блоки — маленькие.
Кроме того, есть мелкие ништяки: например стрикт алиасинг в си идет для единиц трансляции, а в раст — каждом месте использования. Указатели на виртуальную таблицу в раст хранятся вместе с указателем, а не с данными (свои плюсы и минусы).

То, что BSP написаны на С — тоже не технический момент, а «организационный», и исторически сложившаяся в текущий момент времени данность. Раст, кстати, сопрягается с другими языками. В первую очередь с си. Так что вобщем «в железо» это тоже можно шить, теоретически. Но там скорей всего придется шпарить без растовской stdlib.

Думаю, си и плюсы — устарели, и их преимущество лишь в том, что к ним много написано кода и много есть специалистов.
UFO just landed and posted this here
Специалисты бывают двух типов:
1 — я знаю технологию Х — буду делать на ней и ничего нового ненужно
2 — появилась технология У, которая лучше Х, давайте все перепишем на У

Первый тип никак не переманишь — второй сам перейдет и будет влиять на приток новых специалистов.
UFO just landed and posted this here
Есть ещё третий тип: Я никогда этого не делал, на чём мне его сделать? Выбираю…

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

Ничего не мешает на нем писать прикладное ПО. У меня уже несколько клиент-серверных приложений, где и сервер и клиент написаны на Rust.
loop, возвращающий значение, это что-то взрывающее мозг.

let the_answer_to_everything: i8 = loop{ if false {break 42;}};

То есть мы записываем значение 42 в the_answer_to_everything, но только никогда.

я надеюсь что clippy скоро подтянется и будет ругаться на такое. как раз для него задача


Так-то этот код особо не отличается от старого


let the_answer_to_everything: i8;
loop {
    if false {
        the_answer_to_everything = 42;
        break;
    }
}
Я это понимаю, но экзестенциальная проблема остаётся: loop возвращает значение, не смотря на то, что он бесконечный цикл.

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


fn f(should_stop: bool, n: i64) -> i64 {
    if !should_stop {
        f(should_stop, n + 1)
    } else {
        0
    }
}

fn main() {
    let n = f(false, 0);
    println!("n = {}", n);
}

Тоже вот ожидается что функция вернет значение, а она стек лопнет и грохнет все. Был бы стек бесконечный или сработала бы хвостовая оптимизация (edit: в release сборке срабатывает, кстати) — был бы полный аналог кода с loop.


^ Без should_stop булки, кстати, будет предупреждение warning: function cannot return without recurring — приятная мелочь.

Вы описываете другой случай: по синтаксису функция должна возвращать значение, а она делает сайд-эффект. В принципе, это вопиюще, но все привыкли.

А вот к обратному не привыкли: с точки зрения системы типов у меня написано, что бесконечный цикл возвращает значение. Это что-то из матанализа — после того, как мы n устремили к бесконечности, мы получаем результат и добавляем его к значению другой величины.
Sign up to leave a comment.

Articles