5 ms·

That's exactly what was meant. With Loom Java will hopefully not have the same function split as languages like JavaScript (or C# for that matter) where you hav

That's exactly what was meant. With Loom Java will hopefully not have the same function split as languages like JavaScript (or C# for that matter) where you have to add lots of async/await everywhere; and instead will have something like Go (where everything is async). 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
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]
pca006132 4y ago
I don't understand the part about go, does that mean go doesn't require async but gives you the functionality of async? (I never tried go) The problem with async is that we can separate when to start a task and when to ask for its result. The compiler can just add await everywhere an async function is called, it is trivial, but you don't get the flexibility of async. If everything is treated as async, you will need to await everything (perhaps some syntactic sugar to allow for immediate await)
- shellac 4y ago
  > If everything is treated as async, you will need to await everything In go you work rather differently. You let tasks go off and do their thing, and provide a channel to communicate. Pulling a response from the channel is the 'await'. A good part of go's magic is that these tasks - goroutines - don't result in large amount of blocked threads. Java will soon have the building blocks of something rather similar to goroutines.
  - pca006132 4y ago
    OK I see, but I think these two approaches address different problems? The approach used by go is more powerful than async but also more verbose. The implementation is also different, async can be implemented with a generator but goroutine can't.
jayd16 4y ago
I guess I was confused because right now you do not code Java like that.
deleted 4y ago
[deleted]

vbezhenar 4y ago

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]

pca006132 4y ago

I don't understand the part about go, does that mean go doesn't require async but gives you the functionality of async? (I never tried go) The problem with async is that we can separate when to start a task and when to ask for its result. The compiler can just add await everywhere an async function is called, it is trivial, but you don't get the flexibility of async. If everything is treated as async, you will need to await everything (perhaps some syntactic sugar to allow for immediate await)

shellac 4y ago
> If everything is treated as async, you will need to await everything In go you work rather differently. You let tasks go off and do their thing, and provide a channel to communicate. Pulling a response from the channel is the 'await'. A good part of go's magic is that these tasks - goroutines - don't result in large amount of blocked threads. Java will soon have the building blocks of something rather similar to goroutines.
- pca006132 4y ago
  OK I see, but I think these two approaches address different problems? The approach used by go is more powerful than async but also more verbose. The implementation is also different, async can be implemented with a generator but goroutine can't.

jayd16 4y ago

I guess I was confused because right now you do not code Java like that.

deleted 4y ago

[deleted]