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

Ответ на: комментарий от 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Python, Kotlin, Scala, Swift

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous ()