
Why I’m Leaving Elm - neillyons
https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/
======
salimmadjd
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 concerned that it made the language seem stagnant.

Immediately, after posting it was clear it was a major concern by others as
well. So what did Evan do with that criticism? He spent the opening part of
his European talk mocking it [0].

I didn’t take it personally, but it illustrated the kind of mindset Evan has.
A good leader would have asked questions about why many feel that way and
would have instituted a process for more frequent updates. It became clear to
me, outside of being brilliant at designing Elm he is not the person to take
it to the next level of adoption. If it’s not moderately adopted it won’t make
sense recommending it for any production project, even if it does many things
right.

To me it feels like (sadly) Elm will just be a hobby project despite what it
could have been.

[0] [https://youtu.be/uGlzRt-FYto](https://youtu.be/uGlzRt-FYto)

~~~
jaredklewis
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 way.

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

~~~
amw-zero
Sounds like that’s a complete facade though. Plenty of people are overly
polite because it inflates their ego to be perceived as polite.

And the article isn’t talking about politeness so much as openness. Which, the
Elm team seems very very closed off.

~~~
nathanasmith
>Plenty of people are overly polite because it inflates their ego to be
perceived as polite.

Can you point me to some article or rigorous paper that would help me take
this claim seriously?

~~~
hitekker
I think the idea that most people are nice to some people, and not nice to
others is a generally accepted premise.

~~~
nathanasmith
>I think the idea that most people are nice to some people, and not nice to
others is a generally accepted premise.

Nothing I said implied I disagreed with that "premise" and it seems bizarre
how what I did say could somehow lead to your non sequitur of an answer. At
any rate, what should have been obvious I was taking exception to was the idea
that "plenty of people are overly polite because it inflates their ego to be
perceived as polite." That comes across as reductive. The same argument could
be used to criticize anyone's motivations for practically anything and
anything's opposite. So and so does x because it inflates their ego to be
perceived as doing x or so and so is overly impolite because it feeds their
ego to be perceived as someone with a gruff demeanor. It's too easy so I was
looking for some kind of article that at least made a convincing argument for
its application in at least this specific context. I'm still waiting.

~~~
orestarod
Like you said, anyone's motivation for their actions can be questioned.
Everyone's motives are questionable. I don't think an article is needed to
argue about that. I, personally, am kind to many people just because it is
troublesome not to be, or to extract specific behaviors as a return. I managed
to get a driving license without bribing (bribing for that is standard
practice here), because I was so overly polite and non aggressive during
training that my instructor genuinely believed I was one of the few pure souls
left on this planet. The instructor then managed to persuade the examiner of
my driving test that the reason I was not paying was because I was naive and
really thought I could drive making zero mistakes, not because I was trying to
get away with it ( if you don't bribe, a single tiny mistake is enough to get
cut, and you can't really avoid it if the examiner wishes, also the examiner
and the instructor share the bribe). That saved me about 150 euros. That's
politeness ft or you.

~~~
nathanasmith
I'm frankly not buying this lazy argument. The assertion that "plenty of
people are overly polite because it inflates their ego to be perceived as
polite" is bullshit. In it's general form it's no more than a convenient tool
to disparage those you don't like. Dislike a person but lack a rational or
socially acceptable way to criticize them? Easy, just use this prebaked
phrasing to cast any exhibited behavior negatively. Imagine somebody doesn't
like happy/serious/polite/flirty/whatever people. Then to them
happy/serious/polite/flirty/whatever people are just acting
happy/serious/polite/flirty/whatever to be perceived that way as an ego boost.
It's an absurdly reductive cynical word game when you need to hate but can't
come up with anything substantive. The argument's unprovability short of mind
reading and its applicableness to anything (and anything's opposite!) removes
any intellectual rigor as it careers completely over the side of "proving" too
much. Vacuous rhetorical flourish trotted out in the middle of discussion to
target anything the opponent says or does as mere self-aggrandizement.
Seductive if one goes for that kind of sophistry however the reality of human
motivation does not resemble this arbitrarily contrived model of, to echo the
GP, ego inflation. Here's the real reason people seem "overly" polite: a
combination of cultural norms, fear, being non-confrontational, and power
dynamics. As simple as it is.

I know that some people are willing to go through much mental gymnastics to
justify hate and derision while seeing themselves as virtuous but had no idea
this mean spirited belief pattern was at all pervasive here, however this
discussion has led me to revise that belief. It's sickening but rather than
continue to get worked up I'll just log out for another 6 month hiatus like
I've done before when this community gets a little too high off its own farts.
Hopefully things will be better, folks a little less stir crazy in October.
Later.

------
EdSchouten
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](https://package.elm-lang.org) offline.
That will leave so many projects out there in an unbuildable state. Even if
you saved source tarballs of the core packages, there is no way to tie it into
the build yourself. The Elm compiler must load it through the official package
site.

I would thus personally strongly advise against using something like Elm to
build any piece of software that needs to be maintained over time. It's too
much of a risk.

~~~
razze
That's not correct, you can just inline any package into your vendor folder in
your project.

And the package website is just an index, the sources need to be on github in
the first place (this has some problems too), but if the website is down, you
can still grab them from github.

~~~
vaer-k
Here's the relevant section from the article for this comment.

[https://lukeplant.me.uk/blog/posts/why-im-leaving-
elm/#why-d...](https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#why-don-
t-you-just-ing)

------
bwanab
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 Elm in the
past for a hobby project with an eye towards using it in production, I
probably won't ever use it. I loved the original promise. Evan's ideas about
the Elm Architecture are worth reading and learning for anyone. But, as many
others have pointed out, if one has to maintain a project over the years, the
breaking changes in the language would have caused great bouts of teeth
gnashing.

I don't love Java, but over the years I've come to expect that with each new
major version of the language, that a small amount of work needs to be done to
guarantee my production code will keep working and I can integrate new
features as I have time. With Elm, every release forced me to spent hours
figuring out how to make my old code work again.

~~~
bartread
> But, as many others have pointed out, if one has to maintain a project over
> the years, the breaking changes in the language would have caused great
> bouts of teeth gnashing.

This isn't just a problem for Elm but for front-end development in general.
Not so much because of JavaScript the language, but because of the libraries
and, to a much lesser extent, the browser APIs.

In the library and framework space many take semver as license to completely
rework their APIs with every major version bump because they "got it wrong"
last time around. It's pretty infuriating because in most cases whatever
benefits the new API offers are generally fairly marginal and not worth the
cost of all the reworking that needs to be done.

I'd always rather an API was stable than perfect because, for one thing,
you're never going to achieve that perfection you dream of. There will always
be some new use case or better conceptualisation that you didn't think of and,
really, all you're doing much of the time is thrashing by pursuing this. To me
it often seems like immature software engineering.

I haven't written any Java for a _very_ long time, but I know that C# code I
wrote back in 2004 targetting .NET 1.1 would still run substantially
unmodified today on the latest .NET runtimes[1] - in fact I'm pretty sure some
of it is.

 _[1] Possibly not .NET Core, but certainly the classic runtime._

~~~
mdtusz
A fantastic example of this _not_ happening in js libraries though is
Plotly.js. It's still on a 1.x release and has maintained backwards
compatibility (for the most part) with the original API for _years_.

Full disclosure, I used to work there (specifically, on plotly.js).

~~~
noir_lord
Another is KnockoutJS which went from 2 to 3 with minor changes and virtually
nothing broke on 2.x -> 2.x+1 in all the time I used.

I'm kinda sad it (functionally) died out because they clearly valued and
worked hard on that.

~~~
bartread
Both Plotly.js and KnockoutJS are great examples of stability.

I think KnockoutJS may still the only (formerly) major framework that focussed
only on doing data-binding really well without adding in loads of other
functionality. As you say, a shame it died out.

I don't know if KnockoutJS is dead, so much as done or perhaps complete. If
all you want is data-binding it might be worth considering. It was released as
recently as 5 months ago
([https://www.npmjs.com/package/knockout](https://www.npmjs.com/package/knockout))
and it's still getting the occasional bug fix:
[https://github.com/knockout/knockout/pulls](https://github.com/knockout/knockout/pulls)

I suppose it's not that trendy so good luck getting buy-in at a team level,
but it would certainly still work for a bunch of different use cases.

~~~
noir_lord
Agreed on all points, there is an advantage in using whatever is currently
flavour of the month though (more documentation, components, better
integration with dev tools and such) but I used KnockoutJS for a couple of
years and really liked it, it was a massive upgrade over jquery for a lot of
UI stuff and brought some much needed sanity.

These days I use either React or Vue in the same role as the world keeps
turning.

It's amazing they are still putting work into it for those people with massive
codebases dependent on it though, anyone picking that 7-8 years ago definitely
made a good bet.

------
kazinator
I don't agree with everything here. Open source really does mean that you just
have all the code to rebuild the thing from scratch under the right sort of
license. Open source doesn't mean anything else, like having access to design
decisions.

Interaction style and personalities are also not part of the definition of
open source; open source doesn't mean nobody is brusque or abrasive. Some
communities have additional codes of conduct and social contracts and what not
for that sort of thing.

Here is a balanced viewpoint from the GNU Awk and Bash maintainers:

[http://www.skeeve.com/fork-my-code.html](http://www.skeeve.com/fork-my-
code.html)

Elm users who are not happy should fork the code --- everything, including the
ecosystem's dependencies on an ELM internet domain --- and maybe produce
something that is completely self-contained. Software that relies on "phoning
home" is a risk regardless of where that is hosted and whether the people are
nasty or nice.

If the Elm core developers don't like it and kick people out of their project
for forking, you just have to bite the bullet on that.

(From the description of what that project is like, why would you care about
being kicked out. Kicked out or not, your 20 line bugfix still isn't getting
looked at for another two years.)

~~~
diggan
Agree. I'm gonna be honest and say I haven't finished the entire article so
author might have elaborated further after, but I got a chill when reading the
following passage:

> The second is that if you advertise something as Open Source, there is a
> common set of assumptions about what that means, some of which are explicit
> in accepted definitions of the term.

It seems the "common set of assumptions" is around that people can get
involved and actually have impact on the direction of the project, but that's
not at all included in the actual definition of open source.
[https://opensource.org/osd](https://opensource.org/osd)

And I'm starting to see this sentiment crop up more and more recently, where
someone open sources something just to share the code, while people expect the
maintainers/creators to fit their project to their worldview. I think this
misconception is the source of many throwing a fit on GitHub in issues/PRs
where the maintainers won't change something based on the user's views.

Open source is and should continue to be about that you are free to fork the
code if you don't like the direction. Otherwise, assume nothing from others
work they publish for you to use for free.

Edit: I continued reading and found bunch of more passages where the authors
understanding of open source seems to be incorrect. Some examples:

> Bu I think this claim is increasingly hard to defend. For me, real Open
> Source goes beyond a LICENSE file.

> I’d like to see some kind of openness in the development process before I
> considered something to be Open Source

> It seems that Evan and the core team have forgotten that languages,
> especially Open Source ones, operate as platforms, and in these platforms
> contributions from other developers and reputation are critical.

> Fairness must be a central principle in any Open Source project

While I agree that these things are nice, they are in no way required to
called a project Open Source. Open Source is strictly about the software that
is under the license, not the community/company around it. The creator and
maintainers are free to accept/deny any patches they feel like, and project
should still be considered open source, as long as the _actual_ requirements
of open source are followed.

~~~
palerdot
> I continued reading and found bunch of more passages where the authors
> understanding of open source seems to be incorrect.

The author is one of the "core team" members of Django[0]. So, it is safe to
say that whatever assumptions he has about open source is not a fantasy and
cannot be compared line-by-line to a text book definition of open source.

[0] -
[https://lukeplant.me.uk/personal.html](https://lukeplant.me.uk/personal.html)

~~~
davidcuddeback
> _cannot be compared line-by-line to a text book definition of open source_

Why not? The OP claims that his opinions are explicitly mentioned in accepted
definitions:

> _some of which are explicit in accepted definitions of the term_

If the OP is going to make that claim, why should we not expect to be able to
find validation for his assumptions in a written definition of open source?

~~~
Talanes
The fact that your quote starts with the word "some" should tell you
everything you need to know.

~~~
davidcuddeback
It doesn’t tell me which or his opinions he thinks are backed up by accepted
definitions or what he considers an accepted definition. So no, it doesn’t
tell us anything. It sounds more like a weasel word to get out of providing
citations to back up his arguments.

------
save_ferris
> 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 possible in Javascript, but we chose
> Elm and it makes it very hard”.

Hard pass on Elm if this is true. This is an incredibly damaging accusation,
is this consistent with other people's experience using Elm?

~~~
holtalanm
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 would
suggest taking a look at ReasonML or possibly ClojureScript. Personally, I've
just been using TypeScript written in a functional way, and it serves my needs
at this point.

~~~
mercer
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.

~~~
smoyer
The use of "dictatorship" in your comment brought a smile to my face because I
thought of the BDFL title given to Python's creator ... and then imagined the
Elm team forgot the "B" at the beginning of the acronym. Note that I have no
personal experience with Elm and am in no position to take sides. The comment
just describes the mental image I got from your comment's ink blot.

~~~
int_19h
Most dictators believe that they are benevolent, as does their close circle
(which is then often seen as "the community", because it has the loudest
voice). From the blog, it definitely sounds like this is the case for Elm.

------
dbrgn
This post resonates with me. I'm not deeply involved in Elm, I just have an
Elm side project (started on 0.17) with roughly 1k lines of code.

Do I love Elm? Yes, definitely. It's such a well-designed language. Lots of
thought went into it. It's very focused and has great (albeit sometimes non-
obvious) solutions for almost everything.

However, the leadership style is also what keeps me from recommending Elm to
anyone wanting to create a project that cannot be simply rewritten in case Elm
does a change that doesn't work for you. I wouldn't use Elm at work, since it
would be a very high-risk situation. (In fact, I was faced with that decision
and decided against Elm.) If you face a blocker, you're screwed.

A version of Elm that is being developed in the open, where people are allowed
to make suggestions, where all feedback is considered valuable, where people
can experiment and explore the design space without artificial limits? Yep, I
would _love_ such a thing, and I'd happily contribute.

Until that happens, I'll happily use Elm for small, personal low-risk
projects. I do hope that the situation will improve once the "big rewrite"
with a WASM backend is done.

~~~
haolez
This kind of leadership gave us Go. It's not necessarily bad. If everyone gets
their way with the language specs, then all languages will look like a weird
dialect of C++ :)

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

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

~~~
leshow
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.

~~~
dragonsh
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/](https://ziglang.org/)

~~~
iopq
Parts of Firefox are already written in Rust:

[https://wiki.mozilla.org/Oxidation](https://wiki.mozilla.org/Oxidation)

they are continuing the work to replace the least performant/secure components
in Rust when it's easily possible to switch them out

------
xtian
As someone who spent over a year working on a production Elm app, I agree with
this post 100%. Our team experienced all of these issues and more.

The true cost of the approach Evan and the core team have taken is hard to
measure, since what I observed most was skilled community members with the
time and will to contribute silently abandoning the community after their
efforts were roundly rejected or ignored. The record of these interactions
tend to be scrubbed from GitHub and other community forums.

There are some really great ideas in Elm, but I would never recommend it to
someone as a tool for production use. It is run more like a hobby project.

~~~
javier2
I (luckily) only implemented a few smaller projects in elm around the time of
0.18 release.

I started looking into how to get WebCrypto working, and was scared away by
how they treated outside contributors. I liked Elm as a language, and Evan
made a very good design. But to the core team, I got the message that they
intend to work at their own pace, at their own leisure and will probably not
take much input from outside contributors. This makes it very hard to expand
the community and the usefulness of the language. They still have not afaik
released anything for WebCrypto or WebWorkers. It is fine they are committed
to the 100% pure language for frontend idea, but it makes it very hard to use
if the Gods in the core team does not think it's fun/worthy to solve.

------
jlokier
For me, the best thing I got from this critique was the link to this 2018 talk
by Evan:

The Hard Parts of Open Source,
[https://www.youtube.com/watch?v=o_4EX4dPppA](https://www.youtube.com/watch?v=o_4EX4dPppA)

I found Evan's talking style really entertaining and enjoyable, and I totally
relate to the first part about "why don't you just..." and "have you thought
about delegation..."!

The HN comments here are near uniformly negative towards Elm and supportive of
Luke's criticisms. Fair enough, it's a reasoned critique and those are
definitely issues that would affect users.

I found the critique informative and useful. I don't use Elm though I've
watched with passing interest for a while. Now I feel there are gotchas or
expectations I should be aware of if I'm considering using it, about the way
the project is heading.

But I felt it came off way more entitled than I'm comfortable, mainly when
Luke starts _moralising_ , placing ethical obligations upon Evan.

That came over to me as "you are obliged to do a lot more work that I want you
to do, on your own time and personal cost, and to stop developing the project
according to your own vision or you are a bad person".

~~~
hombre_fatal
> That came over to me as "you are obliged to do a lot more work that I want
> you to do, on your own time and personal cost, and to stop developing the
> project according to your own vision or you are a bad person".

I mention this in my top-level comment, but here's Rich Hickey of Clojure
responding to similar assertions:
[https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au...](https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_authority/do1olag/)

> Clojure was not originally primarily a community effort, and it isn't
> primarily one now. That has to be ok. The presumption that everything is or
> ought to be a community endeavor is severely broken. A true community
> respects the autonomy of its participants, else it degenerates into a cult
> of need/want.

The people who write these "I'm leaving X" posts must know they have
disproportional power in such a tiny pond. Imagine writing the same post about
Javascript or Java because you thought it was supposed to be a democracy or
something. Nobody would even read your post.

~~~
lolc
Let's take Java as a point of reference, since you brought it up. Imagine the
JDK were opinionated about which authors were allowed to write packages that
use FFI. And people wanting to use it would be instructed to build a
relationship to said authors to get their code blessed to use FFI. It is
wholly inconceivable. I'm sure you'd see quite a few "Leaving Java" posts over
it.

~~~
hnbroseph
your scenario isn't all that different from how the jdk authors view the use
of internal classes, like sun.misc.unsafe.

~~~
lolc
Here's what Oracle says[0]: "Technically, nothing prevents your program from
calling into sun.* by name." And I don't think I ever accessed sun.* when
writing Java. So the example seems both ill-suited and far-fetched to me.

One of the first things I did in Elm was writing a tiny JS snippet to get a
missing piece from the browser. It was something I needed and my site wouldn't
have worked without it. I later switched to the Elm implementation once that
became available.

Now given the stated goals of the Elm project, I will be unable to repeat
this. Which means I expect I'd be stuck if I again wanted to access the
browser API before the Elm people got around to implement that part. And that
wholly changes my view of the project.

I'm using Elm for a toy project. If I'm blocked, I go do something else. What
a pity though.

[0] [https://www.oracle.com/java/technologies/faq-sun-
packages.ht...](https://www.oracle.com/java/technologies/faq-sun-
packages.html)

------
scarfacedeb
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
rewriting the app after the 3rd Elm upgrade. I think it's irresponsible to
advertise the language to be used in production and break it every fucking
year. Speeches about finding the perfect solution are great for academical
discussions and toy languages, but you can't just remove the stuff that your
community uses without offering any alternative. It all stems from the
arrogance and cult-like behavior of the core team. I'm sure that they're
wonderful and very smart people who do their best to create the best version
of the language that they can. But their management style is too dictatorial
and they don't respect their community.

For me, the split started with elm formatter discussion on github. I disagreed
with some of decisions that the core devs made and I wanted to see what other
developers have been saying about it. On of the issues was the preference for
4-space indentations instead of 2-space. I understand that it's important to
have a single source of formatting for the language. But at that time there
was no consensus on what amount of spaces to use. Basically, the community
divided almost 50/50 between the two. Moreover, a lot of core libraries and
example code still used 2-space indentation. (that's why I preferred it). Due
to lack of consensus, there was a suggestion to add a flag to formatter to set
the indentation. It required to change some parts of code to pass the flag to
the formatting module. At that moment, one of the core devs stepped up and
closed the discussion because he didn't approve of this decision and he just
said that 2-space people should adapt to the new 4-space default (that wasn't
supported by any majority). It was the first time when I felt that the Elm
management is too strict and I don't want to have anything to do with people
with such attitude.

~~~
marcus_holmes
isn't this the exact problem that tabs solve?

~~~
dkersten
Yep! If people used tabs, then everyone can display it how they like and these
stupid discussions wouldn’t be necessary. Alas, for some reason the world has
rallied behind spaces. Sigh.

~~~
jcranmer
It doesn't really solve the problem. How do you format this code with tabs:

    
    
      <TAB><TAB>function name(arg1, arg2,
      <TABs or spaces?????>   arg3 <-- align with arg1)
    

The other issue is with maximum line length. If you have a maximum line length
of 80, do tabs count as 2 spaces, 4 spaces, or 8 spaces towards meeting that
line length?

Using spaces ensures that it at least looks consistent, independent of your
tabstop settings.

~~~
ggregoire
> It doesn't really solve the problem. How do you format this code with tabs:
    
    
      <TAB><TAB>function name(arg1, arg2,
      <TABs or spaces?????>   arg3 <-- align with arg1)
    

Just wondering… do you realign the parameters every time you rename a
function?

~~~
mikewhy

        <TAB><TAB>function name(
        <TAB><TAB><TAB>arg1,
        <TAB><TAB><TAB>arg2,
        <TAB><TAB><TAB>arg3,
        <TAB><TAB>)
    

That means this never comes up, and you don't need to change adjacent lines
because you've renamed a function.

~~~
jlokier
That wastes a lot of vertical space if you have a lot of function calls. If
you're one of those who prefer that, it's ok. I much prefer:

    
    
        function name(arg1, arg2, arg3,
                      arg4, arg5, arg6);

------
beh9540
We had a pretty similar experience with elm around cookies. The elm-
lang/cookie repo README starts with "Cookies are an ancient mistake of web
browsers. They make a bunch of security problems quite easy, so consider this
an expert library." However, they never address reading cookies, so if you're
using a framework that does CSRF protection with cookies, you have to use
ports, which adds quite a bit of complexity for something as simple as making
an API request.

Elm looks great on the surface, but once you start digging in you really start
to realize it's "there" way or else. It's too bad, the ideas have a lot of
promise, but we pivoted away quickly after running into the "core arrogance" a
couple of times and went with Typescript/React/Redux.

~~~
hombre_fatal
Well, you should be using `httpOnly` cookies (i.e. unusable from the browser)
and setting them from the server. Your browser client will automatically send
them.

document.cookie _is_ a security vulnerability that's hard to find in any
respectable documentation. It's up there with sql string concatenation.

~~~
jfkebwjsbx
SQL string concatenation is fine. You mean parameter concatenation (into the
query string).

~~~
hombre_fatal
Call it whatever you want, but everyone knows what "SQL string concatenation"
is referring to wrt injection. I don't think a finer point is necessary.

------
toastal
I'm mentioned in the article. I had nearly the exact same experience as the
author from a different side of the planet -- and we even overlapped on
i18n/l10n issues. I actually raised some of these issues in a blog/Reddit post
from a rewrite I did in 2016, where this was one of the biggest pain-points
(back when native code was cryptic but legal). After that thread was closed
without real answers or a way to reply, I stopped participating in any
meaningful way to the community and did all side projects in something else.
I've been afraid to even ask the community for any sort of assistance because
of the hostility I've encountered for suggesting something was wrong or
incomplete. You can see in the authors constant preapologies in the article
that he's really afraid of the tact chosen for this so he doesn't get any
flack to put him in even worse standings with community; this is absurd, and
it's the reason it needed to be aired out in a long blog post after bottling
frustrations.

I've switched jobs since, but we've discussed migrating from Elm to PureScript
for the last like year without having a big enough reason to pull the trigger,
but maybe this would be a good time since it seems a lot of people are
frustrated in the community and I've had to come up with a few too many
'clever' solutions to get around limitations.

I think Elm is the best playground to learn functional programming, but I
wouldn't recommend it to anyone for anything other than a learning opportunity
or a narrowly-scoped weekend SPA project.

------
novok
When I researched elm a few years ago, I pretty much came to the same
conclusions that the author came about the hard way.

1\. The native / non-native split and coming hard deprecation of native,
although makes sense from a 'code purity of the ecosystem' perspective, will
ultimately be a huge hindrance in practice.

2\. Elm specifically puts it's author as the single point of failure, decision
making and design, because he wants to make sure the language features are
designed right by sacrificing development multithreading.

3\. Because of the 2 decisions above, forces elm to effectively be a research
/ toy language, who's ideas we benefit from the ideas showing up in other
languages. Such as elm's error messages probably inspiring rust and swift to
improve their error messages. You can't rely on elm as a business.

4\. Elm might of been better off not using the browser as it's runtime
environment in the end because of the above 3 issues and how bad javascript is
and went straight for a flutter or squeak style of implementation setup, which
doesn't cause as many 'temptations of native' kinds of issues.

------
hombre_fatal
These posts (and HN comments) really make me wonder if adopters of fringe
languages are always going to be thin-skinned developers who get emotional
when they realize they won't be part of the language's design decisions. That
"On Whose Authority" rant about Clojure complains about the exact same things.
And I'll refer to Rich Hickey's response:
[https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au...](https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_authority/do1olag/).

Elm in particular has this weird problem where there are vocal people in the
community who you can count on to drape a wet, accusatory blanket over every
discussion, and you wonder why they can't just find another language that they
do like. Sometimes you need to leave the theater so other people can enjoy the
show.

Also what are these languages yall are using where you're part of steering
committee level decisions?

This blog post is full of the usual suspect complaints, like being annoyed
that a language can use features like custom operators but they can't in their
user lib even though most people would agree that user packages shouldn't be
able to invent yet more custom operators. It's such a weird jealousy for a
point to be "but core libs can do it, why not me? :(". Well, simple: think of
the rest of us who don't want every user lib to define its own custom
operators. But the complainer here gets hung up on what seems like an ego /
entitlement issue.

~~~
saagarjha
> most people would agree that user packages shouldn't be able to invent yet
> more custom operators

I'm actually curious why; I have yet to see people actually abuse operators
outside of C++, and those were _in the standard library_ …

~~~
earth_walker
This can be a problem in Haskell, where you can find a library using some
operator like +>>* that you haven't seen before, imported from one of its 30
odd globally addressed modules, which may just be re-exporting other modules.

Hoogle/google rarely help with such operators, so finding any documentation is
often an exercise in frustration, scanning through library after library for
one declaration.

~~~
dwohnitmok
How does Hoogle not help with such operators? Hoogle can search over all
packages in the Stackage package set and can also be installed locally to look
over all the dependencies of your project.

------
superdisk
I fully agree with everything listed in this article. One point he alluded to
(by mentioning the "friendly" exclamation marks) but didn't fully address is
the Elm community's bizarre and infuriating language policing.

You can't say the word "guys" in the Slack channel, or a bot will come and
correct you, and tell you to say "folks" instead. And from then on, you'll
notice the core team all use the word "folks" incessantly in their writing,
it's like some weird cult. You'll notice it from the quotes of Evan and
Richard in this article.

The forbidden JavaScript FFI is called either "kernel modules" or "native
code" despite it being neither. They also claim it's an "implementation
detail" or "flaw" despite the fact that it's obviously not.

There are more examples. If you go against any of these rules then you're
ostracized.

I quit using Elm because of this problem above all else. I recognize the need
to have respectful rules for conversation but having a dialect of newspeak
that you're forced to use is just too ridiculous.

~~~
SrslyJosh
> You can't say the word "guys" in the Slack channel, or a bot will come and
> correct you, and tell you to say "folks" instead.

Being asked to use inclusive language is a weird thing to complain about,
especially as the very first example you give.

> And from then on, you'll notice the core team all use the word "folks"
> incessantly in their writing, it's like some weird cult.

I use "folks" and other non-gendered language by my own choice. It's a habit I
developed after self-reflection. Am I in a cult?

~~~
serf
>Being asked to use inclusive language is a weird thing to complain about

that is, if you consider the word 'guys' as gender bound and inclusive.

Female friends with myself in attendance are often referred to as 'Guys' by
waitresses, waiters, and serving staff nearly anywhere I've gone. A former
roommate who worked as a server at a restaurant used the word non-inclusively
with the same meaning as 'Folks'.

So, first get people to believe the word 'Guy' is inclusive.

It's not.

It's originally synonymous with 'Fellow'[0], which is also from non-inclusive
origins meaning colleague, even if 'Fellow' was attached to males in the 50s
and 60s common American English.

>I use "folks" and other non-gendered language by my own choice. It's a habit
I developed after self-reflection. Am I in a cult?

Good. That's a great choice of habit. I commend you.

Now, please, reconsider 'Guys', it's not as bad as the (current) common tongue
might paint it.

[0]: [https://www.washingtonpost.com/news/volokh-
conspiracy/wp/201...](https://www.washingtonpost.com/news/volokh-
conspiracy/wp/2015/05/14/the-origin-of-the-word-guy/)

~~~
mcherm
> >Being asked to use inclusive language is a weird thing to

> that is, if you consider the word 'guys' as gender bound and inclusive.

I think you might be overlooking another possibility. The same reasoning
applies if you believe that SOME OF YOUR AUDIENCE considers the word "guys" to
be gender-bound. If that is true, then a reasonable person might decide that
for the sake of that audience it might be polite to use a different term even
if that reasonable person doesn't ascribe any gender to the term.

------
antew
I've been working in Elm for a few years, and I feel like I can answer some of
the questions.

0.19 introduced a new restriction on Native code (javascript), previously you
could compile kernel code in your own projects, now you can't. You've never
been able to publish a package using native code to the package site (only
packages under the elm or elm-explorations github namespace can).

If you feel strongly about it there are ways around it, forking the compiler,
or giving your project a fake "elm/whatever" name so that the compiler will
build it, there is also a set of shell scripts on github that allows you to
get around the restrictions. I've used it before to make some tooling to track
virtual-dom performance.

The biggest miss in the post in my view is not looking more at using Custom
Elements for the internationalization needs. Having a custom element where you
pass in a posix time and have it formatted using the Intl APIs is very
possible, and it also allows you to wrap up the interface between Elm and JS
in a nice, type-safe way.

The 0.19 upgrade was fairly large, but manageable. Our app was around 70k LOC
when we upgraded from 0.18 to 0.19, the upgrade was fairly smooth, and it
hugely improved our build times. I had actually forked the 0.18 compiler to
improve build times, full builds took around 2 minutes, and incremental builds
around 45 seconds. In 0.19 full builds take 4 seconds and incremental builds
less than a second.

I share in some of his experiences as well, I have had posts deleted on the
Elm Discourse page for mentioning a way for someone to run a fork of a core
package to get a fix. I stopped working on a private package manager for Elm
after someone described an existing solution as a hostile attack on Elm.

Overall the benefits of Elm still outweigh the downsides for me, no other
language I have used has made development a joy like Elm has, refactoring is
honestly fun, change whatever you want, follow the compiler errors, and at the
end everything works again. Packages are generally high quality and work, an
Elm package that hasn't received any updates in a year probably isn't
abandoned, it's finished. Coming back to code I haven't worked on in a while
is easy, the type system has my back, and most Elm code looks similar due to
using the elm architecture and elm-format.

~~~
jfkebwjsbx
Side-note: "kernel" code is bad naming for JS modules.

~~~
maxhille
I would say the name is fine in terms of the Elm runtime. This is not about JS
modules, but about calling the JS API of the browser and also managing some
state there.

------
cultofmetatron
This came at an awkward time. I just bought Richard Feldman's book "Elm in
Action" a few days ago and was working through the first 2 chapters. This has
made me reconsider my intention use Elm in my startup.

Having features randomly fail on me and having to rewrite an entire library in
elm vs calling out to js means less time creating features that matter to my
customers! I was drawn to elm as a way of spending less time debugging my own
code in production. Part of that overall strategy means pulling in tested,
working code whether it's also elm or js.

Some of what I see here could easily relegate elm to being a toy language; a
damn shame considering how good it is as far as strongly typed functional
languages to js go.

~~~
erichocean
> _This has made me reconsider my intention use Elm in my startup._

Choose Boring Technology
[http://boringtechnology.club/](http://boringtechnology.club/)

Seriously, don't use up your startup's innovation tokens on some guy's hobby
programming language.

~~~
cultofmetatron
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.

~~~
hombre_fatal
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.

~~~
dorian-graph
> One was to allow me my Debug.crash calls.

This innocent line has a lot behind it, and probably a lot of PTSD for Elm
developers.

The Elm compiler has a --debug flag that would compile with a useful debugging
window. It was fundamentally broken for how long? A year?

There were many, many posts about it in that time, several community forks
etc. There was little comment on this from Evan or the inner circle.

The debug flag being broken, and seemingly ignored, is a horribly beautiful
example of the blog post. Imagine having effectively the only debug tool
broken for your main programming language

------
okareaman
I knew nothing about Elm or Luke or Evan before this, but I'm always curious
about social relationships in the developer community. That said, I read
Luke's article, then watched Evan's video "What is Success?" then I went back
and read a couple more of Luke's articles. I am reminded of "Scala War Stories
with Paul Phillips," which to me is kind of a classic of the genre of a great
developer with huge passion and incredible work ethic almost driven to a
nervous breakdown.
[https://www.youtube.com/watch?v=v1wrWQcqLpo](https://www.youtube.com/watch?v=v1wrWQcqLpo)
I was really impressed with Evan's thought process. I liked his thoughts and
feelings about design simplicity and getting it right. I was also really
impressed with Luke. He has a practical bent I appreciate and was really
excited about his i18n solution, rightly so...and then the clash... I'm really
sad about this. There are no winners here. No one is wrong. It's a loss all
around. I'm sorry.

------
xupybd
Evan is brilliant, Elm even more so.

There are trade offs that they are making that I totally understand. There is
one way to do things. There is one path to fix things. Everything works one
way and works incredibly well.

But those trade offs come at a cost. It is very hard to take Elm into
production having to put all of your trust in Evan and the few in his company.
There are going to be times that your bugs are not considered bugs by the core
team. There are going to be times when your required features are considered
harmful to Elm by the core team. Other projects allow you the freedom to work
around those sorts of things. Elm has tightened things so this is very hard to
do. Elm has made huge wins by doing that. But it makes Elm in production a
much harder sell.

I love Elm I want to use it production. But I don't want to have to front to
my manager trying to explain we can't do X because I picked a technology that
met my needs as a developer but not failed to meet the needs of the business.

Evan has every right to build Elm as he sees fit but it's painful to sit here
as a dev and see something so perfect yet have to go for something so terrible
for commercial considerations.

~~~
chase-sequence
I cannot understand how one could call something "so perfect" if it cannot be
feasibly considered for use in production. How can something perfect come with
so many drawbacks and warnings?

~~~
xupybd
Please forgive my hyperbole.

Elm achieves simplicity and reliability by having it's entire eco system
locked down.

But it turns out the same things that make it a brilliant developer experience
make it unusable in production.

I suspect I can and might use it in production but if I do I will be putting a
lot of trust in one guy. No one else can really take over.

------
adius
I‘m not sure why this hasn’t been mentioned by anyone: If you’re unhappy with
Elm‘s constraints the obvious solution is to switch to PureScript
(purescript.org). It’s basically are more powerful Elm like language with a
great FFI and absolutely no constraints how to work with JavaScript. There are
also a lot of compatibility packages to provide functions and workflows from
the Elm ecosystem.

~~~
christiansakai
The learning curve to PureScript is way higher than Elm. Is that not that
obvious?

~~~
mjepronk
Do you think it is harder to learn than Ocaml/ReasonML though?

I think there is a good free introductory book [1], a welcoming community [2],
the language and ecosystem are quite stable nowadays and there's good tooling
(now that there's the Spago package manager).

[1] [https://leanpub.com/purescript/read](https://leanpub.com/purescript/read)
[2] [https://discourse.purescript.org/](https://discourse.purescript.org/)

~~~
vchak1
It's definitely harder. I have been doing O'caml for about 20 years now, and
we have probably one of the largest Elm apps out there. I looked at
Purescript, especially because it also compiles to other languages (C++, BEAM)
but the learning curve is a bit steep.

------
mrozbarry
Original author of the elm-firebase ( [https://github.com/pairshaped/elm-
firebase](https://github.com/pairshaped/elm-firebase) ) here. While I think
Elm certainly has some rough patches in both their aggressively PC community
and the immaturity of the language (still many breaking changes, not 1.x,
etc.), it's not that awful. I was told that elm-firebase was basically a
waste, and don't use native modules, so I stopped development. I didn't need
to make a big stink, and write a huge blog post on why I'm leaving Elm and how
the community is toxic.

If the author needs to leave the community, then do it, but no one needs to
leave a community with so much drama.

~~~
bmurphy1976
That's what many people (myself included) have done. Unfortunately by not
sharing our experiences, others will have to learn things the hard way.

If Evan is entitled to run Elm however he wants, Luke is entitled to post
whatever criticism he wants on his own blog.

If nobody ever speaks up, do you think things will actually ever get better?

~~~
mrozbarry
To be clear, I don't have a problem with Luke posting his experience, but
there's a difference between reporting the news and reporting your feelings.

I think about half that article could be deleted, and it would still hold
content of "why I'm leaving," but without building this huge drama oriented
narrative.

~~~
dorian-graph
As much as we can pretend that feelings aren't involved in software
engineering, it will never be true, especially when relationships is the
currency

------
Keats
The last time I looked at Elm was about ~4 years and this attitude was already
showing. We hesitated building our business front-end in Elm at the time and
had a general bad feeling about its future considering the various
interactions we had seen. Seeing this article makes me pretty glad I didn't
invest time in Elm.

~~~
lazersharkman
Same. We founded on Haskell but had some need to more front-end oriented code.
Can say Elm was never considered because I was hearing this weird stuff back
in 2016--not to mention it would just make hiring even harder. Can't trust
tooling that will be capricious.

~~~
hopia
What did you settle on, considering you were otherwise Haskell focused?

~~~
lazersharkman
Typescript. We try not to be type/pl theory fanatics. Choose your tools well.
Haskell is great since the core of our product is an interpreter/compiler with
multiple stages. But I don't wanna use it everywhere.

Personally I'd be using JS (or TS) + jQuery. Almost no dependencies, but a lot
more manual. No one would be happy on the team if we did this of course. And
it can be impractical

------
GiorgioG
Elm has a bus-factor of 1.
[https://github.com/elm/compiler/graphs/contributors](https://github.com/elm/compiler/graphs/contributors)

I feel quite uncomfortable hitching my wagon to a single developer who owes me
nothing.

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

~~~
GiorgioG
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](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.

------
canadaduane
Has anyone started a full fork of the compiler and ecosystem?

It seems like the size of the pool of the "Elm disaffected" is large enough by
now that a fork of the entire project might be worthwhile.

I imagine there are a lot of software engineers (like me) who at one time used
Elm, but lost interest under the leadership of the core team.

~~~
fbonetti
I think people have already taken the good parts of Elm and implemented those
ideas in other frameworks. Redux was inspired by the Elm, for example. I
personally like using React, Redux, and Typescript. It's nowhere near the
purity of Elm, but it's good enough.

------
Accacin
Long, but I think reasoning was explained very nicely without it reading like
an attack on anyone in particular. I would love to read a nice response to
this, but personally I will not be looking to use Elm anytime in the future.

~~~
wpietri
Agreed. I initially groaned at the length, but I think it was necessary to
make his case. This isn't the first time I've heard complaints about Elm
leadership like this. And I especially appreciated his nuanced take on open-
source projects and entitlement.

I tend to place organizations on a spectrum from supportive to controlling. It
always is a mix, of course. But open source especially should skew supportive,
and this seems like just the opposite.

------
ar-nelson
I haven't used Elm, so I have no horse in this race. But I feel like I've been
hearing these stories for a while, that it started out as an interesting and
useful language but kept having features removed in new versions. Since it's
open-source, and apparently there are existing projects in older versions of
Elm that would effectively be held hostage by these feature removals, I'm
amazed there hasn't been a (well-known) fork yet.

Has anyone considered making a compatible fork of Elm?

~~~
mrunkel
They could call it pine.

~~~
hellofunk
Or even Mutt.

~~~
hellofunk
Well I guess that downvoter doesn't know much about email history.

------
leshow
I gave up on Elm years ago. It's kind of funny, I paid for the Elm in Action
book that was partially written like 6 or 7 years ago. I got an email last
week that it's finally finished. It's hilarious that the book has taken this
long, probably because they had to rewrite it every release.

~~~
michaelcampbell
Mostly the same for me, but a "mere" 4 years ago. Absurd.

------
tmcw
I've used Elm on a few projects - most recently oldfashioned.tech - and it's a
lovely language. I read this article expecting the word 'ethical' to
eventually point to something and it never did.

The author wanted a different language, shouted at a bunch of people for not
agreeing with him, those people correctly wrote him off as a productive member
of the community, and then he wrote a long blog post about how he can't see
their side of the argument.

Indeed, he should use a language that aligns with his preferences.
Extrapolating from his experience into this right vs. wrong narrative doesn't
actually work.

Even after his explicitly acknowledged troll-like behavior, he didn't get some
expletive-laden response from the project maintainers. He wasn't banned from
the repos. At no point does he substantiate the idea of the leadership style
being 'threatening.'

On the other hand, there are plenty of communities with actual threatening,
abusive behavior in plain view, that everyone's aware of. There are plenty of
communities that "well actually" every forum post instead of being helpful.
Elm isn't one of those.

------
gdotdesign
I've invested a lot of time in Elm about two-to-three years ago, the two main
things was elm-ui [1] and elm-github-install [2]. At the time elm-ui was
impossible to build without "native code" so I used it and built elm-github-
install to make it work.

Suffice to say, I've run into the exact same issues as the author. Had they
allowed me to contribute in a meaningful way Elm now would have a nice UI
library and probably a much nicer package website which I've developed as well
[3] (no longer running, but I've turned maintenance mode off for a few days so
you can take a look).

I stopped using and contributing to Elm when 0.19 came out. If you are
interested how much effort I put in just check the Elm related repositories in
my Github profile [4].

After that I missed the developer experience and I created Mint [5], so in the
end some of knowledge I gathered during that time have been put to good use :)

I just can't understand how they could ignore all the work I've put in, if
someone would invest that much time and effort into Mint (or any open source
project of mine) I would welcome it and or at least start a dialog on how we
could integrate their work into the language.

Anyway, I thought I share my Elm story with you (although probably a bit late
:))

Cheers

[1] [https://github.com/gdotdesign/elm-ui](https://github.com/gdotdesign/elm-
ui)

[2] [https://github.com/gdotdesign/elm-github-
install](https://github.com/gdotdesign/elm-github-install)

[3] [http://elm-directory.herokuapp.com/](http://elm-directory.herokuapp.com/)
[https://github.com/gdotdesign/elm-
directory](https://github.com/gdotdesign/elm-directory)

[4]
[https://github.com/gdotdesign?tab=repositories&q=elm-&type=s...](https://github.com/gdotdesign?tab=repositories&q=elm-&type=source&language=)

[5] [https://www.mint-lang.com/](https://www.mint-lang.com/)
[https://github.com/mint-lang/mint](https://github.com/mint-lang/mint)

~~~
emerongi
Mint looks cool!

Maybe this is answered somewhere, but what would you say is the differentiator
between Mint and Svelte? Many of the design choices seem similar. I am in the
position of starting a new hobby project soon myself and currently Svelte is
the one I have landed on.

Thank you for your efforts.

~~~
gdotdesign
Thanks :)

Mint has what Svelte doesn't:

\- consistent language with a good type system \- at its base it is a
functional language \- styling is built in - [https://www.mint-
lang.com/guide/reference/components/styling...](https://www.mint-
lang.com/guide/reference/components/styling-elements) \- routing is built in -
[https://www.mint-lang.com/guide/reference/routing](https://www.mint-
lang.com/guide/reference/routing) \- language constructs for error handling \-
language constructs for asynchronous tasks \- compiles to Preact so the build
output is small \- easy JavaScript interopability

Svelte has what Mint doesn't:

\- it is basically JavaScript compiler \- different syntax for template (HTML)
vs code \- code is just mostly JavaScript and can use NPM packages (I think)
\- have their own runtime without virtual DOM \- transitions and animations
are built in \- reactive by default (without the need for language constructs)

I haven't really played around with Svelte though so I might be a bit biased.
I suggest that you try both a see what you like more.

Let me know if I can help with that :)

~~~
emerongi
Thanks for the great answer, very comprehensive. I will try out Mint :)

------
danpalmer
Well done to the author for the level of self awareness in this post. It’s
hard when faced with frustrating situations to remain calm and critique
usefully rather than emotionally, but this was mostly well done.

I hope more engineers can learn to be this self aware. I know I’m working on
it.

------
rstarast
Somewhat tangential to the valid arguments here, it _is_ possible to work
around the Elm 0.19 restrictions:

[https://vllmrt.net/spam/subverting-
elm.html](https://vllmrt.net/spam/subverting-elm.html)

[https://github.com/robx/shelm](https://github.com/robx/shelm)

------
sullyj3
Wow, this is pretty damning. The author seems fairly level headed and the
criticisms feel well reasoned. I've played around with elm a little bit, but
this really puts a damper on my desire to dive in further. Hopefully the core
team takes some of this criticism on board.

~~~
bjz_
I've definitely found Elm worth playing around with - it's a really
beautifully designed language with some really cool library design thrown in
that I wish more people would learn from. That said I'd _really_ recommend
steering clear of it for important stuff due to the issues described in this
article.

------
roebk
As someone who’s been watching Elm since 0.18 and writing Elm since 0.19, I’ve
heard similar stories to this in the past.

Elm is a great language for building frontend apps, I feel far more confident
and enjoy writing code in Elm than I ever did in JavaScript / TypeScript. It
also feels like Elm is becoming a little more stable and hopefully the big
breaking changes of the past aren’t going to be as severe moving forward.

I do wish Evan and the core team were a touch more vocal and transparent about
future plans and responsive to bugs / issues. There’s a balance to strike here
and it doesn’t feel like we’ve hit the sweet spot yet.

I’ll still keep on writing Elm, as it still brings me happiness. I just hope
issues like this don’t have an overwhelming impact of the growth of the
community.

------
popara
When I decided to commit my project to Elm, back in 2017, I have seen all
those writings on the wall. Basically I am buying in someone's whim. One
caveat is that I can stop following his whim, freeze source code that I need
and carry on my development with out needing or caring about future releases,
ie, I do the dreadful fork.

I work alone so I choose my tech destiny.

But when you look at the guy at which will you are submitting to, and can't
but say he is the everything I want from a COMPILER MASTER. He have designed
clean and well working language and ecosystem around it.

This is the ecosystem where you are not afraid that one of library's
dependencies might install crypto miner or steal your user data.

You are sure with like 99.99999....% that you won't have errors in runtime.

And language is simple, my wife started writing it, you only need to know to
structure the code and all the frontend power is to you.

Ad hominem - also Evan is soft spoken guy that cares about his life's work,
and sharing it with others.

Ad hominem on my side - I am sick of ALGOL languages. After 12 years of
proffesional work with many different languages, touching JS or anything
related gave me head aches, such inherently stupid and inefficient ways of
building systems, from syntax to /ways of doing things/ and making sure they
are /allright/.

Luke may have different ambitions than me, I wanted to build reliable systems
that brought me money, for me, after 3 years of Elm, I am happy as I can be.

I build new features with confidence and speed. It took me 3 days of work to
switch to 0.19. I have deleted big chunks of JS that I though were necessary
in order for my app to work. But I was wrong, there were pure way to do it.
That was rewarding mental exercise for me, after which I had cleaner code, and
customers noticed performance improvements.

Can language /be better/? Yes.

Is Elm at the point where think it desperately needs some improvement, because
of which my work is blocked or stalled? No. It wasn't like that since 0.19.

Luke is off and rude in this post at least. He is considered about the posture
of OSS not the real benefits of it. Why Luke didn't came up with big blog post
about the features he would like to see in Elm? Much more constructive than
bitching about it.

~~~
dorian-graph
> Luke is off and rude in this post at least.

I found him humble, self-aware, forgiving, and kind

> Why Luke didn't came up with big blog post about the features he would like
> to see in Elm? Much more constructive than bitching about it.

I think you may have missed one of, if not the, fundamental point of the post.
Even if he did (which he did at times), it would've been pointless.

~~~
popara
Please, if you find a link to constuctive Luke's criticism, please post it, I
am willing to change my mind.

------
praveenperera
I used Elm in 0.18. I actively campaigned for its use. After 0.19, I actively
campaign against it.

Back when I chose Elm, ReasonML and ReasonReact was not around. That is what I
would choose instead now. I am currently stuck with an Elm 0.18 app that I'll
need to convert to React or bucklescript-tea.

Elm's leadership and as a result the community around it is super arrogant and
toxic.

------
lolc
As a casual user of Elm it was interesting for me to read from someone who
knows more about its development process. Unfortunately the author is
frustrated by the process. And that frustration resonates with me. I've
personally run up against these end-of-discussion comments that do not address
the points that were raised in the thread.

Obviously, the developers of Elm can choose their development style. And those
who can't live with that style can fork or fuck off. Still it is sad to see
people sore from conflict. The author has a lot of investment in Elm,
otherwise they wouldn't have written this. When I need to decide on my
involvement in Elm, I will consider how conflicts are resolved.

I understand the purism of Elm, and I know it is part of why I like the
language. I accept it takes unpopular decisions to keep it "pure". On the
other hand, when I see people break off over limitations that the Elm project
places on its users, but not on themselves (one of the main points of that
article) I do get a sad feeling. What kind of relationship is this where you
trust yourself with compiler features you don't allow other people to handle?
Words like patronizing, controlling, and self-serving come to mind. They may
have the best of intentions and my protection in mind, but I prefer the
privilege to know I can shoot both my feet if I need to.

------
leoh
I have a hypothesis that people treat open source a little like the way that
some managers and product managers treat software engineers — as dispensable,
as people that shouldn't have authority or control, as people that don't know
what the best is for the product. Unfortunately this isn't true. Empathetic
makers — the ones that are most successful — are often deeply in touch with
(a) needs of customers and (b) know what they are capable of offering.
Unfortunately, what individuals offer is often not thought of as a gift (in
both the open source world and in business), but rather as a given. This
orientation is harmful to the human spirit, but unfortunately we have grown
used to it in our world of seemingly endless commodities.

------
soamv
Having maintained an open source project for a while I relate to a lot of the
problems brought up here.

It's really really hard to create a contribution system that works well when
there is a large set of users, a large set of contributors, _and_ a tricky
design space. It's tempting to become authoritarian, especially when the
design space is complex and you've thought about it longer than anyone else.
Inclusion is a shit ton of work, and a lot of it feels non-technical and
boring to most people.

It's tempting to throw away compatibility and ask users to just deal with it.
No project is perfect at this, but infrastructure stuff has a much higher bar
for this than most other projects. That makes everything else that much
harder.

Most tech culture undervalues management a lot, especially in open source. But
open source should be valuing it _more_ , because the problems are so much
harder than in a small co-located one-company team -- communication is lower
bandwidth and higher stakes, there's no way to manage other people's
schedules, there's differing goals and incentives, and on and on.

------
tobyhede
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 CoffeeScript, experiments with ClojureScript and Elm, I
see the appeal.

But you can easily find yourself stranded. Following the herd is important if
you want to hire and maintain projects for the long term.

~~~
hombre_fatal
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.

~~~
tobyhede
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.

~~~
bravura
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?

~~~
tobyhede
This too. And then you're only as good as the interoperability your platform
is providing.

------
francasso
If the post is accurate in the Technical Limitations section I wouldn't touch
Elm with a 10 foot pole.

------
samtechie
Maybe am mistaken but isn't a language that hasn't reached version 1 by its
nature supposed to have breaking changes. It is expected that while you can
use the language for your projects there is no guarantee that new additions
won't break your code so you use it at your own risk unless Elm uses a
different versioning system.

------
Chris2048
Holy Moly. Congrats on such a concise critique; I expect it's hard to spend so
much work on the thing you're _leaving_.

~~~
mercer
I'll second this. I've read many "why I'm leaving <x>" posts and regardless of
the degree someone might agree/disagree with the contents, it's a very fair
article. That's difficult to pull off, I'd say.

------
cfv
Really well reasoned parting letter.

Hoping he'll fare better doing Reason instead. I've tried and haven't had much
luck selling it to our local Powers That Be but I understand it's a bit of a
nerdy, tough sale.

~~~
brodouevencode
Started following Luke back when he was doing a lot of Django work. He's not
the type to do things "just cuz". Most of his work is well thought out and
very reasoned. Big fan of the guy honestly.

------
type0
What I learned from this article:

All Elm developers are equal, but some are more equal than others.

~~~
michaelcampbell
And that distinction seems to be very, very clear.

------
kuon
I really like Elm. I don't use it now for some of the reasons pointed in the
article but I like the lessons it taught me.

It shows how you can do a lot of things with functional/reactive programming.

Building an app in Elm can be frustrating but it can teach a lot of concepts.

------
dzonga
I will forever be grateful to Elm, for introducing me to Functional
programming. And the helpful community. But a lot of things could've been
handled differently in that community. e.g if Elm had been made sort of the
route that ReasonML is trying to go i.e a functional ML wrapper around JS.
with full inter-op without the message passing madness.

------
Myrmornis
After reading that I’m fairly clear in my mind that Elm is something I will
avoid if possible. The author seems extremely credible to me and several of
the quotes entirely damning. For example, the one where the core team / leader
ended a communication by saying that they weren’t interested in hearing
alternative views but that they did want feedback on whether their
communication was clear. I cannot imagine that behind those words lie people I
would want to work with.

------
myu701
The closest I've been to using elm is elmish.

As a completely random internet user evaluating what proglangs to look at
next, I'm staying far, far away from elm itself.

------
mwfunk
This is a ton of emotionally charged verbiage about community interactions
here, but at any point does this person say what they were using Elm to do?
That seems like a pretty important point. Is this somebody who was just using
the language recreationally, for their own amusement? And if so, did they have
some expectation for the language community to be a source of (online) social
interactions and connections with people?

Because if so, that really changes the significance of the accusations, in the
sense that it makes them almost meaningless. "I wanted Elm to be my new life
and my new friends and I wanted to shape it myself as a personal milestone but
that stuff didn't happen and now I'm mad and I'm leaving" is a heck of a lot
less meaningful to me than, "this language doesn't work well for the problems
I'm trying to solve, and the maintainers aren't interested in adapting it to
my problem domain, so I'm going to move on to some other language for this
thing I'm working on".

I really don't care if someone is pissed that a language development community
didn't make someone feel like they belonged to a social club or otherwise
interacted with him in a way that satisfied some void inside of him. But if
there was some actual purpose to his language noodling, as opposed to being
purely recreational, it would be infinitely more interesting to know about how
it fell short of the purpose, why the language fell short, why the maintainers
didn't want to evolve it in that direction, and what language the author is
moving to for their project that does a better job, and why they chose that
language. That's meaningful. Anything related to whether or not they felt
listened to or if they felt like they were on the inside or the outside is
just utterly meaningless, it's like when people complain about news articles
that don't have anonymous comment sections.

I realize that to a lot of people, the recreational community aspects of open
source development are literally the only thing they care about. But I also
realize that to some of those people, they don't understand that this is not
the primary purpose of hardly any of the projects they care about, language
projects probably least of all. Open source maintainers are not obligated to
anybody to create a fun community for recreational users, with a well-lined
pathway to becoming a recreational core developer. But that is clearly all
that this person cared about, hence all of the emotional stuff which I just
don't get. I'm not saying it's invalid, I just don't personally relate to that
perspective at all.

~~~
rcxdude
I mean, he goes into some detail about the issue: he wants to be able to use
an internationalisation library, but the best option is in javascript, and
these libraries are very hard to write because i18n is really hard with a
bunch of edge cases. He also gives evidence that some commercial apps using
Elm _really_ need this functionality. He wrote bindings so it could be used in
Elm, it worked well, but the core team were not interested in his solution,
seemed to misunderstand the problem, and will not allow anyone else to solve
it without an outright fork (which the core team act extremely hostile
towards).

------
savanaly
Elm wasn't the right language/community for this author and that's ok, not
everything is for everyone. I use and love elm as something to write my side
projects in. It has a zen like appeal for many reasons:

\- No runtime exceptions in practice, so you are developing against the
compiler and almost never need to manually test what you're writing

\- Very opinionated about how to do most things. There's usually just one good
library to solve a problem and it solves it in a particular way. What you lose
in the process of trying to solve your problem in a way that's not optimal for
you, you gain in not having to search for the optimal solution.

\- Little politics or debate about the language itself. This does make it like
a cult, that's a fair comparison. Doesn't hurt my enjoyment of it though :)

\- Tooling is pretty good, with helpful linters, stylers and plugins for vs
code, vim and so on that the relatively small community has standardized on.

\- Very active community on their Slack, I get considerable help on all
problems from syntax to architectural at all hours of the day from certain
tireless people on there. I do my part to help as well, I try to help the
ultra-newbies now that I'm not one anymore.

I think the type of engineers who "think big" and want to do very ambitious
things that would require them to have input on the direction of the language
will not be happy in Elm, so I'm never surprised by the posts like this that
are quite frequent. HN is especially full of these type so be cautious if this
note is applicable. I also don't think I would recommend Elm as the solution
to my 2k+ engineer company even though it's my favorite language. There's just
too much at stake at that point to take a chance that the Elm process will
screw you. But for small projects, maybe under 50 people? I think it can be a
very strong candidate.

~~~
yawaramin
May I ask, how are you doing i10n?

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

~~~
yawaramin
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...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Intl)

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

------
IAmEveryone
This mirrors my experience quite perfectly.

To add another aspect: The over-management of GitHub issues is, in my
experience, borderline pathological.

On dozens of occasions (no exaggeration), I've experienced the following:

\- I notice some bug, or some missing functionality.

\- After dozens of searches I finally find a relevant Github issue. It's
difficult to find because it's closed, in a project with a different, former
name to the current version of the package, and part of a now-defunct GH
organisation.

\- The only comment on the issue was Evan saying the issue is being folded
into some meta issue bundling "issues concerning <some broad concept>". He
closes the issue and adds a line into the meta issue.

\- Any discussion of individual items on the meta-issue is blocked

\- Work on that collection of issues is not going to happen "right now"
because "it's so much more efficient to work on sets of related issues".

\- 14 months or so later, some work is done on <general concept>. The issue is
closed (& locked)

\- My original issue obviously persists

Evan seems to consider open issues as accusations or personal failures, or
otherwise I can't understand why this is happening. When some recent version
broke the existing support for WebSockets, the issue was immediately closed
(making it, again, invisible to people experiencing this problem and searching
with default options).

The most constant output of Elm leadership are long-winded essays explaining
how, specifically, you're stupid. You don't get to use WebSockets. We could
merge this patch fixing the problem, but anyone could do that. It's just code,
after all, and "Code is Easy" ([https://www.youtube.com/watch?v=DSjbTC-
hvqQ](https://www.youtube.com/watch?v=DSjbTC-hvqQ)). Have you heard about XY
problems? It's a great concept that neatly explains why _you_ are the problem,
not us.

I _really liked_ Elm. I would (have) loved to see it succeed. I fully
understand that small, young projects come with limitations, that it may take
a long time to fix some issue, that backward-compatibility may be broken, etc.
Not once have I complained about some issue, Elm or otherwise, not being fixed
fast enough. And on the few occasions where I witnessed such a sense of
entitlement, I called them out on it.

But the defensiveness of Elm Core to whatever they perceive as hostility has
somehow led directly from "benevolent dictator" to this weird kiddy version of
Stalinism, where everyone is always upbeat, and "constructive", and prefacing
even totally valid questions with five paragraphs of Dear-Leader praise and
caveats about probably just being really stupid, lest they trigger the
benevolent ego.

I'm just really happy I never used Elm for work projects. I imagine trying to
get something fixed when it really matters is a lot like getting ventilators
to blue states these days.

------
alephu5
Seems like two different discussions going on here, on the one hand you have
core language design such as not having typeclasses, and it's fair to say it's
the core team's prerogative to organise these decisions as they want. On the
other hand there's no good argument for intentionally restricting language
features from certain users, it's not in anyone's interest. I am a big fan of
safe languages that use a formalism to stop you _accidentally_ modifying
shared state or hitting a runtime error but why should the designers care
about me making a bad architectural design, i.e. including some JavaScript
modules in an elm package? If I misuse it and write a bad application that's
my problem, you can't protect bad developers from themselves because they'll
just use other tools. If I publish a library with JavaScript, okay show a
warning to the user, have red scary text on the package description page if
you want. But let the users decide how they want to build their applications.
The argument that this would block a clear path to WASM is bogus, they've
already shown that breaking tons of libraries doesn't bother them.

------
olvn
I've used Elm professionally for about a year, having done full rewrites of
both a bloated React/Redux SPA and a map data visualizer with complex JS
interop using ports to Leaflet, AWS Cognito, etc. Luke Plant's blog post
doesn't at all reflect my experiences with Elm or my feelings about the core
team.

For those not privy to the Elm tea, a brief primer: this blog post is
primarily concerning a months-old issue regarding the removal of the ability
to use native modules, which are effectively patches to the Elm runtime[1]
which circumvent the core features of the language that provide its greatest
strengths: a genuinely helpful compiler and ironclad runtime guarantees (still
have yet to encounter a production runtime error that wasn't on the JavaScript
side of things!) This "feature" (used loosely) was largely undocumented,
always verboten from distribution in user packages, and never intended as
anything more than a stopgap measure in extremely rare cases.[2] It was
/officially/ not a core language feature intended for widespread usage, and
consistently advised against by the Elm team. The removal of native modules
was spoken about publicly months before the breaking upgrade. It came as no
surprise to me. As an engineer who tries really hard to be responsible, I do
not build software which relies on features which are advertised as 'do not
use unless absolutely necessary' and are soon-to-be deprecated unless I'm
willing to accept the inherent risk of doing so.

The core Elm team was, in my opinion, extremely communicative, well-reasoned,
and thoughtful in this change and in others, despite the inconvenience to a
small subset of people. For each feature discussed in Luke's post, there is an
accompanying Discourse thread[3], discussion on Google groups, Github
gists[4], etc., that carefully lays out the reasoning, and carefully consider
the scope of a change (in the instance of the removal of custom operators, the
Elm team analyzed the package ecosystem and determined less than 5% of
packages were affected)[4].

I won't cover the moral arguments around the obligations of open source
maintainers as this has been covered ad nauseam with the Clojure and Rust
fiascos of a similar sort - though I personally believe maintainers don't owe
anyone anything, and I try to treat all free software graciously, as a
precious gift, lucky to receive it at all. I will say that Elm's somewhat
slow, closed BDFL-ish governance is well-documented as well[5, 6], available
to all who seek to understand the Elm development process and decide for
themselves if this is an ecosystem to hitch their wagon to. Of course the Elm
maintainers get to patch their own runtime with native modules, because they
are implementing core parts of the language, it's practically tautological.
That users living in userland cannot do it is not unfair; it's a language
design feature. What Luke seems to see as a stifling of an open community by
the closure of issues and deletion of posts on the Discourse is often basic
organizational maintenance to handle redundancies. Conversations around these
issues have happened for months and in some cases years, and decisions have
been made. They may not be to everyone's tastes. That should be just fine! If
someone went to Famous Amos Cookies on Discourse, Slack, their mailing list,
and opened a Github issue and PR suggesting this genius idea they just had,
it's so good, wait for it - an oatmeal cookie without raisins! - I hope they
would clean it up, close the issue, delete my posts, etc., for their own
sanity. Not to mention that the opening to Luke's opus here is an admission of
his own rudeness to the Elm team on most of these fora. Of course the
relationship with maintainers will be strained with this kind of behavior.

There are critiques of Elm, to be sure. The pace of releases is somewhat slow,
custom operators might be nice for 3rd party parsing libraries, it might be
cool to have a PR merged in to get that fuzzy feeling only OSS contributors
get. But you cannot reasonably argue that Elm's team has been unfair,
discriminatory, uncommunicative, or arrogant (pathos, so much pathos here!). I
don't generally post comments anywhere, but articles like this are
irresponsible and damaging not just to the well-being of maintainers who are
being generous with their time trying to make something with great care, but
to people (like many top level commenters here) who might have tried Elm but
won't due to an inside baseball post from a spurned developer. It makes me
actually sad, like want-to-cry sad.

[1] [https://newfivefour.com/elm-lang-basic-native-
module.html](https://newfivefour.com/elm-lang-basic-native-module.html) (any
somewhat experienced Elm developer will get nervous looking at this trivial
example and immediately see what might break)

[2] [https://groups.google.com/forum/#!msg/elm-
dev/1JW6wknkDIo/H9...](https://groups.google.com/forum/#!msg/elm-
dev/1JW6wknkDIo/H9ZnS71BCAAJ) (2015!)

[3] [https://discourse.elm-lang.org/t/native-code-
in-0-19/826](https://discourse.elm-lang.org/t/native-code-in-0-19/826)

[4]
[https://gist.github.com/evancz/769bba8abb9ddc3bf81d69fa80cc7...](https://gist.github.com/evancz/769bba8abb9ddc3bf81d69fa80cc76b1)

[5]
[https://www.youtube.com/watch?v=o_4EX4dPppA](https://www.youtube.com/watch?v=o_4EX4dPppA)

[6]
[https://github.com/elm/projects/blob/master/roadmap.md](https://github.com/elm/projects/blob/master/roadmap.md)

~~~
whiletruu
I have been using elm at work (in prod) for about three years, my team and I
have rewritten a hard to maintain 50kloc+ angular application to elm. The
rewrite started with elm 0.18 and was finished with 0.19.

We started using elm extensively about a year before 0.19 was released and it
was very clear to us from the start that even though it's possible to use
native modules, it's a feature that should not be used and will not be
supported in the future.

The experience we have had with elm and it's community have been nothing but
great.

If we had stumbled upon a blog post/ thread like this when figuring out how to
proceed, I'm not sure we would have given elm enough thought and tested it out
properly. This makes me really sad as well.

------
jlokier
I've just realised that by the understanding of "Open Source" assumed by Luke
and by many of the commenters here:

\- Firefox isn't Open Source.

\- Lots of other things often held up as shining examples of Open Source are
not Open Source.

...because they are worked on by people or teams who decide their own design
goals and roadmap, and while you can contribute and talk about the project,
many users feel the project moves on without catering to their needs or
remaining compatible over time.

Firefox is an interesting example, not only because it's a poster child for
Open Source, but because it evolved from Netscape Navigator's source release
and is associated with events when the "Open Source" term was being coined.

------
throwaway17_17
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 of the new release no code, other
than that code coming from the Rust team may use ‘unsafe’?

— This is an honest question I’ve been holding in all afternoon, and seeing
this still on the front page, I just decided to ask.

~~~
ta20200202
> 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.

------
ghthor
I'd be interested to see why the author would be unable to use the ports
interface to work with the API of his package.

My understanding about why the core team is being so controlling over the
native modules access is that they're trying to prove that each native module
is pure, so they can make assumptions and declarations in the compiler that
the code produced is pure. By forcing unblessed/unreviewed modules to use the
ports interface they can maintain this assumption. Without doing this you lose
all of that assumption and your compiler falls apart, if it's based on that
assumption.

~~~
sonofaplum
The author gives more specifics in the footnotes, specifically footnote #4
[https://lukeplant.me.uk/blog/posts/why-im-leaving-
elm/#id14](https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#id14)

------
G4BB3R
I can't believe people are still complaining about something that happened
almost 2 years ago for a good reason, or even about Elm not having
typeclasses, or worst, for elm-format using 4 spaces, that is pointless. And I
personally prefer Elm the way it is, with typeclasses the compilation speed
and error messages wouldn't be the way it is now. There is already Purescript
for those who need typeclasses and better js ffi, no need to follow the same
path. In the next few years Elm will have everything we need as pure elm, and
libs with great quality.

------
the_gipsy
This is a very emotional piece. While a lot of his points are true from some
perspective, they seem to come from an expectation that Elm should be treated
the same as enterprise languages or frameworks, whose ultimate goal is to "get
traction and adoption" as success measure.

I have used Elm in a hobby project, a multiplayer web game, which I have been
developing over 4 years now. Elm has been a complete joy. New features and
refactors are done incredibly fast AND safe. I believe this is due to Elm's
restrictions letting no unsafe code "in".

------
mcguire
Is it just me or does the Elm development style resemble that of Go?

~~~
int_19h
It's not just you. There's definitely a similar "we know how to do everything
better, which means differently" vibe here, and a similar penchant for
rewriting everything to minimize library dependencies outside of the
ecosystem.

But with Go, at least it's the community as a whole making the decision to be
like that - people might shy away from cgo, for example, but it's a
convention, not a hard limitation. And if you do decide to use Go in your app,
you still get to choose how much or little of it there will be.

With Elm, it seems that there isn't any community consensus along these lines,
or even a community in the same sense (i.e. that can establish a consensus
that would be meaningful). It's practically a religion - you get the rules
delivered to you on stone tablets, and you're either all in or all out. Except
in this religion, there are new stone tablets every couple of years.

It might be an overly uncharitable comparison, but I can't help but remember
[https://wiki.lspace.org/mediawiki/Abominations_Unto_Nuggan](https://wiki.lspace.org/mediawiki/Abominations_Unto_Nuggan).
Especially "Abomination 6543: Umbrellas or any other Devices that shield the
wearer from the Blessings of Nature", in the context of native/kernel code.

------
frozenlettuce
Besides being much more elegant, Elm's tooling is very limited when compared
to JavaScript and React. When working with the js+react+redux combo, you have
access to specialized browser extensions that allow exploring the application
structure and events. It's sad because the language precedes Redux, but the
centralization from its owner made it lose the boat. The fact that the Elm
blog has a new post only once a year does not help, either.

------
quercus
This sort of thing is why I stopped open sourcing my work (I had several
successful open source projects a decade ago). I realized that it was the
responsibility of an open source maintainer to put the community first, but I
was only interested in strictly pursuing my own interests. Neither side was
wrong, I just realized I wasn't cut out to be a maintainer. Maybe Evan should
also consider if he's cut out for the job.

------
lewisjoe
When a technology wraps over another technology with its own opinions -
doesn't it always end up bad?

Especially when the wrapper decides to take away the escape hatches, locking
people into its opinions without considering genuinely valid exemptions.

I wonder how so many truly bright minds, bought into this philosophy, despite
knowing this was coming. I guess the promise of Elm was just far too
convincing.

------
tarkin2
I loved the Elm architecture even though I left it behind a couple of years
ago because it developed into an explosion of files with a fairly large
project.

I hardly interacted with the community (although I think I remember that slack
bot correcting people for using 'guys') but the architecture is both
conceptually simple and great and should be emulated.

------
OOPMan
No offense to anyone here contributing to Elm, but the project sounds like
it's a dumpster fire based on the linker post.

------
socialist
If it all ends up generating Javascript, why don't people learn to write good
Javascript.

Rather than compound problems with unnecessary incompetence and calling it
functional and typed. The only thing typed I discovered is undefined
incompetence from Elm to C++.

There is always an excuse to complicate problems when you are incompetent and
invent useless languages.

------
tolmasky
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.

------
eweise
Elm gets taken out behind the woodshed again on hacker news. Remind me not to
open source software.

------
auggierose
Just bought the book _Elm in Action_. If people are so frustrated about the
leadership, but still say it is a great language, it definitely is worth
checking it out.

------
dmjio
Haskell will accept you !

[https://haskell-miso.org/](https://haskell-miso.org/)

------
java_script
Wow I never knew how much I loved typescript until reading this. Never had a
blog post worth of complaints, at worst just cast to ‘any’, write a comment to
recheck after the next update, and clock out at 5. And maybe pray for
forgiveness from God for my code having side effects if I’m feeling guilty.

------
jaeming
I literally just started learning Elm this week and then I find there's all
this drama and baggage to consider.

It's seems like 0.18 to 0.19 was a divisive upgrade for the community. I feel
like a lot of good languages or frameworks go through this existential crisis
at some point. There was Python 2 to 3, or Angular 1 to 2, Node vs IO, etc.. I
think Vue narrowly avoided it on it way towards 3.0 (maybe remains to be
seen). I remember when Rails community split when Yehuda Katz got frustrated
with DHH and made Merb, and then they merged back together for Rails 3.

It seems like open source has a love/hate relationship with the benevolent
dictatorship model.

------
ybit
[https://github.com/dmjio/miso](https://github.com/dmjio/miso)

"""

Miso was written exactly for Haskell enthusiasts who want the simplicity of an
Elm interface without sacrificing too much performance. The benefits I’d say
are thus:

• Type sharing. A lot of web dev becomes boilerplate -- serializing and
transferring state is a large part of the work of web dev. Type sharing
ensures correct-by-construction serialization between server / client amidst
any changes to your business logic data types, allows you to focus on your
apps core offerings as opposed to minutia.

• Rich ecosystem. The Haskell ecosystem has many great libraries that compile
w/o any problems on the frontend.

• Concurrency. Programming with threads and synchronization primitives is now
first class in the browser.

• Extensibility. Compared to Elm’s ports feature, the GHCJS FFI is a much
simpler way to interface with third-party libs. Also, Haskell supports
typeclasses, and Generic programming, a rich lens library, etc.

• Community involvement. You’ll be working directly at the intersection of a
lot of interesting developments in GHC, specifically around cross compilation,
syntax, lenses. Any new advancements to GHC has an impact on your frontend
code. Also, many PhDs use, love and contribute to Miso. These people tend to
be very smart, empathetic and intellectually curious as opposed to dogmatic
and contentious that can be found in the software engineering industry at
large today.

• Nix, a one-tool-to-rule them all for dev, build, and deploy. While not easy,
deterministic builds are the future and help one to sleep at night (I’ve
found). It can be used solely for personal dev, or for an entire organization,
and anything in between.

• Virtual DOM. If your Haskell web framework does not handle the tedious task
of DOM manipulation for you, you have been failed as a library consumer IMO.
Miso has a very well-tested, simple recursive micro virtual DOM diffing
library that can exist standalone and can detect regressions in performance
via a benchmark suite.

• Simplicity. Unlike many other ivory tower libraries in Haskell, Miso
maintains a simple interface. Many different common abstractions were explored
in the early stages of development (free monads, FRP, etc.) and found lacking,
unnecessary or replaceable by a simpler solution without sacrificing features.
Miso does not attempt to hide behind complex type-level abstractions and blame
end-users for their lack of understanding. As opposed to a top-down approach
that shoe-horns an abstraction into an environment where it does not belong,
Miso takes a bottom-up approach to fully understand its environment, the
browser, it’s APIs, the DOM and its short-comings and provide a simple
commonly-used abstraction to the end-user that can scale to large
applications. This also makes it easier for newcomers to Haskell to get up and
running quickly.

• Industry adoption. Several companies are using miso in production for
various things in their company, from full product to internal tools / data
visualization.

• Isomorphic. Due to the rose tree structure of both the DOM and HTML, pre-
rendering increases load-time and overall UX along with correct SEO.

"""

^ from the author of Miso

------
ybit
[https://github.com/dmjio/miso](https://github.com/dmjio/miso)

Miso was written exactly for Haskell enthusiasts who want the simplicity of an
Elm interface without sacrificing too much performance. The benefits I’d say
are thus:

• Type sharing (A lot of web dev becomes boilerplate -- serializing and
transferring state is a large part of the work of web dev. Type sharing
ensures correct-by-construction serialization between server / client amidst
any changes to your business logic data types, allows you to focus on your
apps core offerings as opposed to minutia).

• Rich ecosystem (the Haskell ecosystem has many great libraries that compile
w/o any problems on the frontend).

• Concurrency (Programming with threads and synchronization primitives is now
first class in the browser)

• Extensibility. (Compared to Elm’s ports feature, the GHCJS FFI is a much
simpler way to interface with third-party libs. Also, Haskell supports
typeclasses, and Generic programming, a rich lens library, etc.)

• Community involvement (You’ll be working directly at the intersection of a
lot of interesting developments in GHC, specifically around cross compilation,
syntax, lenses. Any new advancements to GHC has an impact on your frontend
code. Also, many PhDs use, love and contribute to Miso. These people tend to
be very smart, empathetic and intellectually curious as opposed to dogmatic
and contentious that can be found in the software engineering industry at
large today).

• Nix, a one-tool-to-rule them all for dev, build, and deploy. While not easy,
deterministic builds are the future and help one to sleep at night (I’ve
found). It can be used solely for personal dev, or for an entire organization,
and anything in between.

• Virtual DOM. (If your Haskell web framework does not handle the tedious task
of DOM manipulation for you, you have been failed as a library consumer IMO.
Miso has a very well-tested, simple recursive micro virtual DOM diffing
library that can exist standalone and can detect regressions in performance
via a benchmark suite).

• Simplicity. (Unlike many other ivory tower libraries in Haskell, Miso
maintains a simple interface. Many different common abstractions were explored
in the early stages of development (free monads, FRP, etc.) and found lacking,
unnecessary or replaceable by a simpler solution without sacrificing features.
Miso does not attempt to hide behind complex type-level abstractions and blame
end-users for their lack of understanding. As opposed to a top-down approach
that shoe-horns an abstraction into an environment where it does not belong,
Miso takes a bottom-up approach to fully understand its environment, the
browser, it’s APIs, the DOM and its short-comings and provide a simple
commonly-used abstraction to the end-user that can scale to large
applications. This also makes it easier for newcomers to Haskell to get up and
running quickly).

• Industry adoption. (Several companies are using miso in production for
various things in their company, from full product to internal tools / data
visualization).

• Isomorphic. Due to the rose tree structure of both the DOM and HTML, pre-
rendering increases load-time and overall UX along with correct SEO.

------
passthejoe
That was a long, long one.

