[bitblender]

Disliking async/await does not make someone "generally bad at programming". This is a childish ad-hominem mindset that has no place in technical debates. Rust's decision to adopt async/await over green threads was intended to keep the runtime lean, not because it is an inherently better abstraction. Java certainly could have async/await syntactic sugar around its existing futures api, but project loom has greater ambitions by retrofitting asynchronous IO onto the existing thread api. The authors are certainly not "simply wrong" for this decision.

[neonsunset]

Sure, it is "childish and ad-hominem", it is also efficient and usually works. Also, non-async/await solutions for concurrency and asynchrony result in a more verbose, complex and bloated syntax, having to invent fancy terms like "structured concurrency" for use cases which in C# are simply expressed by awaiting the task at the point of its consumption and not declaration (no special methods required) or in Rust via simple, albeit for a different scenario, join!().

[anonymoushn]

> Also, non-async/await solutions for concurrency and asynchrony result in a more verbose, complex and bloated syntax

I just write the same code that I would write if it were synchronous and it executes asynchronously.

[neonsunset]

How would your code look like if you wanted to fire off two concurrent requests and then consume their results later on? In C# it is just

var user = service.GetUser(id);

var promos = service.GetPromotions(category);

var eligible = GetEligibility(await user, await promos);

[anonymoushn]

I guess like this:

    var user = try alloc.create(@Frame(service.GetUser));
    user.* = async service.GetUser(id);
    defer alloc.destroy(user);

    var promos = try alloc.create(@Frame(service.GetPromotions));
    promos.* = async service.GetPromotions(category);
    defer alloc.destroy(promos);

    var eligible = GetEligibility(await user.*, await promos.*);

but the claimed difference is not present in this code. It is that GetUser and GetPromotions do not themselves know whether they are async. The author of service is able to just take some readers and writers or some types or objects implementing some protocols and use them, then service's methods inherit the async-ness of its dependencies.

[astrange]

async/await and structured concurrency are two different things, Swift has an async/await syntax but is still structured concurrency.

The point of async/await is that it converts your function into a reentrant state machine (in a different way than compiling a sync function already turned it into a state machine.) The problem with the usual design is that it uses futures, which are bad because they have dynamic lifetimes.