I hate to just directly question your last statement, but “tons of unsafe” is a red flag that the way things are being done. You should need it for direct interactions with a C API, or for the lowest level of interacting with bare metal memory registers, or for lowest level high performance code that’s verging on or actually using assembly.

I can see how doing windows API stuff would cause a lot of the FFI usage of unsafe, but that should be handled by the winapi or a windows api crate that converts things to idiomatic rust and the rest of the codebase would be dealing with logic.

Entirely possible you hit an edge case here where you were writing glue code which exclusively talked to hand-optimized SSE algorithms or something, but that is exceedingly rare compared to someone just starting out who’s experienced with C trying to do things the C way and fighting through unsafe rather than looking for and finding higher-level patterns that are idiomatic.

> I've gone through hundreds of source codes in Kernel, and most of them wouldn't pass code review in my company - cutting-corners everywhere, multipurpose functions, lack of documentation; those are issues which can't be fixed by just changing a language.

Except they are mitigated to such a degree that it again makes me doubt you were coding idiomatically.

Rust tends to force you to exhaustively handle code paths, so it will require a lot of explicit opting out to cut corners.

Type-safety tends to help a lot in making multipurpose functions self-verifying. Function chains come up a lot more in Rust and type inference works so well because of this.

Documentation is a lot easier when you can just have people use “cargo doc” and add a bit of markdown and some doctests that will get exercised by CI.

> Sure it will protect developers from missing "free()" here and there, but it's gonna bite from another side.

RAII is the smallest difference in DX in Rust compared to working in C. For me the biggest differences were tooling, and type-safety making it a lot easier to catch bugs at compile-time, and enforce design assumptions I had about the architecture.

I don’t necessarily expect it to be easier to write Rust code, but I do expect it will catch more issues up-front rather than at runtime or in the field, so you will end up doing more code-compile iterations (seconds to minutes) and fewer code-customer iterations (hours to days or weeks).

Though when it comes to C++, there is less surface area of the language to learn to get to the modern “safe” constructs and the constructs enforce their own proper usage rather than expecting the developer to, so I expect an intermediate developer to be writing better code until a C++ developer gets to an expert level.

In my experience--and most others' too--it is far better to design APIs so that they are impossible to misuse, rather than relying on developers to remember the rules to prevent misuse. This is where maxims like "parse, don't validate" come from. C's type system is simply too weak for API misuse to be made compile-time failures, which means you have to rely on convention, and anyone who thinks that convention can be made robust across a multimillion line codebase is delusional. One of the advantages of Rust is that you can create newtypes which rewrap the APIs to make misuse impossible. I've been working on some numerics code in Rust, and the first thing I did was to make different types for the different kinds of indices (rows, columns, permuted rows, etc.) so that it's simply impossible to use the wrong index for a given array.

Also, one of those things I've noticed is that most of the people who are dismissive of Rust is that they point to its protection against 'missing "free()" here and there.' Which is strange, because it probably doesn't even make the top 10 list of problems in C that Rust protects against. The C issue that keeps me up at night when I write C code is pointer invalidation, which is what Rust's lifetimes + mutability xor aliasibility rules are meant to protect against. So why talk about free and not pointer invalidation?

Like here you have one of the lead devs of the Linux kernel saying that Rust solves many problems that he has seen happen repeatedly in the kernel, and you’re saying “hm well they must just have been sloppy”.

Alright show up buddy, let us code review

> If this standard were consistently enforced, this site would be a graveyard

That sort of thing is super easy to say, but is plainly untrue. Alas, it has a destructive effect in its own right. If you guys knew how fragile everything is that we're trying (and failing) to achieve here, I believe you would be more careful. It's a tragedy of the commons thing: it's feels better to point fingers and blame others for a deplorable shared situation, than to fix one's own contributions.

That is not to dispute that many embarrassingly low-quality comments get posted to Hacker News. It bothers me and I wish it were otherwise.