Most of the corporations were built on free languages and ecosystems which existed before they did.
Too big to fail is not the hacker ideology I grew up with. Maybe that's gone now.
That kind of polished integration often costs money. In contrast, in the open source world we limped along with gcc + gdb for decades until Clang was able to force the issue (which was funded by Apple, Google, Microsoft, ARM, Sony, Intel, and AMD).
To directly counter your "npm + TypeScript + VSCode", I counter with "Hex + Elixir + NeoVim".
I recently worked on a project involving a couple Docker containers, one of which wraps a Postgres DB and the other extends it.
Some of the features of the extension are broken because the Postgres maintainers changed something key in their Docker image (they disabled the DB listening on localhost) and the scripts the extension generates assume localhost is accessible.
In the (volunteer, free) open source ecosystem, nobody is paid to have that be their problem to solve and so problems like that, to my observation, rarely get solved because these two groups are unrelated to each other and it's nobody's job to make sure "the whole offering" is easy to use.
(And as an ardent and frequent user of Emacs, I simply must see the config file someone claims to have put together that competes with VSCode for managing TypeScript projects. That's a hard claim to swallow without evidence; I've tried, and it's extremely non-trivial. Emacs just pulled in eglot for LSP support... Not that one couldn't self-install it earlier, but every time you have to mutate a system to one-off your own solution you increase the maintenance burden of that system.)
... I'll have to carve out some time to look at Elixir. In my world, of course, "Doesn't have a tool to compile to JavaScript that has made it to v1.0 yet" is a major strike against it, but my problem domain is specific. ;)
I’m not trying to set the wrong tone here but… how hard is it to modify a docker image that is used as a fundamental part of a production system? There isn’t someone who’s job it is to wrangle these things?
Key thing is: these two teams maintaining two separate Dockers aren't part of the same org, so there's no incentives to align either image to not break the other. If they were commercial entities driven by maximizing userbase or revenue, there would be reason for them to minimize breaking each other (especially if they were the same company; then someone's in charge and can tell one team or the other "Fix it or you're fired").
All of those languages and their ecosystems had major corporate backing before today's megacorps used them to get to where they are.
I mean, GIMP exists, but any one of a half-dozen commercial products built by fewer people in less time are easier to use and have better feature lists. It's not that it's not possible for GIMP to be best-in-class, it's that it isn't best-in-class. (And sure, dear reader, GIMP works perfectly well for you. Great!)
Given more time, I'd love to explore the idea that "most of the corporations were built on free languages and ecosystems" given how many of the companies we're talking about today seem to have some roots in C, developed under corporate control. But definitions are everything in a statement like that, so it probably would take a lot of time to sift through and ultimately convince nobody either way.
It's probably my love affair with Lisp speaking, but I really think there is space for PLs to implement 80% of production-level features with 20% effort and improve slowly as they turn out to be blockers. There's also a branding thing: users who are put off by lack of corporate funding won't be working on the ground floor of building a PL anyway. That's fine.
LLVM/JVM/WASM give leverage to both indie and corporate langs. More of those types of tools are great.
I've got a toy language I've built at home for my own reasons. Lots of developers do.
The difference (especially in these modern times) between my toy and Rob Pike's toy is that Rob is paid by Google to develop it, hammer out the details, work out the bugs, and support it. As are the whole team Google dedicated to it.
Some languages get supported by volunteer armies (Lua comes to mind, last I checked), but TypeScript, Go, and Rust are supported / maintained by corporate money and it's hard to compete with that because a corporation can throw money at a language that isn't done yet while it's harder to get volunteers excited about a broken toolset.