5 ms·

Rust has very real limitations and trade-offs. It compiles slow and the binaries are large. The compiler also makes performance sacrifices that makes it general

Rust has very real limitations and trade-offs. It compiles slow and the binaries are large. The compiler also makes performance sacrifices that makes it generally slower than C. I'm sure the language will continue to be successful, but it hasn't "won".

pkulak 2y ago
Why do you say slower than C? I’ve never seen a reason to believe they’re anything but roughly equivalent.
- Defletter 2y ago
  The last I heard, Rust had issues with freeing memory when it wouldn't need to, particularly with short-lived processes (like terminal programs) where the the Rust program would be freeing everything while the C version would just exit out and let the operating system do cleanup.
  - asa400 2y ago
    Rust has ManuallyDrop, which is exactly the functionality you’re describing. It works just fine for those types of programs. The speed of the two is going to be largely dependent on the amount of effort that has gone into optimizing either one, not on some theoretical performance bound. They’re both basically the same there. There are tons of examples of this in the wild at this point.
    - zozbot234 2y ago
      ManuallyDrop seems overkill when you have Box::leak().
      - edflsafoiewq 2y ago
        You may also be able to simply exit() before your allocations get dropped.
- Narew 2y ago
  From my experience on C++ vs Rust on test algorithm. For a naive algorithm implementation rust is usually slightly faster than C++. But when you try to optimise stuff, it's the opposite. It's really hard to optimise Rust code, you need to put lots of unsafe and unsafe is not user-friendly. Rust also force you on some design that are not always good for performance.
jicea 2y ago
I maintain a Rust project that is ~50,000 loc [1]. I've never felt that compiling is slow, in the contrary it's always a pleasure to see how fast the project compiles (at least in debug). In release, build time is longer but in this case, it's in the CI/CD so it doesn't bother me. We try to be very conservative with adding dependencies so it may help compilation time. Also I'm coming from a Java/Kotlin world so a lot of things appear like fresh air in comparison... [1]: https://github.com/Orange-OpenSource/hurl https://github.com/Orange-OpenSource/hurl

pkulak 2y ago

Why do you say slower than C? I’ve never seen a reason to believe they’re anything but roughly equivalent.

Defletter 2y ago
The last I heard, Rust had issues with freeing memory when it wouldn't need to, particularly with short-lived processes (like terminal programs) where the the Rust program would be freeing everything while the C version would just exit out and let the operating system do cleanup.
- asa400 2y ago
  Rust has ManuallyDrop, which is exactly the functionality you’re describing. It works just fine for those types of programs. The speed of the two is going to be largely dependent on the amount of effort that has gone into optimizing either one, not on some theoretical performance bound. They’re both basically the same there. There are tons of examples of this in the wild at this point.
  - zozbot234 2y ago
    ManuallyDrop seems overkill when you have Box::leak().
    - edflsafoiewq 2y ago
      You may also be able to simply exit() before your allocations get dropped.
Narew 2y ago
From my experience on C++ vs Rust on test algorithm. For a naive algorithm implementation rust is usually slightly faster than C++. But when you try to optimise stuff, it's the opposite. It's really hard to optimise Rust code, you need to put lots of unsafe and unsafe is not user-friendly. Rust also force you on some design that are not always good for performance.

jicea 2y ago

I maintain a Rust project that is ~50,000 loc [1]. I've never felt that compiling is slow, in the contrary it's always a pleasure to see how fast the project compiles (at least in debug). In release, build time is longer but in this case, it's in the CI/CD so it doesn't bother me. We try to be very conservative with adding dependencies so it may help compilation time. Also I'm coming from a Java/Kotlin world so a lot of things appear like fresh air in comparison... [1]: https://github.com/Orange-OpenSource/hurl https://github.com/Orange-OpenSource/hurl