The only reason I didn't write more stuff in D was that the stack traces from my programs were pretty much useless. Maybe I was supposed to set a --better-stack-traces flag when I compiled it or something idk.
[1] One of the algorithms used by https://github.com/TOGoS/PicGrid
Scala gets pretty close to LISP-level of metaprogramming support between its intrinsic support for macros[0] (not to be confused with the C/C++ preprocessor of the same name), the Scalameta project[1], and libraries such as Shapeless[2].
Not comparing Scala to D, just identifying a language with similar functionality.
0 - https://docs.scala-lang.org/scala3/reference/metaprogramming...
That being said, I can't think of many scenarios in which an application where user-code is all `@nogc` would be hindered by occasional GC'ed stdlib methods.
One standout example of viability is the "dplug" library for realtime audio processing plugins and the commercial AuburnSounds VST's written by the author.
That's one of the craziest things I've heard here. These two languages sit at opposite ends of abstraction.
In D, you can write Python-style slop code and/or C#-style slop code. Two very different styles of slop code, both of which can be written in D. Or even mixed and matched.
Gives what you wished for. It's functional, though (among other things). Unlike most lisps, (dependently) typed. But hey, available at compile-time.
Cannot recall any longer if the original article on the matter appeared on The C/C++ Users Journal or Dr. Dobbs.
Eventually it started to get abused and the Turing completeness has been discovered.
Since C++11, the approach to a more sane way to do metaprogramming with templates has been improving.
Instead of tag dispatch, ADL and SFINAE, we can make use of concepts, if constexpr/eval/init, type traits, and eventually reflection, instead of the old clunky ways.
http://web.archive.org/web/20131101122512/http://ubietylab.n...
Via "Accidentally Turing-Complete":
Computing things using templates is not intuitive. Many of us have gotten used to it - but that's because that's all we had for many years. It's a different sub-language within C++. As constexpr capabilities widen, we can avoid "tortuted" templates and can just write our compile-time checks and figurings in plain C++ - more or less.
Sometimes, enhanced language features in C++ allow us to actually throw away and forget about other existing features, or at least - complex and brittle idioms using existing features. Like SFINAE :-)
With C++23 can be made relatively readable, and with the right compiler, builds within sensible timeframe.
I've seen the vast majority of build time in a very large C++23 project be taken up by reflection in fmtlib and magic_enum because both have to use templates (I think).