Опрос: Три-пять лучших фич C++

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

Весь буст слепо — да, не будут, это симптом рака. Но в бусте есть несколько годных либ.

Ты-то передал объект с «const», но функция дернула метод, который через глобальные ссылки поменял «константный» объект.

Предпочту держаться от такого кода подальше.

Самый-присамый каноничный пример проблемы — оператор присовоения самому себе. У него ведь тоже «const T&», но при этом он сразу же свой аргумент меняет, и потому надо обязательно это дело поднимать костылем из &arg != this.

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

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

https://en.cppreference.com/w/cpp/language/rule_of_three

Это уже считается нормой, что для объекта нужно создавать три-пять методов, 2-4 из которых делают по сути одно и то же. По идее ведь компилятор вообще не должен был разрешать вызов T& operator=(const T& other), если аргумент меняется в результате вызова, нарушая константность. Но константность в крестах слишком слабая, она мало от чего защищает. Хуже всего то, что создается ложное впечатление будто защита есть.

Если учесть частоту использования операторов присовения, то, грубо говоря, на десять строчек твоего кода будет два тонких малозаметных способа выстрелить себе в ногу. Но ты будешь читать код и не заметишь подобной проблемы, потому что ты годами натренировался именно эти тонкие вещи находить. Я сам в сишке надрессировался вынюхивать тончайшие намеки на трудности при выполнении, но я не испытываю иллюзии по этому поводу и понимаю, что ошибиться в сишке очень и очень просто. В отличие от некоторых наиболее отбитых здесь, которые всерьез рассказывают про «в сишке меньше ошибок, ведь больше контроля над выполнением, не ошибайся — и не будет багов».

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

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

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

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

Проблема в том, что «сложно» в крестах — это любая нелокальная память, которая потенциально изменяется из неизвестного числа месте.

А где это легко?

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

Каким образом?

Ты серьезно считаешь меня питонистом?

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

Потом меня это дело задостало, я взял и сократил время компиляции до 5 минут

Поделись рецептом что ли.

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

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

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

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

Соберу в кучу эти цитаты, чтобы подчеркнуть, что «держаться подальше» ты от операторов присваивания в крестах не сможешь

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

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

Это уже считается нормой, что для объекта нужно создавать три-пять методов, 2-4 из которых делают по сути одно и то же.

О каких пяти и четырёх методах речь? Ладно ещё конструктор и оператор присваивания, хотя они достаточно отдалённо похожи друг на друга.

По идее ведь компилятор вообще не должен был разрешать вызов T& operator=(const T& other)

И как это должно было бы работать? В рантайме? Спасибо, не надо. Или ты опять за своё: сделайте чтобы всё работало как я хочу, иначе не надо никак?

Не вижу, как из моих слов получается такой вывод.

Дык, ты постоянно говоришь «X не решает всех проблем» (или «X можно поломать, если…»). Вот я и говорю, что всё можно поломать, а значит гарантий нет нигде.

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

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

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

Проблема в том, что «сложно» в крестах — это любая нелокальная память, которая потенциально изменяется из неизвестного числа месте.

А где это легко?

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

Каким образом?

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

Не именно питонистом, но человеком любящим динамические языки. Ну и С

Гениально. Придумал бы что-то еще более абстрактное, вроде «любящего уверенность и определённость».

Потом меня это дело задостало, я взял и сократил время компиляции до 5 минут

Поделись рецептом что ли

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

Я просто еще раз напоминаю, что медленная компиляция — это не какое-то неотъемлимое свойство любого мощного языка, а просто следствие плохой архитектуры этого языка. Паскаль был создан разрабом компиляторов, и даже на слабых компах выдавал 200 тыс строк в секунду. Zig создан упоротым системщиком-процедурщиком, потому на современном компе парсит в AST порядка 9 млн строк в секунду. Что говорят нам выкидыши энтерпрайза? «Скажите спасибо, что хотя бы тысячу строк в секунду компилируем».

Ничего против «неугомонности и гибкости» не имею, но в твоём случае явно не хватает глубины. По крайней мере, относительно плюсов и раста

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

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

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

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

Что есть «серебрянная пуля»? Один инструмент для того, чтобы закручивать винты, забивать гвозди, и смотреть на микробов? Весь парадокс популярных ЯП, который неявно описал сам Страуструп, сводится к тому, что для популярности ЯП должен реализовывать несовместимые фичи. В противовес этому, настоящее качество ЯП определяется простотой языка. То есть, популярность и качества языка противоположны друг другу. И одно из противоречивых требований — иметь возможность писать «быстро-просто-безопасно», и при этом максимально низкоуровневую системщину на машине Тьюринга, поскольку машина Тьюринга естественным образом стала противоположностью надежности и производительности примерно последние 40 лет.

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

Да, потому int не нужен, нужно прямо писать let b = a + 2. Вокруг этого был весь бум динамики 90-х годов.

От операторов присваивания может и не смогу (хотя в расте их и нет, по крайней мере, определяемых пользователем), но вот не писать код, который присваивает сам объекты самим себе, постараюсь

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

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

Передаешь два аргумента функции, функция внутри присваивает один аргумент другому. Эту цепочку можно удлиннять дальше и дальше, и когда-то ты ошибешься.

О каких пяти и четырёх методах речь? Ладно ещё конструктор и оператор присваивания, хотя они достаточно отдалённо похожи друг на друга

Перемещающий конструктор и перемещающее присовение.

По идее ведь компилятор вообще не должен был разрешать вызов T& operator=(const T& other)

И как это должно было бы работать? В рантайме? Спасибо, не надо. Или ты опять за своё: сделайте чтобы всё работало как я хочу, иначе не надо никак?

Если формально — да, можно в рантайме. Но если переменные чисто локальные — возможна оптимизация.

Дык, ты постоянно говоришь «X не решает всех проблем» (или «X можно поломать, если…»). Вот я и говорю, что всё можно поломать, а значит гарантий нет нигде

const ломается везде, это не просто «есть недостаток», это сломанный by-design инструмент. Сишники даже не пытаются играться в const, который как бы есть, но на самом деле нет, а вот среди крестовиков эта религия почему-то получила популярность.

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

Ты ничего не сможешь сделать с рукожопами. «Рукожопы gonna рукожопить». Другое дело, что убрать тонкие UB из языка надо, но до конца обезопасить его ты не сможешь, зато сможешь упростить достаточно для того, чтобы ревью говнокода не вызывал приступы ярости.

Пакеты в очереди колбасятся как хотят по любым алгоритмам. после чего чистятся GC.

Погоди, ты изначально говорил о желании «отозвать пакет». GC, сам по себе, это сделать никак не поможет. Если задача просто дропнуть всю очередь пакетов или проигнорировать какой-то отдельный по условию, то, опять же, GC тут вообще ортогонален. И «почистить пакет» (удалить объект) нет проблем и без сборщика мусора.

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

Повторяю вопрос: как тут помогает GC?

Гениально. Придумал бы что-то еще более абстрактное, вроде «любящего уверенность и определённость».

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

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

Похвально, но возникают вопросы к проекту и команде. На «моём» проекте, на который недавно ссылался, вопросом скорости компиляции занимаются регулярно. Тыкнул какой-то случайный билд на дженкинсе: собирался больше двух с половиной часов, правда это релиз (и, вероятно, с тестами). Локально проверять лень. Я к тому, что где-то действительно можно добиться чудес, но на нормальных проектах за этим следят и ускорение в разы - это уже дофига и редко случается.

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

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

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

Но дело даже не в этом. Вот если бы ты честно говорил: раст слишком сложный, хочу что-то попроще, но со свойствами А и Б. Тогда и спорить было бы не о чем. Но нет, ты вместо этого начинаешь рассказывать о каких-то странных проблемах языков. Кстати, чем тебя Go не устраивает-то? Язык простой, достаточно быстрый, в ногу выстрелить сложнее, чем в С - бери и радуйся?

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

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

Что есть «серебрянная пуля»?

Почему ты меня спрашиваешь? Это ты ведь её ищешь ругаясь на все остальные языки.

Да, потому int не нужен, нужно прямо писать let b = a + 2. Вокруг этого был весь бум динамики 90-х годов.

Хорошо, что этот бум прошёл.

Передаешь два аргумента функции, функция внутри присваивает один аргумент другому. Эту цепочку можно удлиннять дальше и дальше, и когда-то ты ошибешься.

Вопрос в том приведёт ли эта ошибка к каким-то последствиям. Ок, это случилось - я присвоил объект самому себе. И что? Если это присвоение написано нормально (даже без «костыля» с this != other), то внешний код никаких изменений не увидит.

Перемещающий конструктор и перемещающее присовение.

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

А пятый метод?

const ломается везде, это не просто «есть недостаток», это сломанный by-design инструмент. Сишники даже не пытаются играться в const, который как бы есть, но на самом деле нет, а вот среди крестовиков эта религия почему-то получила популярность.

А может «сишники» (или скорее ты) «не осилили»?.. Хотя ладно, сломан, так сломан. Серьёзно спорить уже не могу.

Ты ничего не сможешь сделать с рукожопами.

Конкретно в моём случае могу: не брать их на работу. К слову, «чудовищно переусложнённые» языки выступают своего рода фильтром. Совсем безнадёжные за них и не будут браться.

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

Не уверен, что «убрать UB» - это (всегда) «упростить». По крайней мере, при сохранении прочих качеств.

Пакеты в очереди колбасятся как хотят по любым алгоритмам. после чего чистятся GC.

Погоди, ты изначально говорил о желании «отозвать пакет». GC, сам по себе, это сделать никак не поможет. Если задача просто дропнуть всю очередь пакетов или проигнорировать какой-то отдельный по условию, то, опять же, GC тут вообще ортогонален. И «почистить пакет» (удалить объект) нет проблем и без сборщика мусора.

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

Повторяю вопрос: как тут помогает GC?

Задача — выяснить, в каком состоянии находится наше приложение, и что дальше нужно делать. «Почистить пакет» — это не проблема, если у тебя один поток выполнения. Если у тебя потоков несколько, то здравствуй RCU, Quiescence State Reclamation, или, в конце-концов, GC — упорядочил по степени фичастости высвобождаемых структур. RCU требует, чтобы объект был простым значением. Я в PSO реализовывал высвобождение сложных структур с Quiescence State через дополнительный счетчик ссылок. Но циклические ссылки нельзя высвободить даже счетчиком ссылок — нужен строго GC.

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

