3 ms·

I’m sure I’m missing context, and presumably there are other benefits, but 5-15% improvement is such a small step to justify rewriting codebases. I also wonder

I’m sure I’m missing context, and presumably there are other benefits, but 5-15% improvement is such a small step to justify rewriting codebases. I also wonder how much of an improvement you’d get by just asking for a “simple rewrite” in the existing language. I suspect there are often performance improvements to be had with simple changes in the existing language

tdiff 2y ago
I agree that simple rewriting could have given some if not all perf benefits, but can it be the case that rust forces us to structure code in a way that is for some reason more performant in some cases? 5-15% is a big deal for a low-level foundational code, especially if you get it along with some other guarantees, which may be of greater importance.
turtletontine 2y ago
Far better justification for a rewrite like this is if it eases maintenance, or simplifies building/testing/distribution. Taking an experienced and committed team of C developers with a mature code base, and retraining them to rewrite their project in Rust for its own sake is pretty absurd. But if you have a team that’s more comfortable in Rust, then doing so could make a lot of sense - and, yes, make it easier to ensure the product is secure and memory-safe.
- johnisgood 2y ago
  > if you have a team that’s more comfortable in As is the case with any languages, of course, it is not in favor (nor against) Rust.
- maccard 2y ago
  Disagree - a rewrite for “maintainability” is an engineer saying they want to rewrite in their preferred language. I wouldn’t allow someone on my team to rewrite a core dependency for “maintainability”, but I absolutely would if they suggested it would be faster and safer.
  - ForTheKidz 2y ago
    > a rewrite for “maintainability” is an engineer saying they want to rewrite in their preferred language Not necessarily—sometimes languages are especially poorly suited for tasks or difficult to hire for.
    - maccard 2y ago
      We’re talking about a rust rewrite of a fairly core level library. I don’t think C is inherently unsuitable or difficult to hire for. If the library was in Fortran then maybe. But yes you are technically correct, congratulations.
      - ForTheKidz 2y ago
        I was responding to a general claim. In any case, I certainly disagree that C is suitable in 2025 for the vast majority of possible use-cases. For fun? Sure, but not for shipping code you want to rely on. Obviously the code isn't going anywhere, and obviously we DO have reliable code we've built with C. But acting like C and Rust deliver equivalent value is simply farcical: you choose C for rapid development and cheap devs (or some other niche concern, like using an obscure embedded arch), and you choose rust to solve the problems that C introduced.
        johnisgood 2y ago
        Million dollar question: why Rust over <insert any memory safe language>? Common Lisp? OCaml, Ada / SPARK, etc. if not C?
sedatk 2y ago
> 5-15% improvement is such a small step to justify rewriting codebases They hadn't expected any perf improvements at all. Quite the opposite, in fact. They were surprised that they saw perf improvements right away.
pdimitar 2y ago
Even 5% on a hot path are quite the big gains, actually. Furthermore, they said that they did not expect any performance gains. They did the rewrite for other reasons and got the unexpected bonus of extra performance.
maccard 2y ago
There are hopefully very few things that can be done to low level building blocks. A 15% improvement is absolutely worth it for a library as widely used as a compression library.

tdiff 2y ago

I agree that simple rewriting could have given some if not all perf benefits, but can it be the case that rust forces us to structure code in a way that is for some reason more performant in some cases? 5-15% is a big deal for a low-level foundational code, especially if you get it along with some other guarantees, which may be of greater importance.

turtletontine 2y ago

Far better justification for a rewrite like this is if it eases maintenance, or simplifies building/testing/distribution. Taking an experienced and committed team of C developers with a mature code base, and retraining them to rewrite their project in Rust for its own sake is pretty absurd. But if you have a team that’s more comfortable in Rust, then doing so could make a lot of sense - and, yes, make it easier to ensure the product is secure and memory-safe.

johnisgood 2y ago
> if you have a team that’s more comfortable in As is the case with any languages, of course, it is not in favor (nor against) Rust.
maccard 2y ago
Disagree - a rewrite for “maintainability” is an engineer saying they want to rewrite in their preferred language. I wouldn’t allow someone on my team to rewrite a core dependency for “maintainability”, but I absolutely would if they suggested it would be faster and safer.
- ForTheKidz 2y ago
  > a rewrite for “maintainability” is an engineer saying they want to rewrite in their preferred language Not necessarily—sometimes languages are especially poorly suited for tasks or difficult to hire for.
  - maccard 2y ago
    We’re talking about a rust rewrite of a fairly core level library. I don’t think C is inherently unsuitable or difficult to hire for. If the library was in Fortran then maybe. But yes you are technically correct, congratulations.
    - ForTheKidz 2y ago
      I was responding to a general claim. In any case, I certainly disagree that C is suitable in 2025 for the vast majority of possible use-cases. For fun? Sure, but not for shipping code you want to rely on. Obviously the code isn't going anywhere, and obviously we DO have reliable code we've built with C. But acting like C and Rust deliver equivalent value is simply farcical: you choose C for rapid development and cheap devs (or some other niche concern, like using an obscure embedded arch), and you choose rust to solve the problems that C introduced.
      - johnisgood 2y ago
        Million dollar question: why Rust over <insert any memory safe language>? Common Lisp? OCaml, Ada / SPARK, etc. if not C?

sedatk 2y ago

> 5-15% improvement is such a small step to justify rewriting codebases They hadn't expected any perf improvements at all. Quite the opposite, in fact. They were surprised that they saw perf improvements right away.

pdimitar 2y ago

Even 5% on a hot path are quite the big gains, actually. Furthermore, they said that they did not expect any performance gains. They did the rewrite for other reasons and got the unexpected bonus of extra performance.

maccard 2y ago

There are hopefully very few things that can be done to low level building blocks. A 15% improvement is absolutely worth it for a library as widely used as a compression library.