4 ms·

Async/await is extra syntax and one more function color which you have to keep in mind, while being just a workaround for expensive threads. Recent Java has ju

Async/await is extra syntax and one more function color which you have to keep in mind, while being just a workaround for expensive threads. Recent Java has just made threads cheap, so async concurrency is much simpler and more consistent with existing libraries and APIs.

pharmakom 4y ago
An Async<T> is not a T whether you have the monadic sugar or not. Why make life more difficult when you can have code that reads linearly?
- wiseowise 4y ago
  In Kotlin it is just T, the function is suspend.
  - pharmakom 4y ago
    Then the language is implicitly converting it through suspension for you. They are still different things. What if you don’t want that to happen?
joe_fishfish 4y ago
Cheap threads are fine if you’re in a server environment, and you need to spin up a large number of short lived parallel jobs. It’s not hugely helpful for a UI-bound application which occasionally needs to move some work into a background thread to cut down on UI jank. Kotlin’s suspending function syntax effectively lets you know which operations are going to (potentially) take a while, so you can make sure the UI thread isn’t blocked, and also make sure you’re communicating to the user that something is happening.
- kasperni 4y ago
  Custom schedulers are coming later with Project Loom. Should be fairly easy to create something where particular threads could have a higher/lower priority.
- nlitened 4y ago
  If I understand your point correctly, you say that suspend keyword gives you a hint for which functions are long running, so that you run them in a background thread. I think that’s a very flawed assumption. Some IO operations are pretty fast, like reading a local filesystem, and can be done in the UI thread, while some heavy non-async functions are accidentally O(n^2), and freeze your IO thread. And if you say that “of course you should know what you’re doing”, then I think that suspend syntax just adds extra complexity without much semantic benefit.
- invalidname 4y ago
  Loom has zero impact on client, sure. But I disagree that async is better for client. It makes it much harder to debug and track issues.
tluyben2 4y ago
Can you provide a good cheap thread example for Java vs async/await. What I find online is horrible compared to async/await but people keep talking about function colouring etc. I just cannot see what is the issue. Nor do people give better examples; I was watching some guy on YouTube who said async/await sucks and my idea is better, then spent 30 minutes explaining his idea vaguely. No implementation, no examples.
- nlitened 4y ago
  In the simplest case, you take an async function, remove `async` and `await` keywords, and as a result you get a normal function which you can call and get a result without awaiting, which has better and more predictable performance, and a straightforward stack trace (and a simpler language syntax and semantics). All upsides, no downsides. Probably you can think of a more complex example where it’s not that straightforward, please link code that you have in mind, we can see how with cheap threads it could be made better.

pharmakom 4y ago

An Async<T> is not a T whether you have the monadic sugar or not. Why make life more difficult when you can have code that reads linearly?

wiseowise 4y ago
In Kotlin it is just T, the function is suspend.
- pharmakom 4y ago
  Then the language is implicitly converting it through suspension for you. They are still different things. What if you don’t want that to happen?

joe_fishfish 4y ago

Cheap threads are fine if you’re in a server environment, and you need to spin up a large number of short lived parallel jobs. It’s not hugely helpful for a UI-bound application which occasionally needs to move some work into a background thread to cut down on UI jank. Kotlin’s suspending function syntax effectively lets you know which operations are going to (potentially) take a while, so you can make sure the UI thread isn’t blocked, and also make sure you’re communicating to the user that something is happening.

kasperni 4y ago
Custom schedulers are coming later with Project Loom. Should be fairly easy to create something where particular threads could have a higher/lower priority.
nlitened 4y ago
If I understand your point correctly, you say that suspend keyword gives you a hint for which functions are long running, so that you run them in a background thread. I think that’s a very flawed assumption. Some IO operations are pretty fast, like reading a local filesystem, and can be done in the UI thread, while some heavy non-async functions are accidentally O(n^2), and freeze your IO thread. And if you say that “of course you should know what you’re doing”, then I think that suspend syntax just adds extra complexity without much semantic benefit.
invalidname 4y ago
Loom has zero impact on client, sure. But I disagree that async is better for client. It makes it much harder to debug and track issues.

tluyben2 4y ago

Can you provide a good cheap thread example for Java vs async/await. What I find online is horrible compared to async/await but people keep talking about function colouring etc. I just cannot see what is the issue. Nor do people give better examples; I was watching some guy on YouTube who said async/await sucks and my idea is better, then spent 30 minutes explaining his idea vaguely. No implementation, no examples.

nlitened 4y ago
In the simplest case, you take an async function, remove `async` and `await` keywords, and as a result you get a normal function which you can call and get a result without awaiting, which has better and more predictable performance, and a straightforward stack trace (and a simpler language syntax and semantics). All upsides, no downsides. Probably you can think of a more complex example where it’s not that straightforward, please link code that you have in mind, we can see how with cheap threads it could be made better.