Go is open to forks and PRs though. It’s more “we’ve got a vision, but we’ll hear you out”. Elm is full cathedral, Elm comes down from the gods with no input or transparency into the decision process.

The Elm developers have a history of ostracizing people who even mention the possibility of forks from the community; tester89 posted a link with a lot of good context.

They take a very heavy handed and adversarial stance to development. I had just started getting into Elm when the news of .19 basically breaking everything and the core team just brushing off peoples cries and it soured me on the entire language.

When pre-v1 Go broke things, `go fix` was there to at least try and help.

Sounds like Go's cathedral has a nice little bazaar in front, once a year, only for those who applied and were grated. In other words: better marketing.

I'm not defending Elm team members being rude. But when I look at Elm I see a much better designed language than Go, run by a much smaller team. Elm changes quite minor things in pre-1.0. Go forgot that polymorphism is cool, nulls are bad, etc. Now Go wants to fix some of that, but that would create a new notion of idiomatic Go that it's std lib is not in sync with.

To some extend this is a fate all popular languages befall. Look at Java for some sci-fi, or even better C++.

There was a similar project to `go fix` with elm-upgrade (https://github.com/avh4/elm-upgrade). We migrated a ~100k LOC app at work from 0.18 to 0.19 and while it was tedious, the compiler really has your back and makes it easier.

We weren't bit by the removal of native/kernel code, but it definitely turned a lot of people away that may have been committed to Elm before.

True that.

We also ported our Elm codebase from 0.18 to 0.19. It took us almost a week working almost 24/7 across two timezones to make the damn thing compile again. Did not see the UI for the entire week, but once it compiled it (mostly) just worked like nothing had changed (that's after 429 files changed, 16422 insertions(+), 12116 deletions(-)).

My colleague took notes of the progress at https://gist.github.com/mordrax/efcd34739ed56bb64d2b12d2401b...

Wow! Apologies if this is answered in those notes but my quick question is: Did you make extensive use of Debug.todo to cordon off sections of the app that wouldn't compile in order to work on and "see" the other sections in the meantime? That's what I do on my small elm apps, e.g. put whole features or functionality behind Debug.todos.

I might be wrong but I think Debug.todo was introduced in Elm 0.19. But in any case we were not aware of it at the time and didn’t use it. Btw Debug.todo is amazing and we do use it now sometimes.

I remember hearing Mordrax speak about the upgrade, quite herculean!

At our company it was much less drastic. At the time we had about 35kloc of Elm and it took me one evening of Vim macro frenzy. The trickiest things we encountered were an elm/http API change and temporarily vendoring packages that didn't yet upgrade themselves.

From the gist:

> We have until Friday 7th September to upgrade to Elm 0.19.

I'm completely ignorant about the transition, but I'm curious what the source of this deadline was. Would you mind expanding?

Basically business didn’t see any benefits of spending time on the upgrade, time that could be used to improve/add features to the product.

> basically breaking everything

This is unnecessarily dramatic, and far from the truth.