Hacker News Reader

Comment by josephcsible | Hacker News Reader

In version 0.19, the core team hardcoded a whitelist into the compiler of which projects are allowed to use native code (which happened to basically be the core team's pet projects). This basically crippled the language beyond usability for everyone else. https://news.ycombinator.com/item?id=22821447 https://news.ycombinator.com/item?id=17842400 https://news.ycombinator.com/item?id=16510267

As for a replacement, I'd look towards Haskell. At a language level, it looks really similar to Elm, and it's been having a lot of work done towards being more practical on the Web lately, e.g., GHC 9.6 getting a WASM backend merged.

View on HN

Yep. And the core team has that "happy cult" vibe where they think that if they're (passive-aggressively) polite enough, they don't have to worry about anyone's opinion outside their insular little group. I tried to use it for a little project about a year ago, ran into some problems, and, searching around, found my problems were 1. not unique to me, and 2. were definitely not going to be solved by the language designers, despite a lot of people having the same suggestions. Their attitude is "either you design your app how we'd prefer you to or you don't use Elm at all." This doesn't work in any other technical project, but they think it's going to work for them for some reason.

"Happy cult" vibe is exactly how describe that faux-niceness they throw around. Thanks for coining that phrase.

Honestly, the boldness of the opinions is also what makes elm well designed.

I never really used it, but I see plenty of other languages that are perhaps too much driven by consensus rather than vision.

Opinionation is often useful but it's best implemented with an escape hatch of some sort for when you run into a sufficiently weird situation there's not actually a sensible way to deal with it.

I don't particularly mind if a project holds their opinions sufficiently strongly that they mark the escape match big red letters with "BY USING THIS YOU ARE VOIDING YOUR WARRANTY, IF IT BREAKS YOU GET TO KEEP BOTH HALVES" and then tapping the sign any time somebody asks for support with using it, but it should still -exist-.

The escape hatch is Haskell. The only reason Elm exists is to remove escape hatches from Haskell.

The escape hatch of elm is the ports system to interface with javascript.

Ports is explicitly async and therefore only viable for a significantly limited subset of purposes.

This has been discussed at length elsewhere in this thread, on elm related discussion boards, and in multiple articles.

Ports is the -preferred- way to interface with javascript, certainly, and when its inherent limitations aren't a deal breaker, its being preferred is entirely sensible.

It is not, however, an escape hatch in any meaningful way, hence why people were extremely upset when the actual escape hatch was disabled by maintainer fiat.

I guess I am less strict with what I consider an escape hatch. It does not need to be optimal or follow my preferred method IMHO.

Other than performance I do not see any limitation of the async port system. You can call back from the js side. It is an especial way, I agree, but one that keeps the Elm paradigm intact. It is quite clever. It is "different", but I do not consider that a limitation, but a matter of preference.

I think it's also fine to just say no when people ask for an escape hatch. Say, no and tell them use another tool.

Not every tool, has to solve all problems.

But I do think people should spend more time articulating what their tools don't do, rather than what they do :)

What were those problems you ran into?

Also the fact that their package manager is strongly coupled against https://package.elm-lang.org/. There is no way to override it. This means that if that package site ever goes down, you will be left with an unbuildable project. Seems pretty risky to me.

I mean you should be proxying/caching your repo anyway, non? Even just to save on bandwidth.

It's a lot more fiddly to do that if the package manager doesn't support you doing it. (In fact it might be impossible if it's using HTTPS)

No.

You don't need native code to be productive in Elm. Elm is perfectly useable without it. Use of native code was not widespread before 0.19 anyway.

I would know. I was working on a large native code project that was killed by 0.19. It sucked for me that my project could not continue, but, I can't say that it has made much of a practical difference when it comes to making software applications. My project was called "elm-canvas" and it was about providing canvas support. Since 0.19, other people have found implementations of the HTML canvas element that do not rely on native code (Like Joakin's great 'elm-canvas' https://github.com/joakin/elm-canvas). For my own HTML canvas based software projects, I have been able to find my own non-native code implementations that work pretty well.

So, I think I faced a disproportionate amount of this problem, and I can't even say it has made much of a difference to my own productivity in Elm (and I have written a lot of Elm).

I've never used Elm or interacted with the community but reading some of those posts remind me that the B in BDFL is quite important.

Evan's hella nice. Some folks just really really don't like being told "No."

(There are comments upthread calling the Elm community "happy cult" because they said "no" so nicely!)

The complaints you hear about Elm are pretty much all of the "Evan said no" ilk.

What you don't hear is are actual bug reports, eh? People aren't kvetching about how their Elm apps broke, eh? That silence is deafening, once you listen for it. Elm works. It may be the Easy-Bake Oven of web dev, but the things it cooks are perfectly edible!

(Following that metaphor, most JS frameworks, etc. produce muffins with bits of broken glass in them.)

"Nice" and "benevolent" are not the same thing.

Do you have an actual point to make, or are you just being pedantic for fun?

Some of the most manipulative and self-serving people you’ll ever meet are “nice”.

So, is that a claim you're seriously making about Evan?

- - - -

Not to be arch, but this whole line of discussion is uninteresting to me. I'm glad to discuss Elm, but I don't want to hear unfounded character assassination of a kid who's only guilty of being willing to say "no" to people who want to change his language in ways that he's not into.

From my POV Elm stands as a serious challenge to the entire JS ecosystem. I keep asking, "What's the business value argument for not using Elm?" and no one has a good answer.

> "What's the business value argument for not using Elm?"

The ecosystem of Javascript is vast, in comparison to Elm, which can save time and money (especially now that apparently Elm doesn't allow JS code). JS devs are likely also cheaper than Elm devs due to the high supply. Just two reasons why I as a business owner would still write in Javascript/TypeScript over Elm.

The crucial point is exactly what you're referencing ("his language"). The way that contributions, feedback, and issues were treated was very much not in line with a tool that people depend on for their work. It was in line with a personal hobby project, but the marketing and promotion did not set those expectations. They strongly promoted the project as a tool for use in industry. So your defense is not convincing to me as someone who did try to use this tool in a professional setting where I was accountable to a larger organization for delivering on technical requirements.

People weren't asking to compromise or control the design of the language. They wanted to be able to contribute to the project (usually just first-party packages) in order to have their problems solved in a timely manner or have their issues addressed in some other way. This was usually after having invested hundreds of hours in the language, because the basic golden path was very polished in Elm.

I can only speculate on the reasons why there was this disparity between marketing and reality. Certainly the language gained a lot more interest and community investment than a Show HN hobby project, and some people did benefit from that. I'm not making any specific claims about Evan. The "nice" aspect is relevant because while following the Elm community closely, I witnessed many harsh interactions on the part of Evan and Richard Feldman that were simply wrapped in gentle verbiage.

Here's just one example (check the edit history): https://github.com/gdotdesign/elm-github-install/issues/62#i...

So what I'm not hearing is that Elm didn't work. It worked, right?

Evan and co. just wouldn't agree to let you contribute to solve your problems and issues in the way you would have preferred?

(In re: the "harsh" comment you linked to, I don't know what to tell you. It doesn't read as "harsh" to me, if anything it shows admirable restraint. In any event, I'm not interested in "tone policing" Richard Feldman. I know nothing about him.)

- - - -

I'm one of those people who are like, if you don't like what Evan's doing just write your own, eh?

Meaning no disrespect to Evan and co. and what they've achieved, it's not that hard. It just isn't. Elm-style languages are pretty easy to implement (that's kind of the whole point, yeah?)

It divides the complainers into two groups: those who can write their own but instead prefer to leverage Elm devs via what amounts to various forms of emotional and reputational blackmail; and those who can't but still want to leverage Elm devs via what amounts to various forms of emotional and reputational blackmail. Either way, I personally feel comfortable dismissing their complaints without further consideration.

- - - -

Do you have any technical complaints about Elm? Did it ever break in production? What was the most interesting bug you encountered using Elm? That's the discussion I'd like to have.

This is starting to sound unhinged. You're identifying strongly with Evan but you're also denying how deeply he matters to you. That seems mentally unhealthy.

Are you ok?

Are you? You're making drive-by psychological diagnosis on the Internet. Maybe rethink your rhetorical style?

It's uncool to troll like that. This is a two-day old thread. Were you just hanging around waiting for me to respond so you could troll?

I think anyone can see something is wrong upstairs, man. If that sounds like trolling, I'm sorry. It sucks that HN is your only contact with the real world and I hope you can find something to worship besides Elm/Evan.

Why are you interested in having a discussion on any of this when you can just talk to yourself (i.e., write your own)? It’s really not that hard.

Yes, Elm and its core packages had bugs and critical omissions that were outstanding for years, many of which affected our app. It was a running joke on our team to try to guess the vintage of the extant GitHub issue whenever we ran into a problem. I consciously fled the ecosystem and community many years ago so I don’t remember specifics anymore. And the repos were scrubbed of all past issues when 0.19 was released so we can’t go check either.

If you appreciate implied threats for creating a package which gives people some (unauthorized!) control over their own destiny, then I can see why this comment wouldn’t trouble you. Have fun in the sandbox.

> Why are you interested in having a discussion on any of this...

I'm interested in systems which permit bug-free programming. Elm seems like a step in the right direction, bringing semi-obscure ideas closer to the mainstream. Lot of JS programmers got some exposure to Elm-like FP.

> you can just talk to yourself

I mostly do. (I'm a recluse, this account on HN is my primary channel of communication to the outside world.)

> (i.e., write your own)? It’s really not that hard.

I am writing my own system, and it's really not that hard.

> Yes, Elm and its core packages had bugs and critical omissions that were outstanding for years, many of which affected our app.

That sucks. But really, without any details your vague memories aren't much to go on.

> appreciate implied threats

I'm not sure what you mean, maybe I misread the message. It didn't sound to me like anyone was threatening anyone.

> Have fun in the sandbox.

Thanks! I will.

> From my POV Elm stands as a serious challenge to the entire JS ecosystem.

Lol, OK. Spoken like a cultist. Bad news for you: It's not going to happen.

> What's the business value argument for not using Elm?

The time and energy investment into using any JS code in Elm for things not currently sorted out is severely disproportional to the value provided by Elm. The ROI is just not there. If you compare it to the FFI layer of PureScript, there is no question that it's nice to have validation, etc., but it's just not worth it.

The very restrictive view of packages (where to get them, what you can upload and use, etc.) is also a very obvious deal breaker.

I would be surprised that you find these two things that everyone keeps bringing up not to be good answers to your question, but then I remember how being in the Elm community felt like: "Everything Evan says or thinks we all think". It's the same culty feel that Elixir has a lighter version of.

FYI use double newlines between paragraphs/links, otherwise it shows up as one line.

I completely agree with you, the way the Elm team handled it was not conducive to collaborate usage of their language, it was more like only they wanted to use it fully.

> This basically crippled the language beyond usability for everyone else.

This is not true. You can argue that it was perhaps the downfall in terms of contributions and popularity. But you don't need native code for writing apps in Elm.

You don't need a hammer to hit a nail, but if you hand me a screwdriver I'm going back to Node.

The fact that the maintainers made a whitelist for their projects disproves your point.

"Their projects" were core libraries or experiments IIRC.

Does this still assume a separate TypeScript/React frontend or the like, or can you actually do the whole frontend in Haskell?

Reply on news.ycombinator.com