[linkage]

C has plenty of high quality linters like ClangTidy that can teach junior and intermediate developers what not to do. Granted, even with linters, C projects typically have more vulnerabilities than Rust projects, but C has fewer concepts a developer must know to produce working code. For example, to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownership semantics. In C, you just need to know what a struct is and what a pointer is.

[jancsika]

> In C, you just need to know what a struct is and what a pointer is.

Suppose we have a team of experts busily analyzing every single state of the code. They are reading/valgrinding/fuzzing/etc.-- in real time as the intermediate developer writes code.

Each time the developer tries to compile, the team quickly votes either to a) remain silent and leave the dev alone, or b) stop compilation because someone thinks they've discovered an invalid read/write or some other big no-no that the compiler will not catch (but the Rust compiler would catch).

If they choose b, the experts stop for a bit and discuss the clearest way to communicate the hidden bug. Then they have a quick conversation with the intermediate developer. Suggestions are made, and the whole process repeats.

Is this process substantially faster than just learning Rust?

Edit: clarification

[baq]

> to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownership semantics. In C, you just need to know what a struct is and what a pointer is.

It is misguided to say that recursive data structures should be easy to write. They are difficult to reason about and the Rust compiler is right to point this out. CS is not engineering, you should be writing those trees with a pencil on a piece of paper as Dijkstra intended, not in C.

[crote]

How often do you DIY a self-balancing binary tree? Sure I wrote a few in college, but in the real world you are almost always just using an existing library. Optimizing for edge cases like that doesn't make sense.

And is your hand-written C implementation going to be safe and correct. You didn't mention any kind of locking or atomic operation, so is it going to unexpectedly break in a multithreaded environment?

The concepts of Rust are definitely more complicated, but in practice it just means that C makes it easier to shoot yourself in the foot. It's easy, but is that really the most important thing here?

[nine_k]

This assumes a perfect student who is not going to make any mistakes while writing their code, not even a typo. If an error is introduced, things become much harder on the C side. The compiler may miss it. It could manifest as a bug that only occurs in certain non-obvious circumstances, and manifests erratically (e.g. an out-of-bounds write clobbering data of a node next to it in the heap). Rust would most likely just not allow such a bug to be introduced.

In the same vein, driving on a modern busy road requires you to know about lanes, speed limits, various signs, traffic lights, rules of turning and merging, etc, etc. A road without all of that, where a steering wheel plus two pedals suffice, of course still allows you to drive, and drive fast, but it requires much more attention from a driver; many driver's mistakes are noticed later, and lead to more dangerous accidents.

[SkiFire13]

> For example, to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownership semantics.

This assumes a self-balancing binary tree must have nodes with parent pointers. Without those you don't need reference counting and without that you don't need `RefCell` either.

[woodruffw]

How often do you find yourself implementing self-balancing trees in either C or Rust?

[tcfhgj]

once in university