Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.

As much as I really like the mechanics of Rust and the language itself, I don't think I'm gonna use it for any of the device drivers I'm working on.

The problems you have quoted are due to developers being sloppy. 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. Sure it will protect developers from missing "free()" here and there, but it's gonna bite from another side.





There is not one group of developers C folks won’t throw under the bus (eg by calling them sloppy) to defend C.

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”.


Yep.

Frankly there is a whole subsection of our profession which is composed of engineers who have differentiated themselves on their elite skills with difficult low-level languages, and if you pry that cultural marker away from them, they get defensive.

I see this in C/C++ forums all the time: "Rust doesn't solve a problem I have". Actually, yes it does. They might not think it, but I've been in enough codebases over the years by some very skilled C & C++ programmers to know better. The mistakes are preventable by a decent modern language that doesn't let you just null and leak all over the place in entirely preventable ways.

Rust has all sorts of problems, it's definitely not perfect. It is not the final form for systems programming languages.

But it's getting tiresome to see people who won't admit that the C legacy is a real problem at this point. And it's not like it (lack of safety, rigour, etc.) wasn't known along the way (or Ada would never have been a thing, etc.) -- it just wasn't considered important.

Well it should be now. Hell, in the kernel in privileged execution space more than anywhere else it is most important.


when you say "i did lots of unsafe operations", i think it contractions the claim that you "followed the rust way of doing things". what's the point of using a "memory-safe" language if you just gonna use unsafe blocks and ignore that? i agree with you point that there's some operations that rust sucks and c is a better option although. but my claim is that writing unsafe rust and safe are diferent things, for example they created a book talking just about unsafe rust -> https://doc.rust-lang.org/nomicon/

We have literal decades of experience showing that the problem isn't "get good"--no matter how many best practices are followed, it turns out that the next generation of fuzzers or analyzers or whatnot is able to uncover yet more problems in the most perfect codebases we're aware of.

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?


> 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.


I agree with you there. Rust lets me spend my remaining brain cycles considering the logic and flow of my code, not worrying that I screwed up memory handling and such.

> And yes, I followed "the Rust way" of doing things.

Alright show up buddy, let us code review




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: