4 ms·

Oh I completely agree Tokio is a complex piece of software, but my point was you need to implement a decent amount of that even for trivial cases where Tokio is

by jpc0 2y ago

Oh I completely agree Tokio is a complex piece of software, but my point was you need to implement a decent amount of that even for trivial cases where Tokio isn't needed and therefore the default response is to just pull in Tokio. Part of the complexity for me at least in async Rust was that it is some weird mix between coroutines and completion handlers. It's a pretty nice abstraction with once you wrap your head around it but how many Rust devs would be able to do that? Should I find a performance regression and need to dive in to the code it takes a lot of unknown unknown to be explored because what is actually happening is hidden from you by the abstraction and the Async book's response is "don't worry about that just use tokio". And the "advanced" section is incomplete. I've almost always found the complexity of these systems to be reasonable when I've dug through it, but I had to manually mess with Rust code to understand the async model, the book failed to explain what it is and when it clicked it made a ton of sense. Maybe my issue is that Rust just forces abstractions down your throat and says "trust me you need it" but I would much rather discover why and even find a more relevant abstraction. The last example I made still stands, there is so much complexity caused by abstractions that the wgpu "book" recommends an older version of winit because the current version made API changes that requires a lot of code change. Winit 0.30 released almost a year ago, I understand that it is likely a volunteer maintainer there but if the language allowed for easy refactoring why has it been a year? The fact that the webgpu standard is still in active development likely adds to that.

the__alchemist 2y ago
Commenting on two loosely-coupled things here! The WGPU/Winit compatibility situation is indeed a mess. (Throw EGUI in there too if you're into that...) I was able to get all of them onto the latest, but it was an adventure of troubleshooting, and asking for help on Discord, Github etc. I think this could have been avoided by adding current and/or practical examples to the WGPU repo and/or docs. So, documentation problem maybe? Most of the examples are too provincial or trivial to use as a basis for building a practical project. (Or upgrading one!) Count me as someone who can't grok Async. I've tried several times. It doesn't stick to my brain, and/or I'm not sure how to keep it from propagating through the code. I've come to the realization that I will probably never get it, and/or see eye-to-eye with the rust community on this. Most of the web ecosystem will remain off-limits.
vlovich123 2y ago
Async rust is purely a state machine equivalent to c++ coroutines. There’s not really any more magic than that within the language itself. In other words, async rust is syntactic sugar and nothing else. Tokio is a work stealing runtime that then layers other requirements on it (eg futures must be send to support work stealing). This is similar to Apple’s libdispatch. I’m not sure what performance problems or other magic you’re referring to but it’s hard to answer non-specific gripes with information. It sounds like you’re saying it should be easier to roll your own runtime and there’s slow progress on standardizing some of the pieces. But there’s a lot of runtimes you can pick from (async-std, snol, glommio, monoio, etc). It’s fine that implementing a runtime is complex because a lot of that complexity is inherent (Rust adds some extra boilerplate but that’s all it really is) I haven’t really found Rust’s async to be all that hard to grok. It’s got some annoying boilerplate in some places where there’s impedance mismatches in very rare hyper specific cases but those don’t normally come up.
- jpc0 2y ago
  From what I played around with Rust futures are not entirely coroutines but a mixture between coroutines and sender / receiver model. I'm pretty sure C++ will end up somewhere similar in the end or at least most libraries will model it that way. Effectively the language has built around the idea of a runtime being needed at all whereas C++ coroutines ( and coroutines in general ) don't need a runtime. They are just state machines with syntactic sugar. In Rust something that get's awaited is expected to inform the runtime of when it should be continued. You cannot just have a bunch of coroutines that call each other, you must build a basic runtime even if it is just doing normal coroutines. Once that clicked to me it made a lot more sense but it was pretty annoying seeing syntax for coroutines but not being able to just use them as coroutines. And I have no specific performance gripes, it's more that instead of just needing to understand he CS fundamentals, I also need to understand how the language decided to implement those CS fundamental and abstract them away. I think possibly being able to grok Rust async model being easy for you is slightly clouding the complexity of it. If you know the complexity of what is needed to do mutltithreaded async well then it's not hard to wrap your head around why it was done that way, and as I said I found the implementation beautiful when I understood it, but there was no documentation that mentions it and the only documentation is surface level. As one of the other comments here said, it's like python devs wanted to write a low level high performance language. All the knobs are there but they decided to hide them away behind abstractions that theoretically make the happy path easy, but slightly off the happy path you get thrown into the deep end. In C / C++ world there isn't any kiddie pool, all the uglyness is on display.

by jpc0 2y ago

the__alchemist 2y ago

Commenting on two loosely-coupled things here! The WGPU/Winit compatibility situation is indeed a mess. (Throw EGUI in there too if you're into that...) I was able to get all of them onto the latest, but it was an adventure of troubleshooting, and asking for help on Discord, Github etc. I think this could have been avoided by adding current and/or practical examples to the WGPU repo and/or docs. So, documentation problem maybe? Most of the examples are too provincial or trivial to use as a basis for building a practical project. (Or upgrading one!) Count me as someone who can't grok Async. I've tried several times. It doesn't stick to my brain, and/or I'm not sure how to keep it from propagating through the code. I've come to the realization that I will probably never get it, and/or see eye-to-eye with the rust community on this. Most of the web ecosystem will remain off-limits.

vlovich123 2y ago

Async rust is purely a state machine equivalent to c++ coroutines. There’s not really any more magic than that within the language itself. In other words, async rust is syntactic sugar and nothing else. Tokio is a work stealing runtime that then layers other requirements on it (eg futures must be send to support work stealing). This is similar to Apple’s libdispatch. I’m not sure what performance problems or other magic you’re referring to but it’s hard to answer non-specific gripes with information. It sounds like you’re saying it should be easier to roll your own runtime and there’s slow progress on standardizing some of the pieces. But there’s a lot of runtimes you can pick from (async-std, snol, glommio, monoio, etc). It’s fine that implementing a runtime is complex because a lot of that complexity is inherent (Rust adds some extra boilerplate but that’s all it really is) I haven’t really found Rust’s async to be all that hard to grok. It’s got some annoying boilerplate in some places where there’s impedance mismatches in very rare hyper specific cases but those don’t normally come up.

jpc0 2y ago
From what I played around with Rust futures are not entirely coroutines but a mixture between coroutines and sender / receiver model. I'm pretty sure C++ will end up somewhere similar in the end or at least most libraries will model it that way. Effectively the language has built around the idea of a runtime being needed at all whereas C++ coroutines ( and coroutines in general ) don't need a runtime. They are just state machines with syntactic sugar. In Rust something that get's awaited is expected to inform the runtime of when it should be continued. You cannot just have a bunch of coroutines that call each other, you must build a basic runtime even if it is just doing normal coroutines. Once that clicked to me it made a lot more sense but it was pretty annoying seeing syntax for coroutines but not being able to just use them as coroutines. And I have no specific performance gripes, it's more that instead of just needing to understand he CS fundamentals, I also need to understand how the language decided to implement those CS fundamental and abstract them away. I think possibly being able to grok Rust async model being easy for you is slightly clouding the complexity of it. If you know the complexity of what is needed to do mutltithreaded async well then it's not hard to wrap your head around why it was done that way, and as I said I found the implementation beautiful when I understood it, but there was no documentation that mentions it and the only documentation is surface level. As one of the other comments here said, it's like python devs wanted to write a low level high performance language. All the knobs are there but they decided to hide them away behind abstractions that theoretically make the happy path easy, but slightly off the happy path you get thrown into the deep end. In C / C++ world there isn't any kiddie pool, all the uglyness is on display.