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

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

Твой любимый цепепе _пытается_ в move-семантику.

Вряд ли цепепе может быть любимым. Он просто лучше rust.

move-семантику, заметь, c++ осилил без поломки старого кода.

Попутно разрешая оставлять объекты в невалидном состоянии.

При нормальном дизайне ничего не случится, а если пропустишь, то проблемные места статические анализаторы покажут.

В C memmove тебе тоже не нужен, только deep copy на каждый чих - только хардкор?

Неявный? Не нужен.

Да я вот тоже не могу понять, зачем ты просишь комптлятор поглотить объект

Я ничего не просил. Это же обычный for in цикл, кому в голову пришло сделать такие правила языка, чтобы он неявно объекты захватывал и уничтожал?

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

Лучше чем? Что ты его знаешь? Другой причины нет. Раст сосёт ровно по одному параметру - отсутствию некоторых библиотек, да и то - не особо. А дешёвое перемещение лучше дорогого копирования и неявного вороха ссылок.

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

Да я вот тоже не могу понять, зачем ты просишь комптлятор поглотить объект

Я ничего не просил. Это же обычный for in цикл, кому в голову пришло сделать такие правила языка, чтобы он неявно объекты захватывал и уничтожал?

for ничего не уничтожает; если ты создал объект, и им никто не владеет, то его логично уничтожить. Также компилятор подчищает все созданные объекты, не имеющие биндинга, в конце каждой строки кода. И цикл ничего не захватывает, он работает с итератором, который ты ему подсунешь. Да, есть «подкапотные» правила, позволяющие подсунуть ему объект, а не итератор, и вместо for i in vector.into_iter() писать просто for i in vector, или for i in &vector вместо for i in vector.iter(), но если это слишком сложно для тебя…

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

Да что у вас за секта такая? Вам не о том, сложно или просто, понятно там или нет и пр. Даже крестовики так не оправдывают треш в плюсах.

Так а что тебе надо? Ты ж сформулировать не можешь. У ЯП версия 1.34, усеки, пожалуйста; все претензии к дизайну можешь смело отправлять в «СпортЛото» или в журнал «Мурзилка».

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

Он тебя ограничивает в возможностях, потому что они нормальный статический анализ не осилили.

И конечно-же будет сразу пример на Rust. И на С++ с нормальным статическим анализом

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

Парадокс Блаба всё ни как не отпустит плюсоводов

Я так понял, тот анон вполне себе юзает другие языки. Да и в раст разочаровался только после использования его на практике. Парадокс блаба тут ни при чем.

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

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

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

Ну кроме совсем ванильных языков надстроек. Мол писал на Java, попробовал Kotlin

Котлин не только Java. Знакомый перешел с objective-c на kotlin native и рад. Правда я так и не понял, почему не swift, но это совсем другая история. Котлин действительно хорошо задизайнен. А Rust - спорно.

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

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

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

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

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

Ada давно существует, бери и пиши.

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

В C++ нет модулей.

В C++20 будут. Но думаю, имелось в виду простая возможность подключить С++ файлы и библиотеки через систему модулей такого языка.

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

На самом деле нет, активно трогал оба, гораздо более лучше сделали.

В Rust borrow checker отслеживает время жизни объекта, а не переменной, и move-присвание (которое by default, к тому же) делает простой memmove и забывает про источник. Ничего занулять не надо т.к. деструктор не вызывается.

В С++ компилятор не в состоянии отследить время жизни объекта, поэтому есть требование оставлять переменную-источник в empty-but-valid состоянии, к которому потом применяется деструктор, что с одной стороны сказывается на производительности, а с другой стороны требует ручного написания move-конструкторов и move-присваивания.

Ну и сама ситуация, когда у тебя по дефолту работает дорогущее копирование, а для эффективного move надо что-то дописывать, довольно неудачная для системного ЯП.

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

Разве есть нормальный статический анализ для C++, покрывающий 100% фич языка? Для C я такое видел, для C++ — нет.

Как показывает опыт, при подключении какого-нибудь Boost с адовым трешем из темплейтов, статический анализ либо затыкается, либо выдаёт 100500 false positive.

Плюс к этому, из твоих комментов складывается впечатление, что ты контролируешь 100% кода в твоём проекте, что при наличии сторонних зависимостей далеко не так. Плюшка Rust в том, что проверяется не только твой код, но и код зависимостей. Да, тут можно сказать, что в какой-нибудь библиотеке может быть адская содомия из unsafe и жонглирования сырыми указателями, но такое очень маловероятно.

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

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

Для этого есть cargo-geiger.

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

«современный C++» безопаснее раста.

Не безопаснее, но вполне сопоставимо. Особенно если учесть современную культуру разработки(юнит тесты, автотесты, код ревью), вездесущий CI с его автоматическими прогонами и статических анализаторов и санитайзеров, да и про фаззинги всякие забывать не стоит.

Ну серьезно, того C++, которым так пугают растоманы, давно уже нет. Возможно, еще есть островки легаси, ну так там никто и не перейдет на раст.

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

Выше уже правильно написали, что гарантии раста распространяются не только на ваш код, но и на все зависимости.

Ну а стат. анализаторы для плюсов в принципе не могу дать тех гарантий, что даёт раст.

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

Тут лучше было бы привести иной пример. У тебя здесь не работает из-за ссылок, это не про синхронизацию. Лучше бы сразу через Cell показать, что просто так нельзя из разных тредов обращаться к одним данным(без имплементации Sync).

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

что толку от этих гарантий?
пока что на русте никто кроме кучки фанатов и мозиллы не пользуется
ну да, все те о ком вы подумали это именно кучка фанатов

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

Ну а стат. анализаторы для плюсов в принципе не могу дать тех гарантий, что даёт раст

Раст ограничивает тебя ссылками, временами жизни(особенно, если сам не может вывести) и пр.

Кстати, не всегда понятно, что и почему работает или нет.

fn foo(x: &mut i32)
{
    println!("{}", x)
}

fn bar(x: &mut i32)
{
    foo(x);
    foo(x);
}

Сможешь без шпаргалки сказать, работает ли и почему?

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

да да я другой аноним, я тот который год назад уже заходил в подобную тему
и говорил что даже через год раст будет в задней трубе
на этот раз я открыл гласдор(вместо хаха ру), вбил rust и с тысячи найденных вариантов, по просмотренным первых 200
чистых вакансий по расту нашел аж целых две
одна из них в мозилле, вторая в кракене
все остальные вакансии либо какой то кривой матчинг
либо это смесь rust/C/C++/java/ruby/php/javascript/итд
у вас есть математические знания что бы просчитать дальнейшую тенденцию ?
поэтому все ваши игры слов о том что там в расте лучше чем С++ нужна только для вашего чсв на фоне агонии

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

Раст ограничивает тебя ссылками, временами жизни(особенно, если сам не может вывести) и пр.

Время жизни такое же как и в C++, только тут компилятор его проверяет.

Кстати, не всегда понятно, что и почему работает или нет.

И почему меня это должно волновать.

Сможешь без шпаргалки сказать, работает ли и почему?

Нельзя дважды использовать мутабельную ссылку? Код не запускал.

RazrFalcon ★★★★★ ()