Go's approach? Go has the same extreme BDFL approach to ignoring community feedback in favor of the leader's vision. I don't see what is different about Go.

I think the difference with Go is the Google backing. Go ignores community feedback, but not the feedback it gets from within Google. So at least it can justify itself by saying, this works for Google, and that's proof enough its pretty damn good.

Elm's BDFL cannot make such claim, since he doesn't use it to build products closely similar in nature to most users of Elm. I think this is both good and bad. Its good in that Elm is more ideological in nature, since the creator is not motivated to break his ideologies by real world constraints. Its bad, because people who have those constraints must find ways to shoehorn the beautiful ideology, into the dirty real world. That's where a lot of the user pain comes from.

Evan works at NoRedInk which has 250 000 lines of Elm in production.

Interesting, I thought he had moved on to doing a masters or PhD.

Well then, I take back some of my hypothesis.

I meant go's compatibility promise https://golang.org/doc/go1compat which is totally different, and no they are not ignoring the "community" they are just keeping that promise which I and many Go users appreciate.

Go broke a lot of things pre-1.0. Rust did as well! Just think it's worth remembering before making comparisons like this.

They communicated it a lot differently, though.

Yeah, I agree. And when Rust removed poorly designed things, they were often replaced with alternatives that solved the problem better, so it was never felt like a pain.

Common with many languages, actually.

That has its downsides, but if the people maintaining the language are too lacking in strong opinions about the language, you'll have other kinds of problems: bad features get into the language and now everyone must be prepared to deal with errant use of those features in the wild; there are too many too similar ways to do the same thing, so the language becomes hard to learn and teach; there are features you never normally use, so you're terribly confused when you accidentally invoke them (suppose you have `val` and `var` as two ways to bind variables, but everyone only uses `val` because `var` has some weird extra semantics.)

Basically, you get C++.

This is what I love about programming languages; it's a true marketplace of ideas. There's something out there for everyone, and a project of every flavor. You see this happen all the time with languages projects, especially opinionated ones, where someone likes the general vibe of the language, but wishes it were more like something they are more comfortable with. But sometimes a language just wants to be where it is, especially when it's run by one ego. Programming languages can be very personal things for their authors, much like a novel is for writers.

Go has a rigid backwards compatibility promise. Any language feature you rely on is sticking around.