Hacker News Reader

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.

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.

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.

> 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.

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-...

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?

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.

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.

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

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.

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.

My assertion is that Rust gets enough of this other stuff right that unlike C++ it doesn't start out more painful than languages I've used with GC. I can only speak for my own experience writing software in these languages and so that doesn't allow for questions like whether Rust programmers are rare or expensive which might influence whether you make a .NET thing or a Rust thing.

When things get more complicated sure, Rust can mean you spend too much time figuring out how lifetimes should best work compared to a GC environment. But even a fancy GC doesn't promise to release unused resources promptly, so for non-memory resources you can end up needing to care about lifetimes anyway, and the GC languages do not prioritise this problem.

FWIW the phrase you probably wanted is "en masse" from the French meaning "as a body" not in mass.

You keep missing the point why I use automatic memory management when describing languages like D and Swift instead of GC.

Exactly to make the point that those languages offer the same deterministic tooling and not mix with how Java does it.

I haven't written any Swift, or D but as I understand it Swift just chooses to do reference counting everywhere. Maybe it at least factors out the places where this is a waste of everybody's time? I can't tell.

I don't see that as any kind of upside over Rust. It sounds like one of those "my first Rust project" codebases full of Arc<Thing> when Box<Thing>, Thing or sometimes even just &Thing would have been appropriate.

In fact this then makes me realise you consider "it has reference counted smart pointers" to be "automatic memory management" but then you say Rust is suited for situations where that isn't possible, does that mean you didn't know Rust has reference counted smart pointers (two kinds even)? Or does it mean you consider all of Rust above core to be superfluous (Rc is in alloc) ? Either way this makes very little sense.

And so I went back and now I'm also puzzling what you think Value Types are and why you believe that's relevant. Is the problem that you bumped your head and now you think Rust is Java ?

This would have been more relevant had Rust existed 30-35 years ago when C++ was ascending to supremacy. As it is, C++ is being pushed further and further into niche use cases and Rust is competing with C++ in those ever-decreasing niche use cases. That was my point in the first place - Rust seems like it's too little, too late. Add Go to the mix and there's even less of a reason to use Rust. It feels like Rust is obsolete before it even got started.

> 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.

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.

Here, http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

Thanks for the link.

I don't see any occurrences of "Rust" in this document...

https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c...

Better like this?

Thanks! This article makes some nice recommendations, but they don't have much to do with Rust, these things have been in a lot of other mainstream languages for a long time. I'm not sure this supports zozbot's claim that the modern trend is to "refactor C++ code so that it's more Rust-like" very strongly.

I also assume they meant that that we should adhere to AxM in C++ (since that's the only thing new Rust brings), to make interop with Rust easier, but I could be interpreting incorrectly.

> But the advantage of Rust goes far beyond mere safety...

Could you say what they are?

For me, it's a pleasant syntax to work with. The code structures make a lot of sense to me. I like the approach of using Result return types instead of exceptions really works well (especially with crates like anyhow and thiserror to abstract away the messiness of how errors are created/propagated) (writing JVM code for my day job, I find myself often wishing for Rust features).

Available in Kotlin and Scala.

True, although they have to coexist with Java exceptions. Also, they target the JVM (I have a vague notion of there being JVM-to-native compilation projects, although some of what makes the JVM appealing would be difficult to impossible to do in native code).

Native code compilers have existed since about 2000 in commercial compilers, and there are JIT caches as well.

Depends what you are comparing it to, but often listed are features of a modern language & type system: expressive generics, pattern matching, sum & product types, iterator chaining, etc

> 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.

An interesting thought, but are you suggesting we could run arbitrary Rust code, unsandboxed, in users' browsers?

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.

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.

If you want to eliminate memory-safety bugs you cannot use unsafe Rust. Restricting yourself to safe Rust also has a performance cost.

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.

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

Rewriting C code in Rust is probably quite economical.