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

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

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

No.

This is FUD. For any normal web app you don't need that functionality, just use the built in "ports" concept to interface with JS stuff.

And it being open source means nothing stops you from forking it and adding your own native modules. Reason no one has done it is it's no need, and doing thinga that way would break the promises the compiler makes about no runtime bugs.

As for a replacement (if one feel that's needed), gren-lang is a kinda fork (but no promises of being backwards compatible) by a core member.

> This is FUD. For any normal web app you don't need that functionality, just use the built in "ports" concept to interface with JS stuff.

The change was handled extremely poorly. I only knew one team using Elm in production at the time. They went from being huge proponents of Elm to recommending against it after the 0.18/0.19 changes and drama upended a lot of their work.

If it's really just a "hardcoded whitelist" that causes trouble, said fork would truly be easy to maintain.

Until they do some other halfbaked thing that's harder to follow along with. When people show you who they are, believe them the first time.

Compilers are supposed to be boring, especially when your language has ~exactly 1. If you can't trust the people maintaining it, it's too much risk to take. Having to do an entire rewrite in a different language can easily kill a company or a project.

Would you need to maintain a fork at all? Couldn't you obliterate the rule when building the compiler?

What's the difference between that and a fork?

One doesn't require a "community of maintainers", its an adhoc tool you use to get your own stuff done, every project has them what is one more?

Until another change against the community interest comes along. You only trust the "benevolent dictator" for as long as they remain benevolent.

It would be, if the code wasn't so horrifically bitrotted at this point. GHC has changed a lot since Elm last got any meaningful update, and they decided to use unsafe GHC primitives everywhere that have no support guarantee. You have to fix a bunch of issues with the compiler source before it will even compile on a relatively new version of GHC.

It would be weird to create such a fork casually, but it's a bit surprising that nobody in the community did it by now. Isn't forking the open source way of dealing with political disputes like this?

Gren is apparently such a fork: https://gren-lang.org/

Is it? https://gren-lang.org/book/faq.html#what-are-the-differences... doesn't mention anything about native code.

> While we could spend considerable time and effort in creating a language which would look very similar to Elm, we've instead decided to fork the compiler and core packages, and use that as the basis of Gren.

https://gren-lang.org/news/220530_first_release/

One of Evan’s colleagues from NoRedInk actually started his own language heavily inspired by Elm that aims to fix a lot of its ecosystem problems.

https://www.derw-lang.com

I’m not sure if it’ll go anywhere but I like the idea that it’s interoperable with existing JS/TS packages.

I was using Elm full-time back then, and I think some important context to note is that 0.18 had outstanding issues which had seen no movement for years (and PRs were generally ignored). The official guidance was “wait for 0.19.” While 0.19 addressed many or all of these issues, it came with a number of breaking changes, some very significant. It also coincided with a reorganization of the GitHub repos which happened to scrub all past issues, PRs, and discussion as well as a more stringent moderation policy on the official forums.

Well that last bit alone would put me permanently off a language. It's always wild to me when open-source leaders let the power go to their heads. If they want that kind of control over a community, they should go start a backwoods cult. Or at least start a company where they're signing the paychecks.

That's why I left Elm. There were major unfixed bugs for years. I liked the concept, but I couldn't deal with the slow progress to fix things.

> It was bad enough that they got it wrong, but then Evan doubled down by dedicating the opening of his next conference talk to mocking the users who were unhappy about the changes: https://www.youtube.com/watch?v=uGlzRt-FYto

> The part where he mocks a commenter for asking "Is Evan killing Elm's momentum?" is weirdly prescient, given that these events ultimately did mark the slowdown of the Elm community. Elm development came to a near halt about a year later.

Wow, that was hard to watch. He takes people being passionate about Elm and discussing potential issues and mocks them.

If I was a proponent of Elm that felt uneasy about its direction at the time, this would have made it easy to walk away from.

Forking a compiler is a gigantic pain. None but the most hardcore would bother. It's far easier to give up pushing the boulder and go use something else, which I hazard to say many have done. Or, they see the difficulty in using ports for stuff and never even start using the language.

not sure if FUD or not, but i distinctly remember people saying that they feared to fork the compiler because they were threatened with being banned from all the official channels and fora if they did.

How hard could it be to spin an anonymous fork though.

if you're going through all the trouble of forking you want to build a community around your fork, so you're not the only one maintaining it.

C'mon, it's forking a whitelist.

no, i was around in the elm community at the time, and what people wanted to fork for was a better way to support native js code in their own projects. there was a bit more to it than just adding filenames to a whitelist.

Once the maintainer has ignored all community feedback on said whitelist and then threatened said members of community for considering removing the whitelist, why in the world would you assume it'll remain "just a whitelist"?

Ports are not really a solution for rendering code. Obvious example is internationalization API. It’s not feasible to communicate back and forth through port every time you want to format a date.

Some folks propose web components but that’s another can of worms. Increase in complexity and still no help from compiler.

> It’s not feasible to communicate back and forth through port every time you want to format a date.

Why not? Is it code complexity or runtime inefficiency you are referring to?

Actually both.

Let's say that on desired page, you have three components with dates somewhere - date of article, dates of comments below and date of last login in the header.

After some user action, you navigate to this page. In Elm terms that mean your Model updates and then your rendering functions will run.

Only then you can see that you need to format dates - your rendering function should be responsible for formatting.

Rendering function should be synchronous - so you need to return some string for date - "loading state" or default format. So user gets "flash of unformatted date".

Now, you should somehow communicate with Port - that mean, send asynchronous message "format this date for me". (And sending messages in render function is not something really supported out of the box in Elm)

Then Port comes back with response, you need to put this formatted value in your global Model (some kind of Dict from unformatted to formatted dates?) and that triggers another render with formatted value.

In summary: - you have multiple render loops where one would be enough - you pollute your global Model with junk that could be easily derived - you introduce latency in rendering because Ports are asynchronous

Ports are great for interaction - user clicks something, you can send command and wait for response and update your model. But there are a lot of cases where you want use synchronous, pure function from Javascript like Intl API.

So, the elegant way to solve this would be to use an Elm i18n library and just use ports to get the users region instead of formatting every single string.

I understand that it is hard for a software developer to accept that these things need to be reimplemented, but it also seems to be a natural consequence of "up-typing" an entire eco system.

I studied formal techniques for PL. A large portion of the work was in reimplementing existing things in Coq, HOL, etc. Not particularly interesting, but necessary to reach a mature ecosystem.

I do undestand that this makes it a no-go for a lot of people until these things have been implemented. This is also natural.

> but it also seems to be a natural consequence of "up-typing" an entire eco system.

Reimplementation of i18n API in Elm would make sense only if benefits from types could outweigh robustness of browser implementation. Due to not very expressive Elm type system I really doubt that. You can’t capture intricacies of i18n in Elm type system.

I have more confidence in already tested and used by millions API in the browser than in reimplementation in niche language.

Elegant solution would be if I could write well typed layer that calls browser API. Low bar of entry would drive adoption and in effect real world test. But that’s not possible anymore.

> Elegant solution would be if I could write well typed layer that calls browser API

Not if your goal is correctness.

Again, it is completely OK that Elm is not your choice if it does not align with your values, which appears to be the case.

> Not if your goal is correctness.

Could you define correctness in this context? I'm asking because I don't believe that you can achieve correctness using Elm type system. I don't see how you can encapsulate i18n rules inside Elm type definitions. Maybe something like Coq could do this ...

You can't express something like "if passed 3 as group size, integer part of the number should be represented as string with separators between three digits". Even in Elm that's something that you need to handle not in type system but in runtime code.

What is more - many core packages are just this - typed layer over browser API. elm/regex introduce barely any type safety. It assumes that browser API is "correct".

> Again, it is completely OK that Elm is not your choice if it does not align with your values, which appears to be the case.

I often see this response from Elmers but really I don't understand the point of it. I responded to claim that Ports solve all problems. I provided good, real example where Ports are a bad solution. In return I was scolded that I don't understand software engineering.

I don't jump into elmconf and complain or demand changes. I just provide my take on the discussed issue. And to be frank, I think that's very valuable take for someone who decides if Elm is good for them. That kind of information is not present on elm homepage and is not obvious for new users.

Well, as with all logic systems you can only express correctness up to its granularity. Elm's type system is, as you mention, very rudimentary and basically just HM + reactive programming.

First, I don't write any serious applications in Elm, and would never do it. I don't find that it is productive because of the reasons you list. Just as I would never write any serious applications in Coq.

But with Elm, as with Coq, I can appreciate that their goals are not immediate developer productivity. Maybe some day when the ecosystems needed are fully implemented. Until then I just applaud everybody working on systems that are strongly typed and ensure that all their dependencies are.

I believe this will provide tremendous value – when ripe.

The problem with I18n in particular is that reimplementing in Elm causes pretty unreasonable download size bloat.

> And it being open source means nothing stops you from forking it and adding your own native modules. Reason no one has done it is it's no need, and doing thinga that way would break the promises the compiler makes about no runtime bugs.

No, it's because one of the core team members made threats against everyone who said they were thinking of forking it: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#forka...

I've never seen such an openly hostile OSS maintainer team as Elm's.

sveasoft

Sveasoft wasn't OSS.

Sure they were, they just didn't want to admit all their code was GPL.

Wow, that is wild! And yes, that kind of thing can totally drive off contributors.

Long ago I went to a local Scala unconference. At the time there were at least two popular web frameworks, and one of the authors was in attendance. [1] Chatting during one of the breaks, I asked him some question about his framework, something about testability of apps. He quickly grew enraged and shouted at me. I slunk off, wondering what I had done wrong.

At the bar after the conference, a few different people apologized to me for his outburst. Not him, mind you, just other people. I was like, "Aha, I recognize this. He's a missing stair." [2] He was clearly an asshole to people on the regular, but the community just put up with it.

That was the last time I went to a Scala event. Life's too short to put up with bullies, or people who accommodate them.

[1] I no longer remember which framework or which author.

[2] https://en.wikipedia.org/wiki/Missing_stair

Presumably Lift / David Pollak, which haven't been relevant for about 10 years; the Scala community has gone through a lot of effort to remove bad actors since then, for the record (and while the drama lingers on, I don't think anyone would deny that standards are much higher now).

