юнионы в C++

Я подумал, что переманить пытаетесь. :)

ТС-а?! Чур меня…. У нас порог вхождения сильно повыше чем в плюсы будет.

Насчет Реал тайм я не спец. Но по рассказам местного народа там в ход идет много чего, от плюсов до лиспа на плисках.

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

Прямо идеальный пример.

И вы уперены, что JS умерет?

но VS Code меня устраивает, в то время как IDE, написанные на Java - слишком тормозные, а написанные на C++ - просто слишком убогие (потому что на убогом

Нет, ты не отличаешь IDE от текстового редактора с плагинами. Не существует IDE на электроне. В то же время на С++ и Java написаны наиболее сложные IDE, снискавшие мировую известность.

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

Именно поэтому GCC, LLVM, ICC, EDG и другие компиляторы, опять же, мировой известности, написаны на С++.

Числодробилки, внезапно, пишут тоже и на лиспе, и даже на Обероне (допилив сам Оберон, т.к. его легко расширять).

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

Неинициализированная матрица для числодробилки, забитая мусорными числами - это же прекрасно!

И? Такое сразу отсеится тестами.

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

А в пилотной версии еще на простых моделях косяк может всплыть.

Бггг, а без перехода на личности и фантазий о проблемах с безопасностью при написании числодробилок у Вас есть что сказать?:-)

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

Ну ты во-первых себя не особо хорошо показал в разговоре, во-вторых, я работы на плюсах не ищу, у меня вообще с работой всё норм.

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

Я над ними на работе за деньги работаю. В свободное же время пишу телеги :)

Именно поэтому GCC, LLVM, ICC, EDG и другие компиляторы, опять же, мировой известности, написаны на С++.

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

Нет, ты не отличаешь IDE от текстового редактора с плагинами. Не существует IDE на электроне.

Ну можно и в эту сторону поспорить. В VS Code есть всё, что нужно мне. Да, там нет рефакторингов. И только. Автоформат кода, переходить к определению и отлаживаться - можно, легко, более-менее работает, для нескольких языков. При том, в эклипсе я сломался на попытке наладить под себя шрифты.

Ну бывают разные традиции

Фантазировать на ЛОРе, например.

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

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

И вы уперены, что JS умерет?

Попытки его обойти налицо. Тут и typescript, и dart, и всякие технологии для создания приложений вне браузера. В этом ситуация вполне подобная сям и плюсам. Умрёт? Ну хз что будет вообще через 5 лет. Технология, набравшая массу, живёт долго, примеры только что были, тот же Кобол и Фортран с его блас-лапаком. То же касается и сей-плюсов. Но это не значит, что с ними не нужно бороться, расчищать место под будущее.

Ну можно и в эту сторону поспорить. В VS Code есть всё, что нужно мне. Да, там нет рефакторингов. И только.

Я не спрашивал, что есть в VSCode, и чего нет. Я не спрашивал, хватает ли тебе того, что там есть.

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

Все это есть в виме. Это не делает VSCode IDE. Это делает VSCode текстовым редактором, крайне неэффективно использующим приклеенные изолентой и соплями сторонние инструменты. Это чудовищные тормоза по сравнению с реальным IDE.

При том, в эклипсе я сломался на попытке наладить под себя шрифты.

Боже, какая чушь. Какое отношение имеют шрифты к IDE?

Я перестаю отвечать тем, кто хамит, называет меня психом или априори рассуждает, что я что-то не осилю, или использует манипулятивные приёмы. В этих случаях я подаю жалобу и прерываю разговор. Это не значит, что я слился, это значит, что есть правила разговора, которые нужно соблюдать, если есть желание со мной поговорить. Когда мне указали, что Го не потомок Активного Оберона, я это проверил и признал свою неправоту, хотя мне даже сначала показалось, что это манипулятивный приём, а на самом деле чел показал изъян в моей собственной логике, в итоге я ему сказал спасибо.

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

const It cit;
то второй нельзя будет итерировать (он ведь константый)

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

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

