4 ms·

> easier to use from writing a web service to writing a high performance DB Have you looked at what the actual implementation code of tokio / axum etc looks li

by jpc0 2y ago

> easier to use from writing a web service to writing a high performance DB Have you looked at what the actual implementation code of tokio / axum etc looks like? I can't comment on DB because that is quite far out of my wheelhouse but regarding game engines, I've almost universally seen people revert to storing objects in arrays and passing around "handles" which is literally pointers with extra steps... But I guess at least you are protected from some issues there. Rust forces absurd levels of abstraction onto code very early and if you are wrong you need to make sweeping refractors. I really want to love the language, but building bottom up is extremely difficult with it, it may be Stockholm syndrome and familiarity but I can generally get much further into a project much quicker in C++. In Rust it feels like I'm fighting the language and it's not the borrow checker. There are so many great ideas in Rust and I keep trying it because of them, don't get me wrong I do think a safer language is the future but Rust isn't there yet. Every time I try it it's better though.

vlovich123 2y ago
I have actually looked at the interior of Tokio. While there's a lot of complexity there, most of that complexity is in making a highly performing multi-threaded work-stealing runtime rather than anything Rust-specific. Indeed, I find it easier to reason about than in C++ because the ownership rules are enforced and where they're violated is clearly annotated with unsafe & lots of documentation explaining why it's safe. I suspect you'll see similar things in axum but I can't speak to that codebase specifically. I don't think you'd be able to do something meaningfully easier in C+. I think it is Stockholm syndrome. It took me about 2 months to get familiar that it wasn't uncomfortable anymore and 8 months to reach the "I can generate code faster than I ever could in C++". For context consider that I'd spent the prior ~11 years coding on and off in C++ professionally and the prior 10 years before that as a kid learning C++ so C++ was definitely a language I felt at home in. I spend almost no time compared to C++ trying to make the build system work and I can quickly pull in high quality components others have written vs in C++ where I either have to implement it myself, spend time on build integration, or figure out a way to do without.
- 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.
pcwalton 2y ago
> I can't comment on DB because that is quite far out of my wheelhouse but regarding game engines, I've almost universally seen people revert to storing objects in arrays and passing around "handles" which is literally pointers with extra steps... But I guess at least you are protected from some issues there. Regarding game engines, the empirical evidence shows that Bevy has been moving at least as fast as, if not faster than†, comparable C++ engines. I listed all the features I landed in the past year here: https://news.ycombinator.com/item?id=42945730 https://news.ycombinator.com/item?id=42945730 We love to argue on message boards about theoretical or anecdotal productivity of programming languages, but at the end of the day the only thing that matters is what people have actually been doing with the language, and for Rust the answer is "quite a lot, actually". †In my view, Bevy has been moving significantly faster than comparable C++ engines, but I don't need to argue that to make my point.
- jpc0 2y ago
  Don't take it as an attack on game engines in Rust. It really isn't, it's more an observation that people happily work around the fundamental language design and that should be an indicator to the language authors. And they are definitely listening though, when I last took a dive into Rust I faught a lot of weird borrow checker edge cases that I could easily verify as correct. The borrow checker now no longer complains about some of those cases. As I said I think it's a language maturity thing. It will get there.
  - vlovich123 2y ago
    The borrow checker changes you’re talking about is several years old. The next gen borrow checker should solve the remaining annoyances but that’s years away. But I disagree that Rust code breaks down to emulating pointers by way of handles.
    - jpc0 2y ago
      Not entirely what I was saying, it's one of the patterns I've seen and those that use arrays and indexes into arrays as "handles" will also vehemently disagree with me when I say they just implemented "we have pointers at home". Those are pointers, there's slightly more protections with them but depending on how you model it use after free bugs are back on the table when doing that. At least buffer overflows shouldn't be possible since that is runtime checked.

by jpc0 2y ago

vlovich123 2y ago

I have actually looked at the interior of Tokio. While there's a lot of complexity there, most of that complexity is in making a highly performing multi-threaded work-stealing runtime rather than anything Rust-specific. Indeed, I find it easier to reason about than in C++ because the ownership rules are enforced and where they're violated is clearly annotated with unsafe & lots of documentation explaining why it's safe. I suspect you'll see similar things in axum but I can't speak to that codebase specifically. I don't think you'd be able to do something meaningfully easier in C+. I think it is Stockholm syndrome. It took me about 2 months to get familiar that it wasn't uncomfortable anymore and 8 months to reach the "I can generate code faster than I ever could in C++". For context consider that I'd spent the prior ~11 years coding on and off in C++ professionally and the prior 10 years before that as a kid learning C++ so C++ was definitely a language I felt at home in. I spend almost no time compared to C++ trying to make the build system work and I can quickly pull in high quality components others have written vs in C++ where I either have to implement it myself, spend time on build integration, or figure out a way to do without.

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.

pcwalton 2y ago

> I can't comment on DB because that is quite far out of my wheelhouse but regarding game engines, I've almost universally seen people revert to storing objects in arrays and passing around "handles" which is literally pointers with extra steps... But I guess at least you are protected from some issues there. Regarding game engines, the empirical evidence shows that Bevy has been moving at least as fast as, if not faster than†, comparable C++ engines. I listed all the features I landed in the past year here: https://news.ycombinator.com/item?id=42945730 https://news.ycombinator.com/item?id=42945730 We love to argue on message boards about theoretical or anecdotal productivity of programming languages, but at the end of the day the only thing that matters is what people have actually been doing with the language, and for Rust the answer is "quite a lot, actually". †In my view, Bevy has been moving significantly faster than comparable C++ engines, but I don't need to argue that to make my point.

jpc0 2y ago
Don't take it as an attack on game engines in Rust. It really isn't, it's more an observation that people happily work around the fundamental language design and that should be an indicator to the language authors. And they are definitely listening though, when I last took a dive into Rust I faught a lot of weird borrow checker edge cases that I could easily verify as correct. The borrow checker now no longer complains about some of those cases. As I said I think it's a language maturity thing. It will get there.
- vlovich123 2y ago
  The borrow checker changes you’re talking about is several years old. The next gen borrow checker should solve the remaining annoyances but that’s years away. But I disagree that Rust code breaks down to emulating pointers by way of handles.
  - jpc0 2y ago
    Not entirely what I was saying, it's one of the patterns I've seen and those that use arrays and indexes into arrays as "handles" will also vehemently disagree with me when I say they just implemented "we have pointers at home". Those are pointers, there's slightly more protections with them but depending on how you model it use after free bugs are back on the table when doing that. At least buffer overflows shouldn't be possible since that is runtime checked.