11–20 of 499 posts
I'm surprised Rust went with a Scala-inspired async/await considering it wasn't well-liked outside of PLT enthusiasts. JavaScript adopted it as I don't think you could bolt any other type of sugar on top of the event loop in browsers... but Rust shouldn't suffer from such baggage.
> The thing I really want to try and get across here is that *Rust is not a language where first-class functions are ergonomic.* So... don’t use first-class functions so much? It’s a systems language, not a functional language for describing algorithms in CS whitepapers. Or use `move` (the article does mention this). There are easy paths in most programming languages, and harder paths. Rust is no exception. The fact…
That would look a lot better as a Trait with four methods.
IMO the only viable way out is through: Rust needs to get the ability to properly abstract over lifetimes and functions that it currently lacks (HKT is a necessary part of doing this cleanly). A good litmus test would be reimplementing all the language control flow keywords as plain old functions; done right this would obviate NLL.
But yeah that's going to take a while, and in the meantime for 99% of things you should just write OCaml. Everyone thinks they need a non-GC language because "muh performance" but those justifications rarely if ever hold up.
I'm surprised Rust went with a Scala-inspired async/await considering it wasn't well-liked outside of PLT enthusiasts. JavaScript adopted it as I don't think you could bolt any other type of sugar on top of the event loop in browsers... but Rust shouldn't suffer from such baggage.
I'm surprised Rust went with a Scala-inspired async/await considering it wasn't well-liked outside of PLT enthusiasts. JavaScript adopted it as I don't think you could bolt any other type of sugar on top of the event loop in browsers... but Rust shouldn't suffer from such baggage.
I'm surprised Rust went with a Scala-inspired async/await considering it wasn't well-liked outside of PLT enthusiasts. JavaScript adopted it as I don't think you could bolt any other type of sugar on top of the event loop in browsers... but Rust shouldn't suffer from such baggage.
Big mistake! I never accomplished what I set out to accomplish.
Most of my experience is in C#, where the difference between async and threaded code is mostly syntax sugar. (Until you get into the details.) (And async code makes writing UI code much cleaner.)
Trying to write async Rust as a novice is downright hostile. The tradeoff of threads makes async code such that it's only worth it if your Rust process will have highly concurrent load; as opposed to C# where refactoring threaded code to async is housekeeping.
I'm someone who wishes I could use Rust for everything, but I'm coming around to the idea that it isn't really suited to everything. It was designed for the problems faced by low-level programmers, and it continues to be something of a revelation in that area, and it has also really punched above its weight in totally unrelated areas, and that's great. But I don't know if we should expect it to be great at those other areas that are so far outside its core wheelhouse. I think it's good that Rust has an option for async, but comparing its async ergonomics to Go may just be an apples-and-oranges thing.
I'm surprised Rust went with a Scala-inspired async/await considering it wasn't well-liked outside of PLT enthusiasts. JavaScript adopted it as I don't think you could bolt any other type of sugar on top of the event loop in browsers... but Rust shouldn't suffer from such baggage.
Do you have a source on people generally disliking async/await? I've become a fan of it in JS.
Where your sync functions have X considerations and your async functions have separate Y considerations - BUT, async/await sugar makes these widely different behaviors look nearly identical - so you get "clean" sync code aesthetics on your asynchronous code and are sort of on your own when tracking the behavior of its implication.