Comment

BatmanAoD@programming.dev ⁨9⁩ ⁨months⁩ ago

I very much understand thinking that Rust has too much hype, but the differences between C and Rust are so fundamental that “switching between” them just to “keep your interest fresh” seems ill-advised to me. To be honest, your statements about both C and Rust so far seem pretty superficial; have you actually used Rust for anything nontrivial?

C syntax is simple, yes, but C semantics are not; there have been numerous attempts to quantify what percentage of C and C++ software bugs and/or security vulnerabilities are due to the lack of memory safety in these languages, and although the results have varied widely, the most conservative estimate (this blog post about curl; see the section “C is unsafe and always will be”) ended up with an estimate of 40%, or 50% if you only count critical bugs. If I recall correctly, Microsoft did a similar study on one of their projects and declared a rate closer to 70%.

This means that the choice of language is not just about personal preference. Bugs aren’t just extra work for software developers; they affect all users of software, which means they affect pretty much everyone. And, crucially, they’re not just annoyances; cyberattacks of various kinds are extremely prevalent and can have a huge impact on people. So if 50% or more of critical software vulnerabilities are due to the choice of language, then that is a very good reason to pick a safer language.

Rust is not the only choice for memory-safe languages. If you like the simplicity of C, you should definitely learn Go (it’s explicitly designed to be as simple as possible to learn). But I would also strongly recommend looking into Zig, which hews much closer to C than Rust does; in fact, it has probably the best interoperability with C of any modern language.

source

Sort:hotnew top

lysdexic@programming.dev ⁨9⁩ ⁨months⁩ ago

C syntax is simple, yes, but C semantics are not; there have been numerous attempts to quantify what percentage of C and C++ software bugs and/or security vulnerabilities are due to the lack of memory safety in these languages, and (…)

…and the bulk of these attempts don’t even consider onboarding basic static analysis tools to projects.

I think this comparison is disingenuous. Rust has static code analysis checks built into the compiler, while C compilers don’t. Yet, you can still add static code analysis checks to projects, and from my experience they do a pretty good job flagging everything ranging from Critical double-frees to newlines showing up where they shouldn’t. How come these tools are kept out of the equation?

source
- robinm@programming.dev ⁨9⁩ ⁨months⁩ ago
  I’m not familiar with C tooling, but I have done multiple projects in C++ (in a professionnel environnement) and AFAIK the tooling is the same. Tooling to C++ is a nightmare, and that’s and understatement. Most of the difficulty is self inflicted like not using cmake/meson but a custom build system, relying on system library instead of using Conan or vcpkg, not using smart-pointers,… but adding basically anything (LSP, code coverage, a new dependency, clang-format, clang-tidy, …) is horrible in those environments. And if you compare the quality of those tools to the one of other language, they are not even close. For exemple the lint given by clang-tidy to the one of Rust clippy.
  
  If it took no more than an hour to add any of those tools to a legacy C project, then yes it would be disingenuous to not compare C + tooling with Rust, but unfortunately it’s not.
  
  source
- BatmanAoD@programming.dev ⁨9⁩ ⁨months⁩ ago
  You are making an extreme and completely absurd assumption, and it also sounds like you’ve misread what I wrote. The “attempts” I’m talking about are studies (formal and informal) to measure the root causes of bugs, not the C or C++ projects themselves.
  
  I cited one specific measurement, Daniel Stenberg’s analysis of the Curl codebase. Here’s a separate post about the testing and static analysis used for Curl.
  
  Here’s a post with a list of other studies. The projects analyzed are:
  
  Android (both the full codebase and the Bluetooth & media components)
  
  iOS & MacOS
  
  Chrome
  
  Microsoft (this is probably the most commonly cited one)
  
  Firefox
  
  Ubuntu Linux
  
  Do you really think that Google, Apple, Microsoft, Mozilla, and the Ubuntu project “don’t even consider onboarding basic static analysis tools” in their C and C++ projects?
  
  If you’re curious about the specifics of how errors slip through anyway, here’s a talk from CppCon 2017 about how Facebook, despite copious investment into static analysis, still had “curiously recurring” C++ errors. It’s long, but I think it’s worthwhile; the most interesting part to me, though, starts around 29:40, where he asks an audience of C++ users whether some specific code compiles, and only about 10% of them get the right answer, one of whom is an editor of the C++ standard.
  
  source