3 ms·
Async/await with futures/tasks/promises is really useful. Having async build in a language simplifies code and reduces boilerplate. Of course it introduces func
by kmac_ 4y ago
Async/await with futures/tasks/promises is really useful. Having async build in a language simplifies code and reduces boilerplate. Of course it introduces function "colors" as some say, but that's a good tradeoff imo as it's easy to handle (much easier than not having async/awiat). Java ecosystem is quite behind and won't catch-up because the language itself has some pain points like type erasure, nullable references (even C# got rid of that), etc. and that won't change ever. The most popular libraries and frameworks are stuck in time. Languages are moving forward and developers follow that, Rust, TypeScript show the way.
- Reason077 4y ago> "The most popular libraries and frameworks are stuck in time." 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.
- blagie 4y agoI like async/await, but I haven't seen any language do it well. Doing it well would involve: 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.
- kasperni 4y ago> won't catch-up because the language itself has some pain points like type erasure, nullable references (even C# got rid of that), etc. and that won't change ever. 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. [1] https://jspecify.dev/ https://jspecify.dev/
- oweiler 4y agoAt some point Java will introduce value types, which are non-nullable.
- invalidname 4y agoI assume the parent is referring to Loom which makes synchronous threading as efficient for throughput as asynchronous. This has multiple advantages such as a simpler model, easier debugging, understandable stack traces, etc. This is better and simpler than async/await.
- PaulHoule 4y agoSometimes I wish I had more colors to put on functions to organize my program, storage, resources, etc.