Comment by zelly | Hacker News Reader

Comment by zelly | Hacker News Reader

Memory errors are not as big of an issue in the real world as the designers of Rust seem to assume. Andrei Alexandrescu has this quote about how Rust skipped leg day. You should all look it up. Here's what actually matters, in the real world, for the type of programs I'd choose Rust or a Rust-adjacent language:

- Fast compile times

- Easy build system. Must be parallel, saturate all cores, and handle distributed builds as a built-in first-class feature. Should be able to produce static binaries or dynamically linked binaries. Should be able to consume binary dependencies (that means a stable ABI).

- Optimized, fuzzed, highly-tested, standards compliant web stack built-in

- Ability to compile CUDA kernels, built-in

- Automatic memory management with an escape hatch for where manual is necessary

- Rich metaprogramming and compile-time reflection

- Created by or funded by a large U.S. corporation so that PMs are likely to choose it.

- IDE/LSP language server/editor plugins maintained by the language designers

Failing this, you are an academic language, not a real world industry programming language in 2020.

> Memory errors are not as big of an issue in the real world as the designers of Rust seem to assume.

Microsoft and Google have both reported that memory safety errors make up about 70% of their security vulnerabilities.

Still, security issues are secondary. The primary issue is always to make things work. You have no security to worry about if you don't have a working software.

That is solved by using garbage collection.

There are times you need manual memory management. Then there are other times you don't (the vast majority of use cases). Rust forces you to constantly pretend that memory management matters, which gets quickly tiresome.

Not everyone is working on Chromium or Windows. The reality of the matter is that for most real-world software development security doesn't matter at all.

How many percent of all errors are memory safety errors? Why did Google choose C/C++ for Fuchsia after evaluating also Rust? How come, Actix announced a new version with memory leaks fixed?

> How many percent of all errors are memory safety errors?

They did not release those numbers.

> Why did Google choose C/C++ for Fuchsia after evaluating also Rust?

A couple of things here:

* We don't actually know if they did evaluate Rust for the kernel or not.

* At the time they would have been making that evaluation, Rust was one year past 1.0, and was significantly less mature than it is now.

* They had a bunch of people who had experience with existing kernels that were in C and C++, and in fact, based Zircon on one of them: LK.

All of these are good reasons to pick what they picked. However, there's one more thing here, and that's that Fuchsia is a microkernel, and so the kernel is a lot smaller than in other OSes. Rust is used for a bunch of components that would be in the kernel if Fuchsia was a monolithic kernel.

> How come, Actix announced a new version with memory leaks fixed?

Well, first of all, memory leaks aren't a memory safety issue, so this would be irrelevant. However, Actix had actual memory safety issues as well, and did fix those. This happened because the author used a lot of unsafe that they didn't need to. This is pretty straightforward though; it was easy to find those issues because of the way that Rust works, and then they were fixed. That's kind of the point!

- Easy build system. Must be parallel, saturate all cores, and handle distributed builds as a built-in first-class feature. Should be able to produce static binaries or dynamically linked binaries. Should be able to consume binary dependencies (that means a stable ABI).

Rust can actually be built with Bazel. The tooling an ecosystem for doing that is nowhere as good as Cargo and I really wish the Rust team would focus more on supporting other build systems as first class (i.e. not having half the conventions for packages being set by Cargo - things like build.rs output syntax, the various environment variables), since they bring a lot of mature tooling and performance to the table.

Reply on news.ycombinator.com