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