const<iterator<int>> cit1;

iterator<const<int>> cit2;

Ок, мой коммент стерли, я его перефразирую.

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

До этой дискуссии я к Вам и Вашей разработке относился со сдержанным интересом, скорее положительно. Но Вы сумели изменить мое мнение.

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

ЗЫ и да, надо отвечать даже за то что ты сказал в интернете каким то анонимам.

И если текст слишком мелкий, то его читать неудобно. Поэтому в IDE должна быть возможность настройки шрифтов, не выносящая мозг.

Ты знаешь как настроить шрифты в интерфейсе vscode?

На панельках и менюшках?

Жалоба была мной подана за хамские выпады.

Я догадываюсь зачем Вы пишете телегу.

Пока что мимо.

Если наш Институт привлекут в качестве экспертной организации, то я сделаю все, что бы Ваша разработка не получила финансирования/внедрения

Раз да Вас. Приятно чувствовать свою власть и способность её применить для блага!

Мне это не было нужно. Потому что в ОС у меня уже как-то настроен нормальный размер шрифта, а в VS Code шрифт всего один (мне пока попадался). А вот в Эклипсе это было реально неприятно.

Исключительно в теории (нужно специально постараться - тут уж каждый ССЗБ). На практике - не встречал.

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

Сколько существует реализаций деревьев, и насколько по-разному они хранят данные внутри себя ради эффективной вставки и т.д.? А для cbegin нам ничего не мешает все данные запихать в обычный массив, и обновлять этот кэш, только если были вызовы мутабельных методов.

Мне это не было нужно.

Насколько я помню, это было невозможно.

Ваш пример хорошего IDE не удовлетворяет вашим же требованиям к хорошему IDE.

Причем здесь власть? Вы хотите сформировать а аудитории отношение к плюсам и Яру - Вам это удалось. Продолжайте в том же духе.

Дальше скучно. Всего хорошего, спасибо за беседу.

Если это какая-то попытка меня поймать, то давайте не тратить время: в Eclipse я страдал от шрифтов, в VS Code - нет. Я не знаю, как это получилось и об этом не думаю, пока мне что-то не начинает мешать. В случае VS Code ничего не мешает - это наилучший вариант.

Яр уже давно закрыт, 3 года, но про новую разработку не скажу, а то и она под репрессии попадёт. Впрочем, и она уже тоже на грани закрытия. Насчёт отношения к плюсам - вряд ли, я же в основном спрашивал, а мои аргументы, которые я привожу, в общем-то общеизвестны. Либо люди их уже приняли, либо уже отвергли. Интересная оценка результатов моей работы, но тоже мимо :) Вам тоже всего хорошего.

Если это какая-то попытка меня поймать

Э… забавная реакция на явный прокол.

В чём прокол? Размер шрифта в текстовых окнах меняется сочетанием клавиш, в т.ч. это распространяется и на логи. ЕМНИП в эклипсе меня доставал мелкий шрифт в логе компиляции. В VSCode этой проблемы нет. Т.е. в VSCode проблемы со шрифтами у меня не было. Допустим, я нечётко сформулировал требования к инструменту, но это мелочь. Если Вас радует, что меня на этом поймали, то примите мои поздравления. Видите, я не сливаюсь, т.к. я не играю в спорт «будь всегда прав и победи всех остальных», а завёл тему, чтобы что-то узнать. Я признаю поражение. Тем не менее, «настоящая IDE» Eclipse доставила мне боль, а «жирный текстовый редактор с болтающимся скотчем» - не доставил. Я на данный момент успешно просматриваю определения, собираю и отлаживаю программы на go, C, java и python в VS Code - всё более-менее работает. Кажется, когда-то и ноду отлаживал. Языки, которые она не осилила - это ocaml и Common Lisp - там только емакс. Но их и эклипс не осилит, 99%. Так что называй хоть редактором, хоть пирожком - оно работает. Да, проблемы были. Но в случае жабы проблемы в VS Code решились почему-то быстрее, чем те же проблемы в JB.

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

