Comment by jpc0 | Hacker News Reader

Comment by jpc0 | Hacker News Reader

Parent Full thread

> 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.

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.

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.

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.

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.

> 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.

That's a perfect characterization - you can still get to the ugliness when you need it (& I don't think it's such a sheer cliff but YMMV). The "python devs wanted to write a low level high perf language" was derogatory suggesting that those authors didn't know what they were doing and crippled the language. It's quite the opposite I think though - they knew exactly what they were doing & made it super easy for developers to write correct code with a simpler mental model of the code.

As for "async as coroutines", you're right that it's a bit more complicated than C++ coroutines, but that's why there's an explicit coroutine mechanic headed your way: https://doc.rust-lang.org/std/ops/trait.Coroutine.html

> The "python devs wanted to write a low level high perf language" was derogatory suggesting that those authors didn't know what they were doing

I didn't mean it as derogatory at all actually, more a matter of it's being pushed to developers that have never used a systems level language and had to deal with the types of algorithms at the systems level, and actually most of them can even do it because the abstractions are great. But those same developers can't see how those abstractions could be implemented and wouldn't know where to look.

Hey at least this chain of comments has helped me understand my dislike of where Rust is positioned and as I said in another comment the language authors are makeing the necessary changes to appease people like me, I'm happy to hear about the corouting mechanic because it adds another checkbox that Rust is at the very least trying to position itself correctly.

You are the first rust "evangelist" that I've had he privilege to chat with that actually didn't make me want to drop the language and go back to C++.

You pointed out where rust is strong without just shouting "you are holding it wrong". Thanks for the great experience.

Neat. I think Rust even today basically is good enough to almost never touch c++ again. The strengths outmatch the weaknesses significantly and you end up at a significantly higher output velocity because the software is more stable and higher quality.

> I didn't mean it as derogatory at all actually, more a matter of it's being pushed to developers that have never used a systems level language and had to deal with the types of algorithms at the systems level, and actually most of them can even do it because the abstractions are great. But those same developers can't see how those abstractions could be implemented and wouldn't know where to look.

While there are certainly people who came to Rust from higher languages and Rust’s safety guarantees makes system- level programming more accessible, the language authors and many early users are very clearly systems engineers and understand the space. That’s why noalias is such a critical part of the language and it turned out that LLVM implemented that incorrectly in a bunch of places because no c++ code actually exercised that attribute all that much (and the noalias is a good chunk of the reason why a straight port of c/c++ code often ends up performing slightly better). Rust is the first language I’ve seen where I’d feel comfortable designing a high performance system and then having someone with a web background also contributing without creating all sorts of problems. That’s why network just is impossible in c++

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.

> 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

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.

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.

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.

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.

It’s possible use after free isn’t actually possible because Rust’s ownership system lets you express lifetimes that the compiler enforces (or you enforce it at runtime yourself).

But handles aren’t uncommon even in c/c++ - it’s nothing to do with the language and more how the author thinks the particular problem domain is best modeled.

Reply on news.ycombinator.com