а дальше нежелание разбираться в «сложных языках» умноженное на «хочу как я привык (но быстрее)»

Давай поставим вопрос иначе: почему я должен хотеть разбираться в языках, которые повёрнуты ко мне жопой? С хаскелем мой опыт закончился где-то на уровне сотни строчек кода (очень солидный результат, на самом деле), после чего я понял, что никогда не будут писать на этом языке. У хаскелистов даже есть специальная олимпиада: как взять простейшую вещь (монаду) и описать её настолько длинно, сложно, и непонятно, что это описание сможет понять только тот, кто уже хорошо знаком с монадами. Блин, я даже будучи знакомым с монадами не могу понять ту дичь, которая написана в статьях, «поясняющих» что такое монады. Кстати, если интересен правильный ответ:

https://www.youtube.com/watch?v=b0EF0VTs9Dc — Monads and Gonads

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

Похвально, но возникают вопросы к проекту и команде

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

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

Хм-м-м, разве это не актуально для 98% всей индустрии? «Код посредственного качества» — это даже вполне себе Qt, просто, её можно оправдать «наследие, мы начинали с девяностых и тащили совместимость до сих пор». Другое дело, что некоторые копируют Qt при написании проектов с нуля в 2022.

Вот если бы ты честно говорил: раст слишком сложный, хочу что-то попроще, но со свойствами А и Б

Пф-ф-ф:

Опрос: Три-пять лучших фич C++ (комментарий)

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

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

Кстати, чем тебя Go не устраивает-то? Язык простой, достаточно быстрый, в ногу выстрелить сложнее, чем в С - бери и радуйся?

Я разве когда-то писал, что меня не устраивает Go? Прекрасный язык, не считая того, что я почти с ним не знаком... почему-то.

Да, потому int не нужен, нужно прямо писать let b = a + 2. Вокруг этого был весь бум динамики 90-х годов.

Хорошо, что этот бум прошёл

Давно смотрел статистику популярности ЯП?

Но циклические ссылки нельзя высвободить даже счетчиком ссылок — нужен строго GC.

Можно использовать слабые ссылки. Что характерно, это бывает нужно и с GC.

Давай поставим вопрос иначе: почему я должен хотеть разбираться в языках, которые повёрнуты ко мне жопой?

А я такого и не говорил. Не хочешь - не разбирайся, но тогда и твоё мнение об этих языках особой ценности не имеет, разве что если мы выбираем язык по критерию «byko3y смог осилить» (ладно, ладно - «захотел»).

Впрочем, «повёрнуты жопой» - это уже эмоциональная оценка, а не техническая.

https://www.youtube.com/watch?v=b0EF0VTs9Dc — Monads and Gonads

А в виде текста нет?..

Хм-м-м, разве это не актуально для 98% всей индустрии?

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

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

Опять же, это говорит человек, который видел предмет спора издалека.

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

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

В общем, это нормально когда упирают на преимущества (особенно на официальной странице языка). Если ты зайдёшь в какой-нибудь чатик по расту, то там будет более широкий выбор мнений: восторженные неофиты, люди вдоволь походившие по граблям и, в том числе, разочаровавшиеся. Статьи говорящие и сложностях и проблемах мне тоже попадались.

Я разве когда-то писал, что меня не устраивает Go? Прекрасный язык, не считая того, что я почти с ним не знаком… почему-то.

Так может пора познакомиться поближе? Вдруг тогда и искать максимальное безболезненное подмножество плюсов не придётся.

Давно смотрел статистику популярности ЯП?

А что там? Смотрю TIOBE: в пятёрке динамический только питон. В десятке - добавился джаваскрипт. К обоим из этих языков типы как могут прикручивают.

Если это присвоение написано нормально (даже без «костыля» с this != other), то внешний код никаких изменений не увидит

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

Это просто геморрой на ровном месте. И да, это именно то, что я подразумевал под «авторы библиотеки годами морочились, а ты просто пришел и у тебя вроде как всё само работает». Тот же упомянутый деструктор QWidget усыпан горой костылей для обработки подобных щекотливых ситуаций со сложными ссылками.

Перемещающий конструктор и перемещающее присовение.

А пятый метод?

Деструктор.

Хотя если у тебя объект допускает инициализацию в «пустом» состоянии, то ты можешь выразить конструктор (и обычный и перемещающий) через присваивание (и обычное и перемещающее)

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

Но механизм неявных операций в крестах настолько безумно переусложнен, что полномочия компилятора заканчиваются где-то на copy/move elision. К сожалению, C++ написан при полном непонимании принципов работы компиляторов и, в частности, механизмов их оптимизации, потому подраузмевает, что ты будешь руками описывать каждый чих и пук, двигать каждый байтик у объекта при каждом доступе к объекту. В частности — в крестах не принято иметь никакого «пустого» состояния объекта, и это породило множество очень веселых форм садомазохизма.

А может «сишники» (или скорее ты) «не осилили»?.. Хотя ладно, сломан, так сломан. Серьёзно спорить уже не могу

И даже разработчики компиляторо не осилили, прикинь, они не оптимизируют const. Как я уже упомянул выше, на самом деле const используется сишниками, но в сильно более ограниченной роли константного значения «const int a = 2», со строго бинарной констатностью. Эту роль он способен выполнять, а не роли костыля для обозначения логической константности.

Конкретно в моём случае могу: не брать их на работу. К слову, «чудовищно переусложнённые» языки выступают своего рода фильтром. Совсем безнадёжные за них и не будут браться

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

Но циклические ссылки нельзя высвободить даже счетчиком ссылок — нужен строго GC

Можно использовать слабые ссылки. Что характерно, это бывает нужно и с GC

Можно, но рано или поздно в достаточно сложном алгоритме ты упираешь в циклы. Никто ведь даже не пытается описать достаточно сложную логику на крестах, чтобы было о чем говорить. Я сам по молодости пытался на Си писать сложную логику, с тех пор я такой глупости не повторял. Потому что количество подводных камней с ростом сложности растет в геометрической прогрессии, и в какой-то момент таких «this != &other» на каждую строчку нужно проверять сотни, и ты просто вязнешь наглухо в собственноручно созданной трясине.

Впрочем, «повёрнуты жопой» - это уже эмоциональная оценка, а не техническая

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

https://www.youtube.com/watch?v=b0EF0VTs9Dc — Monads and Gonads

А в виде текста нет?..

В интернетах нету, есть только презентация в текстовом виде.

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

Опять же, это говорит человек, который видел предмет спора издалека

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

GC преподносят как решение всех проблем, умалчивая о нюансах. Про функциональное программирование как серебряную пулю в противовес «плохому ООП» рассказывали давно и продолжают это делать. Любители ДСЛ и макросов регулярно байками кормят. Ну и т.д

Я лиспохейтер, если ты еще не заметил. Хотя я люблю кложу. но не за то, что она лисп. И индустрия тоже любит кложу не за лисп — лисперов не берут писать на кложе.

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

Так может пора познакомиться поближе? Вдруг тогда и искать максимальное безболезненное подмножество плюсов не придётся

Гугл именно с этой целью Go и создавал — сделать замену одновременно для C++, Java, и питона. Это три основных языка гугла. Они взяли лучшее из каждого языка.

Смотрю TIOBE: в пятёрке динамический только питон. В десятке - добавился джаваскрипт. К обоим из этих языков типы как могут прикручивают

TIOBE отображает популярность по поисковым запросам. Смотри на stackoveflow, особенно вкладку «Professional Developers»:

https://insights.stackoverflow.com/survey/2021#section-most-popular-technolog...

В топе JS, SQL, TypeScript, Python, Node.js, Bash, PHP. Из статических в топ 10 C# и Java, хотя в случае C# это уже спорно, потому что не так давно туда добавили динамические классы, то есть, можно вызывать функции и читать поля по строке-названию с любыми аргументами. В частности, это дает суперпростую сериализацию-десериализацию, особенно в JSON.

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

Можно проще: сначала увеличивать счётчик, потом уменьшать. Да, есть нюансы о которых надо знать, но всё совсем не так ужасно, как ты рассказываешь. Опять же, изначально речь шла о RAII и деструкторах, а теперь ты начинаешь приводить в пример случаи, где этот механизм вообще не помогает. И не потому что RAII и деструкторы в плюсах кривые, а потому что они никаким боком к оператору присваивания не относятся. То есть, если ты хочешь сказать, что язык не простой, то я изначально согласен. Но ведь ты клонишь к другому: язык сложный - значит «ничего не работает» (как ты хочешь).

Деструктор.

И с чем он дублируется?

Да, мудрые люди делают максимально простые конструкторы-деструкторы у объектов, и это помогает от кучи проблем, но это ни разу не крестовый мейнстрим.

Ну я бы не сказал. Или ты опять сейчас в Qt тыкать будешь? Не согласен потому, что там сложность не из-за того, что разработчики недостаточно мудрые. Наверное, если бы сейчас с нуля Qt дизайнить, то кое-что можно было бы сделать лучше. Вот только это малореально, да и в целом десктопные фреймворки (к моему сожалению) вымирают.

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

Можно, но не всегда это оптимально. Отчасти по этому пути пошли в расте: там перемещение «просто работает», ничего определять не надо. В итоге не требуются всякие «костыли» вроде std::move и std::forward и куча нюансов просто исчезает. Вот только на С++ уже написан код, где перемещение не сводится к побитовому копированию и портировать такой код на раст в лоб не получится. Насколько это проблема каждый решает сам, но гибкость и/или оптимальность таки может страдать.

В частности — в крестах не принято иметь никакого «пустого» состояния объекта, и это породило множество очень веселых форм садомазохизма.

По моему, мазохизм - это как раз пустые объекты. С ужасом вспоминаю времена когда делать «двухэтапную инициализацию» не считалось чем-то плохим: все эти init и is_init. Лучше уж optional<T>, которого в те времена не было «из коробки», но теперь-то есть. Плюс у некоторых типов всё-таки есть осмысленное «пустое» состояние: скажем строка или вектор.

а не удобного инструмента для обозначения логической константности.

Исправил для тебя.

Я тебя наверное удивлю, но питон — это переусложненный язык, на уровне крестов

Не удивишь. К счастью, не (слишком) заляпываться динамическими языками я тоже могу себе позволить.

