Live data from Hacker News

Why I’m Leaving Elm

lukeplant.me.uk

331–340 of 450 posts

Re: Why I’m Leaving Elm

#331

Earlier quoted context omitted.

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 depende…

I agree that opionated frameworks can reduce complexity. I was Rails for a very long time. But moving to a new language that you can't hire for seems like an extreme reaction to "our config is complex". One good thing about a mainline technology like TS is that thinga get attention. Manual config today may be supported feature in the future.

Isn't the real risk, in moving to a fringe frontend framework, not just that you can't hire, but that you run into some roadblock you just can't get around? That you have some abstraction leak or messy interactions with JS?

Re: Why I’m Leaving Elm

#332

I believe Elm took some major missteps. Despite doing so many things right with the initial designs (and still one of the best designed front-end experiences) it never grew much beyond the early adopters and it basically remained a fun hobby language. I criticized the basic lack of communication and the infrequent updates in r/elm (I believed these infrequent updates were going to kill the momentum of Elm). I was con…

I also eventually came to the conclusion that elm Will be forever niche and can’t become a mainstream language. I agree with so much of what Evan says in principle, but every time the project development style is criticized, someone pastes a link of Evan basically telling everyone to sit down, shut up, and wait. Which is Evan’s right, but rhetorically speaking, this is horrible. Just a little charm can go such a long…

He's quite charming in person, FWIW, and he has great language design sensibility.

Re: Why I’m Leaving Elm

#333

> For example, if there is a bug in any core library, or something missing, you just have to wait for the core team to fix it, rather than being able to fix it yourself. You might need a performance fix, which can be done using Javascript but not in Elm (lack of destructive updates makes some things very hard to implement efficiently), and again you will be stuck having to explain to your boss “I know this is possibl…

This perfectly describe the situation. While it is possible to do it yourself in Elm without the update, it is quite hard and cumbersome to do so. It is much easier to make a PR, but Elm core team is purposely relationship and personal-trust based, any random PRs will not get accepted in foreseeable future.

Re: Why I’m Leaving Elm

#334
post #253
post #182

Earlier quoted context omitted.

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

Oh please, maybe if all you're doing is reading hackernews articles. The language hasn't really changed that much in the last few years. The only major feature is async/await.

Rust is a complicated language and still has a very long journey ahead to prove its worth, I have yet to see it being used extensively in Mozilla to re-write Firefox which hasn't happened yet (may not happen as replacing C++ with Rust is a nightmare given most useful systems code is still either C or C++).

Hopefully zig [1], picks up. It's compiled code is smaller and better in performance compared to Rust and also provides a mechanism to write safe code with allocator choices. Also the overall zig language design fits in brain as the grammar is not complex unlike Rust which has a steep and complex learning curve. Rust developer spend a lot of time learning language feature and fighting with borrow checker syntax and still need to rely on unsafe C library to do anything useful. Zig made a conscious choice to make it work with C and realize it needs to work with C rather than replace it unlike Rust which is relying on C and still trying to proclaim as C replacement, when its not yet ready.

[1] https://ziglang.org/

Re: Why I’m Leaving Elm

#335

Elm has a bus-factor of 1. https://github.com/elm/compiler/graphs/contributors I feel quite uncomfortable hitching my wagon to a single developer who owes me nothing.

Why are the most recent commits about implementing an endpoint to receive donations for his foundation? Why would you want that in a compiler?

Re: Why I’m Leaving Elm

#336
post #48

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…

If you feel the same way about the Elm project as the author of the article does, you won't be happy with Clojure[script] either. Its community already went through this drama and all the top community contributors(or that at least tried to contribute) left.

Regarding

>all the top community contributors left

Please don't pass on misinformation.

Re: Why I’m Leaving Elm

#337

This criticism is spot on; it is exactly what I observed in late 2018, early 2019 as well. It's an awesome language, but there is basically a big case of 'vendor lock-in'. Certain compiler features are only available to the maintainers, nor is there any way to use alternative package sites. I don't want to know what would ever happen if the Elm developers decide to take https://package.elm-lang.org offline. That will…

> This criticism is spot on; it is exactly what I observed in late 2018, early 2019 as well. These issues were obvious much earlier than that. I looked into Elm and was excited about it initially, in either late 2013 or early 2014. Then I looked into the history of some of the design decisions that baffled me (such as lack of type classes) and concluded the project was poorly conceived and led. The leadership didn't…

> The leadership didn't respect the opinions or capability of its end users

This was the major sticking point for me when it came to Elm. I invested a lot of time into Elm and even published a few packages. Many things contributed to my giving up Elm, but the final straw for me was when the core team removed some userland APIs under the guise of "we can't trust developers not to use these to write bad code". Myself and several others tried to convince Evan to reverse this decision, to no avail.

Re: Why I’m Leaving Elm

#338

Earlier quoted context omitted.

I also eventually came to the conclusion that elm Will be forever niche and can’t become a mainstream language. I agree with so much of what Evan says in principle, but every time the project development style is criticized, someone pastes a link of Evan basically telling everyone to sit down, shut up, and wait. Which is Evan’s right, but rhetorically speaking, this is horrible. Just a little charm can go such a long…

He's quite charming in person, FWIW, and he has great language design sensibility.

I don't doubt it. FWIW, I was really impressed with Elm the language.

But I don't see how their current messaging can possibly be working for Elm's benefit. It feels like the PL equivalent of a politician who refuses to shake hands or take selfies. I don't think it requires Elm or Evan to make any technical compromises just to be a little less off-putting.

Re: Why I’m Leaving Elm

#339

Elm has a bus-factor of 1. https://github.com/elm/compiler/graphs/contributors I feel quite uncomfortable hitching my wagon to a single developer who owes me nothing.

Why are the most recent commits about implementing an endpoint to receive donations for his foundation? Why would you want that in a compiler?

I took a look at Elm a couple of years ago and while I was intrigued I simply couldn't consider using Elm in any serious endeavor. Not because it isn't capable, but because the risk of it dying if/when Evan stops working on it (for any myriad of reasons.) Yes someone could fork it, but that doesn't ensure it would continue to be well-supported.

Remember RethinkDB? When they shut down, the software was open-sourced to much fan-fare, but for all intents and purposes it appears progress has come to a screeching halt: https://github.com/rethinkdb/rethinkdb/graphs/contributors

Elm is unfit for any commercial software project IMO as long as it remains a one-man show. I (like everyone else) have limited amount of time to learn new tech, and despite Elm's technical merits - it's not worth sinking any time/effort into it at this time when other more viable options exist.

Re: Why I’m Leaving Elm

#340

I don’t use Elm. But I have watched several of the founder’s talks about different subjects. That is to say, I have a half decent idea as to what the ‘native modules’ issue means. I think Luke’s issue is that under the newest release Elm is requiring that no code contain any ‘raw’ JS or it won’t compile. It seems like this was an option prior to the current version so is this basically like if the Rust team said as o…

> issue is that under the newest release Elm is requiring that no code contain any ‘raw’ JS or it won’t compile. It seems like this was an option prior to the current version so is this basically like if the Rust team said as of the new release no code, other than that code coming from the Rust team may use ‘unsafe’?

Yes, the problem is similar. It can be considered worse, because in safe Rust you can do almost everything, but Elm is much more limited.

You can still use regular JavaScript with ports, but it is more complicated. It is something like a WebSocket channel, where the server is the JavaScript code.

Post reply on HN