Rust 1.34

Вот это очень типично. Сначала их игнорируют, потому что нужно сделать так, чтобы работало. Потом потому, что пришлось привлекать новых людей, а молодёжь всё равно их не читает и к тому же у всех разные IDE и даже версии компилятора. А потом потому что проект старый.

Я не знаю, где это типично. Нормальные люди пишут нормально. Сейчас почти в любом крестовом проекте код ревью, CI&CD, статические анализаторы, санитайзеры, юнит тесты, авто тесты и т.п.

С нулевою стоимостью не выйдет. В том же Паскале 30 лет как есть ключ, позволяющий отключить проверку диапазона. И константы, и модули, всё то, что никак не завезут в Си толком. Но народ продолжает джедаить на Си, совершая присваивания в заголовке условного оператора.

Если нужно, чтобы было надёжно и при это достаточно быстро, используйте ML, тот же OCaml или MLton. Там если скомпилировалось, то уже большинство ошибок выловилось. Только проектировать будете до опупения. Хотя возможности реально огромные. Но всё равно будут издержки.

Сейчас почти в любом крестовом проекте код ревью, CI&CD, статические анализаторы, санитайзеры, юнит тесты, авто тесты и т.п.

Но практически нигде не используют принудительное форматирование (astyle etc). А пользы от него больше, чем от всего вышеперечисленного.

Мне эта другая логика не понятна. Как-то все скатывается в аргументы типа «мы большие парни, пишем большие проекты и юзаем большие библиотеки». Послушать половину лоровских специалистов - они исключительно под кластеры из 100 машин код пишут :). Это надо далеко не всем.

Насчет синтаксиса и фич - вкусовщина IMHO. Не вижу смысла спорить. На лоре всегда найдутся специалисты, которые будут с пеной у рта доказывать преимущество какой-нибудь нотации, как будто все остальное не имеет значения. Меня то что происходит в расте вполне устраивает. Я бы и на сях писал, не особо заморачиваясь, если б там пакетный менеджер был и нормальное управление зависимостями. Но их нет.

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

Но практически нигде не используют принудительное форматирование

Есть и тут хорошая тенденция, благодаря clang-format.

если б там пакетный менеджер

Conan, например.

не используй GNUсный Rust если ты не педоRust.

Sounds gay

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

Ты забыл разлогиниться или из под анона такое пишет твой парень?

Оно все очень «сбоку», по сравнению с rust-ом (и любым другим Х с микромодулями), где и пакеты и сборка под все платформы сразу из коробки. В итоге никто массово не делает описания пакетов в своих репах и это просто не взлетает.

Есть и platfotmio, толку-то... На закостылять временно хватает, но все равно очень большая разница между родными тулзами.

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

Но народ продолжает джедаить на Си, совершая присваивания в заголовке условного оператора.

питонщики так тоже умеют

OCaml или MLton. Там если скомпилировалось, то уже большинство ошибок выловилось. Только проектировать будете до опупения. Хотя возможности реально огромные. Но всё равно будут издержки.

Расскажи подробнее?

их кто-то поддерживает

И? Какое это имеет отношение к постоянной основе?

Если нужно, чтобы было надёжно и при это достаточно быстро, используйте ML, тот же OCaml или MLton.

Добавлю в вашу дискуссию с анонимом.

OCaml здесь по очевидным причинам пролетает: сборщик мусора, тегированные типы. Откуда такая мантра взялась про OCaml?!

А вот Rust как раз таки подходит под критерии «чтобы было надёжно и при этом достаточно быстро». Это такая фишка языка Rust.

Похожие свойства есть только у Ada и некоторых других производных Паскаля / Алгола, где есть хорошие компиляторы, но Паскале-подобные как по мне, то они сейчас отстают от Rust в плане выразительности, но это только мое личное мнение. Попробуйте-ка там простое замыкание изобразить! Я не говорю про удобные классы типов и ограничения для них, к чему очень быстро привыкаешь, и уже без этого трудно писать код (классы типов в Rust назвали «трейтами»).

Впрочем убеждать никого не собираюсь, потому что не нужно это, да и бесполезно.

<source>:6:61: warning: binding reference member 'm_veryUsefulNumber' to stack allocated parameter 'veryUsefulNumber' [-Wdangling-field]

    Foo(const double veryUsefulNumber) : m_veryUsefulNumber(veryUsefulNumber) {}

                                                            ^~~~~~~~~~~~~~~~

<source>:4:19: note: reference member declared here

    const double& m_veryUsefulNumber;

                  ^

m_veryUsefulNumber
сложнее

Есть CMake от вида которого хочется плакать

Ты предлагаешь раст «от вида которого хочется плакать», дальше что? В чём проблема, если «от вида которого хочется плакать» для тебя ничего не значит?

Все эти хедеры и препроцессоры.

Покажи альтернативу. И что-бы она работала на всех версиях компилятора раста за последние 5-10лет.

Быстро же ты съехал с темы.

каминг-аут же один раз совершается?

Вышел релиз 1.34 языка системного программирования Rust, развиваемого проектом Mozilla.

Где бл"дь браузер, уважаемые компания Мазилла?

OCaml здесь по очевидным причинам пролетает: сборщик мусора, тегированные типы. Откуда такая мантра взялась про OCaml?!

Раньше 15 - 20 лет назад OCaml вполне конкурировал с Си и С++ компиляторами, пусть и не с самыми лучшими.

Если бы да кабы... jvm - это одна программа. И пофиксить одну легче. Да и одну программу можно раз и навсегда проверить всю.