I'm glad to hear it, but for me that still leaves Scala one down on every other language. Once bitten, twice shy.

This is a poor line of reasoning - pretty much every community acquires an ass at some point and when it's not something they've dealt with previously it often takes them a while to figure out how to react.

The question is how they do react once they've figured it out, and Scala's come along in leaps and bounds in that regard.

If anything, you should be more wary of groups that haven't yet dealt with that problem, because they've had no chance to develop the relevant antibodies yet.

I mean, I get it, if you have a bad experience with X, it's going to colour your perceptions going forwards, being human be like that - but similarly to throwing away a dice because you rolled a nat 1 with it at an inopportune moment, it's far from the most rational response available to you.

A community isn't "a dice". It has state. Indeed, dice are precisely designed to be uncorrelated roll to roll. You're claiming it's still weighted, just in a different direction now.

Did they really clean things up? Or is it just talk about how things have changed? The way to find out for sure is for me to spend time in the community. It could be better, or the abuse could just be better hidden. And honestly, given the revolution in recent years in codes of conduct and DEI, I suspect my odds are better with newer communities, as there are now plenty of "antibodies" out there.

But all this tickled my memory. Wasn't their an FP advocate who was also an abusive jackass and far-right kook just a few years back? Yes, yes there was. And gosh, what community was he prominent in? Scala. So if I had waited 5 years and given Scala another chance, I would still have landed in a community where there was significant support for abusive behavior.

