LINUX.ORG.RU

Rust 1.34

 ,


2

11
  • cargo теперь умеет в сторонние репозитории

  • оператор ? теперь может использоваться в доктестах

  • стабилизированы трейты TryFrom и TryInto

  • стабилизированы типы AtomicU8AtomicU64 и AtomicI8AtomicI64 в дополнение к имевшимся ранее Atomic{Bool,Ptr,USize,ISize}

  • стабилизированы типы NonZeroI8NonZeroI128 и NonZeroISize в дополнение к имевшимся ранее беззнаковым аналогам

https://blog.rust-lang.org/2019/04/11/Rust-1.34.0.html

★★★★★

Последнее исправление: MyTrooName (всего исправлений: 3)

NonZeroI8

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

Crocodoom ★★★★★
()
Ответ на: комментарий от Crocodoom

Напишет что устарело и не шкомпилируется, ведь релиз был пол дня назад, пора обновлять стандартную библиотеку! 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

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

Deleted
()
Ответ на: комментарий от Crocodoom

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

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

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

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

MyTrooName ★★★★★
() автор топика
Последнее исправление: MyTrooName (всего исправлений: 3)
Ответ на: комментарий от Deleted

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

anonymous
()
Ответ на: комментарий от Deleted

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

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

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

MyTrooName ★★★★★
() автор топика
Последнее исправление: MyTrooName (всего исправлений: 1)
Ответ на: комментарий от MyTrooName

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

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

Deleted
()
Ответ на: комментарий от Crocodoom

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

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

anonymous
()
Ответ на: комментарий от Deleted

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

anonymous
()

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

anonymous
()

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

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

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

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

anonymous
()
Ответ на: комментарий от snake266

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

anonymous
()
Ответ на: комментарий от anonymous

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

snake266 ★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от Deleted

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

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

anonymous
()
Ответ на: комментарий от snake266

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

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

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

anonymous
()
Ответ на: комментарий от MyTrooName

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

anonymous
()
Ответ на: комментарий от MyTrooName

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

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

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

max_lapshin ★★★★★
()
Ответ на: комментарий от max_lapshin

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от max_lapshin

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от snake266

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

anonymous
()
Ответ на: комментарий от anonymous

Python, Kotlin, Scala, Swift

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

snake266 ★★
()
Ответ на: комментарий от snake266

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous
let a = vec![1, 2, 3, 4, 5];
for i in a {
    println!("{}", i);
}
for i in a {
    println!("{}", i);
}

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.