> I had my journey of using Rust to implement a WinAPI-based app in which I did lots of unsafe (from Rust's point of view) operations. I spent more time on fighting with Rust's protections than on the actual implementation. The result code wasn't safe and looked horrible - totally opposite of what Rust code should look like. And yes, I followed "the Rust way" of doing things.

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.