[flagged]
The change was handled extremely poorly. I only knew one team using Elm in production at the time. They went from being huge proponents of Elm to recommending against it after the 0.18/0.19 changes and drama upended a lot of their work.
There may have been a "right" way to do things under the new version, but breaking major functionality in a minor release without warning is a sign that you don't really care about your users. Changes like this require discussion, warning, and long transition periods.
It was bad enough that they got it wrong, but then Evan doubled down by dedicating the opening of his next conference talk to mocking the users who were unhappy about the changes: https://www.youtube.com/watch?v=uGlzRt-FYto
The part where he mocks a commenter for asking "Is Evan killing Elm's momentum?" is weirdly prescient, given that these events ultimately did mark the slowdown of the Elm community. Elm development came to a near halt about a year later.
> And it being open source means nothing stops you from forking it and adding your own native modules. Reason no one has done it is it's no need, and doing thinga that way would break the promises the compiler makes about no runtime bugs.
I disagree. Maintaining an in-house fork of a compiler just to accomplish what could be done with past versions isn't a reasonable suggestion. The reason people weren't maintaining in-house forks of the compiler just to keep their projects going was because that's a silly thing to do when you could just use any number of more reasonable mainstream projects that don't require such extreme lengths.
It's weird to see people casually suggest "Just maintain a fork of the compiler" as a reasonable solution.
0.19 also coincided with a reorganization of the GitHub repos which happened to scrub all past issues, PRs, and discussion. A more stringent moderation policy was also instituted on the official forums which forbade discussion of potential forks, unapproved workarounds of the new limitations, or any criticism which was seen as too harsh.
> The part where he mocks a commenter for asking "Is Evan killing Elm's momentum?" is weirdly prescient, given that these events ultimately did mark the slowdown of the Elm community. Elm development came to a near halt about a year later.
Wow, that was hard to watch. He takes people being passionate about Elm and discussing potential issues and mocks them.
If I was a proponent of Elm that felt uneasy about its direction at the time, this would have made it easy to walk away from.
I’m not sure if it’ll go anywhere but I like the idea that it’s interoperable with existing JS/TS packages.
Compilers are supposed to be boring, especially when your language has ~exactly 1. If you can't trust the people maintaining it, it's too much risk to take. Having to do an entire rewrite in a different language can easily kill a company or a project.
No, it's because one of the core team members made threats against everyone who said they were thinking of forking it: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#forka...
Long ago I went to a local Scala unconference. At the time there were at least two popular web frameworks, and one of the authors was in attendance. [1] Chatting during one of the breaks, I asked him some question about his framework, something about testability of apps. He quickly grew enraged and shouted at me. I slunk off, wondering what I had done wrong.
At the bar after the conference, a few different people apologized to me for his outburst. Not him, mind you, just other people. I was like, "Aha, I recognize this. He's a missing stair." [2] He was clearly an asshole to people on the regular, but the community just put up with it.
That was the last time I went to a Scala event. Life's too short to put up with bullies, or people who accommodate them.
[1] I no longer remember which framework or which author.
The question is how they do react once they've figured it out, and Scala's come along in leaps and bounds in that regard.
If anything, you should be more wary of groups that haven't yet dealt with that problem, because they've had no chance to develop the relevant antibodies yet.
I mean, I get it, if you have a bad experience with X, it's going to colour your perceptions going forwards, being human be like that - but similarly to throwing away a dice because you rolled a nat 1 with it at an inopportune moment, it's far from the most rational response available to you.
Did they really clean things up? Or is it just talk about how things have changed? The way to find out for sure is for me to spend time in the community. It could be better, or the abuse could just be better hidden. And honestly, given the revolution in recent years in codes of conduct and DEI, I suspect my odds are better with newer communities, as there are now plenty of "antibodies" out there.
But all this tickled my memory. Wasn't their an FP advocate who was also an abusive jackass and far-right kook just a few years back? Yes, yes there was. And gosh, what community was he prominent in? Scala. So if I had waited 5 years and given Scala another chance, I would still have landed in a community where there was significant support for abusive behavior.
Maybe he was booted in 2019 or so? Hard to tell from the web. From his tweets, it look like he has crept back in. Is that because he and Scala are worlds better? or is it just the usual missing stair routine that I observed more than a decade ago? I don't know, can't tell, and won't be finding out, because there are plenty of other technologies for me to pick up.
A lot of that stuff can easily just enable a different set of broken stairs though.
Crafting a code of conduct such that it makes it easy to deal with both reactionary -and- wokescold flavoured bullies is something of an art form, and I've seen a number of communities manage to completely fail at one of the two albeit usually in a very well-meaning way.
Antibodies are great up until they give you an auto-immune syndrome, basically.
(I definitely saw the far right kook get defenestrated, though the community may still be sufficiently quokka to've let him sneak back in through a different door, I'm mostly an observer here - and mostly only looking at all because as a veteran code of conduct advocate I tend to find the various failure modes worth examining)
So "I've just demonstrated how it was [...] a reasonable heuristic" is simply unsupported here. If it's working for you, great, maybe you're encountering a different subset of communities than I am, maybe you've been lucky, maybe I'm simply dead wrong, but getting Elm-maintainer-style passive aggressive over somebody pointing out logical flaws in the underlying claim as to why the heuristic is 'proven correct' is a rather unfortunate way to respond to what was written as constructive criticism of said logic.
Some folks propose web components but that’s another can of worms. Increase in complexity and still no help from compiler.
Why not? Is it code complexity or runtime inefficiency you are referring to?
Let's say that on desired page, you have three components with dates somewhere - date of article, dates of comments below and date of last login in the header.
After some user action, you navigate to this page. In Elm terms that mean your Model updates and then your rendering functions will run.
Only then you can see that you need to format dates - your rendering function should be responsible for formatting.
Rendering function should be synchronous - so you need to return some string for date - "loading state" or default format. So user gets "flash of unformatted date".
Now, you should somehow communicate with Port - that mean, send asynchronous message "format this date for me". (And sending messages in render function is not something really supported out of the box in Elm)
Then Port comes back with response, you need to put this formatted value in your global Model (some kind of Dict from unformatted to formatted dates?) and that triggers another render with formatted value.
In summary: - you have multiple render loops where one would be enough - you pollute your global Model with junk that could be easily derived - you introduce latency in rendering because Ports are asynchronous
Ports are great for interaction - user clicks something, you can send command and wait for response and update your model. But there are a lot of cases where you want use synchronous, pure function from Javascript like Intl API.
I understand that it is hard for a software developer to accept that these things need to be reimplemented, but it also seems to be a natural consequence of "up-typing" an entire eco system.
I studied formal techniques for PL. A large portion of the work was in reimplementing existing things in Coq, HOL, etc. Not particularly interesting, but necessary to reach a mature ecosystem.
I do undestand that this makes it a no-go for a lot of people until these things have been implemented. This is also natural.
Reimplementation of i18n API in Elm would make sense only if benefits from types could outweigh robustness of browser implementation. Due to not very expressive Elm type system I really doubt that. You can’t capture intricacies of i18n in Elm type system.
I have more confidence in already tested and used by millions API in the browser than in reimplementation in niche language.
Elegant solution would be if I could write well typed layer that calls browser API. Low bar of entry would drive adoption and in effect real world test. But that’s not possible anymore.
Not if your goal is correctness.
Again, it is completely OK that Elm is not your choice if it does not align with your values, which appears to be the case.
Could you define correctness in this context? I'm asking because I don't believe that you can achieve correctness using Elm type system. I don't see how you can encapsulate i18n rules inside Elm type definitions. Maybe something like Coq could do this ...
You can't express something like "if passed 3 as group size, integer part of the number should be represented as string with separators between three digits". Even in Elm that's something that you need to handle not in type system but in runtime code.
What is more - many core packages are just this - typed layer over browser API. elm/regex introduce barely any type safety. It assumes that browser API is "correct".
> Again, it is completely OK that Elm is not your choice if it does not align with your values, which appears to be the case.
I often see this response from Elmers but really I don't understand the point of it. I responded to claim that Ports solve all problems. I provided good, real example where Ports are a bad solution. In return I was scolded that I don't understand software engineering.
I don't jump into elmconf and complain or demand changes. I just provide my take on the discussed issue. And to be frank, I think that's very valuable take for someone who decides if Elm is good for them. That kind of information is not present on elm homepage and is not obvious for new users.
First, I don't write any serious applications in Elm, and would never do it. I don't find that it is productive because of the reasons you list. Just as I would never write any serious applications in Coq.
But with Elm, as with Coq, I can appreciate that their goals are not immediate developer productivity. Maybe some day when the ecosystems needed are fully implemented. Until then I just applaud everybody working on systems that are strongly typed and ensure that all their dependencies are.
I believe this will provide tremendous value – when ripe.
And mind you this is a front end tool.
They did a big change of stuff that people depend on, without consulting the community, and then doubled down, threatened people that wanted to fork, all with a weird passive-aggresive tome.