Rust 1.34

NonZeroI8

Што будет, если попытаться записать туда нуль, ну или вычесть два одинаковых таких числа?

Напишет что устарело и не шкомпилируется, ведь релиз был пол дня назад, пора обновлять стандартную библиотеку! https://doc.rust-lang.org/1.27.0/std/num/struct.NonZeroI8.html

Deprecated since 1.26.0: signed non-zero integers are considered for removal due to lack of known use cases. If you’re using them, please comment on https://github.com/rust-lang/rust/issues/49137

Наверное я неправильно перевел и понял, объясните!

Што будет, если попытаться записать туда нуль

NonZeroI8::new возвращает Option

вычесть два одинаковых таких числа

их нельзя вычитать без вскрытия контейнера

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

Наверное я неправильно перевел и понял, объясните!

Наверное, кто-то отписался в треде, и решили, что нужно.

This enables some memory layout optimization. For example, Option<NonZeroI8> is the same size as i8

Наверное, кто-то отписался в треде, и решили, что нужно.

Прекрасный способ разработки, царь то кстати прав был!

Што будет, если попытаться записать туда нуль

NonZeroI8::new возвращает Option

NonZeroI8::new_unchecked

NonZeroI8::new_unchecked

unsafe

https://play.rust-lang.org/?version=beta&mode=debug&edition=2018&... — угу (что-то бета канал стоит, но это неважно)

вычесть два одинаковых таких числа

Этот тип не реализует арифметические операции.

В stable их никогда не было. А тем, кто использует nightly, обновлять стандартную библиотеку — не привыкать.

андефайнед бихейвор :)

Неужели нормальная новость про rust, запарили эти ваши простыни.

Господи, какое говно эта ржавчина.

Так и приходится писать на C++.

Где же мой нормальный язык с совместимостью с C++ на уровне модулей(не синтаксиса), вычислениями и рефлексией во время компиляции, подходами новых вменяемых языков(Kotlin, Swift), хорошим статическим анализом (возможно DbC времени компиляции) и пр.

Почему когда берутся за замену Си и Крестов, делают херню? Сначала go, который разве что питон способен заменить, потом rust с инопланетным синтаксисом, компилятором-параноиком и костылем unsafe, без которого сложнее hello world ничего не написать, и абсолютно нестабильным языком и библиотекой. Жесть какая-то.

Разве это плохо когда компилятор ловит потенциальные ошибки?

Он не просто ошибки ловит. Он тебя ограничивает в возможностях, потому что они нормальный статический анализ не осилили. В итоге лучше взять C++, а в систему сборки и свой CI вкрутить clang-tidy, coverity, PVS studio и пр.

Nim не подходит?

Ну тут я ничего сказать не могу. Мне вот только интересно в каких это случаях компилятор вас ограничивал? Я спрашиваю только из личного интереса

сложнее hello world ничего не написать

про декомпозицию слыхал?

unsafe, без которого сложнее hello world ничего не написать

Можете написать, на основании чего сделаны подобные выводы?

http://www.lorquotes.ru/view-quote.php?id=1081

Nim не подходит?

Там же GC и не опциональный. Тогда проще взять Swift или даже Kotlin(native).

То ли Евгений Ахотникау забыл залогиниться…

А вы писали на Rust? И если да, то после какого языка? После C++ - мрак.

И это я не говорю про ООП, шаблоны и исключения. Уже перебора с владением достаточно для критики.

Замена C++ должна уменьшать стоимость и время разработки, а не увеличивать.

И что? Это избавит меня от unsafe? И он, кстати, до сих пор так и не «загрязняет» функцию, в которой используется?

он просто придумывает, а сам пишет максимум фигню на похапешечке.

У нас наша фирмварь для IP-камер шикарно на расте поживает.

Бред про «чем же нам плюсы заменить» ничего кроме улыбки не вызывает.

Уже перебора с владением достаточно для критики.

Интересно почитать вашу критику.

Да троллит он просто.

У нас наша фирмварь для IP-камер шикарно на расте поживает

Так не от языка зависит, что там и как поживает. Полно проектов, которые чудесно живут на плюсах и даже на голом Си.

Так уже суть сказала, кто писал на крестах и на расте, тот поймет.

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

Бред про «чем же нам плюсы заменить» ничего кроме улыбки не вызывает.

А чего так? Там даже конкретные требования указаны.

Так уже суть сказала, кто писал на крестах и на расте, тот поймет.

Я вас не понял. Может вы сильно привязались к C++?

Может вы сильно привязались к C++

Пишу так же на Python, Kotlin(раньше на Scala), скоро будет проект на Swift( пока теоретически знаю только) - хорошие инструменты. На go пара мелких микросервисов(но go тоже не нравится). Так что вряд ли тут дело в привязанности.

По-моему известного примера с двумя итерациями по сектору уже достаточно, чтоб задуматься.

сектору=вектору

Да я после C/C++ и не так уж все и плохо, разве что было непривычно с владением

Python, Kotlin, Scala, Swift

Все перечисленные языки имеют поддержку «классического» ООП.

go тоже не нравится

В Go, также как и Rust, этой поддержки нет.

Может с этим связано ваше отвращение к этим языкам? Вы привыкли к наследованию и вам трудно спроектировать систему иначе с использованием иных средств?

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

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

Вы привыкли к наследованию и вам трудно спроектировать систему иначе с использованием иных средств?

А давайте начнем с вопроса зачем проектировать иначе?

Для себя еще Haskell использовал. Никаких претензий, красивый язык. Там ООП нет.

На го не писал, ничего тут сказать не могу

Чтобы получить на выходе иную систему с иными качествами?

За счет чего?

За счёт использования иных подходов?

По-моему известного примера с двумя итерациями по вектору уже достаточно, чтоб задуматься.

Можно его привести?

let a = vec![1, 2, 3, 4, 5];
for i in a {
    println!("{}", i);
}
for i in a {
    println!("{}", i);
}

И да, понятно почему так. Но это мало что меняет.

За счёт использования иных подходов?

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

a.iter()

let a = vec![1, 2, 3, 4, 5];
for i in a.iter() {
    println!("{}", i);
}
for i in a.iter() {
    println!("{}", i);
}

И все работает