IMHO, D - избыточен. Избыточен не так как Rust - в закорючках и лайфтаймах, а избыточен так, что смотришь на код, который должен выглядеть проще, чем С++, но вспоминаешь фразы Александреску типа :

«С оut-контрактами дело обстоит ровно наоборот. При замене предка по­томком переопределенная функция должна предлагать больше, чем обещано в контракте. Так что гарантии, предоставляемые out-контрактом метода предка, переопределяющий метод всегда должен предостав­лять во всей полноте (в отличие от случая с in-контрактом).

и это разрывает сердце.

три примера проектов, которые стоило бы переписать с С++ на D

1. GOODS, как пример ООСУБД. рефлексия сделана костыльно на С++. кастомные аллокаторы (перекрытый new) использованы разумно, для пейджинга страницами содержимого ООСУБД.

реализация на D позволила бы использовать нормальную, системную рефлексию. нормальную иммутабельность (immutable, а не const). нормальную многопоточность (через fiber). может, что-то даже разгрузить на CTFE. а кастомные аллокаторы вот и в D тоже есть.

2. InteLib А. Столярова. лисп как библиотека на С++. код на лиспе транслируется в код для объектов на С++ с перекрытыми операциями. частично через шаблоны, но в основном в рантайме.

реализация на D позволила бы использовать CTFE компиляцию, с нормальными шаблонами (а также концептами и рефлексией).

3. LLVM, внезапно. уже есть на D: lycus/MCI. развивается, но не очень активно

большая часть D доступна через CTFE, что открывает две возможности: 1) компилятор как библиотека
2) D, как и лисп, является своим собственным метаязыком (учитывая рефлексию, аннотации и тайпинфо)

3) Calypso, и вызов С++ из D без врапперов — тоже открывает кучу возможностей для метапрограммирования на С++ через D. то есть, метапрограмма на D генерирует код на D, который CTFE раскрывается в сгенерированные коды на С++.

а ну-ка, а ну-ка. быстро, решительно: рассказывай, как бы ты сделал неубогую рефлексию/интроспекцию/интерцессию в крестах.

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

да так, чтобы работало для любых классов и типов

Для всех это нужно ещё меньше, чем для примитивных типов в джаве.

три примера проектов, которые анонимусу стоило бы переписать с С++ на D

Вот так правильнее.

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

Эти «новые элементы» написаны на чём говоря о D? Если на D, то опять же - кто понимает D без компилятора? Если не на D - то какой же это уже «компилятор переписан полностью на D»?

Интересно, а как Труп Страуса относится к развитию Ди? Видит ли в нём конкурента, стремящегося вытеснить плюсы с рынка?

да неважно кому.

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

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

man теорема Тарского об истинности и метаязыках.

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

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

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

а кто именно там реализует эти возможности — по сути неважно.

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

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

Кто жить не может без «неубогой» рефлексии в C++ - использует Qt.

вот кстати, пример о чём я говорю: язык Qt относится к C++ как метаязык (с поддержкой сигналов и слотов) к языку-носителю (moc компилирует в целевой язык С++).

и да, в Qt тоже убогая рефлексия.

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

Вот пойди и воспользуйся новыми и старыми. Только что-то мне подсказывает, что кишка у тебя тонка осилить эту задачу по переписыванию. Но ты не одинок. Я же не зря тут так долго выпытывал удалось ли кому-то сделать что-то подобное. Знатоки утверждают что нет. И это за 15 лет существования языка, на секундочку. Или минимум за 7 (семь!) лет.

D - мертв. В том числе из-за несовместимости с С и С++.

про Calypso в заголовке темы читал? в чём там несовместимость с С++?

в чём несовместимость D с С, если линковаться можно прозрачно?

опять, зачем С++ хвалёная псевдосовместимость «внутри языка» с Си (хотя это другой язык, с отличиями) — если во всех языках есть вменяемый FFI и — совместимость с Си «внутри метаязыка»?

и да, в Qt тоже убогая рефлексия.

Рефлексия в Qt даже избыточна для тех задач, которые она решает. Можно было бы обойтись шаблонами.

Что-то мне подсказывает, что у тебя телепатия непрокачана.

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

да нет, просто нет на это свободного лишнего времени. я вот вижу, как это переписывание нужно делать: берём старый исходник на С++, Calypso, Emacs org-mode babel в качестве WEB LitProg среды, и вдумчиво комментируем, конспектируем:

1) untangle исходного на С++ => .org(*) объясняем сами себе, => tangle исходного C++
2) (**)теперь пишем к (*) метауровень<*> (до концепций, и как можно это сделать проще на другом языке) => tangle результирующий D <= untangle результирующего D (***)
3) (**) сопоставляем с (***) и вдумчиво комментируем. получаем доработанный <*> который будет являться «переводом» на D конспекта (*) на С++.

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