Maybe he was booted in 2019 or so? Hard to tell from the web. From his tweets, it look like he has crept back in. Is that because he and Scala are worlds better? or is it just the usual missing stair routine that I observed more than a decade ago? I don't know, can't tell, and won't be finding out, because there are plenty of other technologies for me to pick up.

> given the revolution in recent years in codes of conduct and DEI, I suspect my odds are better with newer communities, as there are now plenty of "antibodies" out there.

A lot of that stuff can easily just enable a different set of broken stairs though.

Crafting a code of conduct such that it makes it easy to deal with both reactionary -and- wokescold flavoured bullies is something of an art form, and I've seen a number of communities manage to completely fail at one of the two albeit usually in a very well-meaning way.

Antibodies are great up until they give you an auto-immune syndrome, basically.

(I definitely saw the far right kook get defenestrated, though the community may still be sufficiently quokka to've let him sneak back in through a different door, I'm mostly an observer here - and mostly only looking at all because as a veteran code of conduct advocate I tend to find the various failure modes worth examining)

Sure, and I never said otherwise. I'm just saying my personal heuristic is "once bitten twice shy". If you would like to apply a different one in your life, godspeed. But move along with your "poor line of reasoning" accusations. I've just demonstrated how it was not only a reasonable heuristic, it was also proven correct for the very community I was talking about.

