Yes, there’s absolutely a lot of good reasons to use Rust over Go, even for heavily async tasks, I’m merely saying that Go supporting channels in the language makes it a lot easier to use for async tasks. There’s one proper way to send data between concurrent contexts, and that’s a channel, so it gets used a ton in library code.
Rust could get a lot of that benefit by including channels in the standard library. We could still keep the async reactor code out of the standard library, but we’d need trait definitions there so the channels could hook into them.
I personally think the Rust standard library should ship a complete async solution, with core bits being overridable (like with memory allocation), which would make it a lot easier to write clean async logic. I think the standard library should be single threaded, but be multi-threaded compatible, and then allow third party libraries to provide the multi-threaded capability.
@sugar_in_your_tea#golang is a near perfect aproach for writing concurrency and async code, indeed, but rust already has channels in standard library. My github has a lot of concurrency code using only std library, including examples in atomics, channels, mutexes, conditional variables, etc…
Huh, it has been a while since I did async in Rust. I used Actix to build a multi-protocol game server for a toy project, and the only state staring needed went through the database.
I’ll have to play with async Rust some more. I’ve looked through a lot of async code, and while it looks gross, I haven’t actually written much myself to really get a feel for the ergonomics. For other projects, I’ve just used threads and mutexes, which has been plenty. The closest I’ve gotten was messing with GUIs, but that’s been mostly GTK or IMGUI, which have their own synchronization patterns.
Yes, there’s absolutely a lot of good reasons to use Rust over Go, even for heavily async tasks, I’m merely saying that Go supporting channels in the language makes it a lot easier to use for async tasks. There’s one proper way to send data between concurrent contexts, and that’s a channel, so it gets used a ton in library code.
Rust could get a lot of that benefit by including channels in the standard library. We could still keep the async reactor code out of the standard library, but we’d need trait definitions there so the channels could hook into them.
I personally think the Rust standard library should ship a complete async solution, with core bits being overridable (like with memory allocation), which would make it a lot easier to write clean async logic. I think the standard library should be single threaded, but be multi-threaded compatible, and then allow third party libraries to provide the multi-threaded capability.
@sugar_in_your_tea #golang is a near perfect aproach for writing concurrency and async code, indeed, but rust already has channels in standard library. My github has a lot of concurrency code using only std library, including examples in atomics, channels, mutexes, conditional variables, etc…
https://doc.rust-lang.org/rust-by-example/std_misc/channels.html
https://github.com/jcbritobr/concprog/blob/master/src/threadpool.rs
https://github.com/jcbritobr/concprog/blob/master/src/channels.rs
Huh, it has been a while since I did async in Rust. I used Actix to build a multi-protocol game server for a toy project, and the only state staring needed went through the database.
I’ll have to play with async Rust some more. I’ve looked through a lot of async code, and while it looks gross, I haven’t actually written much myself to really get a feel for the ergonomics. For other projects, I’ve just used threads and mutexes, which has been plenty. The closest I’ve gotten was messing with GUIs, but that’s been mostly GTK or IMGUI, which have their own synchronization patterns.
So maybe it’s good enough as is.