If Java adds some nice standardized helpers like this, they will look equivalent. The current proposal is not this clean but that doesn't mean it won't be possible. The key difference is that async/await implies cooperative multitasking. Nothing else happens on the thread until you call await. I find that an easier model to think about, and I opt into multithreading when I need it.
Anyway Rust does this roughly using roughly the syntax you described (except no need to call "fork"). Languages that use async/await do not require you to say "async" at the call site.
I was using `async` as shorthand for "whatever it takes in a particular async implementation to launch an asynchronous task". Here's an example that more or less mirrors what I showed there:
async def main():
task1 = asyncio.create_task(
say_after(1, 'hello'))
task2 = asyncio.create_task(
say_after(2, 'world'))
print(f"started at {time.strftime('%X')}")
# Wait until both tasks are completed (should take
# around 2 seconds.)
await task1
await task2
print(f"finished at {time.strftime('%X')}")
It was a response to a particular thing you said, but I didn't quote because I thought it was obvious (my bad):
> With virtual threads, you need to write fork/join code to do two subtasks. With async await, you call two async functions and await them.
fork/join and async(for you: "whatever it takes in a particular async implementation to launch an asynchronous task")/await have the same pattern (if you need the synchronization point). That example above is a fork/join pattern but without the words "fork" and "join".
> Languages that use async/await do not require you to say "async" at the call site.
Nope, but if you start calling an async function from within a non-async function, then that function now has to become async, and all of the callers of that function have to become async. This isn't a problem with the green threads approach.
