Hacker News new | ask | show | jobs
by cyber_kinetist 1470 days ago
Out of all the new shiny low-level languages, people seem to praise its strong compile-time metaprogramming facilities. Though the compile-time execution engine in D is still a tree-walk interpreter (very bad performance/memory usage), unlike in Nim and Jai where they use a much faster bytecode interpreter for the evaluation.
1 comments

The compile time execution itself is just one piece of the puzzle, the other two being compile time reflection (which I think is actually the key piece) and the built in code generation.

Running functions alone is not that interesting, and neither really is generating code. You can do those (arguably better for some cases) with helper programs as a separate build step. But reflection is non-trivial to do externally, so that's the biggest value add, and using it with all three pieces let you close the loop.

Agree with this, Zig and Jai seems to be the most ergonomic in this area (types can be checked and manipulated in compile time as easy as values in runtime).

But what I’ve mentioned is also very related to the ergonomics of compile-time metaprogramming, since these techniques are all useless if it severely increases builds times up to the point that developers have to use it sparingly. Only Nim and Jai has fully gone the route of using a bytecode VM for compile-time evaluation, while D had a similar project back in 2017 that was abandoned, and for other languages (C++, Zig, etc.) it’s still in the planning stage.