Вы реально такое встречали?

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

Имхо: очень непрактично. Зачем прятать вот это всё за итераторами? Да, можно заставить работать, и да - можно даже заставить работать во всех случаях включая сохранение всех гарантий [не]инвалидации итераторов присущим node-based containers. Но будет медленно. Если бы мне что-то такое было нужно это был бы какой нибудь отдельный tree_view со своими итераторами и логикой синхронизации внешней по отношению к этим итераторам.

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

Вы реально такое встречали?

Так это встречают все, кто руками реализует кэширование доступа. То есть, сценарий выбора между [дорогим, но mutable] и [дешевым, но r/o] доступом к объекту. И на этот сценарий отлично налазит begin/cbegin, которые, как нам и завещал стандарт, могут иметь разные кишки. Или не налазит?

Зачем прятать вот это всё за итераторами? Да, можно заставить работать, и да - можно даже заставить работать во всех случаях

Ну вот хочется спрятать, почему нет?

был бы какой нибудь отдельный tree_view со своими итераторами и логикой синхронизации внешней по отношению к этим итераторам.

Ну этот tree_view всё равно должен иметь доступ к кишкам tree, то есть быть наследником или там friend. Иначе нельзя обновлять кэш частично, только пересчитывать весь tree. А раз это всё равно «друзья», то зачем плодить сущности, почему не сделать всё в классе tree?

vscode

А ничего, что vscode это электрон (хромиум, c++) плюс нода (v8, c++)?

Так это встречают все, кто руками реализует кэширование доступа. То есть, сценарий выбора между [дорогим, но mutable] и [дешевым, но r/o] доступом к объекту. И на этот сценарий отлично налазит begin/cbegin, которые, как нам и завещал стандарт, могут иметь разные кишки. Или не налазит?

А в чём проблема? Ну не учим свой неконстантый итератор кастоваться в константный, это просто не скомпилится. Если разговор о «универсальной» begin(), то range’ы дают возможность кастомизировать их поведение, там все эти ranges::[c]begin() и смежные штуки обзываются «customization point object», или можно специализацию для своего итератора в std:: написать.

PS: хотя не совсем уверен по поводу range’ов, не уверен, что правильно понимаю «customization point object», не факт, что можно свою версию там подставить.

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

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

отлично налазит begin/cbegin

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

Ну этот tree_view всё равно должен иметь доступ к кишкам tree, то есть быть наследником или там friend.

Вовсе не обязательно. Достаточно из tree заэкспозить read-only всё то что нужно для эффективной синхронизации.

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

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

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

про тайпскрипт

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

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

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

Очевидно, что это без плагинов, на счёт node_modules меньше уверен, но вряд ли оно было бы столь тощим.

Кстати, я вот сейчас узнал про существование стандартов CERT C и CERT C++. Кто их исповедует в своей работе? Насколько они помогают от уязвимостей? А от других грабель?

CERT C и CERT C++

Говно редкое.

Можно ли чуть более размазанно, т.е. развёрнуто?

Там бесполезные с практической точки зрения советы/правила, типа «не используй уже освобождённый объект». Спасибо, не знал. Т.е. эти правила созданы не для написания хорошего кода, а для security code review.

Допустим, я нечётко сформулировал требования к инструменту, но это мелочь.

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

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

Но в случае жабы проблемы в VS Code решились почему-то быстрее, чем те же проблемы в JB.

В случае жабы они хоть как-то но решаются. А вот с vscode - облом. У меня у монитора разрешение большое - меню и панельки нечитаемы. Хорошо, что все можно командами сделать, но неприятно.

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

Всего одну? Я знаю ещё парочку.

За такое надо причиндалы отрывать.

За C++ в 2022 году надо отрывать причендалы, согласен.

А что я могу сделать?

Ответить на вопрос.

То есть, вектора из констант или смешанных значений в STL запрещены.

Зачем вам это?