Это достаточно технично?

Это уже не слишком объективно. Вот смотри: ты говоришь «по сравнению с грамотно спроектированными», но на самом деле подменяешь предмет сравнения. Возьмём плюсовый const, который позволяет делать «логическую константность» - ты говоришь «это не нужно, вот язык проще, где этого нет». Аналогично с растовыми лайфтаймами или хаскельным IO (или что там тебе не нравится): ты не показываешь язык, который реализует этот же механизм лучше/удобнее, ты берёшь язык где такой возможности нет и он оказывается закономерно проще.

Я что-то неправильно сказал?

Да, неправильно.

ты мне перечислил кучу штук с малой значимостью, и вот вроде как все эти плюшки вместе дают эффект.

Не считаю, что у штук вроде «удобного пакетного менеджера из коробки» или бороу чекера малая значимость, но да есть и более мелкие вещи вроде «всё выражение». И нет, не всё ты можешь решить «стилем кода». Формально, конечно, можно написать такой линтер, который позволит выделить «безопасное» подмножество языка (без UB), но это будет уже не С++.

В кресты уже вот-вот введут модули и проверки лайфтаймов

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

Насчёт проверок лайфтаймов - ты смеялся когда я говорил, что в Go скоро дженерики завезут, но готов спорить, что в С++ эту проверку добавят совсем не скоро, ну или в каком-то примитивном виде. Поживём, увидим.

Я лиспохейтер, если ты еще не заметил.

Не заметить было сложно. Хотя мне казалось, что ты больше макросо и ДСЛ хейтер, чем лиспо-хейтер.

лисперов не берут писать на кложе.

Насчёт этого ничего не знаю, но у меня сложилось впечатление, что «тру (комон) лисперы» и сами кложу презирают.

Гугл именно с этой целью Go и создавал — сделать замену одновременно для C++, Java, и питона. Это три основных языка гугла. Они взяли лучшее из каждого языка.

