Опубликован релиз языка программирования общего назначения Rust 1.85, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Кроме штатного номера версии 1.85 выпуск обозначен как Rust 2024, что знаменует стабилизацию изменений, предложенных за последние три года. Редакция языка "Rust 2024" станет основой для наращивания функциональности в последующие три года, по аналогии с тем, как выпуск Rust 2021 стал базисом для развития языка в прошедшие три года...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62769
К сожалению, try блоки так и не добавили. Сколько лет уже с такой мелочью тянут.
Сможешь описать, кратко, какая функциональность будет привнесена try блоками?
Чтобы если у падает растовый код, то падал осмысленно, а не в панике.
Хотя...
Может боятся, что будет try{ unsafe{ try{ ... } } } ?
Rust итак обязывает обрабатывать все возможные ситуации поведения кода. Добавить смысла можно через match возможных значений.
> Rust итак обязывает обрабатывать все возможные ситуации поведения кода.
> Добавить смысла можно через match возможных значений.И как ты корректно panic() в хрусте обрабатывать собрался? В ядре по этому поводу некую хтонь try* сделали. Когда оно таки может быть - null - и надо - проверять. Чем это от сишки отличалось - я так и не понял, семантика та же самая, чуда не произошло.
А try видимо - чтобы попробовать вот что-то такое менее #$%нуто делать. Но читать дохлых страусов ДО того как кодить - видимо не модно.
Нафиг этих страусов. Лучше читать сгенерированный на ассемблере код.
> Чтобы если у падает растовый код, то падал осмысленно, а не в панике.Так он осмысленно падает. Даже в лог может записать где и что.
А вот продолжать выполнение программы после паники нельзя - никто не знает что произошло, где память в ансейфе попортили, т.е. в общем стейт неконсистентный.А если стейт все еще консистентный, то это не паника и вы что-то не так сделали в обработке ошибки.
> Даже в лог может записать где и что.Это прям в ядре самого языка такое? А если у меня нет открытого TTY?
Пиши в файл, раз tty нет. Что, и файлов нет? Тогда мигай диодом: три коротких, три длинных, и снова три коротких. И сопроводительной документации напиши, мол, когда так мигает — запомните что вы делали и звоните по номеру 1-800-VSYO-UPALO-MAMA-POMOGITE.
> продолжать выполнение программы после паники нельзяПочему нельзя ограничить панику только той частью кода, которая выполняет одну конкретную задачу? Прибили тред (или фибер, или что там у раста), выдали варнинг, почистили память, позакрывали или вернули в пул всё, что было открыто - а всё остальное продолжает работать.
> Почему нельзя ограничить панику только той частью кода,
> которая выполняет одну конкретную задачу?А вы умеете изолировать память одной конкретной задачи от всех остальных?
Как вы будете гарантировать что вы не испортили что-то еще?
Это как раз та самая Unrecoverable Errors.doc.rust-lang.org/book/ch09-01-unrecoverable-errors-with-panic.html
doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-panic.htmlЕсли же вы можете обработать ошибку и напр. перезапустить операцию, то просто не кидайте panic, а верните Result и обработайте ошибку.
Ну и в теории вы можете переписать panic handler.
> А вы умеете изолировать память одной конкретной задачи от всех остальных?А с самого начала проектировать язык так, чтобы одна задача не портила данные остальных? Раз уж Раст претендует на безопасную работу с памятью. Эрланг же как-то умеет. А то получается, что программе на Расте нельзя доверять больше одной задачи.
Если ты имеешь глобальную кучу и все задачи имеют к ней доступ, то любая из них может похерить кучу. Все эти теоретические изыски, когда сферические части программы выполняются в вакууме, сугубо теоретичны.
> любая из них может похерить кучуПочему-то у Армстронга и компании ещё в 80-е годы прошлого века получилось спроектировать архитектуру языка так, чтобы этого избежать.
> Почему-то у Армстронга и компании ещё в 80-е годы прошлого века получилось
> спроектировать архитектуру языка так, чтобы этого избежать.Почему-то опеннетные эксперты скромно умалчивают, что этот язык выполняется в VM ...
> Почему нельзя ограничить панику только той частью кода, которая выполняет одну конкретную задачу?Почему нельзя? Есть catch_unwind. Со своими особенностями правда, он не гарантирует, что разматывая стек, он может снимать со стека не-растовые фреймы, и RAII он тоже не гарантирует. Я в детали не вдавался, мне как-то нужды нет, но всякие там рантаймы типа tokio вполне устойчивы к тому, что какой-нибудь гринтред паниканёт.
Смешивание в одной функции работу с разными библиотеками, возвращающими разные ошибки.Сейчас если основная функция возвращает определенный тип ошибок, а ты хочешь использовать внутри этой функции какие-то другие функции, которые возвращают другой тип ошибок, то приходится или для каждого вызова функции возвращающей неверный тип ошибок кастовать их к верному при помощи map_err или выносить в отдельную функцию, или костылить самовызывающуюся ламбду.
cargo add thiserror
Это тут причем? thiserror структурированные ошибки превращает в строковые, уничтожая возможность их последующего анализа. Весьма узкоспециализрованная штука.
Совершенно неверно.
Ты перепутал его с anyhow, thiserror лишь упрощает создание идиоматических ошибок
anyhow?
По хорошему, надо бы еще в хруст добавить монады.
Язык без монад - слишком примитивный и непригодный для использования язык.
Только монады спасут вашу память от проверяльщика боровов, который спасает её от указателей.
Хорошая идея. Завалить раст мусором фич!
А-а-а-а, прогер-расты ещё добавилось. Боже, извините за мой примитивный юмор)))
А с монадами язык получается очень сложный. Я люблю Haskell, но я не вижу большой потенциальной пользы от монад в Rust.
GAT-ы вам в помощь! Когда с лайфтаймами монадить научитесь, может и типы вам дадут :)
А давайте ещё и турку к нему прикрутим.
Много чести. Проще игнорировать.
1. unwrap() или expect("message") не обрабатывает ошибку и приводит к панике, если она возникает;
2. "?" бросает ошибку выше по стеку;
3. match my_result {...} позволяет её обработать прямо здесь.try-catch - это другая модель обработки ошибок, её сделают в другом языке. В этом языке такая модель, которую я описал выше.
> try-catch - это другая модель обработки ошибок, её сделают в другом языке.
> В этом языке такая модель, которую я описал выше.А почему try в experimental фичах тогда УЖЕ висит? Не далее как вчера кто-то тут ссыль пульнул - и там разрисованы кейворды и проч были. И указание что - вот - try - experimental. Т.е. оно у них уже по идее есть?!
Там смысл другой
try не про ловлю паник (для ловли паник есть catch_unwind)try про создание ограниченного скоупа в котором оператор ? работает.
let result = try {
fallible_op()?;
};
result получит ошибку от fallible_op, в то время как без блока try её только из функции вернуть выйдет
а они там не нужны, вместо них Result, просто надо писать в несколько другом стиле, постоянно работая "цепочками" из map/and_then/... над Result-ами, а unwrap только в самом конце. Результат тот же (unwrap там, где нужен catch), даже гибче (обработка не ограничена путем по стеку, Result можно передать куда-то и там unwrap-нуть).
> К сожалению, try блоки так и не добавили. Сколько лет уже с такой мелочью тянут.А должны? Это же ООП в чистом виде, если ты их хочешь, тебе скорее в c# или kotin. На мой взгяд траями можно всю концепцию раста разломать
> А должны? Это же ООП в чистом виде, если ты их хочешь,Чего такого объектного в try/catch? Это просто попытка выполнить некий блок, с каким-то действом если "ну значит не прокатило". Само по себе это никак не обязано быть завязано на объекты.
В тот же Forth ещё в стандарт 95 года добавлено было, а он сроду не объектно-ориентированный.
> Это же ООП в чистом видеТакие заявления, которые причисляют к ООП фишки, которые ни разу ни ООП, я подозреваю звучат от людей, кто слаще C++ никакого ООП не едал. Именно такие, почему-то склонны называть ООП фишками исключения, параметризованные типы, перегрузку функций, ... короче любое свойство C++, которого нету в C.
try-catch это размотка стека, в этом нет ни наследования, ни полиморфизма, ни инкапсуляции, то есть ни одного из "китов ООП". И, я отмечу, что в расте размотка стека есть. Есть panic, есть catch_unwind. Да, при этом обработчики в catch_unwind не выглядят как перегруженные функции, и рантайм не занимается выбором функции, которая сможет проглотить тип выкинутого значения. И да, это подходит только для работы с критическими ошибками, не выйдет творить вещи, типа огромных вычислений, полагающихся на то, что какие-то ошибки (допустим деление на ноль) сгенерят исключение, и поэтому не проверяющих каждую операцию (что замедляет код), а выполняющих их без проверок, с обработкой ошибок где-то за пределами цикла с перезапуском вычислений.
> На мой взгяд траями можно всю концепцию раста разломать
Если делать как в C++, то естественно. Но можно было бы сделать что-нибудь попроще. Что-нибудь, что, например, не требовало бы от рантайма сопоставления типов исключения и обработчика. С panic/catch_unwind есть проблема, что они не гарантируют, что RAII отработает как надо. Плюс я не представляю, насколько это быстро или медленно.
С другой стороны, нелокальные goto очень сильно осложняют анализ программы, и соответственно для раста может оказаться невозможным доказывать гарантии о коде им обещанные.
> try-catch это размотка стека, в этом нет ни наследования, ни полиморфизма, ни инкапсуляцииа есть какие-то языки, которые вбрасывают не полиморфные исключения?
> нелокальные gotoНу как бы да, обработка ошибок по радиосвязи. Хз, как это вообще на модель раста наложится.
Эти блоки не нужны. Паники не являются исключениями не смотря на сходство.Если схожий механизм необходим, то есть https://doc.rust-lang.org/stable/std/panic/fn.catch_unwind.html Впрочем, очевидно, он работает только если паники реализованы с раскруткой стека. Если паника реализована через аварийное завершение программы, то её невозможно поймать. В этом и заключается разница между исключениями и паниками кстати.
Не очень понятно, что такое "try блоки". Панику ловить и так есть функция. Обычные же ошибки обрабатываются через Result<T,E>.
Правильные пацаны (go, rust) не используют пережитки прошлого.
Растик позиционируется как замена "С" а не "С++" ибо в последнем нет проблем, которые решает раст.
> Растик позиционируется как замена "С" а не "С++" ибо в последнем нет проблем, которые решает раст.Жаль гугл об этом не знает, и делает всякие MiraclePtr (неудачно).
А в AOSP заменяет си и плюсы и новый код пишет на на расте.
Надо срочно им сообщить, что у плюсов нет проблем))
И чё? Причём здесь какие-то гуглы? Они могут накалякать всё шо хош. Для корпораций раст подходит больше ибо себестоимость разработки меньше ибо квалификация (стоимость) программеров меньше. И фсё. Будешь строчить за чашку супа.
Спецификации как не было, так и нет до сих пор, вместо этого "ну типа, держитесь на старой версии, что баг, что нет - неважно, мы/они не определились".
О! Раст-бинго работает!
Как раз в этом тренде перечислял список гениальных вопросов по новой версии: https://www.opennet.dev/openforum/vsluhforumID3/136086.html#161Но нам, конечно очень интересно, в очередной раз, послушать про стандарты С и С++, с извечной оговоркой: "ну да, их никто полностью не поддерживает, но зато есть бумага!"
>"ну да, их никто полностью не поддерживает,gcc/clang, неа? Они ещё поддерживают переключение между стандартами. А также компиляторы имеют вменямые мейджер версии, которые можно свободно включать в реквайерментс, как и версию стандарта.
> но зато есть бумага!"В промышленной разработке софта бумага важнее всех растоманов вместе взятых. Но ты прав, расту это не нужно, потому что в промышленной разработке раст используют только один раз до разоблачения и увольнения инициатора.
> gcc/clang, неа?Неа. Ни тот ни другой не поддерживает все стандарты полностью. То есть стандарты существуют только на бумаге.
> В промышленной разработке софта бумага важнее всех растоманов вместе взятых.
Согласен целиком и полностью: бумаги важны. Но какое отношение это имеет к стандартам С/++?
У раста нет стандарта, но сертификацию на использование в критических системах он успешно проходит, уже можно использовать для разработки в отраслях: автомобили, промышленность, медицина. Остальное: в процессе. И никакие мисры для него придумывать не пришлось.
> И никакие мисры для него придумывать не пришлось.держи пустомеля
> О! Раст-бинго работает!
> Как раз в этом тренде перечислял список гениальных вопросов по новой версии:
> https://www.opennet.dev/openforum/vsluhforumID3/136086.html#161
> Но нам, конечно очень интересно, в очередной раз, послушать про стандарты С
> и С++, с извечной оговоркой: "ну да, их никто полностью не
> поддерживает, но зато есть бумага!"О да, Дегенератос Инцестис никогда ничему не учится, опыт Python 2 и Python 3 вместе с Перлом, Башем, Мейком и Паскалем ничему не научил.
Кстати, а как ты умудрился написать комментарий на этом сайте? Ведь нет же стандарта на интернет! Он как-то работает, а стандартов - нетути. Загадка!
Ну так тут одна версия сайта. А раст это микс.
Браузеров много, сайтов много, всё работает, стандартов нет. Как так?
Как нет? HTML 5 как пример.
> Ну так тут одна версия сайта. А раст это микс.Не, это соль. Вон тут гражданин - с подходящим ником как раз.
Как это нет стандарта на интернет? Больше тысячи рфсишек, иетф тот-же.
Вот именно, больше тысячи. И ни одна не соблюдается на 100%.Впрочем, у RFC статус рекомендаций
> Вот именно, больше тысячи. И ни одна не соблюдается на 100%.Всю тысячу посчитал?
> Впрочем, у RFC статус рекомендаций
Прям так и написано? "Вот РФЦ раста, но можете их не выполнять" ?
Или ты просто сочиняешь сказки?ps и не надо пугать RFC, я начитался всяких начиная от
rfc822 - который, кстати
STANDARD FOR THE FORMAT OF
ARPA INTERNET TEXT MESSAGES
[1]до RFC 1122, который тоже Status: INTERNET STANDARD [2]
[1] datatracker.ietf.org/doc/html/rfc822
[2] rfc-editor.org/info/rfc1122
> до RFC 1122, который тоже Status: INTERNET STANDARD [2]Мне больше RFC 1149 нравится. Ну а что, стандарт интернета. Регламентирует IPoAC.
> Ведь нет же стандарта на интернет!IEEE, ICANN, IANA, IETF, w3…
ECMAScript, CSS, HTML, XML, SVG, JPEG...
Отсутствие спецификации как-то не помешало на сишке операционные системы писать в прод, параллельно с развитием этой самой сишки. Авось и Расту не помешает.
Оно и не удивительно, почему Юникс сдох.
Потому что когда спецификация сочиняется на ходу, программы долго жить не будут.
Пока компилятор только один, в спецификации нет никакого смысла.Ну напишет кто-то спецификацию, которой единственный существующий компилятор в чем-то не соответствует. И что? Кому станет легче от того, что спецификация есть, и можно смело говорить, что это баг, а не фича? Код от этого компилироваться правильно начнет?
> Спецификации как не было, так и нет до сих пор,Хорошего кексперта издалека видно.
Спецификация есть в виде RFC.
Это распространенный метод, например куча интернет стандартив именно ста стандартизированы.Стандарта ИСО (на который так фаломорфируют сишники) - нету.
Но он пока и не нужен.Напомню что С появился в 78, а стандарт сделали в 89.
И спокойно переписали юникс без каких либо стандартов.> вместо этого "ну типа, держитесь на старой версии, что баг, что нет - неважно, мы/они не определились".
Хватит пороть чушь. Ты же только позоришься.
> Напомню что С появился в 78, а стандарт сделали в 89.
> И спокойно переписали юникс без каких либо стандартов.Это были лохматые годы более четверти века назад. С тех пор стандарты для ЯП стали обыденностью и выходили регулярно. Поэтому такая отмазка в отношении раста не катит - он не появился на заре компьютерной эпохи, не был первым или второым высокоуровневым ЯП и т.д.
> С тех пор стандарты для ЯП стали обыденностьюНу вот можете считать, что уже перестали. Новые языки делаются иначе. Окончательно ненужность и даже вредность стандарта для современного языка стала очевидна по итогу ситуации с Haskell, где в рамках карго-культа стандарт таки сделали, но в результате все пишут не на "стандартном Haskell", а на нормальном Haskell для которого есть компилятор.
> Ну вот можете считатьСтандартом языка надо считать базис, а все остальное - диалекты.
>Напомню что С появился в 78Чаво, -ть?
Мне кажется их из Мазилы выгнали в том числе. что спецификации не могли сформулировать.
Так и остался "Кружок реализаций того, что знают и видят"
> Реализован второй уровень поддержки платформы powerpc64le-unknown-linux-musl. Второй уровень поддержки подразумевает гарантию сборки.А причем тут раст, если это делается исключительно средствами LLVM?
При чем тут llvm, если llvm только перегоняет llvm-ir в машинные коды?
А сам llvm-ir генерирует rustc через цепочку преобразований.Ну и уровень поддержки - это в первую очередь тестирование.
А оно делается на стороне раста, а не llvm.
А вот прям в новости написано буквально следующее: "Второй уровень поддержки подразумевает гарантию сборки. ". А сборкой под целевую платформу в расте кто занимается? Бинго! Это C++ный LLVM.
Чем отличается от c++ с трёх летним циклом стандартов?
Как собрать приложение на C++ из исходников, если приложение состоит из компонентов, которые поддерживают разные версии стандарта?
В большинстве случаев - просто собрать эти компоненты в своей версии стандарта. Как вариант - можно собрать в последней версии. Изменения C++, ломающие обратную совместимость, довольно редки, и на практике пости не роляют.
> пости не роляют?
у человека фаерфокс, а там код на расте так вмешивается в свою критику
Легко. Собираешь а разные библиотеки, потом линкуешь вместе
Тремя компиляторами? Легко?
Для этого существует C ABI. Знаю, что для Дегенератос Инцестиса это сложно, но да, такая штука существует.
> Для этого существует C ABI.Ты хочешь гонять вызовы к плюсовым либам через сишные? А месье знатный еще извращенец...
Ну и прдлиться с тремя компиляторами тоже развлечение на любителя.
Одним компилятором с ключиком говорящем в каком стандарте компилировать данный модуль.
Почему на российском рынке больше востребован Го чем Раст?
Действительно, ведь го должен быть востребованнее больше всего в Голланди, а rust в Russia.
Возможно Голандию и назвали в честь Го, кто знает.
Или в Сербии (rs)
А вот Zig пока, похоже, ни в какой стране не востребован.
Zimbabwe вас ждет.
На го написано много проектов, а на расте ни одного большого проекта нет.
Потому что в Rust принято поощрять использование свободных библиотек (крейтов) в зависимостях. Поэтому существует очень много небольших крейтов, которые Cargo умеет автоматически подтягивать к проекту и разруливать версии. Целевой проект при этом также получается маленьким, потому что он большую часть функционала берёт из многочисленных библиотек.
> Разруливать версииТолько если первая значащая цифра версии не 0. Из-за этой херни в одном проекте может быть десяток дублей таких жирнючих крейтов как rand, openssl, rusttls, libc.
Обычно если дубли и есть, то их 2-3 штуки. Ни разу не видел десяток. openssl и libc вряд ли вам позволит компилятор иметь несколько версий в рамках одного проекта, потому что они не нативно растовые, зависят от внешних Си-библиотек.
Потому что большая часть разработки это плюс-минус перекладывание JSON по HTTP для чего Golang идеальный инструмент
Далеко не идеальный.
В раст выше порог вхождения, а программисты на Го - это те же самые программисты на Жабе, хоп хоп и в продакшен. При этом и Го и Жаба платят за это потерей эффективности по ресурсам, но это обычно мало кого заботит.Блин, ты конечно задал вопрос. Вон, люди до сих пор на прости господи Питоне коммерческие сервисы делают. Уж казалось бы, самое дно. А делают же. Потому что пофиг, деньги на железо есть, пользователей не так много, и так сойдёт.
У гошки порог несравненно ниже, чем жабы. Это просто прокачанная сишка, его учить надо 2 дня всего. Но платят больше, потому что спрос выше предложения.
Мне не нравится, что релизы Rust выходят так часто. C C++ все ясно — он обновляется раз в несколько лет.
Релизы раста: выходят раз в несколько лет
Релизы C++: выходят раз в несколько летАноним с опенета: релизы раста выходят слишком часто, то ли дело С++!
> Релизы C++: выходят раз в несколько летНу так это сейчас. А аноним возможно знает только про переход с C++03 на C++11.
Пссс... там еще есть 14, 17, 20, 23 и будущий 26. И не сложно заметить некую закономерность в этих числах - новый стандарт каждые 3 года.А теперь попробуй посмотреть на rust editions - 2015, 2018, 2021, 2024.
Что мы тут видим? Ну, постарайся подумать!
Ой, знал бы ты как часто веб-технологии часто обновляются. Их хоть каждый день можно учить и всё-равно знания будут устаревшими.
Редакции Rust выходят раз в три года. Если для вас это слишком часто, то возможно вы просто стареете. А вот минорные улучшения языка выходят стабильно раз в шесть недель. И это сделано специально так, по графику, который позволяет держать в тонусе аудиторию опеннета.
> по графику, который позволяет держать в тонусе аудиторию опеннета.Не вводите людей в заблуждение - график проплачивается спонсорами (Gazprom, Gasunie, BASF) в рамках исследования новых технологий получения биогаза. Ничего личного, just business.
> Не вводите людей в заблуждение - график проплачивается спонсорами
> (Gazprom, Gasunie, BASF) в рамках исследования новых технологий
> получения биогаза. Ничего личного, just business.Так вот кто виноват в глобальном потеплении!
Я так и знал!
> выходят стабильно раз в шесть недель [что] позволяет держать в тонусе аудиторию опеннета.Надо чаще – раз в неделю, по пятницам. Как на этой неделе. Было бы прекрасно!
Теперь можно писать[package]
edition = '2024'
Мне не нравится, что надо его ставить через rustup, с Golang всё проще!rm -rf /usr/local/go && tar -C /usr/local -xzf go1.24.0.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin
Мне не нравится, что Rust и его экосистема на моём лэптопе занимает большое пространство, Golang меньше и шустрее!
> с Golang всё проще!А как в Golang решается вопрос с несколькими разными версиями го?
Напр. тебе нужен go 1.24 для текущего проекта, но еще нужен go 1.15 для старого.
Есть утилита для выбора и удобного переключения?
> Есть утилита для выбора и удобного переключения?
go mod и вооще проблем нет
Для того, чтоб управлять несколькими версиями Go есть https://asdf-vm.com/
Вы правы, приведённую вами курдыберду запомнить проще, чем rustup update.
Если с памятью все в порядке, то, конечно, проще.
Да, Rust может быть не идеальным! Но лучше человечество ничего не придумало!
Не надо нам эти ваши ни Rust 1.85, ни Rust 2024.
Rust 2502 - чётко и понятно.
В 2502 всё ещё помнят про Rust?
Это ещё ладно.
А вот если бы руст релизился каждый день, то был бы Rust 250220.
И главное сортировать нормально.
Не эти ваши:
Rust 1.1
Rust 1.10
Rust 1.11
Rust 1.2А то бывает сложно математикам вкурить, что кернель 6.8 древнее, чем 6.12.
в 2502 никаких языков уже не будет. ИИ будет писать в своих машинных кодах, а твои потомки будут работать батарейками. Я это в одном документальном кино видел
Дабы тема не разросталась как предыдущая (не ну реально! я уже устал ржать с убогих)
я перечислю все недостатки RUSTа и претензии к нему сразу:
* ужасный синтаксис
* каждая версия компилятора несовместима с предыдущей
* есть unsafe, значит не безопастный
* ничего хорошего на нём не пишут
* писать на нём в 1000 раз медленнее чем на [вставить язык]
* вот когда [что угодно] напишут, тогда и поговорим
* вместо того чтобы писать новое, только переписывают
* вместо того чтобы переписывать, лучше бы что-то новое написали
* программы на расте компилируются часами! для него нужен суперкомпьютер
* вы портите растом наши прекрасные сишные проекты (и мы теперь не можем в них разобраться, плак-плак)
* а вы видели какой CoC у раста?!
* это все заговор NSA для внедрения закладок!!11
* если софт станет надежным - мы попадем в рабство, тк не сможем ломать свои телефоны и boot
* раст привязан к централизованному карго и от него невозможно отвязаться!!11 а потом они еще и двухфакторку!
* я непонимать раст, поэтому уверен, что там закладки, верните понятную дыряшку!За подборку передавайте свои плюсики Карлос Сношайтилис [1] и участнику пожелавшему остаться неизвестным [2]
[1] opennet.ru/openforum/vsluhforumID3/132732.html#5
[2] opennet.ru/openforum/vsluhforumID3/132732.html#83
Я так и не вкурил, как мне обработать массив, созданный в другом объекте. Бесконца морочиться со сменой владения? Но тогда производительность будет ниже плинтуса.
Безопасность... безопасность ...
Производительность будет ниже при копировании данных, смена владения ничего не стоит
Как так ничего? Инструкция есть, но тактов процессора не потребляет? Магия поди.
Оно при компиляции проверяется.
> Как так ничего? Инструкция есть, но тактов процессора не потребляет? Магия поди.
>> смена владения
> Инструкция есть, но тактов процессораМестные Ж(опо)Скритошники совсем не палятся, млин.
"владение" – это понятие уровня разбора AST, даёт возможность компилятору применить специфические оптимизации. В худшем случае код будет аналогичен коду на С, но если компилятор найдет определенные паттерны – схлопнет в более оптимальный.
Передавайте массив по мутабельной ссылке.
> Передавайте массив по мутабельной ссылке.Так его же позволят передать только в одно место!
А хочется в него писать сразу из разных функций.
И желательно из разных потоков. Всегда в так делаю и компилятор не ругается!
> как мне обработать массив, созданный в другом объекте
> Я так и не вкурилЗадавая таким образом вопросы, и не вкуришь. Задача размыта. Я подозреваю намеренно размыта, чтобы в ответ на любое предложенное решение можно было бы сказать, что оно не подходит для твоего случая.
> Бесконца морочиться со сменой владения?
Во-первых, не очень ясно, что есть "смена владения", во-вторых, овнершипы -- это понятия из компайл-тайма, на производительность они не влияют.
Всё это объясняется во первых строках официальных (и неофициальных) учебниках по Расту. Плюс ровно этот вопрос ты можешь задать любому бесплатному ИИ, и он тебе прекрасно всё объяснит с ответами на вопросы и примерами. Но, давай я тебе новый учебник напишу прям тут в каментах.Если у тебя массив принадлежит структуре ("созданный в другом объекте" видимо про это), то варианты такие:
struct MyObject {
inner_array: [String; 2],
}let obj = MyObject { inner_array: [
String::from("hello"),
String::from("world")
]};for array_element in obj.inner_array {
println!("- {}", array_element);
}
for array_element in obj.inner_array { // второй раз нельзя
println!("- {}", array_element);
}
Так можно, но только один раз, потому что если ты забираешь во владение внутреннее поле структуры, а это возможно только уничтожая всю структуру. Обычно нужно не это, поэтому обычно внутреннее поле во владение не забирают, а на время занимают его у структуры:let borrowed_array = &obj.inner_array; // "&" - ключевое
for array_element in borrowed_array {
println!("- {}", array_element);
}
for array_element in borrowed_array { // второй раз уже можно
println!("- {}", array_element);
}Если тебе надо этот массив поменять, но занимаешь его в изменяемом режиме:
let mut obj = MyObject { inner_array: [ // добавили "mut" на переменную хранящую саму структуру
String::from("hello"),
String::from("world")
]};
{
let borrowed_array = &mut obj.inner_array; // заняли внутреннее поле структуры в изменяемом режиме через "&mut"
borrowed_array[0] = String::from("goodbye");
borrowed_array[1] = String::from("opennet");
} // компилятор дропнул "borrowed_array" при завершении блока, теперь можно опять занимать это поле структуры на чтение
println!("{:?}", &obj.inner_array);Результат:
["goodbye", "opennet"]
То есть ты не можешь один и тот же ресурс одновременно занять на запись и на чтение. Ты, разумеется, можешь читать из переменной "&mut", но пока она жива, ты не можешь создать ещё одну переменную, которая читает из того же поля структуры. Либо чтение, либо запись. Поэтому в целях демонстрации показал как "borrowed_array" дропается, что бы занять поле ещё раз, уже только на чтение с выводом в консоль.
Самый хороший учебник не требующий особых начальных знаний в программировании - официальная дока (The Rust Book).
Самый хороший неофициальнй учебник для упоротых сишников, которые сразу хотят создавать свои коллекции и решать проблемы с указателями - "Learn Rust With Entirely Too Many Linked Lists".
> каждая версия компилятора несовместима с предыдущейНу и зачем так делать?
> Ну и зачем так делать?Вот именно: зачем так делать? Но в большинстве ЯП нельзя использовать в одной кодовой базе конструкции из разных редакций стандарта языка. Например, стало слово "await" ключевым – всё, весь код, где были переменные с этим именем, перестает компилироваться.
Хорошо что в расте не так.
Там он продолжит компилироваться, но безопастно?
Спасибо! Совсем забыл про этот пост ))
> let &[ref x, mut y] = &[(), ()];лучший синтаксис который я видел. Даже перловка обложенная экспешинами не доставляла столько
согласен, но тут не хваает апострофов
Это ты ещё на С/С++ не писал, похоже...
> С/С++Это что за язык такой?
В C++, разве что, угловые скобочки могут кого-то, незнающего про шаблоны, смутить.
> В C++, разве что, угловые скобочки могут кого-то, незнающего про шаблоны, смутить.https://blog.reverberate.org/2013/08/parsing-c-is-literally-...
Синтаксис шаблонов в C++ ущербен by design.
>> В C++, разве что, угловые скобочки могут кого-то, незнающего про шаблоны, смутить.
> https://blog.reverberate.org/2013/08/parsing-c-is-literally-...
> Синтаксис шаблонов в C++ ущербен by design.В приведенной статье речь не про синтаксис, а про разбор. Как это в расте реализовано или зиге?
Вы, видимо, перла никогда не видели, а ваш "опыт" базируется на том, что краем уха слышали об однострочниках и регулярках. Сам по себе перл имеет очень читабельный синтаксис.
Мой опыт включает ковыряния в скриптах на перле, и допиливание их под мои нужды. Я не видел ни одного, который был бы написан если не совсем вменяемо, то хотя бы были бы заметны попытки автора прикинуться вменяемым.> краем уха слышали об однострочниках и регулярках. Сам по себе перл имеет очень читабельный синтаксис.
О, нет, я ещё слышал философию перла, с которой Ларри его выпиливал. Будучи филологом, он решил, что чем больше синтаксических примочек, тем ближе к естественному языку, тем выразительнее язык. "There are more than one ways to do it", aren't there? Сколько там операторов в перле? Сотня наберётся? Почти любая пара символов из цифрового ряда клавиатуры набранная с зажатым шифтом -- это какой-нибудь оператор перла. Я не удивлюсь, если !@#$ -- это какой-нибудь оператор там.
Но помимо этого, что меня больше всего бесит в нём, это использование $ для переменных. Какая-то парша допотопных языков. Я могу понять такое решение в sh и последователях, но потому, что в большинстве случаев использования sh переменные попадаются реже, чем непосредственные значения. Скрипты обрастают этими $, но это расплата за то, что используя непосредственные значения в командной строке не нужно каждое заключать в кавычки. Но perl и php, которые как интерпретаторы практически не используются, зачем-то требуют и $ перед именами переменных, и кавычки вокруг непосредственных значений, и вот этого я просто не понимаю. Хотя, в отношении перла, у меня есть гипотеза, что всё дело в том, что в перле несколько сотен ключевых слов, и придумывая имя переменной сложно избежать совпадения с именем кейворда, про который ты никогда не слышал.
вот так нада писать:return [[([...[new TextDecoder().decode(new Uint8Array(this.#data.match(/.{3}/g)))][0]].reverse().join(''))][0]][0];
Это искусственный пример для демонстрации новой фичи паттерн-матчинга. В реальности вы такой код не увидите (ссылка на массив, два элемента которого являются пустыми кортежами).
Это всё равно не отменяет того, что код на Rust действительно тяжело воспринимать на глаз и читать, по крайней мере мне. По ощущениям, язык задействует каждую клавишу клавиатуры, а комбинации различных символов иногда вызывают желание закрыть и больше никогда в эту сторону не смотреть
Не сложнее чем плюсы читать, но оба сложнее читать чем какой-нибудь go. С python двояко, м одной стороны выглядит просто, но с другой может за простотой быть скрыта большая магия, в которой тяжело разобраться с разбега если что-то пошло не так.А вы с каким языком сравниваете?
Всё-таки вопрос: вы знаете Rust или нет? Просто язык-то на самом деле довольно простой и логичный. Если вы знаете синтаксис сопоставлений с образцом, то никаких затруднений подобный код вызывать не должен. А вот если не знаете - то действительно может быть сложно разглядеть систему. Я думаю ваше суждение - это суждение человека со стороны. Тогда как разработчики на Rust, знающие синтаксические правила этого языка и семантику, никаких затруднений не испытывают.
> кортежамиЛол, таплы теперь кортежи? Не прекращаю поражаться надмозгам, которые превосходя себя находят такие переводы терминам, которые вообще и никак не намекают на суть исходного термина. Да будет тебе известно, что кортеж -- это процессия автомобилей с членовозом посередине.
> Это искусственный пример для демонстрации новой фичи паттерн-матчинга.
Это в расте называется "паттерн-матчингом"? Это же банальная деструктуризация (или как там эти любители переводить термины на русский называют destructuring?), когда структура разбирается на отдельные значения, которые биндятся к переменным.
> В реальности вы такой код не увидите (ссылка на массив, два элемента которого являются пустыми кортежами).
Я не думаю, что претензии к двум tits в квадратном бюстгалтере из правой части. Я думаю, он про левую.
> Лол, таплы теперь кортежи?Всегда ими и были ) А вы, похоже, не учили информатику в университете/институте, иначе бы вопросов таких не возникало.
> Это в расте называется "паттерн-матчингом"? Это же банальная деструктуризация (или как
> там эти любители переводить термины на русский называют destructuring?), когда структура
> разбирается на отдельные значения, которые биндятся к переменным.Да, это сопоставление с образцом (паттерн-матчинг), а не как вы выразились "банальная деструктуризация". Представьте себе. После let идёт паттерн и синтаксис его такой же, как и в match (и как в if let, while let, for и прочих места, где используется сопоставление).
> Я не думаю, что претензии к двум tits в квадратном бюстгалтере из
> правой части. Я думаю, он про левую.А что не так с левой? Она зеркально повторяет правую в части & и [].
> А вы, похоже, не учили информатику в университете/институте, иначе бы вопросов таких не возникало.Да, специализировался в математике, а остальное добирал книгами. Нисколько не жалею, российская "информатика" сугубо провинциальна, ноль оригинальных работ, и "звёзды" типа Столярова, она не может дать ничего, чего нет в книгах. Если не считать, отмороженных переводов типа tuple -> кортеж, которые мне всё равно не нужны. Годяться только на то, чтобы поржать над ними.
> Да, это сопоставление с образцом (паттерн-матчинг), а не как вы выразились "банальная деструктуризация".
Может быть.
> А что не так с левой? Она зеркально повторяет правую в части & и [].
Это не ко мне вопросы, к анониму выше, у него были претензии, не у меня.
В математике есть раздел "Реляционная алгебра", где tuple переводится, как кортеж.
> В математике есть раздел "Реляционная алгебра", где tuple переводится, как кортеж.И не только. В информатику термин кортеж пришёл из дискретной математики. Просто комментатор выше невежественен в вопросах математических терминов. Увидел, что кто-то использует отличное от кальки с английского слово - и это его веселит. Хотя стоило бы призадуматься об уровне своего образования.
> В математике есть раздел "Реляционная алгебра"Не сталкивался с ней в русском переводе.
> Да, специализировался в математике, а остальное добирал книгами. ... Если не
> считать, отмороженных переводов типа tuple -> кортеж, которые мне всё равно
> не нужны. Годяться только на то, чтобы поржать над ними.Весьма сомнительно, что вы "специализировались в математике", так как не владеете математической терминологией:
https://diskra.ru/reshenie_zadach/?lesson=1&id=2
https://www.booksite.ru/fulltext/1/001/008/065/003.htm
Там дано определение вектора, и названо "кортежом". Потом излагается то, что я думаю шло в первые месяцы первого курса на высшей алгебре. Но в начале зачем-то использовано слово "кортеж"? В чём глубинный смысл сего дияния? Это рассеянские информатики пытались отмежеваться от алгебры, и заявить о том, что они не такие как все?Вообще, у меня остались смутные воспоминания, о том, как препод по матану, стебал алгебраистов, за то, что они у матана стырили теорему, и назвали её основной теоремой алгебры. Но я точно помню, что всех этих информатиков он вообще ставил в один ряд с инженерами, которые математики никогда не понимали и не поймут.
Ты написал какой-то бред, и усмехаешься на тем, что это - бред. Молодец, показал этим растоманам, знай наших!На самом деле по-нормальному это выглядит так:
let [a, b] = [1, 2];
println!("{}, {}", a, b);Выведет:
1, 2
То есть это деконструкция массива. Тоже самое можно делать с туплами. Очень удобно.
А остроумный автор просто решил эту удобную фичу забросать ненужными там операторами, что бы выглядело не так понятно.
Автор не остроумный, автор просто привёл минимальный пример переусложненного паттернматчинга, который действительно не получается понять и который был запрещён в новой редакции языка. А следом уже вот этот аналог, который так же делает паттерн-матчинг этого &массива совмещённый оборачиванием в ссылки неизменяемую и изменяемую.
При использовании Rust можно будет оставить в прошлом такие проблемы, как обращение к памяти после её освобождения, выход на границу буфера (частично), некорректное освобождение ресурсов при обработке ошибок и забытые проверки возвращаемых кодов ошибок, что позволит мэйнтейнерам сосредоточиться на реальных ошибках, таких как состояния гонки и проблемы с логикой, а не рассеивать при рецензировании внимание по мелочам.
а на очередную закорючку раста внимание не рассеивается?
> а на очередную закорючку раста внимание не рассеивается?Нет. Рассеивается только у тех, кто не выучил Rust.
Не совсем так. Есть люди, которых напрягает количество разных символов. Не смысл, который за ними, а просто количество символов. Их например топорщит от угловых скобок, а от квадратных не топорщит. Такая вот фигня в голове. Я только пока ещё не понял - это по жизни так, или вопрос привычки.Мне кажется, что привычки. Но тут сложно определить, потому что те, кого топорщит и привыкнуть они не могут - они и прогать на расте не будут тоже, поэтому определить довольно трудно.
Думаю, это вопрос исключительно привычки. Просто в их практике квадратные скобки, скорее всего, встречаются намного чаще угловых. Новые символы - это дополнительная когнитивная нагрузка. Против дополнительной когнитивной нагрузки борется наша лимбическая система, потому что это большой расход энергии (в те времена, когда лимбическая система формировалась, еда была дефицитной). Но, как только мозгу примелькаются новые символы, он к ним привыкнет, создадутся новые связи, человек перестанет испытывать раздражение.
Опять до тучи изменений, притом даже в базовом синтаксисе. Зачем такой язык в ядре?
Крепись, ядро УЖЕ переписываются с небе9опасного С на безопасный раст.
> Крепись, ядро УЖЕ переписываются с небе9опасного С на безопасный раст.Точно безопасный? https://github.com/Speykious/cve-rs
Точно-точно? https://github.com/rust-lang/miri/?tab=readme-ov-file#bugs-f...
Ну не может такого быть же. Все говорят же безопасный, а тут такое https://github.com/rust-lang/rust/issues/25860
Точно безопаснее чем С.Даже правительство США призывает отказаться от небезопасных языков. https://www.opennet.dev/opennews/art.shtml?num=58111
> Точно безопасный?Точно.
А ссылки твои даже здесь, на опенете, уже разобрали по полочкам и ответили почему, несмотря на их наличие, Раст всё ещё точно-точно безопасный.
>> Точно безопасный?
> Точно.
> А ссылки твои даже здесь, на опенете, уже разобрали по полочкам и
> ответили почему, несмотря на их наличие, Раст всё ещё точно-точно безопасный.На вере далеко не уедешь.
Причём здесь вера? Вам же написали, что разобрали по полочкам.
> Причём здесь вера? Вам же написали, что разобрали по полочкам.Каким полочкам? На мои ссылки никто не ответил. Баг про обман борова висит с 2015 года.
Ну чтож, дополним лозунг "Stable API is nonsece!" лозунгом "Stable syntax is nonsence!"
А когда небезопасный LLVM перепишут на безопасный Раст,который безопаснее Ады?
А какие изменения в базовом синтаксисе вы имеете ввиду? ref и mut в паттернах? Так они с самого начала там, просто раньше было больше исключений, теперь всё выглядит более консистентно.
> В выражениях "if let" изменена область видимости временных значений
>> В выражениях "if let" изменена область видимости временных значенийТак это не синтаксическое изменение же.
Такое часто бывает среди здешних (и не только) "экспертов", увы, когда люди путают синтаксис с семантикой.
>>> В выражениях "if let" изменена область видимости временных значений
> Так это не синтаксическое изменение же.Еще хуже. В "стабильном языке", который тащят в ядро в минорной версии меняют семантику if let? Молодцы. Видимо без изменений в псевдодеятельности скучно, а созанием продуктов всем лень заниматься.
Такое ощущение, что вы новость не читали. Речь о вышедшей новой редакции языка Rust.
Так это разрешительная семантика, а не запретительная. Какие в этом проблемы?
Запомни %USERNAME%! Это - не рак, это развитие!
Несмотря на то, что в вашем сообщении содержится неприкрытый сарказм, это действительно развитие. Просто идёт оно немного по-другому, не так, как многие диды привыкли. Есть и минусы, конечно. Но плюсов всё-таки больше. Почему так? Потому что современное ПО (ядро ОС) не упрощается, а усложняется. Уже 40 миллионов срок (да, с драйверами, я помню). И это ведь не предел. Си просто изначально не разрабатывался с учётом такой сложности.
Тормозное развитие. Вирт ещё в 80-х годах придумал надёжные языки для системного программирования (Модула и Оберон) (и ещё Аду придумали), а фирмы только сейчас начали думать что надо бы использовать что-то понадёжнее С. Модула и Оберон - это, конечно, только концепции, но они указывали куда надо двигаться. Кое-как фирмы что-то слепили из Ады и Zonnon'а (то есть Rust). Позор фирмам!
Rust - язык повышенной надёжности, в своей области он, может быть и хорош, но для задач обычной надёжности программировать на нём слишком накладно будет. И уж, конечно, в любительских проектах общественной разработки ему не место.
Если вы такое пишете, то возможно это именно вам не место в проектах общественной разработки.
>программировать на нём слишком накладно будетБиблиотек уже много написали. Так что нет, слишком накладно не будет, хотя некоторые неудобства всё же могут быть с непривычки. Например, относительно высокий порог вхождения (но это одноразовые расходы), сложная семантика (по сравнению с Си, Голэнгом), длительная компиляция (с этим постоянно борются разработчики компилятора).
Зато в итоге получите качественный и быстрый в исполнении код.>И уж, конечно, в любительских проектах общественной разработки ему не место.
Почему? Там много людей со слабыми когнитивными способностями? Или по какой ещё причине?
>Там много людей со слабыми когнитивными способностями?Когда за деньги что-то делают, то можно и напрячься, а если для удовольствия, то надо наоборот как можно более простой язык, чтоб мозги отдыхали. Вот С для этого хорош, можно даже ни о чём не думать.
Так Rust наоборот снижает когнитивную нагрузку. Тебе не надо постоянно думать, что у тебя ссылка (указатель) протухнет вдруг неожиданно, что в многопотоке что-то сломается и т. д.Только там где unsafe пишешь, приходится поскрипеть мозгами иногда. Но и то всегда есть чёткий список, что нужно проверить, какие инварианты доказать.
Фигня все это, через несколько лет в си и си++ затащат новыми стандартами все основные примочки раста и все как сидели так идальше будет сидеть на сях... Потому что тяжело ломать стереотипы, порой даже нереально. Например от самой медленной раскладки QWERTY так и не ушли, а уж почти целый век канул...
В Си это точно не затащат, а в C++ в самом лучшем случае в 29 стандарте будет, а потом ещё пока в компиляторах реализуют…
Интересно, что это пишут люди, преувеличенно шарахающиеся от ясного и несложного синтаксиса Rust. Многоэтажные навороты современного C++ их при этом не смущают. https://ders.by/cpp/norefs/norefs.html
Многоэтажный C++ предлагает шаблоны, а что предлагает Rust заместо них?
>Многоэтажный C++ предлагает шаблоны, а что предлагает Rust заместо них?Вы совсем, что ли, не в теме?
Смотря чего вы хотите от шаблонов. Если вычисления времени компиляции — то макросы и build.rs.
Забавный текст по ссылке. Интересно что автор по сути так и не объяснил чем плохи ссылки (и хороши указатели).