Все ваше существование, как впрочем и мое, строится на этом самом если бы да кабы, но вас же это не смущало до текущего момента. Дело всегда в одной программе, а если быть еще более точным в одной ошибке, которая все портит. К чему эта писанина если суть остается той же? Нельзя проверить одну программу всю раз и навсегда, тем более когда вы постоянно ее переписываете и дополняете, нет ничего постоянного в этом мире, хотя опять же можно принять что-то как условно постоянное через формализацию с оговорками и с «если бы да кабы».

На этот вопрос существует формализованный ответ.

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

Изобрели, точнее развили ранее изобретенные идеи - субструктурные системы типов и владение. Управляемый код - это не единственный способ. Можно ограничить язык, но оставить код нативным и этим добиться memory safety. По этому пути пошел язык о котором новость.

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

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

Что посоветуете натуралам? И если можно тоже в шуточной форме.

Поддержу не будет там модулей, не тот это язык. Для этого есть С++.

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

Ада, кстати, тоже вариант. За счёт суровой типизации она весьма сносна. Как и Модула.

Сорри, я в них путаюсь, речь о плюсах конечно. Ну вот завезут, откроется новое дыхание.

Есть еще момент с установкой всяких вспомогательных тулзов, которая есть в языках Х. На примере раста: https://www.rust-lang.org/tools. Всякие там линтеры, тесты и т.п.

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

Сям и плюсам давно пора подтянуться до этого уровня, пока не просрали все полимеры как похапе.

речь о плюсах конечно
откроется новое дыхание

Смешно.

Что именно?

На примере раста: https://www.rust-lang.org/tools.

Тогда уж: https://crates.io/categories/development-tools::cargo-plugins

Теперь либо раст сдохнет, либо анализаторы для него напишут.

Уже написали https://github.com/rust-lang/rust-clippy

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

Типа того.

Если же это работает и на этапе выполнения каков оверхед дополнительного кода ограничения?

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

Да и в чем вообще смысл если среда исполнения остается по сути нативной?

Невозможность скомпилировать код с memory corruption или data race. Отсутствие UB.

Непосредственное.

#define ПОСТОЯННАЯ_ОСНОВА

Хотя, смысл околонулевой об этом спорить. Сделаем проще «На постоянной основе пишет 10 человек на весь мир» - ложь, пока нет пруфов обратного.

Там солянка, а я только о тех тулзах, что поддерживаются официально.

В clang есть неплохие альтернативы, но все это наковыривать ручками, особенно если другой компилятор - так себе удовольствие.

Сделаем проще «На постоянной основе пишет 10 человек на весь мир» - ложь, пока нет пруфов обратного.

Только компилятор rust больше 100 человек разрабатывают https://blog.rust-lang.org/2019/04/23/roadmap.html

Невозможность скомпилировать код с memory corruption или data race. Отсутствие UB.

Это, на сколько я понимаю, если не использовать unsafe.

Да не обращай внимания, немного троллю). По моему мнению, C++ набрал и продолжает набирать запредельный груз избыточной сложности, что приведёт к его краху. «Второго дыхания» не будет.

Да. Но нужность unsafe преувеличена.

По моему мнению, C++ набрал и продолжает набирать запредельный груз избыточной сложности

Почему же тогда программировать на современном C++ проще, чем на C++ двадцатилетней давности?

Cargo может поддерживать альтернативные реестры

Ага, значит самое время поднять свой crates.io, в котором собирать только хорошие пакеты, причем по одному на задачу, а то задрало выбирать пакет из 5 вариантов, из которых 2 - заброшенные наколенные альфы с половиной пустых модулей, 1 - просто зарезервированное имя пакета, а 2 оставшиеся требуют городить тонны билдеров и врапперов, но при этом все равно жутко ограничены в кастомизации функционала. Основной репозиторий без модерации = большой процент разочаровавшихся среди потенциальных юзеров языка. В хаскеле, где проблемы подобного рода были еще сильнее, придумали stackage, правда он тоже скатился в некомпилябельное гавно. Не дадим расту утонуть в Васянских хелловорлдах!

Почему же тогда программировать на современном C++ проще, чем на C++ двадцатилетней давности?

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

Ну никто ж не мешает подмножества фич использовать. Это уже в руках программистов. Язык как язык. Меня только экосистема напрягает, но очень сильно :).

Это мне напоминает времена, когда компиляторы были говёные (особенно для эмбедов). Всякие долбонавты, считающие себя специалистами по ассемблеру, лезли во все щели, рассказывать что они крутые а остальные плесень. Жизнь расставила все по местам. И с пакетными менеджерами так же будет.

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

Да не обращай внимания, немного троллю). По моему мнению, C++ набрал и продолжает набирать запредельный груз избыточной сложности, что приведёт к его краху. «Второго дыхания» не будет.

Эту сложность добавляют только по необходимости.

Много лет обсуждая варианты.

Бывают косяки с принятием сомнительных решений, но редко и их потом исправляют.

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

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

Идея хорошая, но дальше.

И эта привязка всех к cargo. Смерть руби из за своего пакетных менеджера их ничему не научила.

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

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

Просто с растом особая история из-за жесткости компилятора. Очень сложно спроектировать либу так, чтоб она удовлетворяла всех, кому нужен данный функционал. В итоге неизбежно расслоение, когда одну и ту же задачу приходится решать с разным интерфейсом (ну как DOM и SAX в парсинге xml). И надо это всё разложить по полочкам, а не открыл пакет, посмотрел его зависимости, закрыл.

Вопрос качественного дизайна архитектуры - проблема не специфичная для раста. Просто раст за явные косяки сразу лупит палкой по рукам.

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