They really do appear to be all in on avoiding memory leaks from C/CPP:
> Over the next few years we plan to continue replacing C or C++ software with memory safe alternatives in the Let’s Encrypt infrastructure: OpenSSL and its derivatives with Rustls, our DNS software with Hickory, Nginx with River, and sudo with sudo-rs. Memory safety is just part of the overall security equation, but it’s an important part and we’re glad to be able to make these improvements.
It seems like a really challenging endeavor, but I appreciate their desire to maintain uptime and a public service like they do.
Correctness matters, in their particular game that's especially true although I'm doubtful of common insistence that it's better for this or that software to be fast than correct.
Rust is really good for correctness. Take "Hello, World", the obvious toy program. Someone tried giving it various error states instead of (as would be usual) a normal happy terminal environment. In C or C++ the canonical "Hello, World" program terminates successfully despite any amount of errors, it just doesn't care about correctness.
The default Rust Hello World, the one you get out of the box when you make a new project, or you'd show people on a "My First Rust Program" course, will complain about the errors when they happen. Because doing so is correct.
It's the New Jersey style. The priority for these languages was simplicity of implementation. It's more important that you can cobble together a C compiler easily than that the results are useful or worthwhile. This contributed to C's survival, but we pay the price until we give it up.
I don't know. Most serious programs will use write() and then check the return value. In locations where it does not matter (say a test suite that is guaranteed to signal an error but an fprintf() error message could fail in theory) not checking is fine I think.
You will not see the message if you get a panic either ...
> Most serious programs will use write() and then check the return value.
Similarly in Rust, serious programs will use writeln rather than println, and will receive the standard compiler warning if the Result produced by writeln is ignored.
Setting up your environment so that you have to check for errors or the errors propagate doesn't seem to be cheating when the complaint is that other environments often omit checking for errors even when it matters.
> I struggle to understand why they would say that as the opening statement in such a matter-of-fact manner.
TFA's second sentence explains the facts of the matter along with the flavor of Kool-Aid they stock:
> The CA software itself is written in memory safe Golang, but from our server operating systems to our network equipment, lack of memory safety routinely leads to vulnerabilities that need patching.
> I struggle to understand why they would say that as the opening statement in such a matter-of-fact manner.
Because it is a fact. An obvious, obvious fact to anyone who has been working in this ecosystem for any amount of time.
> Drinking the Rust kool-aid by the sound of it.
Would you say the same thing if they'd instead decided to use golang, zig, nim, ocaml, etc.? If not, maybe consider that your emotional stance around Rust is coloring your judgment.
Our modern systems are built on a house of cards where security is concerned. I agree that the "RiiR" meme is tiresome and dumb, but I'm tired of seeing report after report of new vulnerabilities found in foundational libraries and programs. The majority of those vulnerabilities are of the type that Rust won't even let you compile. Languages like C and C++ have their place, but for most applications, there are safer alternatives that don't require harsh compromises or significant trade offs.
Because since the Morris Worm in 1988, there are still plenty of networking facing services that keep being written in C and C++, and without the necessary sanitary precautions.
True, there are plenty of alternatives for many of those networking services, not necessarily Rust.
I hate writing code in golang, because I have to pepper every single function call with `if err != nil`, but then I think about how much C code I've seen that doesn't do that and I wonder how much of it should.
Golang's error handling is safer than C's, but it's more cumbersome than it needs to be. In high-level code, nearly every func you write can return an error, and 99% of the time you're just going to pass the error up. Webserver will catch all and send 4xx or 5xx, for example. Exceptions are a lot more convenient and encourage solid error handling.
Rust chose a good in-between (the "?" unwrapping syntax). In mid or low level code, anything can still fail, but I suspect the performance impact of supporting exceptions or similar for basic operations (integer overflow, div by 0, etc) wouldn't be worthwhile vs just crashing the program or doing something else. Interestingly, Rust doesn't crash in this case: https://doc.rust-lang.org/book/ch03-02-data-types.html
The only thing I seriously plan to use Golang for is implementing a scripting language in my spare time. Its threading model (greenthreads flexibly mapped to OS threads) is attractive for that.
