6 ms·

I think greenfield projects in Rust make a lot of sense. However, for some existing projects, the math just doesn't check out. I worked on Google Earth for a f

I think greenfield projects in Rust make a lot of sense. However, for some existing projects, the math just doesn't check out. I worked on Google Earth for a few years, and the core was in C++. With ASan and modern C++, memory safety bugs rarely slipped into production... perhaps once every 3-4 months, and this was a million line codebase with 20 engineers working on it. When you consider the cost of a memory safety bug (some users get odd behavior), how rare they happen (because of our good test coverage), and that everything's sandboxed in WASM anyway, there's just not much cost to this kind of memory unsafety bug... and certainly not as much cost as a full rewrite. RIIR makes sense for projects whose memory unsafety causes catastrophic failure. And even then, in some of those cases it makes more sense to use Java or Javascript, which don't expose unsafe operations. RIIR makes sense if someone's doing something with extreme performance requirements, and they're okay with a tiny risk of memory unsafety (from unsafe code). All just my opinion though, I'm sure there are many other great opinions out there.

derefr 5y ago
> and that everything's sandboxed in WASM anyway, there's just not much cost to this kind of memory unsafety bug... Presumably, without the potential for memory-safety bugs, there'd be no need for anything like a WASM sandbox, no? If so, then can't the costs of the WASM sandbox (overhead, potential exploits in the JS/WASM runtime, etc.) be tallied under the column of "costs of memory-safety bugs"? In about the same sense that e.g. the costs associated with running a Web Application Firewall in front of a Wordpress instance, can be blamed on how vulnerable/exploitable Wordpress+PHP are as a stack. If you avoid introducing an attack-surface in the first place, then you don't need to spend effort on guarding it.
- verdagon 5y ago
  An interesting thought, but are you suggesting we could run arbitrary Rust code, unsandboxed, in users' browsers?
  - derefr 5y ago
    Miscommunication, I think. In the context of a web browser, the browser JS execution-context is itself already a sandbox, so running WASM there isn't necessarily doing any sandboxing per se (although it can); it's more just serving as the current state-of-the-art way to host arbitrary native code in the browser. (Too bad about PPAPI.) You'd still be using WASM here whether there was any sandboxing benefit or not. I was instead more thinking about the Google Earth "native" desktop + mobile apps. Those are the environments I presumed you meant when you said that Google Earth is "sandboxed by WASM." Those deploy environments are where adding an intentional sandbox layer would get you some additional safety, over just having the user run a "raw" native C++ executable on their device.
    - verdagon 5y ago
      Thanks for the clarification, yep I meant the web client. We didn't rewrite iOS/Android either, any memory unsafety bugs just cause odd behavior on that user's device, and wouldn't e.g. give an attacker root access to our servers. The costs of the occasional memory unsafety bug didn't seem to approach the cost of a rewrite. I should say, rewriting servers (especially public-facing ones) in a memory-safe language like Rust or Java is a much more reasonable proposition, but for client code, it's a slightly different story.
- atq2119 5y ago
  If you want to eliminate memory-safety bugs you cannot use unsafe Rust. Restricting yourself to safe Rust also has a performance cost.
zozbot234 5y ago
If anything, having such a large code base makes good coding practices even more, not less relevant. It goes without saying that rewrites on something that large - whether to Rust or to some other safety solution, such as C++ with Core Guidelines support - should be targeted to pick the most valuable and lowest hanging fruit first. But the advantage of Rust goes far beyond mere safety, and this is where your comparison with Javascript or even Java might miss the point a little bit. Google Earth itself is a bit like a video game; it doesn't strike me as something where either performance requirements or long-term maintainability are that irrelevant.
- verdagon 5y ago
  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-...
