4 ms·

> I can understand when you need the absolute best performance and you decide to drop to down to C++ Rust is just as fast as C++.

• m00dy 3mo ago
  yeap, unfortunately, only few can see this.
  • lostglass 3mo ago
    It's not though. It's fast enough for many applications but if you need to write a hypervisor then suddenly bounds checks and atomic pointers become significant. Not to mention that rust dramatically reduces your ability to control where memory is allocated. I write in rust and c++, rust isn't as fast. Rust is easier to work with and, compared to the Java crap it's replacing at my work, it's a lot better but it's certainly not zero cost abstractions the way c++ can be, nor is it great for data oriented design because you're hoping the compiler will do the right thing, consistently.
  • flohofwoe 3mo ago
    It depends a lot on the coding style. The sort of Rust code that's heavy on Rc, Arc, Box, RefCell etc... (e.g. the typical band-aids to work around borrow checker restrictions) will be slower than typical C++ code (it's also possible to kill performance in C++ of course, just use std::shared_ptr for everything). E.g. I'd wager that performant Rust code is trickier to write than performant C++ code because you'll have to design your entire Rust codebase around borrow checker restrictions, while C++ lets you 'cheat' without having to fall back to helper types that incur runtime overhead.
• lionkor 3mo ago
  It depends just how fast you need it. C++ is much easier to get to zero abstraction code. In Rust you are constantly fighting the stdlib and other libraries, and you have to litter your hot code with unsafe blocks to get it to stop adding a branch to nearly every object access, be it for bounds checks or over/underflow checks. C++ does a much better job at giving you a zero abstraction API, and you can always drop down to raw pointers if you want, without(!!!!) unsafe blocks and weird tricks. Of course it's unsafe in C++ but the friction to writing a branchless hot loop is muuuuch smaller. When profiling and optimizing Rust code, I very often find myself poring over the generated code, making small changes, reading api docs, and trying again, much more than in C++. Lots of unsafe Rust APIs are not even nearly good enough, even with most checks turned off you will find branches that just branch to panic!(), which is, you guessed it, still more code and a branch than the code would suggest. I get why people think that most systems languages are the same "speed", but they really are not if you are hitting limits of the hardware in your hot loops.
  • imtringued 3mo ago
    How is not having to mark your unsafe code as unsafe a good thing? You couldn't have come up with something more incomprehensible. If 99% of your code doesn't use unsafe, why contaminate 100% of your code base with footguns?
    • afiori 3mo ago
      I agree with your point, but for completeness: > How is not having to mark your unsafe code as unsafe a good thing? The problem with unsafe code in Rust is that IIRC nobody actually figured out yet the "rules" of unsafe i.e. which invariants you can stretch and which can cause UB. My (not super up to date) understanding is that this is an active area of research and progress is being made and also that in practice there are many well understood usages. In short unsafe rust is somewhat worse than C++ as the boundaries of UB are less well understood/defined
      • josephg 3mo ago
        I don’t know what you’re referring to. Unsafe seems pretty well defined for 99% of use cases. Unsafe blocks allow you to dereference raw pointers and call unsafe functions. Thats about it. Remarkably, even in codebases which need a lot of unsafe (eg the kernel), almost all code is safe code.
        • afiori 3mo ago
          What I mean is that unsafe code allows you to eg break std invariants (set invalid length to Vec, unlock a locked mutex, etc.) in ways that can be UB, which of these are UB and which can be used "safely" is sort of unknown. For better or worse they are much more well understood in C as they are front and center of the language semantics
  • hkalbasi 3mo ago
    > over/underflow checks. Integer overflows are not checked in release builds by default, since they are not related to memory safety. On the other hand, rust emits noalias everywhere, which helps in autovectorization.
• yukIttEft 3mo ago
  Is it though. There are so many situations where something is guaranteed to be safe but there is no way to express that in the Rust typesystem, so the only thing you can do is to wrap everything in Arcs and Mutexes, which introduces allocations, pointerchasing and locks
  • iknowstuff 3mo ago
    Hard to imagine a scenario where you don’t need a mutex for correctness and yet somehow Rust forces you to do it? Unless maybe you mean tokio’s work stealing executor, but you can just not use it.
  • afiori 3mo ago
    Just use unsafe then
  • josephg 3mo ago
    I said rust is just as fast as C++. Not safe rust. Use unsafe where it’s appropriate, obviously.