undefined | Better HN

0 pointsbitblender2y ago0 comments

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.

0 comments

neonsunset2y ago

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!().

anonymoushn2y ago

> 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.

neonsunset2y ago

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);

1 more reply

astrange2y ago

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.

j / k navigate · click thread line to collapse

0 pointsbitblender2y ago0 comments

0 comments

neonsunset2y ago

anonymoushn2y ago

> 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.

neonsunset2y ago

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);

1 more reply

astrange2y ago

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

j / k navigate · click thread line to collapse