Rust 1.34

Там есть совместимость с C++ и статическая проверка контрактов?

Да есть, gnat на базе gcc, так что у него все очень неплохо с C++, а уж контракты это прям сейчас хлеб Ada-2012 + SPARK.

Вот недавний редкий обзорный доклад Рыбина из AdaCore

Вот недавний редкий обзорный доклад Рыбина из AdaCore

На 3:10:

«И Ada единственный язык, который честно выполняет требования к международным стандартам, а именно: раз в 10 лет стандарт должен быть пересмотрен».

Докладчик несколько лукавит или не в теме.

Нет. Это разные ответы. MyTrooName фиксит исходную проблему с неверно указанным лайфтаймом для get.

У скопированного значения лайфтайм ограничен функцией.

Поле объекта является ссылка. Проблема тут в неверно написанном get. А именно - нужно руками проставить правильный лайфтайм, поскольку компилятор вывел более ограниченный.

Никогда не понимал плюсоводов, которые так рьяно накидываются на Rust. Наоборот радоваться надо, что появился язык с бОльшим количеством compile-time гарантий. Можно у Rust много чему поучиться.

Особенно повеселило где в ранее в треде compile-time гарантии сравнивались с санитайзерами :)

Наоборот радоваться надо, что появился язык с бОльшим количеством compile-time гарантий. Можно у Rust много чему поучиться.

Так этому-то рады. Просто язык хреновый получился

Поле объекта ссылка, а передаешь в функцию значение, ссылку на которое пытаешься из функции вернуть. У тебя две разные проблемы в коде, лол. Одна с лайфтаймами, вторая с попыткой вернуть ссылку на локальный объект.

На 3:10:

«И Ada единственный язык, который честно выполняет требования к международным стандартам, а именно: раз в 10 лет стандарт должен быть пересмотрен».

Докладчик несколько лукавит или не в теме.

Ну он заинтересованная сторона, но как бы все равно это не умоляет достоинства Ada, так же как и недостатки.

Хотя да, тут я неправ.

compile-time гарантии сравнивались с санитайзерами

Вы не поняли. Сравнивали в целом ситуацию. И не только с санитайзерами, но и статическими анализаторами. А за проверки раст нужно платить дизайном, временем разработки и компиляции.

но как бы все равно это не умоляет достоинства Ada, так же как и недостатки

Это как бы подрывает доверие к тому, что он говорит.

Для C я такое видел

Что за анализатор?

А за проверки раст нужно платить временем компиляции.

мы все еще сравниваем с плюсами?

Единственное место, где нужно платить - это за использование RefCell, которое в критических местах можно заменить на UnsafeCell, эквивалентное тупому куску памяти, где скорость такая же как в Си++, но с теми же гарантиями как и в Си++, т.е. они просто отсутствуют. Таких критических мест не так и много обычно бывает. Можно и заменить.

А вот деление на Rc/Arc в Rust гораздо лучше выглядит по скорости, чем негибкий shared_ptr в Си++.

Так что, бабка надвое сказала.

Frama-C, например.

Но он это делает за тебя.
А системные дескрипторы в плюсах(да в расте) ты оборачиваешь структурой/классом с деструктором.

Вы прочитали всю ветку моих сообщений?

Нет. В C++ все в порядке с move-семантикой.

По вашему, вызов деструктора для объекта, данные которого перемещены — это удачное решение?
На практике это выливается в постоянные проверки в деструкторе на предмет того, был ли объект перемещён или нет.

Нет, не выливается.

Как в подобных ситуациях избавляться от проверки?

Ваши ответы немного не по теме.

Речь идёт об абстрактном ресурсе

Смартпойнтеры работают для любых ресурсов

То есть именно unique_ptr/shared_ptr

Ещё раз.

Тема обсуждения — не выбор оболчки для управления ресурсами.

Тема обсуждения — проверки в деструкторах как следствие кривой move-семантики C++.

Управление памятью было дано как пример. Я прекрасно знаю про существование умных указателей.

Конечно работает, хер ли нет. Мутабельная ссылка единственная (и она тут не нужна), в любой конкретный момент жизни функции bar и ниже по стеку она существует в единственном экземпляре. Странный пример, если бы это не работало — мутирующий код наверное нельзя было бы использовать вообще.

Утащил в вопросы для собеседования: простой, но хороший, с подвохом из-за кажущейся неправильности последнего блока.

Ошибка во втором блоке: анонимный лайфтайм для возвращаемого значения привяжется к тому же лайфтайму что и self, что является сабсетом лайфтайма 'a. Таким образом использование метода get невозможно в функциях поглощающих значение А, так как ссылка полученная через get не может пережить уничтожение объекта.

Надо

impl<'a> A<'a> {
    fn get(&self) -> &'a i32 {
        self.x
    }
}

