[c_crank]

I wouldn't trust Googlers as a measure of any sort of quality, given their love of Go.

C code relying on tons of macros will be harder to read then C code that delegates preprocessing to another language. Rust code that leans heavily into the ML features and unwrap.parent.unwrap.parent.unwap... will be a lot more unpleasant than Rust code written to just get the bit shifting job done. I imagine it really depends on the code base.

[jeffbee]

You might be overestimating the popularity of Go within Google.

That said, a tool like sudo should be written almost entirely in a very high-level language that is easy to use and review. C, C++, or even Rust should be reserved for places where the system interface requires it, if there are any such points of interface.

[Chabsff]

On the flip side, languages like C,C++ and Rust have the major benefit of having next to no runtime component to it, allowing trace-driven fuzz testing to achieve a much higher level of confidence in its test coverage. For a tool like sudo, this can matter a lot.

[nullc]

I think this is really important and it's a big part of what makes it unrealistic to write critical software in Python or Java: It's too slow to get extremely deep testing, even with fancy tricks like snapshotting the execution state to avoid startup costs.

But, that said, Rust code compiled in debug mode which required to get integer overflow detection is slow enough that it severely degrades the ability to use fuzz testing on many codebases, FWIW. I believe the reason is that debug mode always disables numerous optimizations that are required to make rust performant at all because of all the boilerplate emitted by earlier stages of compilation.

AFAIK there isn't a way to get the equivalent of GCC's "-fsanitize=undefined" (or -ftrapv) for checking for unexpected overflows at a performance cost similar to "-fsanitize=undefined" performance cost on C code.

It's still a much better situation than python or java, I think-- but an area that could use improvement which won't be improved if rust is above criticism.

[steveklabnik]

You can pretty trivially turn on overflow checks yet compile with all of the other release options as normal. It's one line in cargo.toml or one flag to rustc.

[nullc]

What is the one line? (I shall benchmark!)

[steveklabnik]

iirc it's `-C overflow-checks=y` to rustc or

  [profile.release]
  overflow-checks = false

in cargo.toml.

I would probably use the flags with RUSTFLAGS to make sure that it goes to all dependencies and not just the crate you're building, if what you're building has dependencies.

[c_crank]

A job for Common Lisp!

[thwd]

Huh? Go has its tradeoffs, some people don't like it and that's fine. But nobody can deny that it is by far one of the most 'readable and reviewable' (the argument in question) mainstream languages.

[c_crank]

The praise of Go didn't end with it being just readable, but also 'brutally pragmatic' and all that.

If Googlers think that Rust code is just as readable as Go, even though Rust obviously makes tradeoffs against readability for other features, I would be tempted to mark that as Googlers just having a culture about being overeager to think the tools they are using are the best.

[earthling8118]

Why can't I deny that it is readable and reviewable? I don't think it is, basically at all. It gets evangelized as if it is but I have yet to see a compelling argument that can convince me. I've had the displeasure of having to dive into some codebases and I specifically hate it for that reason.

[thwd]

Well, I can't speak for you, of course. I also haven't seen that code you reviewed. And I won't try to evangelize you. I'd say, in a nutshell, that Go is readable and reviewable because its grammar consists of the C-style basis that most every imperative language has, and not much more. It's the lack of features that makes it very 'WYSIWYG'.