There's pretty much no reason to not use a memory safe, performant language like Go at this point for infrastructure-ish software.
There's pretty much no reason to not use a memory safe, performant language like Go at this point for infrastructure-ish software.
When they totally could be doing `go get sources.redhat.com...`
If someone works around that on a developer machine, it shouldn't matter, because release builds should still come from an automated system, right?
You say "just 8 years ago" but another way of phrasing that would be "only 4 months after Rust went 1.0". And that's the first release, which means work probably started before Rust went 1.0
>Red Hat is one of the companies that also has a strange C addiction for almost anything.
This is kinda true and I wish it was different, but most of the examples people bring up are ones like the one you brought up. Rust wasn't a "safe choice" at the time they were started.
There's other factors too, like needing to support POWER and Z architectures. If you have a lot of such products written in C, and you have a GCC toolchain team in-house, that's not so difficult. If you have a lot of such products written in Rust, and your LLVM toolchain team is much smaller and the compiler itself less mature on those platforms, it's a bit more challenging. And then the whole issue of dynamic vs. static linking, where there's a ton of organizational inertia in favor of the former.
All that said I think the list of valid excuses is increasingly small nowadays.