Знатоки утверждают что нет.

Старожилы у нас отличаются особой забывчивостью, да.

Но почему ты это спрашиваешь на лоре — а не в профильных сообществах того же D, в юзнетгруппе, например? ты бы ещё в цирке поспрашивал.

значит, намерение твоё нетвёрдо — если обращаешься не к первоисточникам.

про Calypso в заголовке темы читал? в чём там несовместимость с С++?

Левый экспериментальный форк одной из (не самой популярной) реализации D? И это аргумент? Ты борщехлеб штоле?

в чём несовместимость D с С, если линковаться можно прозрачно?
опять, зачем С++ хвалёная псевдосовместимость «внутри языка» с Си (хотя это другой язык, с отличиями) — если во всех языках есть вменяемый FFI и — совместимость с Си «внутри метаязыка»?

Точно борщехлеб. Или пиши 100500-ю обертку поверх сишных библиотек.

да нет, просто нет на это свободного лишнего времени

Ни у кого нет времени на «починку» того, что и так не сломано.

я вот вижу, как это переписывание нужно делать

А я вот вижу, что это переписывание не нужно даже тебе.

Но почему ты это спрашиваешь на лоре — а не в профильных сообществах того же D, в юзнетгруппе, например? ты бы ещё в цирке поспрашивал.

Так ты же утверждаешь, что надо бы переписать на D какой-то GOODS. Значит нету на D ничего подобного? Или ты тоже не уверен?

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

Linkedin использует Erlang в своих сервисах, и благодаря этому добился значительного прироста производительности.

До настоящего момента компилятор D был написан на С++, однако новая версия теперь написана на самом D.

Когда же уже компилятор c++ перепишут на D.

Когда же уже компилятор c++ перепишут на D.

Какой из? IBM, Microsoft, Intel и пр. такой херней страдать не будут. В GCC только-только переехали на С++, причем как раз потому, что тот близок к С. Впрочем ты можешь переписать первую версию cfront:

http://www.softwarepreservation.org/projects/c_plus_plus/cfront/release_1.0/s...

И реализовать свою мечту.

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

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

В Паскале, кстати, есть опережающее описание. В D и OCaml --- интерфейсные фалы, правда, генерирует их сам компилятор.

О опережающем описании я помню, хоть и писал на Паскале совсем не много. Такие вещи не должны писаться руками в отдельных файлах, а быть частью синтаксиса (Паскаль), или генерироваться из кода (как вы упомянули D/OCaml)

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

Дура ты. У всего широко приминимого есть недостатки и преимущества. Вот и все.

И чем же оно лучше раста? Не холивора ради.

Для пользователей Linux выложена первая пробная версия компилятора Calypso, позволяющая в D использовать практически все существующие С++-библиотеки, даже такие большие и сложные, как Qt5 и Ogre3D.

Значит, весь этот D - очередная параша. Как всегда, в погоне за C и C++. Проще уже писать на C и/или C++ и не страдать фигнёй.

И чем же оно лучше раста? Не холивора ради

Набором возможностей. Их в D на порядок больше, причем самых разных. Rust на фоне D выглядит как Basic.

И кстати и именно потому же Rust лучше D.

Какой из?

Да все, а потом забить на апгрейд:)))))

Впрочем ты можешь переписать первую версию cfront:

http://www.softwarepreservation.org/projects/c_plus_plus/cfront/release_1.0/s...

И реализовать свою мечту.

Не, моя мечта - нормальный транслятор ц/цпп win32/x86-linux бинарников в асму а из неё в fpc. Вот только не испачкавшись в плюсах отладить его не удастся.

Ты смешиваешь мух с котлетами.

программист (если речь не о хобби) связан

1) политикой компании и/или выбором инструментария руководителем проекта 2) доступностью для выбранного инструментария инфраструктуры, включая сторонние библиотеки 3) сроками

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

Есть ли потребность в «альтернативе С++»? Есть. Бо как гадкий пунктик «3)» говорит простую вещь: срок разработки на C++, по сравнению с альтернативами, при прочих равных, слишком велик. Вот и бросаются к C#.

И альтернатива в виде честно компилируемого D, может быть очень даже востребована. Энтузиазм вокруг Раста связан ровно с тем же. Однако, ИМХО, Раст стал слишком перегружен хакеризмами и слишком затянул гайки, так что соотношение «качество/срок разработки» слишком уж пострадало.

Есть ли исторический пример, когда столь же маргинальный инструмент доказал удобство и перешёл в мэйнстрим? Ага, есть. Я очень хорошо (собственно, начинал использовать Питон одним их первых в городе, так что вполне в теме) помню ситуацию вокруг Питона и реакцию сообщества в 1995 - 2001. Один в один. Поэтому всю эту дискуссию читать смешно.

