News for hackers. Stuff that matters.
Re:Rust Is Hard, Or: The Misery of Mainstream Programming by duped on Thursday June 02, 2022 @09:58PM (#31603326)
The last thing I would take away from async/await in Rust is that it's "half baked." It's incredibly deeply thought out with years of RFCs, great contribution work that required both low level implementations in nightly and creating extensions to the memory model, and extensive bike shedding and discussion with the community on surface APIs.
Re:Rust Is Hard, Or: The Misery of Mainstream Programming by pclmulqdq on Thursday June 02, 2022 @10:17PM (#31603457)
Like a lot of things in Rust, it's incredibly well thought out but its implementation just isn't complete to the point that it is usable by other programmers. A lot of Rust libraries and components of the Rust STL are "half baked" in this way.
Re:Rust Is Hard, Or: The Misery of Mainstream Programming by Hirrolot on Thursday June 02, 2022 @11:30PM (#31603956)
async/.await in Rust is a perfect example of "code duplication" in the language core. Okay, you have a nice syntax for performing do-notation on futures, but what about iterators, streams, etc? We have generators in nightly and some third-party macros for streams, which sucks.

A proper algebraic effect system could resolve the problem. You can take a look at Koka to see how elegantly it abstracts common control flow patterns using the concept of an algebraic effect.

Re:Rust Is Hard, Or: The Misery of Mainstream Programming by lmm on Friday June 03, 2022 @01:18AM (#31604565)
Algebraic effects are still a research area - no mainstream language has them fully working - but basic Haskell-style higher-kinded types should not be so much of a stretch, and are a necessity if you want reusable libraries for this kind of stuff.
Re:Rust Is Hard, Or: The Misery of Mainstream Programming by inejge on Friday June 03, 2022 @01:39AM (#31604663)
A proper algebraic effect system could resolve the problem.

It could also take as long as the async MVP itself to get off the ground, and you can't know if it wouldn't hit its own snags when deployed at scale. (From long ago, I remember the "non-parametric dropck" RFC as an illustration of a neat concept colliding with reality.)

Languages with mainstream aspirations evolve under greater pressure. I don't know this, but I strongly suspect that async was necessary for Rust to gain acceptance at, say, Amazon. So it couldn't practically have been designed with a wide-open timeframe. The result is what we have; one can uncharitably call it "half-baked" and tut-tut about the sharp edges, but it's workable if you know what to avoid. (But it's so tempting to imagine what could have been, eh?)