I think “how many historical bugs would this have prevented” is a really good way of judging a programming language or feature
I think this is really not a good way to judge a programming language or feature. You just don’t pour a little of the new language/feature over the existing project and bugs simply disappear. You change the structure of the project on a fundamental level, or actually you just create a whole new project. This might avoid the bugs that have appeared in the past, but it will tell you nothing about the complexity and corresponding bugs that get introduced by the new language or feature.
You just don’t pour a little of the new language/feature over the existing project and bugs simply disappear.
This can sometimes literally be the case. Introducing Kotlin to a large Java app has shown me exactly this: NullPointerException practically disappears in the Kotlin code.
If one of the aspects you value in a language is preventing bugs, this seems like a great model to evaluate a language with. No model is perfect, but I think evaluating whether it would prevent historical bugs is one of the best we have.
In the case of Rust and C, they are both imperative. Idiomatic Rust can look different from C, simply because Rust provides more tools for expressive power, but you can write Rust which reads very closely to C (minus the memory unsafety). Of course, it won’t be a 1-1 translation, but it also isn’t a fundamental structural rewrite (unless there are fundamental memory errors).
Without looking into the bugs in detail, I can’t be sure, but I suspect that a number of the ‘we should have checked a thing but didn’t’ bugs would not have occurred in idiomatic Rust or C++, where you would encode the protocol state machine in the type system and be unable to proceed from one state to another without the checks unless you do something that looks obviously dangerous.
I think this is really not a good way to judge a programming language or feature. You just don’t pour a little of the new language/feature over the existing project and bugs simply disappear. You change the structure of the project on a fundamental level, or actually you just create a whole new project. This might avoid the bugs that have appeared in the past, but it will tell you nothing about the complexity and corresponding bugs that get introduced by the new language or feature.
This can sometimes literally be the case. Introducing Kotlin to a large Java app has shown me exactly this: NullPointerException practically disappears in the Kotlin code.
If one of the aspects you value in a language is preventing bugs, this seems like a great model to evaluate a language with. No model is perfect, but I think evaluating whether it would prevent historical bugs is one of the best we have.
In the case of Rust and C, they are both imperative. Idiomatic Rust can look different from C, simply because Rust provides more tools for expressive power, but you can write Rust which reads very closely to C (minus the memory unsafety). Of course, it won’t be a 1-1 translation, but it also isn’t a fundamental structural rewrite (unless there are fundamental memory errors).
Content warning: it contains some offhand derision of Christians.
From https://lobste.rs/s/gmem98/curl_audit_how_joke_led_significant#c_aokevq
Without looking into the bugs in detail, I can’t be sure, but I suspect that a number of the ‘we should have checked a thing but didn’t’ bugs would not have occurred in idiomatic Rust or C++, where you would encode the protocol state machine in the type system and be unable to proceed from one state to another without the checks unless you do something that looks obviously dangerous.