Фактически, станет ли D успешным и широкоиспользуемым инструментом определяется 2я факторами: а) появится ли стандратная библиотка, претендующая на лавры «питоновских батареек» (хотя и имеющаяся весьма и весьма близка к этому уровню) и б) появится ли не монструозная привязка к Qt (не говорю «собственный гуй», так как нужно очень и очень постараться, чтобы собственное решение оказалсь мощнее и качественнее Qt ) и вообще, возможность более внятного использования уже существующих сторонних библиотек.

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

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

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

лол просто лол

Происходит. Так переименовали iostream.h в iostream,

Это же чисто косметическое изменение. Суть-то осталась прежней: без препроцессора никуда, нельзя импортировать определения кроме как впечатав их текст. Так же как и в С. Смотри чем import в java и D отличается от #include

С++ он просто не нужен.

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

Никто не реализовывал совместимость с С, С++ изначально «С с классами».

Да, а ещё и с шаблонами, теперь и с лямбдами, и всё поверх С

Это же чисто косметическое изменение

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

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

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

Да, а ещё и с шаблонами, теперь и с лямбдами, и всё поверх С

Да, и именно это делает С++ уникальным. С и С++, несмотря на всех их недостатки, до сих пор не просто нужны, а очень нужны.

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

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

Есть такая теория: Diffusion of Innovations (известная по работе Crossing the Chasm). В соответствии с ней бывают разные типы пользователей любой технологии/продукта. Начиная от innovator-ов и early adopter-ов, заканчивая late majority и laggards. У каждого их этих типов свои ожидания от продукта и свои цели в использовании продукта. То, о чем пишете вы, относится к типам late majority и laggards (может отчасти и для eary majority). Тогда как у innovator-ов и, особенно, у early adopter-ов ожидания и тебования совсем другие, очень сильно другие.

Есть ли исторический пример, когда столь же маргинальный инструмент доказал удобство и перешёл в мэйнстрим? Ага, есть. Я очень хорошо (собственно, начинал использовать Питон одним их первых в городе, так что вполне в теме) помню ситуацию вокруг Питона и реакцию сообщества в 1995 - 2001. Один в один.

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

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

И то, что говорят C++ники про D, к сожалению, оправдано. Язык D был достойной заменой C++у в 2006-2007-м, когда в развитии C++ был застой, а один из крупнейших игроков на рынке C++инструментария, Microsoft, всем своим видом демонстрировал, что C++ ему уже не интересен, а будущее только за .NET-ом. Вот в 2007-ом у D были шансы оттяпать большой кусок у C++. Но в 2007-ом упомянутый здесь Александреску стал оказывать серьезное влияние на развитие языка и было анонсировано начало работ над D2, несовместимым с D1. Причем, что самое пикантное, стабильному D1, который в начале 2007-го едва-едва достиг версии 1.000, на тот момент было всего полгода. Т.е. язык еще не просуществовал в стабильном состоянии хоть сколько-нибудь заметного времени, а уже объявили о том, что D2 будет совсем другим.

С тех пор прошло уже восемь лет, а ситуация вокруг D все такая же — долгострой, который интересен кучке маргиналов, не умеющих использовать то, что есть вокруг (и речь не только про C++, но и про языки вроде Haskell, OCaml, Objective-C, Swift, Ada, Eiffel и т.д.). Даже самые известные пользователи D, sociomatic, сидят пока на D1 с целой кучей написанных самостоятельно библиотек и не спеша пытаются портировать все это хозяйство на D2. Показательная картинка, особенно с учетом того, что в мире C++ полно старого кода, который без проблем собирается новыми компиляторами.

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

Даже самые известные пользователи D, sociomatic, сидят пока на D1 с целой кучей написанных самостоятельно библиотек и не спеша пытаются портировать все это хозяйство на D2

Уже нет. https://www.sociomantic.com/blog/2015/02/on-sociomantic-and-d2-migration-part-1/

Не вижу противоречий с тем, что было сказано. В заметке о процессе портирования (28-го мая 2015) было сказано:

It is very hard to estimate how long full transition will take—”not soon” is probably the best estimate under these circumstances. Right now we have our own version of Tango ported and another big core library about half way completed, all done by small group of people. The process is likely to speed up a lot once we get to actual applications, but there will also be dragons. Imagine testing a real-time application with new runtime and ported garbage collector and you may see why I am not calling hard deadlines to anyone.

Т.е. не спеша народ занимается работой, которую не нужно было бы делать, будь разработка на C++, Java, C# или любом другом нормальном языке, для которого совместимость — это не пустой звук.

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

