5 ms·

> but the alternative is investing in static analysis for C code, Yeah, the author explicitly acknowledges that: > Eliminating C programming bugs does not nec

> but the alternative is investing in static analysis for C code, Yeah, the author explicitly acknowledges that: > Eliminating C programming bugs does not necessarily require switching programming languages. Other approaches to reducing bug rates in software include: > Coding style rules that forbid unsafe language features. > Building safe abstractions and prohibiting unsafe language features or library APIs. > Static checkers that scan source code for bugs. > Dynamic sanitizers that run software with instrumentation to identify bugs. > Unit testing and fuzzing. > The problem is, the QEMU community has been doing these things for years but new bugs are still introduced despite these efforts. It is certainly possible to spend more energy on these efforts but the evidence shows that bugs continue to slip through.

R0b0t1 6y ago
Yes? Half of those are classes of bugs that would probably still exist with the usage of Rust, that is, they're simply a diversion from what you expected and what actually happens that the borrow checker can't save you from. You need to separate all bugs from the bugs Rust can't introduce. It's safer, in theory, to just do it in Rust first, but it is also important to consider the amount of time it actually takes to implement either. Why is this garnering downvotes...?
- Foober223 6y ago
  Welcome to the Rust world order domination brigade. /s
- alfalfasprout 6y ago
  It's garnering downvotes because a lot of HN readers have never worked with a very large and mature codebase before and understand just how crazy a migration is. They seem to think that writing in Rust magically eliminates most bugs. No... it eliminates certain classes of bugs but instead you get plenty of logical bugs. The number of new bugs introduced in a migration would be enormous. It's not just "translating" the C into Rust-- you ideally need to write "idiomatic" Rust. Rust is a fantastic language but what I despise about its community is how they seem to think every C/C++ codebase should be rewritten in Rust. Either it's a monumental effort or it would decrease the developer base in many cases. In the case of C++ template libraries then it's in some cases even impossible to replicate functionality.
  - zozbot234 6y ago
    > In the case of C++ template libraries then it's in some cases even impossible to replicate functionality. Rust has procedural macros that can replicate anything C++ templates can do, often more cleanly. And C/C++ are hardly immune from logical bugs.
    - ncmncm 6y ago
      > "Rust has procedural macros that can replicate anything C++ templates can do" This is an entirely false statement. Wishful thinking makes a poor substitute for knowledge. Promoting wishful thinking against facts does all readers a disservice.
  - tedmielczarek 6y ago
    Having been significantly involved in the work to integrate Rust into Firefox I can say that while it's definitely nontrivial it's absolutely worthwhile. Every C++ developer I knew at Mozilla that took the time to learn Rust wound up being impressed with it and preferring to write Rust over C++.
