Rust

5980 readers

111 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

EdTheLegendary@programming.dev

kahnclusions@programming.dev

torcherist@programming.dev

Async Rust Is A Bad Language (bitbashing.io)

submitted 1 year ago by fil@programming.dev to c/rust@programming.dev

24 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] wim@lemmy.sdf.org 12 points 1 year ago (1 children)

Maybe it's just me, but isn't async programming a mess in all programming languages?

[–] noli@programming.dev 0 points 1 year ago (3 children)

It's a joy to do async in go IMO

[–] vrighter@discuss.tchncs.de 6 points 1 year ago* (last edited 1 year ago)

not really. first of all async in not the same as threading. And even then, while it makes parallel code easier to write (not easier to reason about), it still has the exact same footguns as anything else, as soon as you venture away from having only one consumer for every producer. Synchronization is still all on you

[–] wim@lemmy.sdf.org 5 points 1 year ago (1 children)

That's a whole different thing to me. That's not async, that's channels and multithreading.

I do that in Rust as well with mcsp channels and it's been fine.

It's the async/await bit that I find incredibly akward all the time.

[–] sugar_in_your_tea@sh.itjust.works 3 points 1 year ago (1 children)

Channels and multithreading are a solution to async problems. Instead of a keyword trying to abstract away the async, you use a mechanism for communicating between coroutines. You can run Go with a single execution thread and still get benefits from goroutines and channels. In fact, Go didn't turn on multithreading until 1.5.

Go solves async with goroutines and channels, not with an async keyword. The runtime is pretty heavy and steps in when standard library functions would block. In other words, it's async by default since blocking IO causes another goroutines to execute.

[–] jcbritobr@mastodon.social 0 points 1 year ago (1 children)

@sugar_in_your_tea @wim
go channels and goroutines are very good and easy to work, but thei cant acquire the performance and security of #tokio. You can write good code and solutions with goroutines, but there are limitations. #Rust async is a bit more difficult to do, but its not so or too complicated or dificult, and you will choose between the two languages by kind of problems you want to solve.

[–] sugar_in_your_tea@sh.itjust.works 1 points 1 year ago (1 children)

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.

[–] jcbritobr@mastodon.social 0 points 1 year ago* (last edited 1 year ago) (1 children)

@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

[–] sugar_in_your_tea@sh.itjust.works 1 points 1 year ago

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.

[–] sugar_in_your_tea@sh.itjust.works 1 points 1 year ago (1 children)

To be fair, a lot of that is because the scheduler detects blocking IO and context switches.

Rust could get really far with Go-style channels.

[–] realharo@lemm.ee 1 points 1 year ago (1 children)

Are Go-style channels different from what Tokio provides? https://tokio.rs/tokio/tutorial/channels

[–] sugar_in_your_tea@sh.itjust.works 3 points 1 year ago

They're very similar, but with very different ergonomics. Go channels are part of the language, so libraries use them frequently, whereas tokio is a separate library and not nearly as ubiquitous. So you'll get stuff like this:

c := make(chan bool)
go func () {
    time.Sleep(time.Second*2)
    c &lt;- true
} ()

select {
case val := &lt;-c:
case _ := &lt;-time.After(time.Second)
}

This lets you implement a simple timeout for a channel read. So the barrier to using them is really low, so they get used a ton.

I haven't looked at the implementation of tokio channels, so I don't know if there's something subtly different, but they do have the same high level functionality.