4 ms·
I see a place for both of them in my toolbox. Go still makes network code and certain models of concurrency stupidly simple. Rust is more of a replacement for
by wybiral 9y ago
I see a place for both of them in my toolbox.
Go still makes network code and certain models of concurrency stupidly simple.
Rust is more of a replacement for C/C++ for me.
- XorNot 9y agoGo confirmed for me what I suspected: which is that I hate hate hate the futures style of async programming. I'm on the lookout for channels and green-threads in Rust (so I can basically write borrow-checked Go-style code in Rust).
- tmzt 9y agoChannels are there but you have to use an API for them. Green threads were removed a few years ago, though there are implementations of co-routines, etc. as crates. Rust is getting an unstable form of async and await as macros/syntax extensions, and there are RFCs discussing adding them to the language in some form. This would still be a wrapper for futures, but a more ergonomic way of using them.
- infogulch 9y agoI'm not entirely convinced that async annotations can't be completely elided. I think that any call stack that touches a sync/async API could have the decision of which to use bubbled up to a top level function via generics.