- staticassertion 6y ago
  First off, I upvoted you, and I wish people wouldn't just downvote. That said, > Half of those are classes of bugs that would probably still exist with the usage of Rust, that is, they're simply a diversion from what you expected and what actually happens that the borrow checker can't save you from. It's unclear what you're referring to. The linked article is talking about vulnerabilities in QEMU drivers, which are almost exclusively memory safety issues from my own experience and memory. The post you're replying to is just about tools and techniques for avoiding them. > but it is also important to consider the amount of time it actually takes to implement either. No one has said otherwise and the article even explicitly addresses this. So I find your point really unclear.
  - R0b0t1 6y ago
    >>> but it is also important to consider the amount of time it actually takes to implement either. >No one has said otherwise and the article even explicitly addresses this. What do you mean by this? The article might reference it (I don't see any reference to this), but if it does it doesn't actually explore what factors would influence costs and their magnitude. That's what I'm looking for.
    - staticassertion 6y ago
      I mean that your statement implies that people are advising to perform expensive work without considering the cost, specifically the cost in terms of time, and that's not true. No one has said that. The article addresses cost in a number of places - maybe not explicitly the cost of time, but it seems weird to focus on that. The article explicitly addresses that it's not so simple to just rewrite a codebase: > Moving a large codebase to a new programming language is extremely difficult. If people want to convert QEMU to Rust that would be great, but I personally don't have the appetite to do it because I think the integration will be messy, result in a lot of duplication, and there is too much un(der)maintained code that is hard to convert.
      - R0b0t1 6y ago
        That's just a token mention of it instead of actually evaluating whether it will be problematic or not. I bring this up as he is probably one of the best people to evaluate this in detail and he didn't; lots of people here are acting like he did.
codetrotter 6y ago
>> The problem is, the QEMU community has been doing these things for years but new bugs are still introduced despite these efforts. It is certainly possible to spend more energy on these efforts but the evidence shows that bugs continue to slip through. While personally being a proponent of Rust, I’ve been wondering if some of the projects that have codebases too big to realistically RIIR any time soon might benefit from running statical analysis as a git hook server side rejecting any commits that don’t pass some set of rules. Though, only having second-hand knowledge of statical analysis of C code through reading blog posts on the net, I am also of the impression that false positives are a common occurrence in statical analysis tools. So based on that I am thinking that it might either not be feasible, or at the very least it would be a major undertaking and you might need to continuously tune the rules and also bugs of this sort would perhaps still slip through.

R0b0t1 6y ago

Yes? Half of those are classes of bugs that would probably still exist with the usage of Rust, that is, they're simply a diversion from what you expected and what actually happens that the borrow checker can't save you from. You need to separate all bugs from the bugs Rust can't introduce. It's safer, in theory, to just do it in Rust first, but it is also important to consider the amount of time it actually takes to implement either. Why is this garnering downvotes...?

Foober223 6y ago
Welcome to the Rust world order domination brigade. /s
alfalfasprout 6y ago
It's garnering downvotes because a lot of HN readers have never worked with a very large and mature codebase before and understand just how crazy a migration is. They seem to think that writing in Rust magically eliminates most bugs. No... it eliminates certain classes of bugs but instead you get plenty of logical bugs. The number of new bugs introduced in a migration would be enormous. It's not just "translating" the C into Rust-- you ideally need to write "idiomatic" Rust. Rust is a fantastic language but what I despise about its community is how they seem to think every C/C++ codebase should be rewritten in Rust. Either it's a monumental effort or it would decrease the developer base in many cases. In the case of C++ template libraries then it's in some cases even impossible to replicate functionality.
- zozbot234 6y ago
  > In the case of C++ template libraries then it's in some cases even impossible to replicate functionality. Rust has procedural macros that can replicate anything C++ templates can do, often more cleanly. And C/C++ are hardly immune from logical bugs.
  - ncmncm 6y ago
    > "Rust has procedural macros that can replicate anything C++ templates can do" This is an entirely false statement. Wishful thinking makes a poor substitute for knowledge. Promoting wishful thinking against facts does all readers a disservice.
- tedmielczarek 6y ago
  Having been significantly involved in the work to integrate Rust into Firefox I can say that while it's definitely nontrivial it's absolutely worthwhile. Every C++ developer I knew at Mozilla that took the time to learn Rust wound up being impressed with it and preferring to write Rust over C++.
staticassertion 6y ago
First off, I upvoted you, and I wish people wouldn't just downvote. That said, > Half of those are classes of bugs that would probably still exist with the usage of Rust, that is, they're simply a diversion from what you expected and what actually happens that the borrow checker can't save you from. It's unclear what you're referring to. The linked article is talking about vulnerabilities in QEMU drivers, which are almost exclusively memory safety issues from my own experience and memory. The post you're replying to is just about tools and techniques for avoiding them. > but it is also important to consider the amount of time it actually takes to implement either. No one has said otherwise and the article even explicitly addresses this. So I find your point really unclear.
- R0b0t1 6y ago
  >>> but it is also important to consider the amount of time it actually takes to implement either. >No one has said otherwise and the article even explicitly addresses this. What do you mean by this? The article might reference it (I don't see any reference to this), but if it does it doesn't actually explore what factors would influence costs and their magnitude. That's what I'm looking for.
  - staticassertion 6y ago
    I mean that your statement implies that people are advising to perform expensive work without considering the cost, specifically the cost in terms of time, and that's not true. No one has said that. The article addresses cost in a number of places - maybe not explicitly the cost of time, but it seems weird to focus on that. The article explicitly addresses that it's not so simple to just rewrite a codebase: > Moving a large codebase to a new programming language is extremely difficult. If people want to convert QEMU to Rust that would be great, but I personally don't have the appetite to do it because I think the integration will be messy, result in a lot of duplication, and there is too much un(der)maintained code that is hard to convert.
    - R0b0t1 6y ago
      That's just a token mention of it instead of actually evaluating whether it will be problematic or not. I bring this up as he is probably one of the best people to evaluate this in detail and he didn't; lots of people here are acting like he did.

codetrotter 6y ago

>> The problem is, the QEMU community has been doing these things for years but new bugs are still introduced despite these efforts. It is certainly possible to spend more energy on these efforts but the evidence shows that bugs continue to slip through. While personally being a proponent of Rust, I’ve been wondering if some of the projects that have codebases too big to realistically RIIR any time soon might benefit from running statical analysis as a git hook server side rejecting any commits that don’t pass some set of rules. Though, only having second-hand knowledge of statical analysis of C code through reading blog posts on the net, I am also of the impression that false positives are a common occurrence in statical analysis tools. So based on that I am thinking that it might either not be feasible, or at the very least it would be a major undertaking and you might need to continuously tune the rules and also bugs of this sort would perhaps still slip through.