Hacker News Reader

Comment by rupertlssmith | Hacker News Reader

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.

View on HN

> 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".

It doesn't matter how good a language is in theory if people using it for practical purposes end up having to abandon it.

Reply on news.ycombinator.com