Imagine how amazing our languages and tooling could be if there was a happy path for talented people to work on this.
For example, the error messages in Elm are just insanely better than in any other language I know. Like, it's not even in the same ballpark. Why doesn't every language have this?
But that's just an example. In general, I think we under-invest in tooling.
I think this has led to many modern open innovations only realistically being useful for solving the problems of very large companies.
On a cynical day I might even accuse certain tools of being designed that way for job security. Or at least it looks that way because the majority of people who are using the tool could only dream of getting approval from management to make a better alternative.
The priorities of many of the tool maintainers, no matter how honest, just don’t match like they used to, and this is in an ecosystem awash with telemetry.
[1]: https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-com...
And in most cases, it's just a matter of sitting down and really thinking about what is the best error message you could provide in that specific scenario, what context is needed any so on. Instead of just writing down the first thing that comes to your mind, and never iterating on it ever again.
It's a combination of economics (who pays for the work? It could be people scratching an itch, but these people also have to have the privilege of being able to pay their bills somehow), difficulty (it's not a trivial problem space, you need to turn your compiler into one that understands not only its own language but also every potential language people try, and the errors might crop up in unexpected places where the context you need to provide good errors is long gone, so you must change the compiler to a bowl of spaghetti design, so you can access, for example, the type checker during parsing) and inertia (developers are used to building tools for themselves, so they dont spend time on diagnostics because they are already familiar with the inner workings od the tool, then other developers use those tools and because every other tool is like that they don't expect good errors, so no one considers them important enough, and the cycle goes on and on).
But let me be clear on one thing: although there are many things in your language design and compiler implementation that you can do to make things easier on yourself (don't throw anything away related to the causal relationship for why a certain constraint is present!), the work is mostly elbow grease, and spit and polish, little more.