It is absolutely not the case that all problems worth solving are solved already. Programming language development isn't necessarily about being a genius but rather a willingness to put in a monumental amount of work. Writing a language that compiles is easy enough. Getting a language off the ground to an actually useful place is tedious, simply in terms of the sheer amount of work to be done. Specification, implementation, documentation, diagnostics, optimization, configuration, tooling support, and creating a standard library (especially a cross-platform one) are things that will mire you in many hundreds of hours of work.
Those are the easy parts actually. You're thinking of them in terms of time spent, which is not a bottleneck at all. That's an illusion.
You need to be a genius, not in the sense of having a high IQ, but rather a genius in the sense of having great ideas. All your competitors are doing the ecosystem marathon, that's not a differentiating factor since your new language will always have a weaker ecosystem unless your language has concepts or features that negate the value of existing ecosystems.
If you have a programming language that makes people 10% more productive, then people will have to spend 10x the time to use your language than it took you to develop it for it to break even. Increasing the amount of effort spent on the language moves the payoff further away.
Your two key goals are developing a more effective technology and to convince people to use it.
This means that differentiating features are critical here. Differentiating features are not present in the old ecosystem, which turns it into a burden rather than a benefit.
Even the _design_ of languages is a generational project. There are open problems in the PL space that we know need to be fixed but we have no idea how. Once you've got the ‘core ideas’ of the language in some papers somewhere (and proofs that they're coherent, which is usually the meat of the process) it's a pretty quick step to get a toy implementation, but then the path to an implementation that is usable for day-to-day work (especially if performance is important) can take decades, and the path to adoption after that can easily take between 5 and 20 more years.
Then people figure out the thing about your core ideas that gets in the way when writing the kinds of real-world programs they want to write and you get to go back to the drawing board for the next language idea :)
As an example of the kind of time scales involved, linear logic was introduced in 1987. Linear (well, affine) types made it into Rust 1.0 in 2015, which IMO is the first time substructural types have made it to a ‘mainstream’ (albeit still far from ubiquitous) language. And that's a very straightforward language feature that doesn't really challenge the dominant imperative/functional hybrid paradigm or have any inherent effect on performance (since it's ‘just’ a type system feature).
IMHO the next big thing up (assuming LLMs and other AI advancements don't throw everything off-kilter) is probably effect systems, introduced in ~2013, for which we can linearly extrapolate a time frame of about 2041!
But maybe not — one exciting thing that's been happening is that (as Jonathan Blow noted) with the growth of lower-level substrates like LLVM the work to go from a toy to a working and performant language has decreased significantly.