У меня есть функция, которая берет вектор ссылок на объекты, и возвращает ссылку на второе значение из вектора. Не важно, какая там ссылка: сишная, или reference_wrapper, или unique_ptr, или shared_ptr — чтобы было совсем ясно и конкретно, пусть тип будет char *. Какова должна быть сигнатура функции?
Может быть const char* get_second(const vector<char *>)?
Или же char* get_second(vector<char*>)?
А если я хочу эту функцию применить к вектору из compile-time константных объектов?
const char* get_second(const vector<const char*>)?

Между прочим, официальная позиция — да, копипасть функции с разными аргументами. Вся стандартная библиотека крестов слепена из такой копипасты, например:
https://en.cppreference.com/w/cpp/container/vector/front
Так выглядит почти любой метод чтения, возвращающий ссылки. Слава богу хоть volatile выкинули, иначе бы пришлось четыре копии держать.

Позиция «ссылки не нужны, копируйте значения, так надежнее» имеет право на жизнь, а также намекает на то, что константная ссылка-аргумент нужна только для копирования в non-const объект — возвращать ссылки на аргумент и его поля «плохо». У меня есть ощущение, что авторы стандартной либы тяготеют к такому подходу, однако, как мы все понимаем, он далеко не самый эффективный. Именно потому Qt сделало строки (и куча других объектов) с подсчетом ссылок вместо стандартных — когда у тебя ездит куча объемных объектов (часто неизменяемых) туда-сюда по коду, то копирование на каждый чих приводит к печальному результату. На самом деле, очень многие высокоуровневые ЯП пошли именно по пути подсчета ссылок: Object Pascal, Java, JavaScript, PHP, Python — это из самых попсовых. Правда, реализация строк Qt выглядит откровенно страшненько при чтении сорцов.

Из мемуаров продажника можно узнать, что Страуструп изначально продавал под названием readonly, а позже const, то, что в современном C++ известно как constexpr, то есть, именно compile-time объекты-константы, а не ссылки на константные значения. Более того, начиная с C++14 компилятор умеет автоматически применять constexpr для функций от констант и снимать его, если функция берется от переменных — то есть, constexpr более не подразумевает const, он вообще ортогонален const-у.

Но это сейчас мы такие умные, а в восьмидесятых была ситуация «не знаю, как его сделать, но звучит красиво — давайте внесем в стандарт языка Си». И внесли (теперь вы знаете, как в стандарт попала поддержка GC). И очень долго время под соусом const существовало три независимых вещи:

 — compile-time константы, каковые были во всех остальных языках, например #define x 42;
 — compile-time выражения-функции, например static constexpr int const& x = 42 (обращаю внимание, что это уже ссылка);
 — read-only аргумент-ссылка на ИЗМЕНЯЕМЫЙ объект, void function(const int &x). Да-да, оптимизирующие компиляторы считают, что объект по константной ссылке может измениться в любой момент, что в фундаменте противоречит идее «константы». Иронично, что исходное название модификатора readonly в данном случае подходит лучше.

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

Но вот же ж константная ссылка, или меня уже глючит?

Так вы же сам объект item не меняете

Вот тебе сюрприз: когда я делаю vector[23] = std::string("asd") — я тоже не меняю объект vector, он может быть константной ссылкой. Тем не менее, разрабы STL запретили делать присвоение по индексу у const vector. Просто «потому что». А в Qt я могу поменять строку, ссылающуюся на разделяемый неизменяемый объект, и при этом произойдет copy-on-write. Итого разрабы стандартной сделали некое отрывистое впечатление, что const в C++ действительно работает, хотя на самом деле работает оно на весьма ограниченном числе сценариев, которые они тщательно отобрали, сделав остальные «ненужно».

Пф-ф-ф, можно вообще все поля у всех объектов сделать mutable — очень удобно будет

Кому будет удобно?

Всем. Потому что const Type и Type станут взаимозаменяемыми.

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