Не согласен ни с чем, ну кроме разве что «трёх основных языков». (:

В топе JS, SQL, TypeScript, Python, Node.js, Bash, PHP. Из статических в топ 10 C# и Java, хотя в случае C# это уже спорно

Нода - не язык, если выкинуть её и прочее вспомогательное, то список получается уже другим: JavaScript, Python, TypeScript, Java, C#, PHP, C++, С, Go и Kotlin. Статика всё-таки в большинстве, пусть и не на первых местах. TypeScript я бы причислял к статически типизированным языкам. По крайней мере, это именно попытка прикрутить типы к JS. Твою аргументацию про C# видел, но не согласен.

Ну и в целом я далёк от веба, так что могу быть не объективен. Даже если большинство кода пишется на JS, то меня это всё равно к счастью слабо затрагивает.

конструктора ничего и не нужно — присваивание тоже можно представить через конструктор.

Гы гы.

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

Не вижу смысла дальше обсуждать субъективщину.

Я там раскрывал что для «разработчиков компилятора» было в приоритете.

А вот, что говорят другие пользователи Rust (https://blog.rust-lang.org/2020/04/17/Rust-survey-2019.html). На основе их мнения и строятся планы по дальнейшему совершенствованию ЯП. Как видим, в 2019 года скорость компиляции была на 4-м по важности месте. В следующем опросе (за 2020 год) 50% пользователей отметили, что скорость возросла, следовательно, можно сделать вывод, что приоритет этой фичи, вероятно, уменьшился.

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

Redox, Servo. Amazon вон недавно виртуалки на Rust выкатила (https://github.com/firecracker-microvm/firecracker/releases/tag/v1.0.0). Либ уже и так довольно много, разрозненных и сторонних. Для этого достаточно зайти на crates.io и убедиться в этом лично.

Потому, как ни странно, Rust провоцирует увеличение числа логических ошибок из-за отвлечения внимания. Код на расте засран вспомогательными конструкциями еще сильнее, чем крестовый, потому что в крестах отдельное жонглирование было допустимо ценой UB, а в Rust по идеоматике ты должен делать три раза «ку» на каждый чих, и только так. Из-за чего либы на расте по большей части составлены из обёрток-интерфейсов (не путать с обертками к сторонним сишным либам).

Rust намного проще Плюсов. Высокоуровневых абстракций там тоже меньше. А раз так, то и вспомогательных конструкций меньше, чем в Плюсах. Раст заставляет программиста быть более осознанным, когда речь идёт о работе с памятью. Это правда. Но и ошибок соответствующих трудноуловимых в итоге получается куда как меньше, чем в C, C++.

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

Не выдаст в силу врождённых дефектов Плюсов. Ссылки ниже. И нет, человек (даже самый аккуратный и усидчивый) не может гарантировать 100%-ю концентрацию внимания.

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

Ты или крестик сними, или трусы надень. Хочешь быстрый код на компилируемом языке без GC - будь добр, напрягайся чуть больше, чем ты привык с Python или JS. История развития ЯП показывает, что языки идут в сторону большей строгости и большего контроля со стороны инструментальных средств. Да, появились динамические языки, где эти ограничения сняты. Но писать по-настоящему крупные проекты на таких языках - то ещё упражнение в эквилибристике. Об этом уже было обсуждение в теме про Питон. Те фирмы, которые начинали на Питоне, в итоге с него уходили в более строгие языки.

кресты и раст — это чудовищно переусложненные языки

Плюсы - да (из-за багажа обратной совместимости), Rust - нет, осваивается за полгода-год.

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

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

настоящее качество ЯП определяется простотой языка

Пока компьютеры не научились досконально понимать человеческую речь. Но подвижки есть. https://www.opennet.ru/opennews/art.shtml?num=56627

Ну и вот ещё немного про C++ vs Rust:

https://www.opennet.ru/openforum/vsluhforumID3/126618.html?n=Ordu#47

https://www.thecodedmessage.com/posts/cpp-move/

https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

Можно проще: сначала увеличивать счётчик, потом уменьшать

Ужасно то, что абстракции текут, и с усложнением кода прогрессивно усложняет его поддержка. Прямо как в Си.

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

Вообще-то, речь шла про константность, про то, что в крестах структуры данных довольно быстро кусают себя за хвост, вызывая присвоение с одним и тем же объектом по обе стороны знака тождества. Это самый простой пример, но примеров есть больше. Самые сложные баги в моей карьере как раз были вызваны рекурсиями вызовов, когда функция вызывая вторую функцию выбивает у себя стул из-под ног. И вот я сидел собирал в текстовом редакторе пирамиды вызовов, чтобы увидеть, что кому и как мешает.

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

Деструктор.

И с чем он дублируется?

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

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

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

Отчасти по этому пути пошли в расте: там перемещение «просто работает», ничего определять не надо. В итоге не требуются всякие «костыли» вроде std::move и std::forward и куча нюансов просто исчезает. Вот только на С++ уже написан код, где перемещение не сводится к побитовому копированию и портировать такой код на раст в лоб не получится

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

По моему, мазохизм - это как раз пустые объекты. С ужасом вспоминаю времена когда делать «двухэтапную инициализацию» не считалось чем-то плохим: все эти init и is_init. Лучше уж optional<T>, которого в те времена не было «из коробки», но теперь-то есть

ADT — это больше, чем просто «инициализировано-неинициализировано». И да, очень жаль, что их не было в крестах из коробки, только недавно начали завозить Optional/Variant/Any. Вот что реально рак — так это пытаться реализовывать Optional на голом крестовом объекте, и потом сидеть с неинициализированным объектом, мол «ничего страшного, всё под контролем, я за всем услежу, тут несложно».

а не удобного инструмента для обозначения логической константности.

Исправил для тебя

Ну я как бы уже отвечал, что «удобен» он не более, чем комментарии в коде — корректность логики все равно придется вручную верифицировать.

А вот, что говорят другие пользователи Rust (https://blog.rust-lang.org/2020/04/17/Rust-survey-2019.html). На основе их мнения и строятся планы по дальнейшему совершенствованию ЯП. Как видим, в 2019 года скорость компиляции была на 4-м по важности месте. В следующем опросе (за 2020 год) 50% пользователей отметили, что скорость возросла, следовательно, можно сделать вывод, что приоритет этой фичи, вероятно, уменьшился

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

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

Так можно сказать о любых высокоуровневых абстракциях, а также о таких базовых вещах, как алгоритмы и структуры данных

Можно. Разница в количестве.

Пока компьютеры не научились досконально понимать человеческую речь. Но подвижки есть. https://www.opennet.ru/opennews/art.shtml?num=56627

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

Не выдаст в силу врождённых дефектов Плюсов. Ссылки ниже. И нет, человек (даже самый аккуратный и усидчивый) не может гарантировать 100%-ю концентрацию внимания
https://alexgaynor.net/2019/apr/21/modern-c -wont-save-us/

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

Это достаточно технично?

Это уже не слишком объективно. Вот смотри: ты говоришь «по сравнению с грамотно спроектированными», но на самом деле подменяешь предмет сравнения. Возьмём плюсовый const, который позволяет делать «логическую константность» - ты говоришь «это не нужно, вот язык проще, где этого нет»

Ты натаскал тезисы из разных веток обсуждения, но собранного тобой тезиса-франкенштейна я никогда не высказывал. Const — это просто бесполезный мусор, это не чрезмерная переусложненность языка. Но в крестах есть куча других фич, которые являются чрезмерно переусложеннностью и плохой эргономикой. Поверх всего этого есть популярные патологичные способы применения этой плохой эргономики, которые в свое время меня ужаснули и отпугнули от крестов. Это сейчас мой анус закалился в бою и я готов к очередному раунду.

«удобного пакетного менеджера из коробки» или бороу чекера малая значимость

Я тебе отвечал, что «удобный» он ровно пока язык малопопулярен. Вот у ноды есть один удобный пакетный менеджер — посмотри, в какой трэшак это вылилось. То же самое будет с растом. Может быть, если он станет таким же популярным, как node.js.

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

Формально, конечно, можно написать такой линтер, который позволит выделить «безопасное» подмножество языка (без UB), но это будет уже не С++

C++ — это настолько зонтичный термин, что непонятно, где он начинается и заканчивается.

Насчёт проверок лайфтаймов - ты смеялся когда я говорил, что в Go скоро дженерики завезут, но готов спорить, что в С++ эту проверку добавят совсем не скоро, ну или в каком-то примитивном виде. Поживём, увидим

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

Гугл именно с этой целью Go и создавал — сделать замену одновременно для C++, Java, и питона. Это три основных языка гугла. Они взяли лучшее из каждого языка.

Не согласен ни с чем, ну кроме разве что «трёх основных языков»

Давай свою версию. Есть люди, которые вполне серьезно говорят, что Go — это реализация гуглового стиля кода C++. Это некорректно, конечно же, корректнее было бы сказать «Go — переосмысление гуглового стиля кода C++». То есть, это уже совсем не C++, но многие идеи позаимствовал.

Дальше всего Go от питона. От питоновости в Go есть только возможность поручить кодописание полному дауну.

При этом к жаве Go ближе всего: и по применению VM-GC, и по оптимизациям локальных данных, которые также есть в JVM.

Нода - не язык

До недавних пор это был самостоятельный язык с кучей несовместимостей с браузерным JS. С ES2015 пошла работа по сокращению дистанции, но она до сих пор ненулевая.

список получается уже другим: JavaScript, Python, TypeScript, Java, C#, PHP, C++, С, Go и Kotlin. Статика всё-таки в большинстве, пусть и не на первых местах

Пф-ф-ф, если так судить — там в хвосте плетется бесчисленные количество никому не нужных языков. Давай в них считать, сколько статики/динамики?

Я это говорил безо всяких опросов.

Мы же приоритеты обсуждали, да? У тебя тормознутость компилятора - чуть ли не самый главный недостаток Rust. Но это не так для большинства остальных людей. А вообще - да, многие считают необычные для других ЯП свойства Rust (заимствования, перемещения, время жизни) сложными. Дело привычки и практики, по большому счёту. Посади человека с C (Паскаль, Питона, JS) на Плюсы, он, скорей всего, тоже охренеет от сложности последних, и вероятней всего намного сильнее, чем от Rust.

Можно. Разница в количестве.

Между чем и чем разница? Хочешь сказать, что абсолютно все фичи Rust тебя отвлекают от работы над логикой приложения?

Херотень. Эти системы часто выдают такую дичь,

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

но в этой статье 100% претензий связаны с явно записанной ручной работой с памятью

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

Я тебе отвечал, что «удобный» он ровно пока язык малопопулярен. Вот у ноды есть один удобный пакетный менеджер — посмотри, в какой трэшак это вылилось.

В какой?

Правда, индустрия не спешит делать Rust мейнстримом

Ну так «наработок» на C, C++ дофига. В один момент не избавишься от них. Да и к Rust были претензии у того же Торвальдса (может уже порешали, не следил).

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

Что удобнее: не иметь рук, не иметь ног, или не иметь глаз? Это к слову о приоритетах.

многие считают необычные для других ЯП свойства Rust (заимствования, перемещения, время жизни) сложными

Перемещения и фактическое время жизни точно так же есть в крестах, используя string_view на тухлую строку можно сделать жизнь очень веселой. Совсем другой вопрос — сколько приседаний компилятор требует выполнить для того, чтобы код собрался. Точно такая же беда есть у Ады, некоторые адвокаты Ады прямо так и говорят «компилятор вынесет тебе мозг до тех пор, пока ты сам не поймешь свой код». Но Ariane V все равно упала, потому что сбойнула логика, которую компилятор проверять не умеет.

Между чем и чем разница? Хочешь сказать, что абсолютно все фичи Rust тебя отвлекают от работы над логикой приложения?

Не все. Меня отвлекают только трехэтажные ёлки типов и необходимость делать в каждой функции три раза «ку» для того, чтобы ублажить borrow checker, а также использовать готовые однострочные обертки реализаци готовых контейнеров-ублажателей borrow checker-а.

Посади человека с C (Паскаль, Питона, JS) на Плюсы, он, скорей всего, тоже охренеет от сложности последних, и вероятней всего намного сильнее, чем от Rust

А я когда-то с этим спорил? Одни только крестовые списки инициализации достойны премии Тьюринга.

Я сказал, подвижки есть. Другими словами, проблема сложности программирования (а также дороговизны программистов, их нехватка) волнует не только тебя

Волнуют? По-моему всем похер, как в советском союзе на Маркса и Энгельса, только на партсобраниях все обязательно упоминают оных — потому что здесь так заведено. Индустрия так и продолжает гонять кал из пустого в порожнее, создавая работу там, где ее не должно было быть. Эта тенденция оказалась настолько запущенной, что наконец возникла реальная возможность заменить машиной труд копипастера со stackoverflow. Но это совсем не значит, что stackoverflow является таким кладезем мудрости землян.

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

Если рассуждать в таком ключе, то автор подменяется понятия умныхуказателей на безопасную работы с памятью в целом и использование готовых контейнеров. Хотя на самом деле нет, потому что автор все-таки лишь вскользь упоминает умные указатели, и претензия «я получаю сегфолт при доступе к nullptr» не особо серьезна — в Java есть точно такая же проблема. Про сомнительность крестовых библиотек STL/Boost я уже упоминал в этом треде.

Я тебе отвечал, что «удобный» он ровно пока язык малопопулярен. Вот у ноды есть один удобный пакетный менеджер — посмотри, в какой трэшак это вылилось.

В какой?

https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tin...

Да и к Rust были претензии у того же Торвальдса (может уже порешали, не следил)

Если даже у Торвальдса есть претензии к Расту, то у меня тем более они имеются.

Что удобнее: не иметь рук, не иметь ног, или не иметь глаз? Это к слову о приоритетах.

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

Перемещения и фактическое время жизни точно так же есть в крестах

Только работает через одно место. Смотри статьи.

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

Ещё раз. К этим приседаниями надо просто привыкнуть. Так же, как надо привыкнуть к двум десяткам способов инициализации объектов в Плюсах, или L-Value, R-value выражениям в Си. Там ты уже свыкся с этим всем. А здесь для тебя всё в новинку: непонятно как-то всё. Непонимание рождает страх и ненависть в итоге.

Меня отвлекают только трехэтажные ёлки типов и необходимость делать в каждой функции три раза «ку» для того, чтобы ублажить borrow checker

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

А я когда-то с этим спорил?

Ты с этим спорил (косвенным образом), когда я предложил тебе с Rust познакомиться. Насколько я понял, с Плюсами ты смирился, но Rust, типа, намного хуже (глядя на твои прежние высказывания). Оказывается, нет, не хуже, а во многих аспектах лучше, начиная от правильного поведения по умолчанию, и заканчивая стандартной средой разработки с довольно таки развитой функциональностью.

Волнуют?

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

Если рассуждать в таком ключе, то автор подменяется понятия умных указателей на безопасную работы с памятью в целом и использование готовых контейнеров. Хотя на самом деле нет, потому что автор все-таки лишь вскользь упоминает умные указатели, и претензия «я получаю сегфолт при доступе к nullptr» не особо серьезна — в Java есть точно такая же проблема.

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

В какой?

https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tin…

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

Если даже у Торвальдса есть претензии к Расту, то у меня тем более они имеются.

Ты безусловно круче Торвальдса (нет). Но ок. :)

Ладно. Чего это я, собственно. Удачи тебе в выборе языка по твоим запросам. Ищущий да обрящет.

Что удобнее: не иметь рук, не иметь ног, или не иметь глаз? Это к слову о приоритетах

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

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

Только работает через одно место. Смотри статьи

Я тебе уже ответил. То, что описывается в статьях — это аналог растового unsafe. Но ты почему-то не говоришь «unsafe в расте работает через одно место».

Так же, как надо привыкнуть к двум десяткам способов инициализации объектов в Плюсах

Неужели ты перечитал весь тред?

Так же, как надо привыкнуть к двум десяткам способов инициализации объектов в Плюсах, или L-Value, R-value выражениям в Си. Там ты уже свыкся с этим всем.

В паскале l-value настолько очевидно, что такого понятия даже не применяют. В Си понадобилось тонкое разделение потому, что K&R реализовали массивы через жопу, из-за чего массив не мог быть l-value. Страуструп засунул это дело ещё глубже, это бесспорно, теперь результату функции можно присовить значение. И нет, я ни разу не привык к этому делу, я считаю реализацию перегрузки операторов в крестах абсолютным злом — нужно было полностью запрещать присвоение результату-объекту и заставлять использовать промежуточную переменную. К сожалению, как я недавно узнал, однострочники на Сишке в те вермена считались писокм моды, ну там присвоить значение переменной в while, а написать for на три строки вообще считалось верхом мастерства.

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

Да, если писать функции на 1-2-3 строчки, то, действительно, бороться нужно не в каждой функции. Правда, в таком случае воевать ты будешь с более серьезным и нечитаемым врагом.

Насколько я понял, с Плюсами ты смирился, но Rust, типа, намного хуже

Неа, неправильно понял. Rust такой же. И с плюсами я смирился именно на уровне «выкинуть 70% фич, 90% бустов и половину STL — получается норм язык».

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

Волнуют одного-двух-трех людей. Остальным глубоко все равно.

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

ну давай я скажу, что в Rust есть unsafe, а значит нет никаких гарантий безопасности памяти... А, собственно, уже давно сказал. Абсолютная безопасность работы с памятью — это миф, есть только уровни защиты и простота отладки ошибок.

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

Это не одиночный случай. Когда я говнокодил SPA на JS, то у меня регулярно возникали сеансы казино с версиями пакетов.

Если даже у Торвальдса есть претензии к Расту, то у меня тем более они имеются.

Ты безусловно круче Торвальдса (нет). Но ок

Я копнул глубже в эту историю с Торвальдсом. Оказывается, у него было два опыта работы с крестами: начало девяностых, когда кресты были на пике своей ублюдочности без стандартов, портируемости, и с абсолютно невменяемой стандартной либой, ; и разработка замены BitKeeper, Monotone, которой занимались обдолбанные до невменяемости адепты ООП, которые выдали неюзабельную лапшу — именно подобное впечатление несколькими годами позже у меня возникло при первом знакомстве с крестами, и именно оно меня ужаснуло, потому что я увидел, что писать работающий софт на «этом» нельзя, Си в этом плане как минимум не хуже (хотя и не лучше). И, точно как Торвальдс, я не смог увидеть за этим трешаком реально полезные фичи.

Оглядываясь назад, объективно основная претензия заключается именно в классах крестов, которые склоняют к монолитно спутанному комку кода и данных. То есть, сегодня ты ввел умные строки в ядро, а завтра у тебя все структуры данных внезапно наследуются от QObject. Потому что. Эта сложность организации интерфейсов с другими языками по прежнему не решена в крестах, между прочим. Сишка же позволяет скармливать функциям огрызок данных любого происхождения — это и есть то, что я называю «функции отвязаны от данных». Спутанность данных и кода было фичей, за которую индустрия купила C++, и эта же фича сделала разработку на крестах кошмаром с абсолютно негибкими монолитами, которые нельзя дернуть из другого языка.

Вообще-то, речь шла про константность,

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

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

Ну так и Trolltech продались и до сих пор у них в плане монетизации дела не прям шикарно идут. А Sun разорились далеко не только из-за джавы, ну и сама джава себя сейчас отлично чувствует. Даже несмотря на «модные и хайповые» языки поверх JVM.

Вот. Как я уже писал — стиль кода решает многое.

И в очередной раз я не согласен с выводом. (:

Во первых, «хитрые» конструкторы перемещения делают не из-за того, что в «плюсах так принято». Я бы даже сказал, что это редкость. В «клее между библиотеками» так вообще этого делать не нужно. Делают так чтобы выжать производительность, но если на С++ и писать, то ради этой самой производительности, иначе какой смысл? Во вторых, даже если ты выкинешь std (и остальные библиотеки заодно) и решишь не пользоваться этой «наркоманией» с встроенным перемещением, то красиво «битовое перемещение» всё равно не сделаешь.

Ну я как бы уже отвечал, что «удобен» он не более, чем комментарии в коде

Так ведь это неправда. Как минимум, некоторые проверки компилятор будет делать - это уже больше, чем «просто комментарии».

Если внимательно проанализировать этот опрос, то по сути на первом месте «язык слишком сложный», после чего идет «компилятор слишком медленный».

Если «нужна более качественная документация» ещё как-то можно натянуть на «язык слишком сложный» (хотя многие люди хотят именно формальную спеку, что попадает в эту же категорию), то «больше библиотек», «поддержка IDE», «нет GUI», «стабилизация» и т.д. - это уже совсем мимо. Сдаётся мне ты опять выдаёшь желаемое за действительное.

Const — это просто бесполезный мусор

А я говорю, что это удобный и полезный инструмент.

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

Ну есть, да. Вот только говорил ты о другом: мол есть языки (целиком) лучше (проще) спроектированные. И даже это, пожалуй, правда. Вся загвоздка заключается в том могут ли эти языки вытеснить С++.

Я тебе отвечал, что «удобный» он ровно пока язык малопопулярен. Вот у ноды есть один удобный пакетный менеджер — посмотри, в какой трэшак это вылилось.

Ну расскажи что ли. Надеюсь это будет что-то поинтереснее истерики с leftpad. Если что, эта проблема возникла, в первую очередь, из-за того, что NPM разрешал удалять пакеты. В расте это изначально нельзя было (только помечать как «нежелательный»), сейчас и в NPM просто так удалить пакет нельзя.

Или же это будет просто плачь про «много зависимостей»? Тоже такое себе. В С++ принята другая крайность: из-за того, что подключить зависимость - это (как правило) целое приключение, то появляются здоровенные комбайны - тот же буст или abseil. Не сказал бы, что это лучше.

И да, borrow checker не такой уж волшебный

А такого я и не говорил, не подменяй тему. Ну и назвать это «мелочью» вижу даже у тебя язык не поворачивается. (:

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

Вот опять ты сравниваешь разные вещи. То чего нет, против того, что есть (но «мало»). Так-то и С++ далеко не доминирующее положение занимает. Когда я примерно четыре года назад согласился на растовый офер, то действительно непонятно, что было бы дальше с языком и какие перспективы. Сейчас же, даже если его начнут закапывать, то моментально он не умрёт - будет время неспешно переключиться на что-то другое.

Давай свою версию.

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

До недавних пор это был самостоятельный язык с кучей несовместимостей с браузерным JS.

Тут я могу ошибаться - нет компетенции, но сдаётся всё-таки, что это всё равно не язык. Платформа - да, но не язык. Это примерно как говорить, что «между С++ и «виндовс С++» огромная разница», подразумевает под последним язык плюс использование платформенных апи. Правда то, что JS был (?) языком одной платформы немного усложняет ситуацию, но всё-таки.

Пф-ф-ф, если так судить — там в хвосте плетется бесчисленные количество никому не нужных языков. Давай в них считать, сколько статики/динамики?

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

Вообще-то, речь шла про константность,

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

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

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

Как я уже писал — стиль кода решает многое.

И в очередной раз я не согласен с выводом

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

Я бы даже сказал, что это редкость. В «клее между библиотеками» так вообще этого делать не нужно. Делают так чтобы выжать производительность, но если на С++ и писать, то ради этой самой производительности, иначе какой смысл?

Да, в клее это не нужно, да, ради производительности по большей части, но не всегда. Бывают объекты, которые нельзя копировать и присваивать. По сути, тот же Rust построен на фундаменте из именно таких объектов — это, на самом деле, самые приятные в работе объекты, поскольку они не будут неявно выделять непонятное число ресурсов и у тебя в распоряжении всегда предсказуемо единственный экземпляр объекта. Объектом же может быть сокет, файл, разделяемая память, мьютекс — что-то, что даже в питоне стоило бы значительного числа циклов процессора. Почему-то в Си проблемы с копированием нет, а в крестах — есть. Потому что ветхозаветные кресты построены на сплошном копировании, даже если тебе нужно простое RAII, вроде «уменьшить счетчик ссылок» или «освободить блокировку» — попробуй угадай, сколько раз на самом деле в сложной функции эти операции делаются. Нужно вызвать функцию с прикрепленными данными? Создавай и копируй функторы.

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

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

Так ведь это неправда. Как минимум, некоторые проверки компилятор будет делать - это уже больше, чем «просто комментарии»

Я не могу однозначно согласиться с тобой, ровно как и не согласиться. Я бы остановился на «фиче с ограниченной и спорной полезностью». Вполне возможно, что в каком-то коде const станет благословлением, но в другом — проклятием и вводить в заблуждение на каждом шагу.

Давай я отвечу по каждому пункту, если мой тезис был неясен:

Better training/Documentation — самоочевидно

More/Better Libraries — самый спорный пункт, согласен. Недостающее звено — сложность написания этих самых библиотек. Люди вроде как хотя либы с «безопасными» интерфейсами, а эти безопасные интерфейсы кошмарно долго и нудно писать, потому что именно в этом месте Rust поворачивается к разработчику ровно жопой, заставляя ковыряться в самых небезопасных конструкциях, и при этом штукатурить безопасный API для программиста-пользователя.

IDE integration — здесь просто: хорошему языку IDE не нужен. Это не очевидно? Да, к слову о жаве: люди пишут уже не на жаве, они пишут на IDE. У меня самого часто при просмотре жавового кода возникает мысль «это машиногенерированный код?». В общем-то, можно смело утвердительно отвечать на этот вопрос, потому что, действительно, он был генерирован полуавтоматически, и так же читается с применением автоматических анализаторов.

Дальше идет «Compilation time», и следующие за ним пункты набрали сильно меньше голосов.

Вся загвоздка заключается в том могут ли эти языки вытеснить С++

Ты как бы между строк говоришь «могут ли они оказаться лучше крестов?» — очевидно, да, и очень легко. И рядом между строк как бы намекаешь на маркетинговую составляющую, которая совершенно иррациональна и имеет прискорбно мало отношения к удобству кодописания на ЯП (хотя бы потому, что решение всё равно будут принимать манагеры, которые в подавляющем большинстве ничего не пониманиют в кодинге).

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

В NPM точно также невозможно удалить пакет — можно только завандалить уже существующий. Что и сделал автор leftpad. Вплоть до того, что, грубо говоря, засунуть туда майнер.

В С++ принята другая крайность: из-за того, что подключить зависимость - это (как правило) целое приключение, то появляются здоровенные комбайны - тот же буст или abseil. Не сказал бы, что это лучше

Модули и системы сборки в C/C++ абсолютно никуда не годится — тут даже не буду пытаться спорить. Но это не та штука, которая переворачивает разработку верх ногами, особенно сегодня, когда в дистрах есть пакетные менеджеры, когда уже есть и пакетные менеджеры специально для крестов. Просто представь на секунду, что тебе нужно разрабатывать на Rust БЕЗ ИНТЕРНЕТА. Это я как бы о том, почему в Си не было пакетного менеджера. Пакетный менеджер — это прежде всего хороший репозиторий, без репы он становится тыквой. Да, приятно, когда вместо включения копии вспомогательный либы ты просто ставишь ссылку на пакет в репозитории — но оба подхода имеют право жить. А если в репе зависимости поломаны — то ты сам же побежишь копировать вспомогательную либу в состав своей.

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

«Попытались взять лучшее из каждого языка» — так сойдет?

Ну и Go полностью убить их всё равно не сможет

Пф-ф-ф, кобол и фортран живы до сих пор, хотя языки максимально мерзопакостные и вырвиглазные. IT — это очень инертная отрасль, в ней убить что-то, что существует дсотаточно большое время, нереально. Блин, у нас вот в одном банке до сих пор терминалы оператора на MS DOS работают, а ты говоришь «убить».

До недавних пор это был самостоятельный язык с кучей несовместимостей с браузерным JS.

Тут я могу ошибаться - нет компетенции, но сдаётся всё-таки, что это всё равно не язык

JS как язык, подобно тому же питону, почти ничего из себя не представляет. Большая часть «языка» — это стандартная либа, в том числе массивы, объекты-словари, модули. И вот те же модули очень сильно разные в ноде и браузере. Глобальный неймспейс тоже разный, работа с файлами — вообще небо и земля.

Пф-ф-ф, если так судить — там в хвосте плетется бесчисленные количество никому не нужных языков. Давай в них считать, сколько статики/динамики?

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

F#, Clojure, Dart, Asm, VBA, R, COBOL — это совсем не щитимель-скриптовуха.

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

Забавно, учитывая, что я склоняюсь как раз в к противоположному: разумным ограничениям, которые предотвращают ряд ошибок. Это ты в какой-то теме топил за «свободу» против «плохих гуглов, которые насильно внедряют раст». Мол нормальным программистам оно больше мешает, чем помогает. Прикол в том, что любая такая «защита» имеет способ обхода (unsafe в расте, unsafeCoerce в хаскеле, believe_me в идрсе и т.д.). Тем не менее, оно всё равно полезно так как позволяет «минимизировать ансейфность», но если ты опустился до этого уровня, то только и остаётся, что «быть внимательным» (ну и обмазываться тестами).

Да, С++ далеко не самый удачный пример в таком контексте потому как там почти всё ансейф. Тем не менее, плюсовую константность можно отнести к подобным инструментам. А ты говоришь «а вот если сделать так, то всё поломается», что для меня звучит как «датчик для дверей лифта не нужен» (ведь его можно хакнуть или испортить).

С чем не согласен?

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

Почему-то в Си проблемы с копированием нет,

Да ладно? Вот есть у тебя хрень* ресурс. Можно её скопировать и как? Так сразу и не скажешь: может безопасно будет скопировать указатель (а делать free как раз нельзя), может надо поискать функцию copy_хрень, может ещё что. В С++ же у типа более явный контракт: есть оператор копирования - значит копировать можно. А сколько это будет стоить ты и в С не скажешь без заглядывания в код или документацию.

но в другом — проклятием и вводить в заблуждение на каждом шагу.

Ты так говоришь как будто любая другая абстракция не может обманывать. Чистая функция в хаскеле может делать unsafePerformIO, невинный код на джаве может сегфолтиться и течь благодаря JNI и т.д. С++ язык более опасный - это да, но принципиально такие же проблемы могут быть везде.

Недостающее звено — сложность написания этих самых библиотек.

Это уже притягивание за уши.

Написать что-то объёмное даже не столько сложно, а «долго» (дорого). На одном энтузиазме тут не уедешь, нужен коммерческий интерес. Впрочем, я бы не сказал, что у раста всё плохо с библиотеками. Скорее даже наоборот.

IDE integration — здесь просто: хорошему языку IDE не нужен. Это не очевидно?

Нет. Простому (примитивному) языку IDE не нужно. Хотя с таким языком больше желания прибегнуть к (внешней) кодогенерации и с джавой именно это и происходит.

Ты как бы между строк говоришь «могут ли они оказаться лучше крестов?»

Как раз нет. Оказаться лучше не так сложно, куда сложнее быть «настолько лучше, чтобы мотивировать переход», ещё сложнее (в случае С++) «быть лучше и позволять бесшовное взаимодействие».

И тут дело не только в маркетинге. Возьмём одного из первых (а может и первого) «убийц С++» - D. Мало каким плюсовикам нужна сборка мусора, а джавистам D тоже оказался не нужен. Да и в целом «продать язык» даже программистам сейчас совсем не простая задача. На нечто нестабильное, без учебных материалов и библиотек не хочется и смотреть. Помнится когда я заинтересовался D, то книга по нему была платной.

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

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

В NPM точно также невозможно удалить пакет — можно только завандалить уже существующий. Что и сделал автор leftpad.

Это неправда, на тот момент пакет именно можно было удалить, в этом и проблема.

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

Просто представь на секунду, что тебе нужно разрабатывать на Rust БЕЗ ИНТЕРНЕТА

Без интернета мне будет тяжело и без необходимости разрабатывать на чём-либо. (:

А вообще на текущем проекте зависимости сложены локально и сборка проходит с флагом --offline, но это всё равно совсем не одно и то же, что «положить рядом С++ библиотеку». Во первых, сбор зависимостей происходит, пусть и контролируемо, но при помощи cargo vendor, а не «руками». Во вторых, плюсовую библиотеку мало положить рядом, надо её подружить со сборкой твоего проекта и там может быть не Cmake, а в расте, опять же, всё «просто работает».

Пф-ф-ф, кобол и фортран живы до сих пор

Как по мне, это не жизнь. На делфи вон тоже пишут, но я бы это записывал в зомби. Но вообще речь не об этом: на коболе пишут потому что легаси - переписать дороже будет. А (весь) С++ на Go так просто не заменишь.

F#, Clojure, Dart, Asm, VBA, R, COBOL — это совсем не щитимель-скриптовуха.

Нет, конечно. Но я не понял по какому принципу ты языки выбрал. Даже в перечисленном динамика не прям преобладает. Но можем пройтись и по всему списку:

• JavaScript - динамика (1)
• HTML/CSS - пропускаем
• Python - динамика (2)
• SQL - пропускаем
• Java - статика (1)
• Node.js - пропускаем
• TypeScript - статика (2)
• C# - статика (3)
• Bash/Shell - пропускаем
• C++ - статика (4)
• PHP - динамика (3)
• C - статика (5)
• PowerShell - пропускаем
• Go - статика (6)
• Kotlin - статика (7)
• Rust - статика (8)
• Ruby - динамика (4)
• Dart - спорно
• Assembly
• Swift - статика (9)
• R - динамика (5)
• VBA - динамика (6)
• Matlab - динамика (7)
• Groovy - динамика (8)
• Objective-C - статика (10)
• Scala - статика (11)
• Perl - динамика (9)
• Haskell - статика (12)
• Delphi - статика (13)
• Clojure - динамика (10)
• Elixir - динамика (11)
• LISP - динамика (12)
• Julia - динамика (13)
• F# - статика (14)
• Erlang - динамика (14)
• APL - динамика (15)
• Crystal - статика (15)
• COBOL - статика (16)

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

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

Странно, что от СПЛОШНЫХ блокирующих работу недостатков Си и Плюсов ты предпочитаешь отмахиваться.

Я тебе уже ответил. То, что описывается в статьях — это аналог растового unsafe. Но ты почему-то не говоришь «unsafe в расте работает через одно место».

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

Да, если писать функции на 1-2-3 строчки, то, действительно, бороться нужно не в каждой функции. Правда, в таком случае воевать ты будешь с более серьезным и нечитаемым врагом.

Чем меньше код функции, процедуры, класса (в разумных пределах, обусловленных необходимым минимумом обеспечиваемой функциональности), тем легче сопровождать и модифицировать код. Поэтому в этом контексте мне не совсем понятно, что ты имел ввиду, говоря о «нечитаемом враге».

Неа, неправильно понял. Rust такой же. И с плюсами я смирился именно на уровне «выкинуть 70% фич, 90% бустов и половину STL — получается норм язык».

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

Волнуют одного-двух-трех людей. Остальным глубоко все равно.

Да ладно. Целые комитеты создаются. Куча бабла вбухивается в R&D.

ну давай я скажу, что в Rust есть unsafe, а значит нет никаких гарантий безопасности памяти… А, собственно, уже давно сказал. Абсолютная безопасность работы с памятью — это миф, есть только уровни защиты и простота отладки ошибок.

В Rust ты сразу знаешь, где у тебя могут быть потенциальные проблемы, потому что такой код помечен ключевым словом - искать проблемы, следовательно, проще. Unsafe, ко всему прочему, нужен далеко не всегда, это исключение из правил, он НЕ рекомендуется к использованию (хотя есть случаи, где без него не обойтись, увы - например, циклические графы). В Си, Плюсах - это неизлечимая болезнь, поражающая весь твой код.

Это не одиночный случай. Когда я говнокодил SPA на JS, то у меня регулярно возникали сеансы казино с версиями пакетов.

С компилированными библиотеками такого не бывает, они всегда сразу совместимы со всеми зависимостями?

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

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

По мере моего погружения в распределенные и многозадачные системы я укрепился в понимании того, чтобы абстракция «дернем подпрограмму, и не важно что в подпрограме» не работает. Например, одна из ключевых задач проектирования lock-free алгоритмов — это доказательство сходимости решения, то есть, доказать, что рано или поздно беспорядочно шатающиеся в циклах compare-and-swap потоки выполнения придут к необходимой цели. Классическая рекуррентная Тьюринг-машина имеет бесконечную сложность исполнения алгоритма, потому сходимость алгоритма на ее основе бесконечно сложно проверить — что-то схожее с задачей остановки.

Потому в идеале для снижения комбинаторной сложности одновременное выполнение из асинхронной модели (не важно сколько — важно что выполняется) должна перейти к синхронной (не важно что выполняем — важно сколько выполняем), вместо бардака, который программист отчаянно разгребает синхронизацией, должна встать изначально скоординированная система. КИ тогда какая-нибудь критическая секция lock-free алгоритма должна иметь свойства вроде «выполняется ровно 20 циклов, ни циклом меньше, ни циклом больше» — и тогда уже на базе этого знания возможна координация плана «вот эта критическая секция мешает мне и будет мешать еще 10 циклов». Это ограничение? Ограничение. Но реализовывать его на традиционных процессорах никак не получится.

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

Высокопроизводительные вычисления на традиционных центральных процессорах небезопасны. Точка. Да, язык может быть говном и привносить собственное UB на ровном месте, но ты никогда в жизни до конца не сможешь обезопасить процессор. Даже с жавой, даже с эрлангом — последний просто прибегает к перезапуску отказавшего сервиса, а жава дедлочится или умирает при ошибке алгоритма. Это всё, что можно сделать.

Авторы Rust перешагнули эту рациональную черту под названием «не усугублять проблему плохой архитектурой языка», и двинулись достигать несовместимых свойств — производительности и надежности сложных систем. Поскольку с технической стороны они одновременно недостижимы, то авторы раста прибегли к политическому инструменту «бить линейкой по пальцам». Не «за то, что код посчитал код небезопасным», а «потому что описание интерфейса либы предписывает бить по рукам за подобный код». То есть, как ты любишь — давайте программно интерпретировать комменты. Причем, я не вижу в языке фич для упрощения написания unsafe кода — ты резко вываливаешься на уровень Си, и механизмы работы с указателями в расте не особо поменялись за 40 лет. То есть, получается снова два языка в одном, как было в C/C++.

Но авторы Rust забыли, что одно из ключевых свойств ЯП — это ПРОСТОТА. Потому что простая программа проще в понимании, проще в изменении. Если выполнение программы очевидно из кода, то не нужны комментарии. У авторов Rust слепое пятно в этой области, а также в области скорости компиляции — для них все языки могут быть только очень сложными и только компилироваться часами.

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

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

Я хочу здесь четко разделить, что есть крестовое UB, которое абсолютно зло и которое было выкинуто из языка, и есть новые инструменты для проведения дополнительных проверок корректности кода — то есть, быть умнее программиста. Некоторые говорят «проверка лайфтаймов устраняет UB» — нет, прежде всего проблему лайфтаймов нужно принести в программу хитрыми оптимизациями очередного холодного участка кода. Есть UB, которое прям само лезет в код — его нужно убирать.

Отсюда мы получаем понимание того, кому и зачем нужен Rust: тем, кто пишет более-менее стандартные низкоуровневые алгоритмы в стопятсотый раз, и хочет наконец начать писать их безошибочно. Это не высокий уровень абстракций, это не многозадачность, это не оригинальные базовые алгоритмы, под которые нужно писать собственные safe интерфейсы и лично проходить ад, через которых проходят создатели растовых библиотек, и из-за которого растовых библиотек так мало несмотря на всю расхайпанность и лайки языку в опросах stackoverflow. Это даже не быстрая разработка, потому что раст ни в каком месте не ускоряет разработку. Это не высокопроизводительные вычисления, потому что они возможны только на GPGPU, FPGA, и ASIC.

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

Да, еще хочу исключить БД и распределенные системы. Да, алгоритмы одной ноды распределенной системы пишут на расте, и пользовательские функции на расте компилируют LLVM для безопасного выполнения внутри БД, но разработку самой БД и самих распределенных систем раст не упрощает, потому что у тебя фоном непрерывно маячит unsafe в виде основного побочного эффекта, ради которого вообще вся система создавалась, для которого ты не проверишь лайфтаймы, borrow checker тебе не поможет, и пакетный манагер не особо пригодится, потому что проблема сборки меркнет на фоне сложности разработки.

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

Не. Масштабируемо. Абстракция течет при росте сложности. Как и комментарии. Я отношусь положительно к комментариям в умеренных количествах. Более того, даже разрешаю тебе юзать константность, если тебе она нравится — все равно стандартная либа уже с константностью писана. Но это примерно одного уровня инструменты, автопроверка константности требует настолько много ручных проверок, что чуть меньше или чуть больше разницы не порешает.

И потому в какой-то степени то, что мы развели с тобой по поводу const — это bike-shedding, огромное обсуждение минорной фичи. Но моя претензия была именно по поводу того, что const мог бы быть значимым, мог бы быть бесконечно масштабируемым и никогда не требовать ручной проверки, то есть, если написано const, то компилятор дает 100% гарантию, что это const, а не ссылка на чёрт пойми что.

И нет, это не «датчик для дверей лифта», потому что обход const происходит на каждом шагу, как если бы все спокойно катались с открытыми дверями.

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

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

В С++ же у типа более явный контракт: есть оператор копирования - значит копировать можно

Есть проблемка. Самый элементарный способ ее увидеть — кастомный алокатор. Здесь ты внезапно выясняешь, что на самом деле копирование не может быть методом объекта — это внешняя функция, оперирующая двумя объектами, и даже более чем двумя (данными менеджера памяти). Также плавно мы переходим к вопросам копирования между переменными разных типов. И по итогу copy_хрень является единственным адекватным решением. Другое дело, что строгость и гибкости типизации этой функции можно было бы сделать намного лучше, чем в Си, и те же кресты чутка приблизились к реализации данной цели. Например, банально запретить делать free по black-box указателю.

Неявные операции крестов — это зло, которое очень многие люди ненавидят. Особенно железячники, которые с удивлением обнаруживают эти неявные операции там, где их не ожидали. Или ожидают копирование, а вместо этого компилятор решил сделать copy elision. При том, что, в общем-то, копирование объекта редко нужно — перемещение и эквивалентная передача по ссылке для объектов сложнее чем «пару целых чисел» более актуально. Именно потому я пишу, что Rust в этом плане лучше крестов.

То есть, рациональное зерно в расте есть, но оно похоронено под слоем мусорных фич, которых накидали в язык «чтобы показать что-то новое публике» — в этом плане я сторонник того, что стабилизация и стандартизация ЯП должна сопровождаться выкидыванием фич из языка, а не добавлением оных, как это обычно делается. С другой стороны, если повыкидывать мусорные фичи, то останется до смешного мало нововведений по сравнению с C/C++ — это именно то, каким я вижу Rust для себя.

Простому (примитивному) языку IDE не нужно. Хотя с таким языком больше желания прибегнуть к (внешней) кодогенерации и с джавой именно это и происходит

Простой != примитивный != хороший. Как раз простые языки часто плохие и сложные. Эталонный пример — Brainfuck.

ещё сложнее (в случае С++) «быть лучше и позволять бесшовное взаимодействие»

Здесь ошибка. Оно очень даже «шовное», поскольку в крестах есть исключения. Если ты посмотришь на современные языки, особенно низкоуровневые — все они позволяют взаимодействовать с сишным кодом, не хуже крестов. Да, в них нельзя сделать extern C, но есть автоматические трансляторы, превращающие сишные объявления функций в аналогичные родные.

Истинная причина выбора крестов — маркетинг и тупые менеджеры AT&T. Будучи в нашем времени, ты никогда не поймешь этого решения, эта аргументация кажется безумной, но если бы ты был там, на собарниях, где обсуждалось принятие C++ основным ЯП, то ты бы по крайней мере задумался «а может, и правда, это хорошая идея». Аналогичная история случилась с жавой, с еще более тяжелыми последствиями. Манагеры создают пузырь безумия, в котором друг друга убеждают и формируют приоритеты, упускают жизненно важные моменты, но при этом обязательно примут решения по поводу навеса для велосипедов, применяют примитивизацию и аналогии до тех пор, пока с обсуждение не будет иметь ничего общего с исходной проблемой. Причем «консенсус» считается достигнутым, либо если это велосипедный навес, либо когда ни один участвующий не возражает, то есть, не понимает, о чём вообще идёт речь.

Я был на таких обсуждениях, и мне хотелось заорать «да вы же е$#@!аты, что вы несете!». Те же Дейкстра с Виртом примерно так и сделали на комитете Алгол 68, только вместо того, чтобы прыгнуть на стол и насрать на него, разослали по залу небольшие записки на пару абзацев со смыслом содержания «здесь происходит какая-то дичь, это никогда не взлетит, мы покидаем этот бардак».

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

Возьмём одного из первых (а может и первого) «убийц С++» - D. Мало каким плюсовикам нужна сборка мусора, а джавистам D тоже оказался не нужен

Ты сам сказал — проблема в сборке мусора. Если Брайт хотел сделать что-то похожее на Go, то ему нужно было больше низкоуровневых фич. А так язык получился запоздалым апгрейдом ветхозаветного паскаля, который еще для виртуальной машины был аля JVM.

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

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

Даже создатель Rust не может ни на что повлиять. Прикинь. Там решение принимается такими деньгами, что один разработчик ничего не значит. Конечно, если ты не Крокфорд, который может в одно рыло половину фич стандарта протягивать — и то у Крокфорда есть много оппонентов.

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

Оформляешь вандаленную версию как минорную, и большинство зависящих пакетов радостно поставят новую версию.

Во вторых, плюсовую библиотеку мало положить рядом, надо её подружить со сборкой твоего проекта и там может быть не Cmake, а в расте, опять же, всё «просто работает»

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

(весь) С++ на Go так просто не заменишь

Весь — не заменишь. Большую часть — заменишь, по крайней мере для нужд гугла. Ты вот в курсе, что большая часть реализации стандартных структур данных Go сделана на самом Go? Там есть весьма низкоуровневые фичи, сравнимые с сишкой.

TypeScript - статика (2)
Dart - спорно

Dart — спорно, а TypeScript — статика? Это схожие языки. Так или иначе — это задворки индустрии. В конце 90-х всех херачили сайты на пыхе — и толку им с твоего статичного Си или Objective-C?

Странно, что от СПЛОШНЫХ блокирующих работу недостатков Си и Плюсов ты предпочитаешь отмахиваться

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

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

Она чисто формальная. Ты намекаешь на то, что за счет явного объявления unsafe повысится безопасность и простота ревью — а я намекаю на то, что если у вас unsafe поломан, то вы сойдете с ума при поисках ошибок. И по итогу на safe-unsafe полагаться бездумно тоже нельзя, и даже в safe коде тщательно вылавливать ошибки. Это и есть то, что я называю «плохо масштабируется по уровням абстракции».

Чем меньше код функции, процедуры, класса (в разумных пределах, обусловленных необходимым минимумом обеспечиваемой функциональности), тем легче сопровождать и модифицировать код. Поэтому в этом контексте мне не совсем понятно, что ты имел ввиду, говоря о «нечитаемом враге».

Я тут в соседнем треде отвечал на «если распилить систему на сотни мелких сервисов — проще понимать»:

а нужны ли мне эти ваши docker-контейнеры? (комментарий)

Одну функцию — да, проще. Но в итоговом зачете весь код будет занимать В РАЗЫ больше строк кода, и хотя каждая функция проще, но множитель больше, и в сумме систему понимать намного сложнее.

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

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

Целые комитеты создаются

И чо? Коммитет — это самая бесполезная ячейка в айти. Какие-то вахтеры собираются, принимают часть очевидных решений, часть рандомной бредятины, и забывают про кучу ключевых моментов, будто их не существует вовсе. Каждый раз, когда заходит речь про соответствие стандартам Си, у меня возникает вопрос «что же бл$#@! в этом стандарте вообще написано? Что оно значит?, потому что в тексте стандарта написано максимально размытое абстрактное „ничто“, а в остальном спецификация языка уже была де-факто написана K&R. Потому я ни в один комитет не верю.

В Rust ты сразу знаешь, где у тебя могут быть потенциальные проблемы, потому что такой код помечен ключевым словом - искать проблемы, следовательно, проще

Но не помечен код, использующий unsafe код. И здесь заключена самая большая подстава. Причем, некоторые алгоритмы исключительно сложно сделать по-настоящему safe, а некоторые, вроде lock-free, и вовсе нереально, потому их в библиотеках нету

Unsafe, ко всему прочему, нужен далеко не всегда, это исключение из правил, он НЕ рекомендуется к использованию

Любое разыменование указателя. А что можно сделать без разыменования указателя? Сложить два целых числа?

Это не одиночный случай. Когда я говнокодил SPA на JS, то у меня регулярно возникали сеансы казино с версиями пакетов.

С компилированными библиотеками такого не бывает, они всегда сразу совместимы со всеми зависимостями?

Напоминаю контекст:

Я тебе отвечал, что «удобный» он ровно пока язык малопопулярен. Вот у ноды есть один удобный пакетный менеджер — посмотри, в какой трэшак это вылилось

Еще раз: пакетный менеджер не сильно упрощает задачу.

Бла-бла-бла раст сложный бла-бла-бла асинхронность бла-бла-бла лок-фри бла-бла-бла ПРОСТОТА бла-бла-бла unsafe.

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

Причем, я не вижу в языке фич для упрощения написания unsafe кода — ты резко вываливаешься на уровень Си

Это правда. Более того: можно подобрать примеры, где С код выглядит даже проще. К сожалению, этому аспекту уделяют мало внимания. Тем не менее, выгода всё равно есть. Хотя бы в том, что не приходится писать 100% кода на С.

То есть, получается снова два языка в одном, как было в C/C++.

Нет, не получается.

Более того, даже разрешаю тебе юзать константность, если тебе она нравится

Ну спасибо. (:

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

Не мог бы. Улучшить свойства этого инструмента, наверняка, можно. А вот если делать «бесконечно масштабируемую и не требующую ручной проверки» штуку, то получится как с бороу чекером: компилятор будет тебе «мешать» отвергая некоторые корректные программы. И тут или мы даём даём возможность сказать компилятору «вот сюда не смотри» или полезность будет не факт, что больше того, что есть сейчас.

обход const происходит на каждом шагу,

Не замечал.

«Вырезать половину фич из крестов» — это имеет большое значение на разработку, не находишь?

Нахожу.

Но всё-таки: без автоматической проверки «соглашения» сложно соблюдать, даже при всём желании. Работал как-то на проекте, где был многостраничный «стайл гайд». И даже его прочитал целиком. В целом он соответствовал здравому смыслу с несколькими местными особенностями. Вот только было всего пару человек, которые на ревью могли написать «вот тут нарушается такой-то пункт, поправь». В итоге нарушения расползались.

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

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

let r = a.checked_add(b);
<обрабатываем потенциальное переполнение>
r.checked_add(c);

вместо a + b + c.

Простой != примитивный != хороший. Как раз простые языки часто плохие и сложные. Эталонный пример — Brainfuck.

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

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

Здесь ошибка. Оно очень даже «шовное», поскольку в крестах есть исключения.

Нет здесь ошибки - именно поэтому и сложнее.

Собственно, с растом история повторяется.

Ну да, ну да…

Даже создатель Rust не может ни на что повлиять.

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

Оформляешь вандаленную версию как минорную, и большинство зависящих пакетов радостно поставят новую версию.

Всё ещё не автоматически.

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

Раст уже популярнее хаскеля, а второй системы сборки пока нет. Сколько лет ждать пока сбудется твоё пророчество?

И про хаскель ты тоже не совсем прав - там одна система сборки работает поверх другой.

Dart — спорно, а TypeScript — статика? Это схожие языки.

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

Так или иначе — это задворки индустрии.

TypeScript? Да ладно. Понятное, что на «обычном JS» дофига написано, но на TS пишут как бы не больше, чем на плюсах сейчас.

Более того: можно подобрать примеры, где С код выглядит даже проще. К сожалению, этому аспекту уделяют мало внимания. Тем не менее, выгода всё равно есть. Хотя бы в том, что не приходится писать 100% кода на С

Ты знаешь, я то же подумал. Вот я писал PSO, и периодически чувствовал, что фатает чего-то более высокоуровневого. Но! Для 90% фич сишки было вполне достаточно, а контейнера STL все равно однопоточны. И даже многопоточные либы буста настолько убоги, что проще написать на сишке своё.

Вот и всё. Как бы «раст лучше Си потому, что не 100% приходится писать на Си». На крестах индустрия пишет, на расте пишут и будет писать, но значение раста сильно преувеличено. Более того, на сишке пишут, весьма активно, и будут продолжать писать, бг-г-г.

Улучшить свойства этого инструмента, наверняка, можно. А вот если делать «бесконечно масштабируемую и не требующую ручной проверки» штуку, то получится как с бороу чекером: компилятор будет тебе «мешать» отвергая некоторые корректные программы. И тут или мы даём даём возможность сказать компилятору «вот сюда не смотри» или полезность будет не факт, что больше того, что есть сейчас

«Этого инструмента»? То, о чем я говорю — это заметно иной инструмент. Прежде всего фундаментальная проблема сишного конст в том, что он постоянно алиасится на изменяемые ячейки — это прямо-таки норма. Страуструп сделал пародию на сишный const, я же предлагаю совершенно иной инструмент жесткой бинарной константности без каких-либо алиасов, который не совсем борру-черек, но какая-то демо-версия оного. Конечно, эту фичу никогда не реализуют — я просто подчеркиваю, что нет никакой причины не иметь ее в языке.

обход const происходит на каждом шагу,

Не замечал

Это я про алиасы, в том числе присвоении.

без автоматической проверки «соглашения» сложно соблюдать, даже при всём желании. Работал как-то на проекте, где был многостраничный «стайл гайд». И даже его прочитал целиком. В целом он соответствовал здравому смыслу с несколькими местными особенностями. Вот только было всего пару человек, которые на ревью могли написать «вот тут нарушается такой-то пункт, поправь». В итоге нарушения расползались

Это довольно сложный политический вопрос. Я подозреваю, что речь идет о крестах, и, действительно, для крестов это прямо целая катастрофа. Для JS делают линтеры, но они не всё могут прповерить, смысл линтеров тот же — это автическая проверка стайл гайда. Причем, без усложнения языка. Вот такие автоматические проверки соглашений я одобряю. И, в общем-то, нет причин не иметь такие линтеры для крестов — возможно, они есть (но я не копал эту тему).

И ты всерьёз предлагаешь усложнить 90% «повседневных» операций ради этого? В куче проектов тебе не нужно каждый раз задумываться об аллокаторе

Нужно. Mozilla тоже так думала. а потом за голову схватилась. Люди пользуют memory manager как бесконечно хранилище, из которого можно сколько хочешь брать и как угодно часто возвращать обратно. Конечно, если тебя волнуют вопросы производительности. А они тебя волнует, если ты пишешь на крестах в 21-ом веке.

Это примерно как с арифметическими операциями - в каких-то случаях тебе хочется явно обрабатывать переполнение, но в зачастую ты будешь совсем не рад писать что-нибудь вроде

На самом деле проблема более серьезная. и она не решена даже в Rust. А именно «зачем мне в простом коде париться», а потом «ой, паника/UB». Например, паскаль бросает обрабатываемые исключения в таких случаях при некоторых опциях компиляции.

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

Pascal, Go.

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

Да.

Раст уже популярнее хаскеля, а второй системы сборки пока нет. Сколько лет ждать пока сбудется твоё пророчество?

А сколько лет существует хаскель? То-то. IT — весьма инертная индустрия, она не любит спешить.

Дык, TypeScript изначально таким был, а в дарте две версии заметно отличаются. Я бы и этот язык в статику записал, но думал ты спорить начнёшь
TypeScript? Да ладно. Понятное, что на «обычном JS» дофига написано, но на TS пишут как бы не больше, чем на плюсах сейчас

TypeScript — #7, Dart — #18. Я писал о том, что в топе в основном динамика.

Вот и всё. Как бы «раст лучше Си потому, что не 100% приходится писать на Си».

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

Более того, на сишке пишут, весьма активно, и будут продолжать писать, бг-г-г.

Естественно. Правда насчёт «весьма активно» есть некоторые сомнения. Если, что я не собираюсь спорить с тем, что на С пишут больше, чем на расте.

Я подозреваю, что речь идет о крестах

Да.

нет причин не иметь такие линтеры для крестов — возможно, они есть

Конечно, есть. Например, clang-tidy.

Причем, без усложнения языка

Что ты под этим подразумеваешь? Мне кажется, что их необязательность, иначе чем принципиально отличается «борьба с бороу-чекером» и «борьба с линтером»? Опять же, потенциально линтер может проверять правила произвольной сложности. И если им следовать, то это вполне себе будет «усложнением (диалекта) языка».

Кстати, для раста линтер тоже есть и я в этом не вижу ничего удивительного.

Нужно

Я тебе не верю. Ты вон бороу-чекер неподъёмным бременем считаешь. Если ещё всюду явно аллокатор протаскивать (и так же явно ошибки выделения памяти обрабатывать), то от бизнес-логики вообще мало что останется.

А именно «зачем мне в простом коде париться», а потом «ой, паника/UB»

Если говорить об арифметический операциях в расте, то UB не будет. Как и паники (в релизе). В целом мне более-менее нравится как сделано в языке: при необходимости ты всегда можешь явно использовать checked/saturated/overflowing/wrapping/unchecked версию операции. Конечно, надёжнее было бы заставить явно выбирать, но тогда желающих писать на языке было бы куда меньше.

Pascal, Go.

Ты сам признавался, что второй толком не щупал. И про дженерики в Go уже почитал? А их уже в следующей версии обещают. Ну и лично мне этот язык, особенно без дженериков, кажется как раз излишне примитивным. На определённых (или до какого-то размера) проектах это, пожалуй, не сильно мешает. Но в целом такое себе.

А что паскаль? Он ведь слегка жив, почему на нём не пишешь?

Я писал о том, что в топе в основном динамика.

Я согласен с этим утверждением только если учитывать количество кода. Ну или мы о топ-2 говорим. Иначе что-то не сходится.

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

Звучит как «можно поставить калеку играть за Спартак, но не за Реал Мадрид — калеку найти проще, чем Рональдо». Да, можно, но ЗАЧЕМ? Есть нарды, шашки Java, есть С#, есть нода, питон, в конце-концов, почему я должен хотеть садить секретаршу писать на низкоуровневом языке? Бабушки в 70-80-х подарили банкам код на коболе и фортране, который до сих пор не могут переписать, потому что переписать миллиарды строк этих заклинаний без ошибок стоит миллиарды долларов. Зато статика и доступа по некорректному указателю там нет, бесспорно.

Я просто хочу сказать, что индустрия через это УЖЕ ПРОХОДИЛА, и кончилось это плохо. Чтобы реально обезопаситься, секретаршам нужно дать не

let s = Rc::new(RefCell::new(String::from("фыв")))

let s = "фыв"