4 ms·

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

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
      - tialaramex 5y ago
        We certainly do disagree on this. Even the first chunk of Herb's talk, before you get to reference counting - illustrates why you might feel more comfortable in another language compared to C++, as once again C++ has the wrong defaults. Rust's defaults are better. Nullable shouldn't be the default. It's really hard to undo this bad decision, it's not one of the easy ones where I think C++ realistically could (but still won't) just fix it, but it's still a mistake. By getting this wrong C++ adds an unnecessary burden. Since Rust doesn't get this wrong that burden isn't present. I am never worrying that the Box<Thing> in a Rust structure might not be there, by definition it's a Thing in a Box, if it might not be there that would be written Option<Box<Thing>> and the compiler would let me know if I ever forgot to account for the None case. And it keeps happening. Later Herb wants an array of known-at-runtime size on the heap, so, he makes one with unique_ptr but of course by default C++ doesn't remember how big this is, so he needs to make sure he tracks it separately, more anxiety. Rust can Vec::into_boxed_slice() and the resulting slice automatically remembers how big it is, even though you've given up the vector's ability to grow or shrink. The machine representation ends up the same if you do it right in both languages, but C++ gives the programmer another thing to worry about.
        pjmlp 5y ago
        Except that still doesn't make Rust better than the alternatives with automatic memory management outside kernels, drivers and domains where Ada/Spark is being used nowadays. Even Google isn't comfortable into pushing Rust into app developers for their OSes, despite the amount of adoption at kernel and driver. So when Android comes out with Rust Compose, Fuchsia does Rustter, or Native Cloud folks migrate in mass to Rust, then I might eat my hat. Naturally you might refer to Rust/WinRT, whose tooling is a joke versus C++/WinRT, let alone using .NET alongside Blend and VS. Doable sure, then again there are people that also insist into using COM from C, regardless of how sane that might look like in practice. So unless Rust reaches a state where ownership is transparent to app developers and distributed computing stacks, we will keep on disagreeing.
zozbot234 5y ago
> one has to reconcile conflicts between C++ paradigms and Rust paradigms... The modern trend is closer to refactoring C++ code so that it's more Rust-like, not the other way around. The C++ Core Guidelines include plenty of indications on "paradigms" and overall design, so this is something C++ developers are being asked to do anyway. But unlike these, Rust is fully intended to ensure no unsafety in the safe subset.
- verdagon 5y ago
  This isn't true at all IME. Rust's paradigms are great a lot of the time, but the best C++ code does not necessarily look like Rust code in all situations. There are a lot of patterns in modern C++ which the borrow checker rejects, for example the observer pattern and dependency injection (the pattern, not the frameworks), which are often the best tool for the situation. Also, are you saying that the C++ Core Guidelines encourage us to make code more Rust-like? I would love to read up on that, if you have a source.
  - pjmlp 5y ago
    Here, http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
    - verdagon 5y ago
      Thanks for the link. I don't see any occurrences of "Rust" in this document...
      - pjmlp 5y ago
        https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c-core-check/ https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c... Better like this?
        verdagon 5y ago

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
    - tialaramex 5y ago
      We certainly do disagree on this. Even the first chunk of Herb's talk, before you get to reference counting - illustrates why you might feel more comfortable in another language compared to C++, as once again C++ has the wrong defaults. Rust's defaults are better. Nullable shouldn't be the default. It's really hard to undo this bad decision, it's not one of the easy ones where I think C++ realistically could (but still won't) just fix it, but it's still a mistake. By getting this wrong C++ adds an unnecessary burden. Since Rust doesn't get this wrong that burden isn't present. I am never worrying that the Box<Thing> in a Rust structure might not be there, by definition it's a Thing in a Box, if it might not be there that would be written Option<Box<Thing>> and the compiler would let me know if I ever forgot to account for the None case. And it keeps happening. Later Herb wants an array of known-at-runtime size on the heap, so, he makes one with unique_ptr but of course by default C++ doesn't remember how big this is, so he needs to make sure he tracks it separately, more anxiety. Rust can Vec::into_boxed_slice() and the resulting slice automatically remembers how big it is, even though you've given up the vector's ability to grow or shrink. The machine representation ends up the same if you do it right in both languages, but C++ gives the programmer another thing to worry about.
      - pjmlp 5y ago
        Except that still doesn't make Rust better than the alternatives with automatic memory management outside kernels, drivers and domains where Ada/Spark is being used nowadays. Even Google isn't comfortable into pushing Rust into app developers for their OSes, despite the amount of adoption at kernel and driver. So when Android comes out with Rust Compose, Fuchsia does Rustter, or Native Cloud folks migrate in mass to Rust, then I might eat my hat. Naturally you might refer to Rust/WinRT, whose tooling is a joke versus C++/WinRT, let alone using .NET alongside Blend and VS. Doable sure, then again there are people that also insist into using COM from C, regardless of how sane that might look like in practice. So unless Rust reaches a state where ownership is transparent to app developers and distributed computing stacks, we will keep on disagreeing.

zozbot234 5y ago

> one has to reconcile conflicts between C++ paradigms and Rust paradigms... The modern trend is closer to refactoring C++ code so that it's more Rust-like, not the other way around. The C++ Core Guidelines include plenty of indications on "paradigms" and overall design, so this is something C++ developers are being asked to do anyway. But unlike these, Rust is fully intended to ensure no unsafety in the safe subset.

verdagon 5y ago
This isn't true at all IME. Rust's paradigms are great a lot of the time, but the best C++ code does not necessarily look like Rust code in all situations. There are a lot of patterns in modern C++ which the borrow checker rejects, for example the observer pattern and dependency injection (the pattern, not the frameworks), which are often the best tool for the situation. Also, are you saying that the C++ Core Guidelines encourage us to make code more Rust-like? I would love to read up on that, if you have a source.
- pjmlp 5y ago
  Here, http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
  - verdagon 5y ago
    Thanks for the link. I don't see any occurrences of "Rust" in this document...
    - pjmlp 5y ago
      https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c-core-check/ https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c... Better like this?
      - verdagon 5y ago