I see a lot of hate for what amounts to user controlled and scheduled tasks. Do people understand that async/await is effectively user land task scheduling, which for any high performance networking app is of vital importance. Consider cassandra versus scylladb
Tokio 1.0 – async runtime for Rust
401–410 of 422 posts
Re: Tokio 1.0 – async runtime for Rust
#402Earlier quoted context omitted.
Go's whole approach to concurrency is about avoiding sharing memory; channels suspend in much the same way as async/await yield points.
I like go, but i don’t understand your point. Go seems to like passing pointers over channels, which is pretty far from avoiding shared memory. Unless you start writing code that looks like actor based concurrency, with channels used to pass messages acrross actors. But this isn’t what i’d call idiomatic go.
Passing pointers over channels doesn't necessarily mean you're sharing memory, you could be passing ownership. Pointer or value are both equally idiomatic.
Re: Tokio 1.0 – async runtime for Rust
#403Earlier quoted context omitted.
> it's a choice made by a particular external library Yeah I think it points to a culture problem. In some ways because dependency management is so easy with Cargo, I think it creates the temptation to just throw in some dependencies to make something work without truly understanding the overall complexity of what you're creating. Something very similar happens in the NodeJS world. > it splits the ecosystem This is s…
I think rust is kind of a perfect language for being profligate with dependencies, because the safety guarantees, typing, etc make it very hard to misuse a library, and relatively easy to design a library that is hard to misuse. A lot of what is not enjoyable about rust as a user is really nice when it's being imposed on people who are not you, whose work you're interfacing with.
Just because a library is safe does not make it good. To the point of the previous poster, you might for instance have an http library which does a lot of unnecessary async work behind the scenes to do a simple synchronous request.
If we all have the attitude "it's good/fast because it's rust" this is not going to lead to a lot of cruft making its way into the ecosystem.
Re: Tokio 1.0 – async runtime for Rust
#404Earlier quoted context omitted.
Sorry for the wording, the term blocking is common in network programming. With blocking I mean waiting. For I/O to complete, for time to pass, or for another task to complete something. In event-based programming, functions must not block. Async functions may seem to block, but they don't rely because a state machine is involved.
That does answer my question, but I don't really understand why the distinction is made. To the caller, a function that spends time waiting and a function that spends the same time calculating both look the same, don't they?
The difference is that the runtime can schedule something else if the blocking is async. It looks the same as sync blocking to the caller, but not the scheduler. The point of async is you can write code that looks synchronous but is actually participating in cooperative multitasking.
Re: Tokio 1.0 – async runtime for Rust
#405Earlier quoted context omitted.
Can you elaborate a bit what it is that you find difficult or undesirable about Tokio? Or async/await + some runtime in general? So, I can relate to not wanting to pull in the dependency. But otherwise it seems pretty straightforward to me. You just macro-decorate the main function, sprinkle some async/await around, maybe add a join or a mutex somewhere, and then pretty much forget all about event loops, messaging, t…
> just macro-decorate the main function, sprinkle some async/await around, maybe add a join or a mutex somewhere, and then pretty much forget all about event loops, messaging, threads and whatnot that is ... not how I have experienced it. I work on building highly concurrent systems every day but async drives me insane. to me the fundamental issue is that although the code now reads linearly, it no longer executes li…
You answered jgilias better than I could, I feel exactly the same way. Async is deceptively simple in my opinion, because while it looks arguably even simpler than an explicit state machine, it makes your program flow nonlinear and I find that a lot harder to work with. With blocking code I can mentally step through the code follow causes and consequences easily, with async I feel like I'm watching a scifi movie involving time travel and parallel universes.
And the loss of control is also an issue for me. I write code for memory-constrained environments, with blocking code and OS threads I can usually bound my memory consumption fairly easily. If I surrender the control to a scheduler runtime I feel like it becomes a lot harder, although here I'm willing to concede that it might have more to do with my lack of experience with Tokio than an objective issue.
Re: Tokio 1.0 – async runtime for Rust
#406Earlier quoted context omitted.
Go's whole approach to concurrency is about avoiding sharing memory; channels suspend in much the same way as async/await yield points.
I like go, but i don’t understand your point. Go seems to like passing pointers over channels, which is pretty far from avoiding shared memory. Unless you start writing code that looks like actor based concurrency, with channels used to pass messages acrross actors. But this isn’t what i’d call idiomatic go.
> Unless you start writing code that looks like actor based concurrency, with channels used to pass messages acrross actors. But this isn’t what i’d call idiomatic go.
Isn't that exactly what Go people push? "Don't communicate by sharing memory; share memory by communicating" and all that. If you start pushing pointers to shared memory around then I'd expect all of the problems of traditional multithreading to reappear.
Re: Tokio 1.0 – async runtime for Rust
#407Earlier quoted context omitted.
I can't speak to the same level of depth about the C++ model as the Rust one, but, while you could do those things, it's not the usual way that it works, at least, if I'm understanding your terms correctly. I'll admit that I find your terms in the first bullet pretty confusing, and the second, only slightly. Let's back up slightly. You have: * A future. You can call poll on a future, and it will return you either "no…
This is an awesome rundown of the whole stack. It's almost like you've explained this stuff before. ;) It might sound complicated, but for typical applications almost all of this happens "under the hood". Usually you'll just add an attribute to `main` to start your runtime, then you can compose/await futures without ever needing to think about `poll` and friends. Here's a small example: https://tokio.rs/tokio/tutoria…
Thanks :)
Re: Tokio 1.0 – async runtime for Rust
#408Earlier quoted context omitted.
No, multithreaded synchronous code is not easier to reason about than async. I think most would agree.
You probably think async code can't have deadlocks like threaded code can. Async is still multi-threaded it's just that the threads are done in user-space and contain an implicit global lock.
Notice I didn't say async code is easier to reason about.
Re: Tokio 1.0 – async runtime for Rust
#409Re: Tokio 1.0 – async runtime for Rust
#410Can someone explain to a non-rustacean what Tokio introduces that's not part of Rust? It looks like Rust provides the async/await semantics, so I'm guessing this is an event loop and dispatching system?
> rustafarian The community prefers the term "rustacean" to be as inclusive as possible. Please keep that in mind in the future.
lmao