4 ms·

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 u

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.

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.