Hacker News Reader

Comment by josephcsible | Hacker News Reader

tl;dr: the Elm compiler has a hardcoded whitelist of projects allowed to use certain critical language features, and anyone who releases a fork of the compiler without that antifeature gets banned from the project's community.

View on HN

Appreciate it. I got through about 10 paragraphs of preamble and disclaimers before giving up. I’m sure this document is what the community and author need it to be, but only being interested in the technical takeaways, your comment at least helps me know what to skim for.

Weird. Why can’t you patch your local version to include the name of your project?

https://youtu.be/E99FnoYqoII?si=r22RK3xy3NJoDnQr

That's a poor analogy. Rails has always had "here's a sharp knife; be careful with it, but you're an adult so use it how you will" philosophy. So Rails comes with recommendations for use, but not mandates.

if your project is a library no one can use it without a similar patch

This may be a good summary of the blog post, but in my opinion it is an uninformed understanding of Elm and Elm's history. JavaScript FFI isn't and never has been a "critical language feature". Rather, people discovered an implementation detail that allowed them to create thin Elm wrappers around JS libs (think Elm interface for d3, leaflet, moment, etc...). This was (rightly IMO) seen as undesirable for multiple reasons and 0.19 closed off the loophole at the compiler level.

As for being banned from the community, I keep seeing this claim but have never seen or heard of such things happening. Sure, there may be a negative reception to folks who keep wanting to re-litigate a decision that was made over and over, but nobody has been banned from anything.

Yup, that's a failed language.

That burns any interest I ever had for looking into Elm.

The language features in question are, to my knowledge, unrestricted JS FFI and adding infix operators. Banning the former completely removes a whole class of security vulnerabilities. Banning the latter means you can't be as terse as you want but new authors in a codebase don't have the problem that new authors in a Haskell codebase can have. So they're both tradeoffs.

So why hasn't anyone set up their own hard-fork community a la neovim? Just not enough interest in it?

1. In open source, everyone plays lip service to how you can just fork things, but nobody wants to do the hard, infinite work of building a new ecosystem. You'll just rediscover the exact thing that burned evancz out.

2. Elm's stance on sync vs async ffi isn't a big deal. A fork is like when there was that IcedCoffeeScript spin off on CoffeeScript: https://maxtaco.github.io/coffee-script/ -- it's more of a gimmick in what is already a tiny ecosystem.

3. Last I checked there was "elm-janitor" for managing patches and getting them into core Elm as an end user or something. Dunno what came of it, but I think it goes back to only a handful of people are going to use something like that. And there are already Elm-inspired languages with ~0 users out there. The hard part is ecosystem.

It's not like Javascript where you can launch something like preact (react but smaller) and get 38k github stars. It's not going to be rewarding.

The community is small enough that it wouldn't make much sense.

Reply on news.ycombinator.com