Let futures be futures
Let futures be futures
Concluding paragraphs are a thinly veiled bash at Golang and its creators. Whatever. I like Go. I like C. I like lots of other languages, for different reasons. Haven't learned Rust yet, but am already tired of the ivory-tower attitude of its proponents.
I would not call it a bash. Go's approach naturally comes up in discussions on async Rust. Thus, it makes sense to at least briefly mentioning the trade-offs that approach has.
I like Go too, but not because it's a good language. I like it because it's the simplest garbage language I have to use regularly, and that puts a cap on how bad it can be. It also got a lot of language-adjacent things right, like tooling.
Heh, 'garbage language' or 'garbage-collected language'? Until Go I considered the two to be the same :)
But yeah... the tooling is a strong point IMO.
(Package management went downhill once the whole GOPROXY thing was introduced. When 'go get' was the simplest way to fetch packages, things were great IMHO ... but I'm not doing big enterprise-y stuff so maybe my view is too narrow as to the issues of 'vendoring', version management etc.)
After using Erlang for a while I became convinced that async anything in interpreted languages is a big design fail. There is a very funny but NSFW (lots of swearing) video bashing node.js along those lines:
The author should look into Koka. As I see it, Koka is at the bleeding edge of effect handling, which is why the async Rust team has taken some nibbles of inspiration from it. Alas, Rust as a whole is far too cemented to overhaul everything for generic effect support, but at least it's been beneficial for async.