rupertlssmith

And then there are sealed DSLs...

Byte encoder/decoder in Elm are opaque, so their implementation is hidden. A smart compiler, such as the one I am writing, can take advantage of that with compiler intrinsics that replace the implementation with something that the compiler itself optimizes.

Yes. But that is about to change, and the compiler is now getting the updates it needs.

Mostly the compiler was fine, we could do with some bug fixes in core packages - not many, but there are a small number of long time bugs that should really be sorted.

Elm was better without custom kernel modules and sync JS-interop.

It kept the Elm kernel small and portable. It forced the 3rd party package eco system to innovate and create things rather than just wrap existing Javscript libraries.

It has enable me to port the small kernel now to C++ for an Elm to native compiler.

Also, if you really wanted to bypass it and have your own kernel, that was always possible and not hard to do. Even in 0.18 custom effects modules could not be shared on the official package site.

Worth noting there are some Elm to native code compiler projects now.

LLMs are way past that, Claude Code can very competently write Elm code now, for example.

I think you got your onion the wrong way around. Inner layers more constrained, outer layers less - working out from Entities in the middle.

An inner layer that permits lots of invalid behavious is akin to building a house on sand. Even Jesus had a parable about that!