[ambrozk]

It's incredible that on just about every piece I've ever read about Elm since they made that decision, this has been the first, second, and third comment. Wanting to try Elm for myself, I disregarded this advice, and.... immediately ran into the exact same problem! I've never seen such a promising project so conclusively killed by pure developer pigheadedness. And, amazingly, they've never backed down at all. They don't seem to mind that they maimed themselves.

[pavlov]

A purity pledge is very typical of cults. It's both a filter and an enforcement mechanism.

This may not apply to Elm. But I imagine it can feel easier and more rewarding to manage a community that's more like a cult than a typical free-for-all open source project.

[truculent]

I think it’s probably harder and less rewarding to manage a community where you’re constantly taking flak for a technical decision people don’t like (and which those people generally don’t engage with the pros and cons of said decision!)

[savanaly]

Out of curiosity, what did you try to do that you hit that issue right away? I've been writing Elm apps as side projects for years, and never even come close to the kernel thing being a problem. My apps are mostly graphically undemanding games and helper tools. What are the types of applications where this becomes an issue right away?

[lolc]

In my case, it was a regex supplied by the user. Elm 0.18 had no support for constructing a regex at run-time. So I made a package that wraps native RegExp. When 0.19 was released, I couldn't upgrade because of those 5 lines. The regex package eventually got regex.fromstring(). So I could've upgraded. But at the time I was bumping against limits accessing Intl and I really hated the prospect of begging some maintainer for access to a browser api.

Elm was the most fun I ever had developing a browser app. Then they decided I shouldn't be allowed to develop a ShootMyFoot module, and it stopped being fun overnight.

[marc136]

> So I made a package that wraps native RegExp. When 0.19 was released, I couldn't upgrade because of those 5 lines. The regex package eventually got regex.fromstring(). So I could've upgraded.

The last commit to the regex package was in May 2018, and Elm 0.19 was released later in August. https://github.com/elm/regex/commits/1.0.0/

So it seems like by the time of the official release you could have replaced your five lines with `Regex.fromString`.

But the missing Intl API is definitely a huge pain, and I understand that you were switching away if you needed it extensively. Or expected to want other sync APIs wrapped.

A common way to solve something like this is with proxy objects like in https://github.com/anmolitor/intl-proxy but it does not give access to every feature in a nice way.

I went the route of least resistance and built the Elm compiler without the Kernel code check. But in the past few years I hardly needed that anymore.

[lolc]

Thanks for the correction regarding the Regex timeline. Git commits are generally more reliable than my memory.

[savanaly]

Yeah, I really feel this a good way to divide developers into two types. There are those like me, to whom the philosophy of discourage foot guns systematically sounds kind of brilliant. To put it in flattering terms, it's pay a short term cost for the long term and hard-to-perceive but very real benefits (making certain categories of errors completely extinct). To put the other side in flattering terms: they're not letting the perfect be the enemy of the good, and never compromising on their vision because the tech is holding them back. I think the latter is definitely dominant in the discipline. I'm glad that at least Elm carries the torch for the former though.

[lolc]

The Elm people themselves worked with the impure browser api all the time. They just don't want me to do it. So it's not even a foolish consistency but just base gatekeeping. Turns me right off.

If you want to divide into two camps how 0.19 was received I'd say it's people who were maintaining a substantial Elm project on the one side and people who weren't on the other. Maybe if you're carrying a torch don't drop it on the ecosystem.

[fulafel]

As a Elm non-user, naive question: would it be possible to use the JS interop (ports) for this, at cost of some clunkiness?

[marc136]

Yes, ports or custom elements are the recommended options, https://github.com/elm-community/js-integration-examples

There are a bunch of other options/workarounds/hacks depending on the need. E.g. using getters or creating proxy objects https://github.com/anmolitor/intl-proxy, or event listeners, or postprocessing of the generated JS code, but those shouldn't be the first idea to reach for.

[lolc]

Yes the answer is always ports when this topic comes up. Unfortunately one can only pass some basic types through ports. Passing a RegExp or an Intl.DateTimeFormat is not possible. It needs a wrapper on the Elm side, and the Elm people decided I can't be trusted to write this wrapper for me.

Back then if I wanted to search a list of strings for entries that match a regex supplied at run-time, I'd have to pass the whole list through a port, filter it outside, then pass it back in. Rather than just using the filter function. Ports are asynchronous messaging which means I have to restructure the whole code and wait for a state change when the filtered list is returned.

Let me cite the Elm docs on ports[1]: "Definitely do not try to make a port for every JS function you need."

So! Where does that leave me? Unsupported, that's where. Because I need a JS function. In 0.18 unsupported was fine. They broke it for 0.19 and the project died. Maybe it was dying of other causes anyway, but that one action sure drove people away.

[1] https://guide.elm-lang.org/interop/ports

[matsemann]

Most likely they didn't understand Ports and immediately wanted to reach for kernel stuff.

[ghusbands]

It's odd and rude to declare someone incompetent from so little information. Especially when the same problem is widely reported by other developers.