- cross-posted to:
- programminglanguages@lemmit.online
- rust@programming.dev
- cross-posted to:
- programminglanguages@lemmit.online
- rust@programming.dev
You must log in or # to comment.
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.