А в последнем блоке — тривиальный лайфтайм, который Rust может вывести сам.

А, уже пояснили :)

Тред не читал

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

Скоро.

А за проверки раст нужно платить

дизайном

Слишком закостенел чтобы отказаться от ООП? Насчет борроучекера: у Си и крестов лайфтаймы точно такие же и правила заимствования данных тоже. Если не веришь — посмотри на гайдлайны GLIB, где контракты по владению-заимствованию прописаны явно. Rust просто автоматизирует проверки соблюдения этих правил.

временем разработки

Благородные доны не считают отладку частью разработки? Сколько времени уходит на отладки гонок данных, напомни?

и компиляции.

Ну не крестовикам уж жаловаться

Не раньше вменяемого GUI-фреймворка.

Если ниша заполнена, то вряд ли там что-то новое появится. На Аде же не пишут популярные видео-проигрыватели.

Есть биндиги для Qt5 - кроссплатформенный, куда уж внемяемей.

На Аде же не пишут популярные видео-проигрыватели.

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

А нынешним хипстерам Ada не интересна в принципе. В том числе и по причине своего почтенного возраста.

Ада разрабатывался как язык для встроенных систем министерством обороны США.

Rust позиционируется как язык общего назначения.

zhdun.png

Есть биндиги для Qt5

Лул. Они много для чего есть. А пишут по-прежнему на плюсах. Догадайтесь почему.

Почему?

Потому, что Qt завязан на фичи C++, типа наследования.

Что же тогда выбрать? GTK? FLTK? TCL/TK?

Qt. И пилить на плюсах. Ну или Electron. Для особых извращенцев - JavaFX/Swing.

Ну ладно, пусть будет, например, новый хороший CMS

Вы про веб? Ну тогда нужно async дождаться.

Про веб, раз уж сейчас так популярны веб- приложения и прочее.

Но ниша raw конвертеров тоже не сказать, что сильно занята в linux, хоть их и достаточно много.

Из прог для конечного пользователя, самыми популярными будут ripgrep и alacritty.

Много чего интересного пока на стадии альфа.

Ада разрабатывался как язык для встроенных систем министерством обороны США.

Ада всегда была и остается языком общего назначения. Ее первую версию, кстати, француз один придумал для американского конкурса. Как обычно, умея решать общую задачу, проще решить частную. Девиз динамического программирования работает много где.

Сейчас, вообще, сложно придумать что-то новое. Многие ниши определились давно, и работает другое правило, чтобы обычно выигрывает не самый лучший, а первый подходящий, а для этого, как правило, использовали Си или Си++.

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

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

Ада всегда была и остается языком общего назначения. Ее первую версию, кстати, француз один придумал для американского конкурса.

Конкурса мин. обороны США на язык для встраиваемых систем. Эту нишу он успешно тогда и занял.

Никто не ждёт переписывания того, что уже написано - за это редко кто платит.

Между тем, Rust как язык прекрасен.

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

Однако не все растоманы могут ответить легко на вопрос =)

И вживую я это тоже наблюдал.

Между тем, Rust как язык прекрасен.

Укуренный синтаксис, ограничения принятых в отрасли подходов, ограничения работы с «ссылками» ради упрощения «проверок» владения с неясной до конца полезностью в реальной жизни и пр.

Изначально очень надеялся на этот язык, но вышло не очень.

приложений для предоставления веб-сервисов

Что значит «представления» в данном контексте? Сервисы на расте писать пока не очень удобно. Кстати, там относительно взлетел go.

Утащил в вопросы для собеседования

нафига нужны такие паззлы? Это же бессмысленно. Раст - это не плюсы с питонами, ошибки компилятора и их исправление тут неотъемлемая часть разработки.

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

Dropbox же его использует в своей инфраструктуре. Из списка других контор, его использующих, многие тоже предоставляют услуги через веб-прилржения в том или ином виде. Не обязательно, чтобы всё держалось на нём.

Но пока массового увлечения написания на нём прикладных приложений для десктопа не видно.

Это потому что они уже написаны. Массово не будет, потому что не так часто нужно создать новое приложение не имеющее аналогов.

у Си и крестов лайфтаймы точно такие же и правила заимствования данных тоже

Тема с одной «мутабельной»(хотя мутабельность тут ни при чем на самом деле) ссылкой или несколькими не мутабельными «в один момент времени» - чисто растовское ограничение. И это не часть хороших практик плюсов, например.

Это делается только для упрощения обнаружения проблем и ни для чего больше.

Я знаю, что delete проверяет на nullptr. Будем считать, что он этого не делает.

А зачем считать, что он этого не делает, если он это делает? Так же должна поступать и любая другая функция очистки любого другого ресурса.