When you're building software with a design lifespan of decades or more, this stability is advantagous. You don't want to have to go back and make big code changes (ie: pay increased maintanance costs) every few years because the libraries and frameworks you used are moving targets.
1) Not crashing-and-burning on simple "Hello World" level use-cases (e.g. working in a Python terminal, a 3-liner script, etc.)
2) Giving actual performance gains in typical cases
3) Allowing code to change in both directions, quickly and easily
4) Integrate well into other parts of the language (e.g. list comprehensions or iterators / generators in Python, or multiprocessing)
I also don't like the amount of verbosity added. I can describe a system which would do all-of-the-above, but I don't think I could have independently invented it. It's based on using JS and Python async / await for a while, and understanding where things were done wrong.
On a mile-high level, I'm also ultimately not sure this is the right model. We:
- Created cooperative multitasking (e.g. in Windows 3.1 and earlies)
- Found pre-emptive multitasking worked better, in part since people were bad at deciding when to release control
- Re-invented cooperative multitasking within apps with async / await
I think there is a more dynamic, higher-level programming model where I describe what needs to be done. Just-in-time profiling and optimization, decides what to do synchronously versus asynchronously versus in a new process versus e.g. on a GPU. An operation like:
[functional_function(x) for x in l]
Ought to sit on CPU synchronously if l is small and f is fast, in their own process asynchronously if they are medium, and on a GPU if they are massive and slow.I wouldn't be so sure if I was you. A lot of work is being put into JSpecify [1] lead by Google and with most major players in the Java ecosystem participating. If it is a success we might see it in the language one day and not just with annotations.