Релиз языка программирования Rust 1.39

Тебе часом не 15 лет?

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

Я для тебя открою секрет. Можно еще реально заниматься сексом. Надеюсь ты не шокирован

Что думаешь чтобы переходить на ReasonML, как синтаксиса для нативных билдов OCaml програм?

Абсолютно верно.

Я использую Akka - однако, теперь только под Java.

«Виртовская» система типов неудобна.

Все эти «подмешивания» «типажей» (traits) - просто излишний «синтаксический сахар».

Мода на подобные «сахарные» диалекты Java была пять лет назад.

DSL (предметно-ориентированные языки) затруднительны тем, что непонятно, а что автор кода хотел сказать?

Секс это миф придуманный женщинами чтоб женить на себе мужчин. В СССР секса не было и все жили прекрасно.

Тебе часом не 15 лет?

Если тебе кажется что я прям из штанов от желания выпрыгиваю — то тебе показалось. Однако, отрицать красоту женского тела я не намерен: после 15 пылу, конечно, поубавилось, но открыто говорить на сиськи «фи» я еще не готов.

Я для тебя открою секрет. Можно еще реально заниматься сексом. Надеюсь ты не шокирован

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

Ну OCaml если что, очень простой. Особого ума не нужно

Не, ну я больше не о ногах прохожей, а то, чтобы перло от выдуманного сюжета где Brazzers-style бабы рассказывают о JavaScript. Вроде уже как раз такое могло бы приесться всем, на реальных красивых женщин не оч похоже

Ну так я ж говорю, в чем трабла сделать форк где лифтайм не отключается?

Дальше произойдёт одно из двух. Либо этот форк окажется отличным, будет работать без напильника с любым С/C++ кодом, в том смысле что корректный код будет компилироваться, а некорректный выдавать ошибку. Чтоб всегда, даже при подключении внешних либ. Постепенно функционал перекочует в другие компиляторы и Rust окажется ненужным несовместимым почти аналогом популярного языка. Ну как какой-нибудь Pascal давно или Oberon сейчас. Будет группа фанатов, рассказывающих, что лайфтаймы украли из Rust и всё равно код на нём красивее и понятнее чем на C++, но всем кто не из их тусовочки будет пофиг.

Либо эти лайфтаймы будут работать через пень-колоду, и нормальный C++ проект просто не будет компилироваться или потребует дописания 100500 всяких аннотаций к каждой функции. Тогда это уже не будет компилятор C++, язык будет необходимо переименовать в D++, в общем-то и получится аналог D, т.е. никчёмный язык, непонятно для чего нужный, с одной стороны типа совместимый, можно небольшие куски C++ кода со стековерфлоу копипастить, с другой - портирование реального проекта настолько муторно, что в общем переписать на Rust ненамного сложнее.

Судя по существовании инициативы C++ Core Guidelines, реалистичен скорее второй вариант.

За D не стоит крупных компаний. Если б не потуги Мозиллы - нафиг бы сдалась ржавчина. Уже C++ последних стандартов выглядит более дружелюбным.

каким образом связаны эти три утверждения? как они опровергают, что D, в сравнении с rust&go - мертв?

чтобы перло от выдуманного сюжета где Brazzers-style бабы рассказывают о JavaScript

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

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

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

еще чуть-чуть и они изобретут хаскель для жвм? :3

Есть и такой – https://github.com/Frege/frege

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

В GCC не стали бы впендюривать в 2019 мёртвый язык.

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

В хаскелле, кстати, помимо Maybe/Either есть и Exception. А вот в расте кроме паники не завезли подобного, увы. Есть,конечно std::panic::catch_unwind, но его совсем не рекомендуется использовать вместо try-catch.

Товарищ-вентилятор, ты совершенно не в теме, в haskell тоже есть исключения. Для них есть свои throw, catch и finally.

Не будет он работать без напильника. Либо придется пожертвовать корректностью проверки, либо придется пожертвовать кодом, который перестанет компилироваться. Если выбирать первое, то для чего тогда вообще что-то делать? Если второе, то уж лучше оставить как есть, чем ломать совместимость. Невозможно полностью перенести лайфтаймы, не внося при этом изменений в синтаксис языка, а внесение изменений в синтаксис по определению превращает твою поделку в D++.

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

Ну это же коллекция компиляторов, коллекционеры вообще любят всякие мертвые вещицы, страсть у них к собирательству…