Я отвечал DarkEld3r-у, что «помогает» оно только если за тебя кто-то уже очень много налюбился с реализацией и тщательной подборкой интерфейсов. Впрочем, при чем тут const? Вот Qt не использует подход стандартной либы C++, в Qt данные объектов константны и изменяемы одновременно. Им типа const не помогает? Оно помогает только если сделать вид, что кроме STL больше готовых решений не существует, что синхронизации нет, подсчета ссылок нет, персистентных структур нет, кэшей нет — пердолим дальше отдельные байтики по указателям через интерфейсы с повышенной надежностью (привет разрабам Rust).

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

Задумался. Пришел к выводу — const не нужен. Каждый раз, когда что-то пишется const — в следующую наносекунду откуда-то магическим образом прилетает переменная без const, которую нужно засунуть в const функции. Опять-таки, разрабы стандартной либы в ряде случаев просто ничего не смогли с этим придумать, в ряде случаев начиная с C++20 в стандартной либе у методов наконец появились constexpr модификаторы, которые сами разбираются, вычисляемы ли они в compile-time или нет, а остальные случаи «не нужны».

Так что за пример такой с константным контейнером (списком константных значений), в котором этом самый константный контейнер нужно модифицировать? Смысл его извращения от меня ускользает

Я предыдущим сообщением уже частично ответил, повторюсь: std::list<const char*>. В идеологии STL интрузивным оно не может быть в принципе. Можно было бы сделать std::list<char*>, но, ололо, это же небезопасно, вдруг кто-то засунет туда настоящую константу, а кто-то другой ее изменит — приложение упадет с segfault. В итоге, как ни прыгай — получаются сорта говна, const поломано by-design, и на самом деле ты сам склоняешься к «const не нужен», но почему-то боишься пойти до конца.

это все равно что

auto lp = item.b;
*lp = std::string(...);

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

это значит - изменить то, на что указывает указатель item.b. то есть сам item не меняется

Я всеми конечностями за то, чтобы признать наконец const T& модификатором доступа к имени переменной, а не модификатором типа.

Эта путаница актуальна и для деления «ссылка-указатель», которая перекочевала в C++ из Cи, и решить ее не удалось (потому что никто ее и не решал, LOL).

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

Ну серьезно, фразы Страуструпа сдержаны, но он сам осознает, что выдал лютейший кал, и между строк у него читается «я что-то высрал, и норм на этом поднялся, а вы на этом теперь пытаетесь программы писать, вот уморы». Как Минаев говорил «я на этой книжке заработал два миллиона, а по ней будут учиться твои дети». То есть, все стрелы и копья, кидаемые с криками «но это же ГОВНИЩЕ», отбиваются щитом «зато популярно, я одобряю, покупайте наших слонов».

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

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

Именно в модулях можно сделать анализ перекрестных ссылок

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

Какое отношение строки-массивы имеют к дополнительным блокам памяти?

Сколько нужно дополнительных блоков, чтобы выделить std::shared_ptr<std::string> ? Два-три.

«двойные указатели» это массив из указателей на ноды. Такой дизайн выбран в связи с необходимостью предоставить требуемые стандартом гарантии. То, что ты хочешь, называется flat_map/flat_set и является другой структурой данных

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

Утечка ресурсов, отличных от памяти, ничем не отличается от утечки памяти, а GC от нее никак не защитит

Повреждение памяти намного, НАМНОГО опаснее, чем просто утекшие ресурсы. Именно поэтому GC на голову выше любого RAII, именно потому в ряде ниш за C++ сразу бьют по рукам. Выполнив некорректную последовательность деструкторов RAII может выстрелить себе в ногу, а GC — нет. С GC потом уже можно опционально спокойно поотлаживать утечки.

кто будет проверять, что в union лежит корректное значение, кто будет проверять, что

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

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

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

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

Go упал в почти пустую нишу, как ни странно. На мой взгляд, Java является худшим из менйстримовых языков, C# был win-only или около того. Написать что-то быстро, с гарантиями работоспособности, и с хорошей производительностью было тупо не на чем. Google до этого использовал Java, и впечатления у них были примерно как у меня. По сути, Go — это Java, сделанная по-человечески.

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

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