3 ms·

Async stuff in JavaScript light years ahead of Java's Future madness. Loom might help but I'm not optimistic about it. For example Spring already kind of deprec

Async stuff in JavaScript light years ahead of Java's Future madness. Loom might help but I'm not optimistic about it. For example Spring already kind of deprecated blocking http web client and new reactive WebClient is terrible. Will they create yet another BlockingWebClient? No they'll ask you to call `block` everywhere and write reactive nonsense filters if you need to enhance it. Spring is worst thing happened with Java.

dymk 4y ago
That may be true, but JavaScript forces you to bisect your libraries (and functions) into Those that Understand Async and Those That Don't [0]. There appears to be no path forward if you want to avoid that. It's very difficult to write generic, reusable higher-order code that shouldn't care if it's doing a sync or async operation. Java at least is building a foundation in the right direction. [0] - https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
- vbezhenar 4y ago
  If you mean that you can't write `map` which would work for sync and async functions with the same code, that's extremely rare problem IMO. If you really need that and don't want to write two versions of code, you can wrap blocking code with promises and use promise API from now on.
  - dymk 4y ago
    It's not at all a rare problem if you work in codebases involving async code. Many `Promise` APIs exist solely to work around that wart. Higher-order functions are the bread and butter of JS, and increasingly Java (especially modern Java).
kaba0 4y ago
But async stuff is a must in JS due to it being single-threaded (yeah I do know about webworkers). Just spawning a thread with a scope which will fork them at the end is just better from every conceivable way. Easier to grasp, easier to maintain, easier to debug - all of which are quite important when concurrency is at the table.
deleted 4y ago
[deleted]

dymk 4y ago

That may be true, but JavaScript forces you to bisect your libraries (and functions) into Those that Understand Async and Those That Don't [0]. There appears to be no path forward if you want to avoid that. It's very difficult to write generic, reusable higher-order code that shouldn't care if it's doing a sync or async operation. Java at least is building a foundation in the right direction. [0] - https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

vbezhenar 4y ago
If you mean that you can't write `map` which would work for sync and async functions with the same code, that's extremely rare problem IMO. If you really need that and don't want to write two versions of code, you can wrap blocking code with promises and use promise API from now on.
- dymk 4y ago
  It's not at all a rare problem if you work in codebases involving async code. Many `Promise` APIs exist solely to work around that wart. Higher-order functions are the bread and butter of JS, and increasingly Java (especially modern Java).

kaba0 4y ago

But async stuff is a must in JS due to it being single-threaded (yeah I do know about webworkers). Just spawning a thread with a scope which will fork them at the end is just better from every conceivable way. Easier to grasp, easier to maintain, easier to debug - all of which are quite important when concurrency is at the table.

deleted 4y ago

[deleted]