Good general advices… As a new learner myself the one mistatke that really should be mentioned everywhere is…
Start by implementing a graph based algorithm.
I mean, all the other advices are good, and I’ve done all of them, but that one is the one that make almost let Rust aside.
Only one thing jumped out on me which I definitely didn’t agree:
Rust makes it especially easy to refactor
Specifically, extracting a piece of code into a separate function could actually be harder in Rust than in some other languages with type inference due to Rust’s treatment of any function as an API boundary and its insistence on spelling out all argument types explicitly. Sometimes the types of intermittent values could be rather unwieldy (cough iterator adapters cough).
I think Rust is easier to refactor correctly. When refactoring something, if it compiles, it often works right away. Maybe it’s just me but when refactoring C++ or Python I always introduce little mismatches that I don’t find until runtime.
Indeed, it’s all relative. I have found having a good strong type system can embolden me to do things I wouldn’t even attempt in a dynamic language. I don’t have first hand experience doing heavy refactoring in Rust; I’ve only used it for a few small projects, but this has been my experience with Haskell, OCaml, and heck even Go, when the type system is capable of covering the invariants you care about. I do find that for a lot of my big refactors in Haskell, a decent chunk of the time it does take has been sunk into updating type annotations that are in principle optional, so I think type inference would help here – but I’ve also found that in larger codebases having the types actually written down for most top-level functions makes reading the code easier. This seems like something a good IDE could solve for you, but I’ve never really taken to IDEs, and the languages that have good inference have not historically had good IDE support anyway (though it’s been improving).
Why would I debug minor type mismatches like a peasant when the compiler can instantaneously tell me the exact location of the issue?
Worse, when refactoring C++, changes can introduce subtle lifetime issues that even good tests may not trigger. ASAN can help, but then I’m debugging ASAN errors instead of the Rust compiler pointing me to the exact line of code causing a problem.
I write good tests, and lots of them. But running a test suite is not a substitute for type and lifetime checking in my eyes.
Indeed, my somewhat pathological case that I’ve come to point to is SQLite; the thoroughness of their testing practices borders on the absurd (which is a good thing):
The page makes a good argument that most of these don’t really count as vulnerabilities, but they are still bugs that would be impossible to even get past the type checker in Rust, which somehow evaded what is the most rigorous testing regime I have ever heard of, on any project in any language.
To be sure, there are many kinds of bugs in many domains that type checkers aren’t great at helping with, much less ruling out entirely. But there are also many where they are a great fit, and in those cases they are both more complete than any possible test suite and also much less effort to make use of.
Neither testing nor type checkers should be the only tool in your toolkit.
I like type inference within a function body, but global inference seems to invariably make debugging more difficult. Even if your editor shows you type annotations, these annotations are the most abstract types that the type system supports rather than the types a programmer intended. Moreover, it seems like managing compatibility would be a big pain if any change made inside of the function body would quietly change its signature (I’m sure tooling exists which could check for this, but I have a hard time imagining that tooling is more pleasant to work with than simple, by-human-for-human annotations).
My experience is that I can feel free to start a big refactoring in Rust, even when I’m working on a new feature in parallel, because I feel secure: I won’t forget anything, the compiler is guiding me step by step and makes me converge towards the correct refactored code. It’s “fearless refactoring”.
I agree with you, refactoring in Rust is quite painful. The author is not wrong about the compiler telling you what changes you need to make once you change a signature or a type, but as you say, I think is way harder that other languages…
This is incredible. Thoughts going out to all the enterprise devops people forced to update their Magneto installs on the Friday two weeks before Christmas!
Ah, I’ve seen at least one security researcher popping a Magneto install online with this so I just assumed it was Java based - presumably there was a Java component somewhere behind the scenes!
Which is exactly the problem of course - if any user supplied input can reach a backend Java component that logs it though log4j then you’re vulnerable.
Maybe one company started it, but this expression is what I heard in many places. Including some that don’t use the same system, but people knew what Sev 1 means. (I’d probably write P1, even though that’s not a thing at my current job)
What I find weird about this story is that no CVE has been created :( Seems that MIcrosoft will roll out a patch, but i can’t find any information regarding that :(
Very well written and even if you’re not going to use any linker script any time soon, it’s good to know it exists.
Good general advices… As a new learner myself the one mistatke that really should be mentioned everywhere is… Start by implementing a graph based algorithm. I mean, all the other advices are good, and I’ve done all of them, but that one is the one that make almost let Rust aside.
Only one thing jumped out on me which I definitely didn’t agree:
Specifically, extracting a piece of code into a separate function could actually be harder in Rust than in some other languages with type inference due to Rust’s treatment of any function as an API boundary and its insistence on spelling out all argument types explicitly. Sometimes the types of intermittent values could be rather unwieldy (cough iterator adapters cough).
I think Rust is easier to refactor correctly. When refactoring something, if it compiles, it often works right away. Maybe it’s just me but when refactoring C++ or Python I always introduce little mismatches that I don’t find until runtime.
Indeed, it’s all relative. I have found having a good strong type system can embolden me to do things I wouldn’t even attempt in a dynamic language. I don’t have first hand experience doing heavy refactoring in Rust; I’ve only used it for a few small projects, but this has been my experience with Haskell, OCaml, and heck even Go, when the type system is capable of covering the invariants you care about. I do find that for a lot of my big refactors in Haskell, a decent chunk of the time it does take has been sunk into updating type annotations that are in principle optional, so I think type inference would help here – but I’ve also found that in larger codebases having the types actually written down for most top-level functions makes reading the code easier. This seems like something a good IDE could solve for you, but I’ve never really taken to IDEs, and the languages that have good inference have not historically had good IDE support anyway (though it’s been improving).
Tests work at runtime, have better covering tests :-)
Why would I debug minor type mismatches like a peasant when the compiler can instantaneously tell me the exact location of the issue?
Worse, when refactoring C++, changes can introduce subtle lifetime issues that even good tests may not trigger. ASAN can help, but then I’m debugging ASAN errors instead of the Rust compiler pointing me to the exact line of code causing a problem.
I write good tests, and lots of them. But running a test suite is not a substitute for type and lifetime checking in my eyes.
Indeed, my somewhat pathological case that I’ve come to point to is SQLite; the thoroughness of their testing practices borders on the absurd (which is a good thing):
https://sqlite.org/testing.html
And yet, memory safety bugs are found somwhat regularly:
https://www.sqlite.org/cves.html#cvetab
The page makes a good argument that most of these don’t really count as vulnerabilities, but they are still bugs that would be impossible to even get past the type checker in Rust, which somehow evaded what is the most rigorous testing regime I have ever heard of, on any project in any language.
To be sure, there are many kinds of bugs in many domains that type checkers aren’t great at helping with, much less ruling out entirely. But there are also many where they are a great fit, and in those cases they are both more complete than any possible test suite and also much less effort to make use of.
Neither testing nor type checkers should be the only tool in your toolkit.
I like type inference within a function body, but global inference seems to invariably make debugging more difficult. Even if your editor shows you type annotations, these annotations are the most abstract types that the type system supports rather than the types a programmer intended. Moreover, it seems like managing compatibility would be a big pain if any change made inside of the function body would quietly change its signature (I’m sure tooling exists which could check for this, but I have a hard time imagining that tooling is more pleasant to work with than simple, by-human-for-human annotations).
My experience is that I can feel free to start a big refactoring in Rust, even when I’m working on a new feature in parallel, because I feel secure: I won’t forget anything, the compiler is guiding me step by step and makes me converge towards the correct refactored code. It’s “fearless refactoring”.
I agree with you, refactoring in Rust is quite painful. The author is not wrong about the compiler telling you what changes you need to make once you change a signature or a type, but as you say, I think is way harder that other languages…
No, no, I didn’t imply it was painful in general. I just noticed this particular difficulty.
Don’t know enough to comment on the article itself but the blog looks really nice.
I felt the same, I can’t really tell if the content is 100% accurate, but the blog is well written and very focused :)
This is incredible. Thoughts going out to all the enterprise devops people forced to update their Magneto installs on the Friday two weeks before Christmas!
Thankfully, Magento is PHP and is unlikely to directly use Log4j.
(But indirectly? Who knows!)
Ah, I’ve seen at least one security researcher popping a Magneto install online with this so I just assumed it was Java based - presumably there was a Java component somewhere behind the scenes!
Which is exactly the problem of course - if any user supplied input can reach a backend Java component that logs it though log4j then you’re vulnerable.
Note the difference in spelling between your comments and soatok’s comment. Maybe you’re referring to two difference pieces of software?
Well, at least they didn’t release it the Friday before Christmas…
I was thinking just about that, it’s bad news for a friday :S
Yeah, at the MANGA that I work at, tickets were filed on all affected teams with instructions to treat this like a Sev 1.
“Treat this like a Sev 1” uniquely identifies your employer.
Maybe one company started it, but this expression is what I heard in many places. Including some that don’t use the same system, but people knew what Sev 1 means. (I’d probably write P1, even though that’s not a thing at my current job)
I doubt that. https://www.google.com/search?hl=en&q=Sev%201%20incident
How does the X-MEN supervillain come into this? ;-)
What I find weird about this story is that no CVE has been created :( Seems that MIcrosoft will roll out a patch, but i can’t find any information regarding that :(
Very well explained, the graphics helps a lot to understand the underlying system.
Very well explained!
$WORK: Planning work for the next year with the team.
$HOME: Trying to parse AML in rust to get PCI configuration for a rust kernel.