Live data from Hacker News

Why I’m Leaving Elm

lukeplant.me.uk

291–300 of 450 posts

Re: Why I’m Leaving Elm

#291
post #9

Earlier quoted context omitted.

this is, at least, consistent with my experience using elm on a side project. Dropped elm like a hot potato when I hit that wall. frustrating, too, because I was really enjoying the language, and everything about it up to that point. The tooling support for Elm is REALLY solid compared to some other functional compile-to-js languages out there. If anyone is looking for a good functional compile-to-js language, I woul…

My brief experience has been similar. Elm is a dictatorship that could be wonderful if it didn't exist in the realm of messy html/js. I experience an icky feeling of stockholm-syndrome part of the time, and just plain frustration at other times when dealing with Elm. What's infuriating is that I do see the benefit of some degree of strict stewardship. It's just that it's too much in this case.

I think Clojure is actually a good example of strict stewardship that works well

Re: Why I’m Leaving Elm

#292
post #213
post #180

Earlier quoted context omitted.

> I guarantee nobody truly cares that you fork Elm. One of my coworkers once edited the elm compiler to remove the native code restrictions, and placed it on NPM. Evan emailed him and asked him to take it down. There may be more to the story that I don't know, but from what I know it sounds like Evan does care.

Did he take it down?

Yes.

Re: Why I’m Leaving Elm

#293

Arrogant is the most accurate word to describe Elm and its leadership. I tried to use Elm in production between 0.14 and 0.18 versions and it was fun and mind expanding experience. I'm truly grateful that I've used it because it introduced a lot of functional stuff to me. But I no longer use it myself or recommend it for any serious work. Breaking changes were negligible in the beginning. But I got fed up with rewrit…

Tab width arguments are amusing, because it's always between 2 and 4.

There’s actually a number between 2 and 4. For some reason it's never considered.

I've got a summary of all the indentation arguments here: https://cthor.me/Indentation

Re: Why I’m Leaving Elm

#294

Earlier quoted context omitted.

> This has made me reconsider my intention use Elm in my startup. Choose Boring Technology http://boringtechnology.club/ Seriously, don't use up your startup's innovation tokens on some guy's hobby programming language.

I used elixir for the backend and its paid off in dividends. That said, I had a year of experience working with it so it was boring technology for me at that point.

I use Elm on two large websites in production with users.

Elm helps me come back to these projects after months and, in two cases, a whole year, and get immediate work done without recredentializing in the whole codebase (which I have to do with my React projects to a greater extent).

You definitely can't be a fragile developer to use Elm, and I think the small community size makes people feel like others are obligated to listen to their opinions. Meanwhile they don't expect this from an ecosystem like React because they know nobody is going to listen to them, the ecosystem is just too big with too many people with hobby horses.

I've patched the compiler one two occasions for the 0.19 release. One was to allow me my Debug.crash calls. Elm is updated so slowly that it's trivial to maintain your own patch. Though I ultimately factored out my two patches.

While TFA makes some good points, just like I can enumerate the downsides of all technology that I use, a large bulk of it is just emotional catharsis. And I think this kind of exodus is a good thing. A lot of the people who supposedly leave stick around like a turd circling the drain just to give their aggressive two cents any time something negative can be said about Elm. I've always felt that to be most tiring of all. Kind of like the people who show up in every Typescript-related thread to say how static typing is for lazy developers and what not.

Re: Why I’m Leaving Elm

#295
Although the particulars are unique, this seems to be another problem stemming from what I like to call "Having Your Open Source and Eating It Too Syndrome". Namely, it seems to me that the authors don't actually want an Open Source project (or perhaps more accurately a Production-Ready Open Source Project). They may certainly want many of the advantages that Open Source brings, but are upset by what I think are honestly completely predictable consequences from not living up to the, regrettably for lack of a better word, "responsibilities" of Production Open Source. I say regrettably because I don't want to get into an argument about what is actually "owed" -- I agree no one entered any contract or whatever. All I'm saying is if you put in the work to convince someone that something is production-ready, and convinced them to stake their livelihood on your project, then it shouldn't be surprising that they are upset when you prioritize abstract principles or decisions over their ability to ship. Again, I'm not implying you should be forced to have a process or do what they say, just don't be surprised when your users get upset, and then on top of that accuse them of "entitlement".

There's a lot of convenient, and perhaps subconscious, confusion of terminology in technology. For example, people can point to the fact that a project isn't 1.0 yet and argue "well you should have known anything goes pre-1.0". But Linux was amazingly solid prior to 1.0, and even the term "Beta" has been watered down by Google's infamous insistence of using the term for ages on their software. I'm not saying you have to agree with the watering down of technical meaning, but you should understand the unfortunate reality that a lot of this is mixed signaling. For example, a common one is "It's beta but we use it in production and it works great!", which if you break it down is kind of a used-car-salesman technique. It's saying "I've created plausible deniability for myself so that I owe you nothing, but the final thought I'm going to leave you with is an emotionally manipulative statement that wink wink it's really ready to go".

