4 ms·

That sounds nice on paper. We all like good coding practices. We all like Rust's benefits, not just the memory safety ones. My argument is a cost/benefit analys

That sounds nice on paper. We all like good coding practices. We all like Rust's benefits, not just the memory safety ones. My argument is a cost/benefit analysis; those nice benefits aren't worth the massive cost of rewriting the whole thing in Rust. In an actual business, one has to justify a project's existence, by showing growth, new features, new users. Imagine stopping that while we rewrite a million line codebase. Now imagine a project which doesn't bring in revenue, and just delivers social good, while having out-of-touch executives looking at our resources and headcount like hungry vultures. Rewriting in Rust would have cost us years, and would have killed Google Earth.

zozbot234 5y ago
> rewriting the whole thing It's not something that has to be done wholesale, obviously. Language interop between Rust and C++ is constantly improving, with one goal being to make rewrites happen gradually while keeping the same interface wrt. outside C++ components.
- verdagon 5y ago
  Alas, doing it gradually doesn't make the cost/benefit any better. It might slightly reduce the short-term risk of the product dying, but it would also increase the medium-term cost of the rewrite. The boundary between C++ and Rust code is often a lot trickier than one might think, because one has to reconcile conflicts between C++ paradigms and Rust paradigms... when one considers all of the temporary code that reconciles those conflicts, we see that the cost just went up. And then moving that boundary is tricky to do in a healthy way, especially when using proper A/B testing practices which require us to have both the old and the new code alive in the same binary. Rewriting often sounds like the solution to things, but in practice it's a very risky and costly thing to do. See also: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  - taylodl 5y ago
    A hybrid solution involving C++ and Rust would make your operational costs soar. No sane person with a budget they're being measured against would ever advocate for that. This gets to the whole problem I have with Rust - I don't see its value proposition. If I have an existing C++ project it makes no economic sense to migrate to Rust. If I have a greenfield project then what is Rust bringing me that Go isn't? Keeping in mind it's far easier to build a team comprised of competent Go developers than it is to build one comprised of competent Rust developers. It seems to me Rust fills very niche cases. What am I missing?
    - pjmlp 5y ago
      Nothing really, Rust's killer application are domains where using a language with automatic memory management and support for value types isn't an option, trying to use it elsewhere, while possible is sacrificing productivity.
      - tialaramex 5y ago
        I really don't agree with this. I feel like we have to get pretty heavyweight in terms of data structure complexity before a GC is paying off enough that I'm glad I'm not in Rust productivity-wise. That's across Java, Go, C#, Python. Maybe there's a GC language I should be using where all this feels easier, but if so I don't know what it is.
        pjmlp 5y ago
        We have to agree to disagree then. Having to create borrow checker friendly data structures doesn't bring anything to the table when writing GUI applications (including design tooling), distributed applications (Akka, Orleans, Erlang style, RDMS SP), CLI tooling, compiler tooling.... In what concerns languages with automatic memory management and support for value types, my list is somehow different, D, Nim, C#, F#, Swift, Go, Linear Haskell, Ocaml with Effects, Eiffel, Common Lisp. And I leave Herb's talk regarding those issues with RC types, "CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.” https://youtu.be/JfmTagWcqoE https://youtu.be/JfmTagWcqoE

zozbot234 5y ago

> rewriting the whole thing It's not something that has to be done wholesale, obviously. Language interop between Rust and C++ is constantly improving, with one goal being to make rewrites happen gradually while keeping the same interface wrt. outside C++ components.

verdagon 5y ago
Alas, doing it gradually doesn't make the cost/benefit any better. It might slightly reduce the short-term risk of the product dying, but it would also increase the medium-term cost of the rewrite. The boundary between C++ and Rust code is often a lot trickier than one might think, because one has to reconcile conflicts between C++ paradigms and Rust paradigms... when one considers all of the temporary code that reconciles those conflicts, we see that the cost just went up. And then moving that boundary is tricky to do in a healthy way, especially when using proper A/B testing practices which require us to have both the old and the new code alive in the same binary. Rewriting often sounds like the solution to things, but in practice it's a very risky and costly thing to do. See also: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- taylodl 5y ago
  A hybrid solution involving C++ and Rust would make your operational costs soar. No sane person with a budget they're being measured against would ever advocate for that. This gets to the whole problem I have with Rust - I don't see its value proposition. If I have an existing C++ project it makes no economic sense to migrate to Rust. If I have a greenfield project then what is Rust bringing me that Go isn't? Keeping in mind it's far easier to build a team comprised of competent Go developers than it is to build one comprised of competent Rust developers. It seems to me Rust fills very niche cases. What am I missing?
  - pjmlp 5y ago
    Nothing really, Rust's killer application are domains where using a language with automatic memory management and support for value types isn't an option, trying to use it elsewhere, while possible is sacrificing productivity.
    - tialaramex 5y ago
      I really don't agree with this. I feel like we have to get pretty heavyweight in terms of data structure complexity before a GC is paying off enough that I'm glad I'm not in Rust productivity-wise. That's across Java, Go, C#, Python. Maybe there's a GC language I should be using where all this feels easier, but if so I don't know what it is.
      - pjmlp 5y ago
        We have to agree to disagree then. Having to create borrow checker friendly data structures doesn't bring anything to the table when writing GUI applications (including design tooling), distributed applications (Akka, Orleans, Erlang style, RDMS SP), CLI tooling, compiler tooling.... In what concerns languages with automatic memory management and support for value types, my list is somehow different, D, Nim, C#, F#, Swift, Go, Linear Haskell, Ocaml with Effects, Eiffel, Common Lisp. And I leave Herb's talk regarding those issues with RC types, "CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.” https://youtu.be/JfmTagWcqoE https://youtu.be/JfmTagWcqoE