kakra
commented
1 year ago Firstly, we should not port code just because it is possible. That makes no sense, there's nothing we do that would suddenly become much better or easier with rust.
Secondly, I was thinking about that already. But it won't come to this code base, at least not anytime soon. If anything, I'd create the driver from scratch with the whole design in mind instead of working on converting a code base that has grown over time. The latter also makes no sense.
But, there's actually some stuff related to the project which I may start in rust: xpadneo will get some user-space components in the future which I'll probably use rust or go for, tendency being more towards rust as it feels more like a traditional language for programs or daemons than go which is more targeted towards micro services.
That said, yes, rust will probably come to xpadneo but rust code won't replace the current driver - weighing the pros and cons that feels like a dumb idea.
Also rust is not better just because it is rust, while C is not bad because it is C. You can create bad code in rust as much as you can create good code in C. Rust just takes away some of the pitfalls you'd usually need to handle manually in C - it doesn't make anyone a better programmer: bad code is bad code, no matter what programming language. And personally, I've not gathered any in-depth experience with rust so I will stay away from converting a working code base. Converting to rust wouldn't make it better, rather it will likely introduce new bugs or changed behavior. We should avoid falling the hype pitfall.
ghost
Recently, support for writing Linux kernel modules in rust has been mainlined. Would it make sense to port this code to rust at some point? I know that I have been hesitant to work on this code because of the unknowns of userspace module dev in C.