Similarly, if you have a fancy landing page telling people why your product is better than other production-ready products, for example Elm compares itself against Angular, React, and Ember, then you are strongly implying you are a peer. So even though the words "production-ready" don't appear on the page, there is a strong implication here. There's certainly no asterisk anywhere saying "pre-shipping numbers", something that game trailers will even do. Again, I don't think this is intentionally deceitful, I think it's supremely easy to accidentally run into this sort of messaging. But you should absolutely be mindful of this and work against this.

Luckily, this is all fairly avoidable if you're willing to take some simple steps. For example, just say "this is a toy project" or at least "We absolutely do not recommend this for production", or even "the primary purpose of this project is for researching ideas that interest me". That can completely avoid any miscommunication and sets expectations up correctly, and furthermore puts you 100% in the right in the event that someone ends up relying on your code... But no one wants to do that because it hurts adoption! This is what I mean by wanting to "Having Your Open Source and Eating It Too". You want to portray an amazing product that does everything well AND is a happy community, while reserving the right to treat it like a side project whenever you want.

Re: Why I’m Leaving Elm

#296

Earlier quoted context omitted.

May I ask, how are you doing i10n?

We do internationalization at Cambiatus. Here's our front end code so you can take a look: https://github.com/cambiatus/frontend

Thanks. That's pretty cool. But I guess I misspoke, what I meant to ask was how are they doing stuff like this: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I.e., date/time formatting, number formatting, and so on.

Re: Why I’m Leaving Elm

#297

I find it fascinating that the author is leaving one fringe language with a small community for another fringe language with a small community- in this case Bucklescript. I've never found the productivity benefits of these JS alternatives worth the risk and cost. There is an understandable desire to move away from the messy reality of JS and it's browser friends, I get it. Having written many thousands of lines of Co…

The upsides make more sense if your Webpack/JS tool chain was growing out of hand. For example, once you take on Typescript, you take on quite a bit of idiosyncrasies. And your Webpack config may grow pretty large over time. We have some hacks in our Webpack config just to avoid some thing like double ESLint/TS evaluation. And it all can start to feel quite precarious. We even found bugs in Webpack's circular dependency plugin.

Meanwhile, Elm does a lot of this right out of the box. There's a point where you may be easily reducing complexity and idiosyncrasies by using a tool like Elm.

Re: Why I’m Leaving Elm

#298
post #182
post #103

Earlier quoted context omitted.

You'll find examples on both sides. Rust is a great example of a successful language growing in the open.

Really growing, so much that it's kinda hard to keep up with

You shouldn’t take your opinions on things from HN discussions that claim that Rust is changing quickly, and then are only able to point out 3 things over 5 years that have changed.

Re: Why I’m Leaving Elm

#299
post #141

After reading a large number of the responses here, I feel like I've noticed a pattern - two types of comments: 1) I've used the language and agree with the conclusions of the post even if I don't necessarily agree with every point. 2) I haven't used the language, but I believe open source projects must be maintained by their maintainers as they see fit. I actually agree with both of these positions, but, having used…

I think there’s also a third category, which is “I’m interested in Elm / have dabbled in it but all this puts me off ever using it for anything serious”.

If the comments in this thread aren’t ringing red alarm bells for the Elm leadership I don’t know what will, frankly.

Re: Why I’m Leaving Elm

#300
post #221
post #195

Earlier quoted context omitted.

I find you're being needlessly formalistic here. The author is explaining where they are coming from. What their understanding and expectations in the open-source world are. This helps to understand their position. That initial part was intended (I guess) to make comments like yours redundant. Because that way we can understand what the author means without guessing about their usage of the term. The article does not…

> What their understanding and expectations in the open-source world are Thanks for putting it like that, it's completely true and I agree. Many people have an understanding and expectation of Open Source that not even the definition of Open Source agrees with ( https://opensource.org/osd ), which is contributing to this problem. That was a bit of the point of my comment. The article doesn't require anything, but in…

The OSI definition is useful as a baseline. When people argue over what open-source means, I think they can mostly agree on that definition. On top of it we see frequent arguments over authors' responsibilities and appropriate stewardship.

Looks like I've accepted that it's a broad term used in a lot of contexts. So having somebody give their angle on it before using the term is already pretty good by my standards. But maybe I'm being too liberal here. What parts do you see people expecting in open-source that go against the OSI definition?

(I can't help but note that you and the author write Open Source with caps which does actually suggest there is a specific meaning.)

Post reply on HN