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.
> Elm was better without custom kernel modules and sync JS-interop.
That may be true, but what would have been even better is never having the feature, as opposed to adding it, allowing many people to become dependent on it, and then taking it away. (Like everyone else, I'm not claiming Evan should not be able to make such changes -- just that making such changes will breed predictable resentment.)
> It kept the Elm kernel small and portable.
This is a good thing.
> It forced the 3rd party package eco system to innovate and create things rather than just wrap existing Javscript libraries.
This is a bad thing, presented as a good thing. Boring as it may be, if wrapping an existing piece of working code does the job with no downsides then it's always better to do that than reimplement it for reimplementation's sake.
Custom kernel never was a feature the language had. It was an implementation detail that people discovered they could hack, but it was never meant as a feature.
> It forced the 3rd party package eco system to innovate and create things rather than just wrap existing Javscript libraries.
Writing everything yourself is not innovation. It's busy work.
Sure it's a good way to learn a language, but when you just want to build an app why would you build yet another searchable select when there are more than enough JS options already available....
IMHO this busywork is (mostly) preferrable, because it meant that any package was truly pure Elm, and you could blindly trust it not to be some wrapper that crashed at runtime.
It's a tradeoff, sure. But this way, Elm didn't become just another "JavaScript with better syntax".
Good to know. I built https://github.com/pairshaped/hypertea to get some of Elm's safety in typescript while being easy for LLMs to use (this is basically just hyperapp in TS, with added elm-like guardrails). Maybe I'll go back to Elm now that LLMs are handling it better.
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.