It’s about not ignoring the clear underlying cause of the bug that is screaming at everyone who reads the bug description.
Include something along the lines of “We will use the URL crate and utilize its API to avoid trivial URL construction errors like this one in the future”, and I may take your postmortem seriously.
A flawless developer does not exist, and at no point did I fault any developer directly for their development work. But that doesn’t mean we should ignore something that is/was clearly and inherently wrong with the code. You would think this is all stating the obvious.
So it’s not "just don’t write buggy code in the first place!”. It’s “this code could clearly have been written in a way that would have prevented this bug from ever taking place”.
And yes, good code matters. A good language matters. A good type system matters. A good use of a good language with its type system, patterns, abstractions, ecosystem, and all it got to offer matters. This is Rust afterall. If those things don’t matter, then we might as well let the code be written in Python or JS, and fully recommit to the church of TDD.
That basically is the same as saying “next time we will write correct code” in your postmortem, which I don’t think is very useful. It’s much more useful to say “our code is not structured in a way that makes testing easy” and “our smoke tests should cover the thing that broke.” That gives you something actionable to work on that will actually prevent this from happening in the future. Otherwise, you’ll end up writing essentially the same postmortem over and over again, each time saying “we will write correct code.”
See this postmortem from Cloudflare as an example.
Under “What went wrong”, point 1 and 3:
1. An engineer wrote a regular expression that could easily backtrack enormously.
3. The regular expression engine being used didn’t have complexity guarantees.
And on what needed to done, point 4
4. Switching to either the re2 or Rust regex engine which both have run-time guarantees.
See! Plenty of procedural talk in that postmortem. Plenty of corporate talk too. But you have to mention that a bad backtracking regex was used. And you have to mention that using regexes with no complexity guarantees was glaringly wrong. To not have done so would have been silly. To not even come close to mentioning those things beyond the specific error in that specific regex, and you wouldn’t have been taken seriously.
A good language matters. A good type system matters. A good use of a good language with its type system, patterns, abstractions, ecosystem, and all it got to offer matters.
Eh research shows otherwise. Rust eliminates defects for a very particular set of problems, but when it comes to logical correctness it isn’t better or worse than other languages. If those problems are prominent in your domain(such as you have to write a ton of concurrent code), Rust makes sense. Otherwise being well rested will have a bigger impact on the quality of your code than the best type system in the world.
In terms of dev practices, the only practice demonstrated to have a consistent positive impact on code quality is code reviews. Testing as well, but whether it’s TDD or other kinds of testing doesn’t really matter.
Eh research shows otherwise. Rust eliminates defects for a very particular set of problems, but when it comes to logical correctness it isn’t better or worse than other languages.
Can you concede, at least to yourself, that you made ^ this ^ up?
By the way, what you claimed “research shows” is so ridiculous that it’s hilarious that you wrote it while being serious.
Hell, I cheekily mentioned Python and JS in particular because the former introduced type hints and the latter triggered creating TS as a saner shield.
Btw, that wrongly-constructed URL wasn’t even an external one. We literally have web frameworks that make sure non-external URLs with invalid paths are impossible to construct. In other words, attempting to construct a wrong one would be a compile error.
By the way, what you claimed “research shows” is so ridiculous that it’s hilarious that you wrote it while being serious.
There is still no research that definitively shows that static types reduce defects more than dynamic types, this is a fact. Turns out we are incredibly bad at studying this, so I don’t know how you can say definitively that it is the case when even the people who study this for a living are not able to make that case.
Eh research shows otherwise. Rust eliminates defects for a very particular set of problems, but when it comes to logical correctness it isn’t better or worse than other languages.
Come on. What was requested by the other user is clear, I think.
You made this specific claim. Can you link to the research showing that? Actual research showing that “Rust eliminates defects for a very particular set of problems, but when it comes to logical correctness it isn’t better or worse than other languages”, not a YT video from a wannabe intellectual talking abstracts and siting some generic studies.
It was my mistake, I said that we definitely know they don’t vs. there is no evidence showing that there is. There aren’t much studies to back this up. The whole point of the talk is that software engineering as a discipline is really poorly studied and we tend to make assertions like this without actually validating them.
If I was betting money on this(I.e. deciding where to focus my investment), the quality of the typesystem would only matter if the typesystem caught real problems that I face in my day to day work. For a Web app for instance, it makes no sense to use Rust vs a GC’d language because the kinds of bugs that you face in Web apps aren’t really the kinds of issues that a borrow checker will help you with. The whole point of Rust being difficult is that it saves you time down the line, if it’s difficult and it doesn’t then that tradeoff doesn’t make sense.
Hilel teaches formal verification for a living, he very much sees the value of automatically proving properties about your program, as do I, but the reality is that the typesystem doesn’t necessarily help as much as we think it does.
the quality of the typesystem would only matter if the typesystem caught real problems that I face in my day to day work. For a Web app for instance, it makes no sense to use Rust vs a GC’d language because the kinds of bugs that you face in Web apps aren’t really the kinds of issues that a borrow checker will help you with.
It’s quite reductionist (and weird) to describe Rust’s type system in terms of it’s borrow-checker only, ditto for describing the other simply as “GC’d languages”.
The borrow-checker together with move semantics and RAII are a small, if dominating -especially for beginners-, part of Rust’s type system. There are many other very relevant aspects, type classes (traits), sum types (enums), hell, not being OOP alone is a big win for many.
Talking about Rust only in terms of its type system would also be reductionist. The macro system alone is a big differentiator (I would know, because I’ve been working on a proc-macro crate for sometime which will support (de-)serializing a format with both more flexibility and reliability than what serde can offer).
Even talking about Rust only in terms of the language is reductionist! The ecosystem and tooling… okay, I will stop reaching further here.
Talking about the other as “GC’d languages” is also reductionist and weird, since it puts, for example, Go (lol) and Haskell on the same bracket. And that’s two strongly and statically typed languages. I could have picked two languages that are even more different than each other. “GC” as a differentiator for languages is actually even more reductionist than “borrow checker” for Rust.
The whole point of Rust being difficult is that it saves you time down the line
Neither Rust is actively trying to be difficult, nor is it really difficult beyond some early friction while learning the language, and even that friction is overblown often by many.
We do actually have some data on this (I wouldn’t dare calling it “research”). There is this part which actually relates to one of the arguments made in your YouTube link:
And, it’s not just correct—it’s also easy to review. More than half of respondents say that Rust code is incredibly easy to review. As an engineering manager, that result is in many ways at least as interesting to me as the code authoring results, since code reviewing is at least as large a part of the role of a professional software engineer as authoring.
It’s about not ignoring the clear underlying cause of the bug that is screaming at everyone who reads the bug description.
Include something along the lines of “We will use the URL crate and utilize its API to avoid trivial URL construction errors like this one in the future”, and I may take your postmortem seriously.
A flawless developer does not exist, and at no point did I fault any developer directly for their development work. But that doesn’t mean we should ignore something that is/was clearly and inherently wrong with the code. You would think this is all stating the obvious.
So it’s not "just don’t write buggy code in the first place!”. It’s “this code could clearly have been written in a way that would have prevented this bug from ever taking place”.
And yes, good code matters. A good language matters. A good type system matters. A good use of a good language with its type system, patterns, abstractions, ecosystem, and all it got to offer matters. This is Rust afterall. If those things don’t matter, then we might as well let the code be written in Python or JS, and fully recommit to the church of TDD.
That basically is the same as saying “next time we will write correct code” in your postmortem, which I don’t think is very useful. It’s much more useful to say “our code is not structured in a way that makes testing easy” and “our smoke tests should cover the thing that broke.” That gives you something actionable to work on that will actually prevent this from happening in the future. Otherwise, you’ll end up writing essentially the same postmortem over and over again, each time saying “we will write correct code.”
False dichotomy much!
See this postmortem from Cloudflare as an example.
Under “What went wrong”, point 1 and 3:
And on what needed to done, point 4
See! Plenty of procedural talk in that postmortem. Plenty of corporate talk too. But you have to mention that a bad backtracking regex was used. And you have to mention that using regexes with no complexity guarantees was glaringly wrong. To not have done so would have been silly. To not even come close to mentioning those things beyond the specific error in that specific regex, and you wouldn’t have been taken seriously.
Eh research shows otherwise. Rust eliminates defects for a very particular set of problems, but when it comes to logical correctness it isn’t better or worse than other languages. If those problems are prominent in your domain(such as you have to write a ton of concurrent code), Rust makes sense. Otherwise being well rested will have a bigger impact on the quality of your code than the best type system in the world.
In terms of dev practices, the only practice demonstrated to have a consistent positive impact on code quality is code reviews. Testing as well, but whether it’s TDD or other kinds of testing doesn’t really matter.
Can you share that research?
https://youtu.be/WELBnE33dpY
It’s not that there is evidence that it doesn’t matter, but there is no evidence showing that it does.
Here is an alternative Piped link(s): https://piped.video/WELBnE33dpY
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source, check me out at GitHub.
Can you concede, at least to yourself, that you made ^ this ^ up?
By the way, what you claimed “research shows” is so ridiculous that it’s hilarious that you wrote it while being serious.
Hell, I cheekily mentioned Python and JS in particular because the former introduced type hints and the latter triggered creating TS as a saner shield.
Btw, that wrongly-constructed URL wasn’t even an external one. We literally have web frameworks that make sure non-external URLs with invalid paths are impossible to construct. In other words, attempting to construct a wrong one would be a compile error.
There is still no research that definitively shows that static types reduce defects more than dynamic types, this is a fact. Turns out we are incredibly bad at studying this, so I don’t know how you can say definitively that it is the case when even the people who study this for a living are not able to make that case.
Come on. What was requested by the other user is clear, I think.
You made this specific claim. Can you link to the research showing that? Actual research showing that “Rust eliminates defects for a very particular set of problems, but when it comes to logical correctness it isn’t better or worse than other languages”, not a YT video from a wannabe intellectual talking abstracts and siting some generic studies.
It was my mistake, I said that we definitely know they don’t vs. there is no evidence showing that there is. There aren’t much studies to back this up. The whole point of the talk is that software engineering as a discipline is really poorly studied and we tend to make assertions like this without actually validating them.
If I was betting money on this(I.e. deciding where to focus my investment), the quality of the typesystem would only matter if the typesystem caught real problems that I face in my day to day work. For a Web app for instance, it makes no sense to use Rust vs a GC’d language because the kinds of bugs that you face in Web apps aren’t really the kinds of issues that a borrow checker will help you with. The whole point of Rust being difficult is that it saves you time down the line, if it’s difficult and it doesn’t then that tradeoff doesn’t make sense.
Hilel teaches formal verification for a living, he very much sees the value of automatically proving properties about your program, as do I, but the reality is that the typesystem doesn’t necessarily help as much as we think it does.
It’s quite reductionist (and weird) to describe Rust’s type system in terms of it’s borrow-checker only, ditto for describing the other simply as “GC’d languages”.
The borrow-checker together with move semantics and RAII are a small, if dominating -especially for beginners-, part of Rust’s type system. There are many other very relevant aspects, type classes (traits), sum types (enums), hell, not being OOP alone is a big win for many.
Talking about Rust only in terms of its type system would also be reductionist. The macro system alone is a big differentiator (I would know, because I’ve been working on a proc-macro crate for sometime which will support (de-)serializing a format with both more flexibility and reliability than what
serdecan offer).Even talking about Rust only in terms of the language is reductionist! The ecosystem and tooling… okay, I will stop reaching further here.
Talking about the other as “GC’d languages” is also reductionist and weird, since it puts, for example, Go (lol) and Haskell on the same bracket. And that’s two strongly and statically typed languages. I could have picked two languages that are even more different than each other. “GC” as a differentiator for languages is actually even more reductionist than “borrow checker” for Rust.
Neither Rust is actively trying to be difficult, nor is it really difficult beyond some early friction while learning the language, and even that friction is overblown often by many.
We do actually have some data on this (I wouldn’t dare calling it “research”). There is this part which actually relates to one of the arguments made in your YouTube link:
Honestly
url.joinlooks like a cluster-fuck of landmines to me: https://github.com/servo/rust-url/issues/333I’d probably have just stuck with strings as well.