Your claims are at odds with each other. If the people who are passionate about a language are the ones who pursue its advanced features (and therefore somehow force them on the rest of the world), who then is left to "actually build shit"? Why, if simple functionality is such a strong requirement of productivity, aren't those who stick to simple features productive enough to maintain an ecosystem without the Architecture Astronauts building all the infrastructure?

It doesn't track that it's possible to simultaneously ruin a language by sabotaging all of its major libraries with novel features if writing code using novel features is actually incredibly difficult. It certainly doesn't track that, once you have somehow sabotaged a language's major libraries, that nobody bothers to "fix" them by introducing a new, simpler version.

> If the people who are passionate about a language are the ones who pursue its advanced features (and therefore somehow force them on the rest of the world), who then is left to "actually build shit"?

Some people are passionate about the language itself, and programming language theory in general. Others are passionate about solving whatever particular problem their project solves.

A simple thought experiment - think about the most widely used libraries and tools across the whole developer ecosystem. How many are built in Haskell? I count maybe one, Pandoc. How many are built in terrible code bases and languages but chug along anyways? I count thousands. How many wildly successful companies have pristine code bases and how many have trash fire code bases that chug along anyways?

>A simple thought experiment - think about the most widely used libraries and tools across the whole developer ecosystem. How many are built in Haskell? I count maybe one, Pandoc.

Purescript and Elm are two more. If you don't count languages, then Xmonad and Darcs are another two. Both Github and Facebook's efforts in mass source-code searching are written in Haskell (though Facebook's is not really released to the whole developer ecosystem).

This is also a misguided thought experiment - Haskell is relatively unpopular anyways (as Rust is). It has a reputation for being difficult to learn (as Rust does). How many tools across the developer ecosystem are written in Rust? Ripgrep, and maybe Alacritty. Does this reflect badly on Rust? No, it's immature and needs a lot of developer support - which is why much of Rust's development effort is in new libraries.

Does a(n alleged) lack of tools reflect badly on Haskell? No, both because it was for a long time considered an academic language, and because Haskell's great successes have also been outside of the "developer ecosystem" - in webservers, for example.

And none of this addresses my original objection to your point: why, if simplicity is so productive, is it not easy to replace complicated libraries with simpler versions? In Haskell, the answer is that the simpler versions are much less powerful, and the power of advanced languages features is actually a boon for productivity, because encoding your invariants in a good type system saves you work elsewhere. That's the whole benefit of Rust's borrow-checker over C++. There is no real risk of Rust getting "too complicated", because these advanced concepts still let people build shit.

I don't know if this is still widely embraced, but Haskell's motto has traditionally been "Avoid success at all costs." It was meant to be a language that embraced PLT and experimented with cutting-edge techniques, so it's not terribly surprising that it's produced more PLT experiments and hasn't produced as much consumer software as, say, Go, which had essentially the opposite philosophy.

You are right with your concern.

Fortunately, when you look at the latest version, Scala 3, you will see that they put more effort into simplifying the language and removing things that people complained about than adding new things.

To be a bit more concrete:

- Remove certain ways of using implicits and making them less confusing

- Cleaning up the language core and removing features (such as impure macros or constructs that are rarely used or confusing)

- Making syntax easier for many cases without adding new features

- Adding union types (comparable to typescript). This is a new feature and not a small one, but I think it will make the language easier to use for many people.

And I think union types and intersection types are a very practical thing to have. So all in all, I'm happy to see that Scala becomes more practical and less esoteric with this release.