Детским садом попахивает твой треп. «Более лучше», «более быстрее», «более безопаснее». Ты не понял, что я требую всего-навсего практических подтверждений этих заявлений? Их нет. Единственный подобного рода проект, на который мне тут дали ссылку - Higgs - и тот оказался фейлом по причине кривого GC в D. Вот, собственно, и весь показатель. Одна болтовня и размахивание руками. Тем временем актуальным является C++14, который по удобству и скорости разработки нечего и сравнивать с C++98. А на подходе C++17. А ты всё пишешь о каком-то сферическом «C++» в вакууме, на котором, якобы, очень медленно делаются проекты (которые на D вообще никак не делаются).

C#

Оно не совместимо. Только декларируется, а в действительности то и дело что-то лезет. по крайней мере при использовании старых веток до 3.0 включительно.

А так --- да. Отсутствие развития --- залог успеха в ынтырпрайзе.

полным-полно

Ровно ноль.

только во вменяемых языках — а не с++

Примеры языков.

рефлексия и интроспекция нужна. это в С++ только проблема

Кому нужна?

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

а ну-ка, а ну-ка. быстро, решительно: рассказывай, как бы ты сделал неубогую рефлексию/интроспекцию/интерцессию в крестах.

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

да так, чтобы работало для любых классов и типов, а не начиная со своего «рефлективного» класса

Меня это не интересует.

да так, чтобы не заниматься байтодрочерством и битхаком в раскладке класса

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

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

Что там придумывать? Это примитивное убожество. Что там нужно? Форич по полям? Реализуется любым школьником.

Всё остальное уже есть. Да и форич по полям реализуется и сейчас.

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

в С++ это же можно сделать проще, же ну? или нет?

Чего проще, балаболка? Ты же совсем нулёвый в хлам. Никого не интересует твоё api, ибо уровень детсада.

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

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

Так я не понял, ты за цепепе или против цепепе? :-)

Этим и отличается С++ от «куллязыков». На нём «закатить солнце» вручную можно, а вот на «куллязыке» нет. Это и делает кресты крестами.

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

Другое дело, что нормальная альтернатива С++, может быть и нужна.

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

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

Если программист пишет «полезные программы» на С++ и посматривает на раст, то это считается?

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

Ну а драйвера и хардкор на Rust - самое то.

Я вот что не пойму, если ты такой гениальный и охуенный - хуле ты не осилил банальный пул объектов на цепепе написать?

Java

Да ладно? Я бы ещё понял, если бы ты скалу назвал.

Ну, собственно, да. В этом-то все и дело.

Возможно, нужна еще и более серьезная поддержка функционального подхода. Но насколько это возможно в рамках близких к железу языков без GC (вроде C++ и Rust) — отдельный вопрос.

Кроме того, имхо, нужна еще и серьезная {новая?} прикладная ниша, в которой бы новый язык на замену C++ мог бы успешно развиваться какое-то время не испытывая конкуренции со стороны других языков.

Вот, скажем, у Objective-C и Swift такая ниша была и есть — это разработка под MacOS/iOS.

Возможно, у Rust-а такая ниша есть — низкоуровневое системное программирование (правда, имхо, там он будет бодаться не столько с C++, сколько с C).

А вот у D такой ниши не видно, т.к. всерьез противостоять C/C++/Rust он не может из-за GC (а языкам с GC он уступает в качестве как самого компилятора, так и инфраструктуры вокруг него).

нормальную иммутабельность (immutable, а не const)

Можешь в двух словах рассказать чем это лучше?

Я не знаю, что такое immutable в D, но может ему не нравится, что const в С++ не гарантирует неизменяемость объекта? То есть можно сделать const_cast или просто объявить поле как mutable и тогда его можно менять всегда.

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

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

Раст стал слишком перегружен хакеризмами

Что такое «хакеризмы» в этом контексте?

Возможно, нужна еще и более серьезная поддержка функционального подхода. Но насколько это возможно в рамках близких к железу языков без GC (вроде C++ и Rust) — отдельный вопрос.

По-моему полноценного GC в C++ нет только потому, что он там никому особенно не нужен. А так то для него там уже местечко предусмотрели. И если от него действительно будет какая-то польза, то его добавят. Но тут опять встает вопрос эффективности. В java 8 вот появились streams. Вроде бы всё хорошо, только на реальных задачах это работает жутко неэффективно. В разы медленнее чем с традиционным нефункциональным подходом. И чем больше операций, тем больше разница. И это на java, в которой всё завязано на GC по умолчанию, а сам GC зрелый. Так что не думаю, что в C++ это в каком-то подобном виде попадет. Именно по причине низкой эффективности.

мудреную бизнеслогику (такая есть и на крестах) на Rust реализовывать очень сложно

Почему?

Нет, я не спорю, что в расте ещё много стоит допилить, но интересует твоё мнение.