An N=1 example of an instance where a line of reasoning produced an accurate answers proves that it -can- produce the right answer, but does not, in fact, tell you anything beyond that about how likely it is to produce the right answer in any given case.

So "I've just demonstrated how it was [...] a reasonable heuristic" is simply unsupported here. If it's working for you, great, maybe you're encountering a different subset of communities than I am, maybe you've been lucky, maybe I'm simply dead wrong, but getting Elm-maintainer-style passive aggressive over somebody pointing out logical flaws in the underlying claim as to why the heuristic is 'proven correct' is a rather unfortunate way to respond to what was written as constructive criticism of said logic.

I see. You'll only listen to me when I've been abused in a statistically significant number of communities. Definitely somebody I'm going to listen to on the topic of where the good communities are.

Not much has changed, no worries.

Hah, thanks! A nice counterpoint to the person who said otherwise. And especially to the person who seems to think that I must have some sort of brain damage to be concerned.

One way Scala experts deal with people disagreeing with them is to contact those peoples' employers/universities, maybe you should revise your profile accordingly.

Come on, this is FUD. You're talking about one or two guys who got into an enormous personal fight years back and were condemned by everyone else.

Who condemned Martin? Sources please.

Why do you even need to care about this as a user?

And mind you this is a front end tool.

They did a big change of stuff that people depend on, without consulting the community, and then doubled down, threatened people that wanted to fork, all with a weird passive-aggresive tome.

You don't need to care about this as a user. That's my point. People at HN complain about elm things that won't affect you.

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

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

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

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

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

The amount of down votes we receive for stating this is quite absurd. I think most people here have never written elm professionally. Then they would've known this is no concern at all. Shrug.

Yea, exactly. I have written a complete functional game in Elm, with multiplayer over websockets, push notifications and whatnot. It has daily users to this day. I never needed "native" code.

Maybe some decisions were wrong, as I said. Elm is not popular today. But they are also right in some aspect: I don't need another TypeScript (but with weird syntax).

Would you mind sharing a link to you game :)

I’ve written quite a bit of elm professionally and it was an issue for me and was a contributing factor (but not sole factor) to leaving Elm behind.

A viable solution to my problem in professional contexts would have been private packages, which I believe Gren supports, so perhaps Gren would be a solution today, but I’ve moved on. That said, what’s happening with Gren is interesting and I applaud it.

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

"Their projects" were core libraries or experiments IIRC.

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

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

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

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

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

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

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

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

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

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

- - - -

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

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

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

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

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

People weren't asking to compromise or control the design of the language. They wanted to be able to contribute to the project (usually just first-party packages) in order to have their problems solved in a timely manner. Or have their issues addressed in some other way.

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

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

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

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

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

- - - -

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

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

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

- - - -

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

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

Are you ok?

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

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

I think everyone here can see something is wrong upstairs, man. I'm sorry that HN is your only contact with real world and I hope you can find something to worship besides Elm/Evan.

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

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

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

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

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

> you can just talk to yourself

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

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

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

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

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

> appreciate implied threats

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

> Have fun in the sandbox.

Thanks! I will.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Not every tool, has to solve all problems.

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

What were those problems you ran into?

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

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

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

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