vnorilo 5y ago
Yes - after writing C++ for 30 years I know how to make my life easy with it. If I never touch the wonky and unsafe bits it just works. But man, after trying to watch after a C++ project with other kinds of programmers on it I kind of wish it was built into the compiler. Rust is pretty much what I do by convention. Also when a beginner asks me whether they should start learning C++, prepare for a long uncomfortable silence while I look for the right words.
cryptonector 5y ago
Rewriting C++ code in Rust is probably not economical. Rewriting C code in Rust is probably quite economical.
silent_cal 5y ago
But you have a big advantage working with 20 C++ engineers for a giant company, right? Maybe Rust makes it easier for smaller teams with a normal budget to achieve the same results.

derefr 5y ago

> and that everything's sandboxed in WASM anyway, there's just not much cost to this kind of memory unsafety bug... Presumably, without the potential for memory-safety bugs, there'd be no need for anything like a WASM sandbox, no? If so, then can't the costs of the WASM sandbox (overhead, potential exploits in the JS/WASM runtime, etc.) be tallied under the column of "costs of memory-safety bugs"? In about the same sense that e.g. the costs associated with running a Web Application Firewall in front of a Wordpress instance, can be blamed on how vulnerable/exploitable Wordpress+PHP are as a stack. If you avoid introducing an attack-surface in the first place, then you don't need to spend effort on guarding it.

verdagon 5y ago
An interesting thought, but are you suggesting we could run arbitrary Rust code, unsandboxed, in users' browsers?
- derefr 5y ago
  Miscommunication, I think. In the context of a web browser, the browser JS execution-context is itself already a sandbox, so running WASM there isn't necessarily doing any sandboxing per se (although it can); it's more just serving as the current state-of-the-art way to host arbitrary native code in the browser. (Too bad about PPAPI.) You'd still be using WASM here whether there was any sandboxing benefit or not. I was instead more thinking about the Google Earth "native" desktop + mobile apps. Those are the environments I presumed you meant when you said that Google Earth is "sandboxed by WASM." Those deploy environments are where adding an intentional sandbox layer would get you some additional safety, over just having the user run a "raw" native C++ executable on their device.
  - verdagon 5y ago
    Thanks for the clarification, yep I meant the web client. We didn't rewrite iOS/Android either, any memory unsafety bugs just cause odd behavior on that user's device, and wouldn't e.g. give an attacker root access to our servers. The costs of the occasional memory unsafety bug didn't seem to approach the cost of a rewrite. I should say, rewriting servers (especially public-facing ones) in a memory-safe language like Rust or Java is a much more reasonable proposition, but for client code, it's a slightly different story.
atq2119 5y ago
If you want to eliminate memory-safety bugs you cannot use unsafe Rust. Restricting yourself to safe Rust also has a performance cost.

zozbot234 5y ago

If anything, having such a large code base makes good coding practices even more, not less relevant. It goes without saying that rewrites on something that large - whether to Rust or to some other safety solution, such as C++ with Core Guidelines support - should be targeted to pick the most valuable and lowest hanging fruit first. But the advantage of Rust goes far beyond mere safety, and this is where your comparison with Javascript or even Java might miss the point a little bit. Google Earth itself is a bit like a video game; it doesn't strike me as something where either performance requirements or long-term maintainability are that irrelevant.

verdagon 5y ago
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-...

vnorilo 5y ago

Yes - after writing C++ for 30 years I know how to make my life easy with it. If I never touch the wonky and unsafe bits it just works. But man, after trying to watch after a C++ project with other kinds of programmers on it I kind of wish it was built into the compiler. Rust is pretty much what I do by convention. Also when a beginner asks me whether they should start learning C++, prepare for a long uncomfortable silence while I look for the right words.

cryptonector 5y ago

Rewriting C++ code in Rust is probably not economical. Rewriting C code in Rust is probably quite economical.

silent_cal 5y ago

But you have a big advantage working with 20 C++ engineers for a giant company, right? Maybe Rust makes it easier for smaller teams with a normal budget to achieve the same results.