В rust тоже по факту есть исключения, но они представлены одной паникой (зависит от настроек паники). Причем, в случае безопасного Rust по идее должны выполняться базовые гарантии безопасности, т.е. грубо говоря, сегфолта или какого другого фатального сигнала быть не должно. Правда, это еще зависит от того, как написаны части unsafe, которые используются из такой «безопасной» части.

островок и скалка по дизайну вынуждены будут повторить судьбу крестов если конечно не смогут оторваться от жвм (спойлер - не смогут, это никому не нужно). А так то никто не спорит что поверхностный слой пудры делает язык местами удобней.

В GCC не стали бы впендюривать в 2019 мёртвый язык.

там и фортран есть и ада, а у ады недавно новый релиз вышел.
мне суть спора не понятна. я что - сказал, что руст хороший ?
оратор заявил, что d популярней rust и go. это ложь.
если сравнивать по популярности, то d - нигде.

И что, Ада тоже мертвая? Мне тоже не понятна суть ваших заявлений. Если вы что то не используете, это не значит, что этого нет. D стабильно развивается, регулярные релизы, ежегодные конференции, коммерческие компании его используют, некоторые вообще строят на нем всю свою инфраструктуру. И тут на тебе, приходит dinama и все расставляет на своих местах. Еще и Аду хоронит. А мужики то не знали! Другое дело, что go конечно более распространен чем rust или D - это да. Причем у Rust именно много хайпа, в отличие от go или D.

да все нормально с D, просто вбрасывать же кто-то должен периодически чтобы оживлять дискуссию.

https://eta-lang.org/

объем головного мозга человека действительно уменьшился

Если судить только по объёму мозга, то миром должны были править киты, ну или как минимум слоны.

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

А вот в расте кроме паники не завезли подобного,

Есть `Result<T, E>` и сахар в виде `?`. В принципе хватает. И при этом быстрее исключений.
Плюс ещё думают над try-блоком.

Т.е. без исключений вполне можно обходится и не особо над этим страдать.

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

Ну так и есть, естественный отбор не работает, все как в Слепом часовщике

А так просто уровень дискуссии падает.

Сказал человек, экстраполирующий собственное мнение на всех.

И при этом быстрее исключений.

Спорно. Скорее на оборот.

Result медленнее исключений? С чего бы это?

На большой вложенности, на x86_64, исключения должны быть быстрее. Как минимум это верно для C++.

Result далеко не бесплатный. И если у нас 100500 проверок внутри функции, может ощутимо влиять на производительность.

Пока не дошло до измерений у самого, но пишут в тырнетах, что именно так. Имеется в виду C++, конечно.

А в растишке эти Error еще надо бывает приводить к другу другу, чтобы по типу совпадало.

Потом, Result отжирает стек чуточку больше.

Но причём тут скорость?

И если у нас 100500 проверок внутри функции,

Ну разве что 100500.

Как причем? Из таких мелочей и складывается эффективность часто, когда все остальное на одном уровне. В C++ есть даже связанное с этим понятие «пессимизация» - как бы в укор Кнуту :)

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

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

Result медленнее исключений? С чего бы это?

Обычно исключения реализованы так, что они бесплатны до тех пор, пока исключение не было брошено. Потому, если в результате исполнения ошибок мало (а это типичная ситуация), то код на Rust будет постоянно делать дополнительную работу, а код на С++ - нет.

Да есть даже ненулевой шанс, что предсказатель переходов, вшитый в (суперскалярный) процессор, может дать сбой при оценке Result.

Ещё раз, ты можешь показать как большее использование стека влияет на производительность?

Как будет падать скорость если вместо `struct res` я буду возвращать `struct{ enum rtype; union{ struct res; struct err; }; }`?

Ну, вообще говоря, паддинг и выравнивание. Либо выравниваешь, увеличивая затраты памяти, либо пакуешь плотно, тратя больше процессорного времени на распаковку.

Как будет падать скорость если вместо struct res я буду возвращать struct{ enum rtype; union{ struct res; struct err; }; }?

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

Ну дык выравнивание ещё специально отключать надо.
Так-то все структуры выравниваются по умолчанию. Даже в сишечке.
Просто я к тому что большее использование стека совсем не равно меньшей производительности.

Не стану приводить. Обойдешься! Причем, для себя я это делал при тестировании.

Технически правильно, но если ошибок мало, branch predictor будет редко ошибаться. Какой-то оверхед будет, но насколько заметный - сильно зависит от кода, который в разных языках будет, естественно разным.