Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Patterns for Defensive Programming in Rust

corrode.dev

Post reply on HN
Print view View original

31–40 of 99 posts

Re: Patterns for Defensive Programming in Rust

#31

Post by hurril »

zozbot234 wrote: post #25
hurril wrote: post #21

Earlier quoted context omitted.

You have a good point there, that is better. But it is still, well honestly, wrong. Two orders ordered at different times are just not the same order, and using a typeclass approach to say that they most definitely are is going to bite you in the back seat. PartialEq and Eq for PizzaDetails is good. If there is a business function that computes whether or not someone orders the same thing, then that should start by p…

You can solve this in the general case by implementing the typeclass for the coarser equality relation over an ad-hoc wrapper newtype.

Well it isn't a good call. This is the kind of code that OOP makes people write.

Re: Patterns for Defensive Programming in Rust

#32

Post by thatoneengineer »

Aside from just being immensely satisfying, these patterns of defensive programming may be a big part of how we get to quality GAI-written code at scale. Clippy (and the Rust compiler proper) can provide so much of the concrete iterative feedback an agent needs to stay on track and not gloss over mistakes.

Re: Patterns for Defensive Programming in Rust

#33

Post by mattarm »

tczMUFlmoNk wrote: post #22
perching_aix wrote: post #16

Earlier quoted context omitted.

Is there an industry standard name for these teams that I somehow missed then?

You may wish to search for "readability at Google". Here is one article: https://www.moderndescartes.com/essays/readability/ (I have not read this article closely, but it is about the right concept, so I provide it as a starting point since "readability" writ large can be an ambiguous term.)

See https://abseil.io/tips/ for some idea of the kinds of guidance these kinds of teams work to provide, at least at Google. I worked on the “C++ library team” at Google for a number of years.

These roles don’t really have standard titles in the industry, as far as I’m aware. At Google we were part of the larger language/library/toolchain infrastructure org.

Much of what we did was quasi-political … basically coaxing and convincing people to adopt best practices, after first deciding what those practices are. Half of the tips above were probably written by interested people from the engineering org at large and we provided the platform and helped them get it published.

Speaking to the original question, no, there were no teams just manually reading code and looking for mistakes. If buggy code could be detected in an automated way, then we’d do that and attempt to fix it everywhere. Otherwise we’d attempt to educate and get everyone to level up their code review skills.

Re: Patterns for Defensive Programming in Rust

#34

Post by perching_aix »

mattarm wrote: post #33
tczMUFlmoNk wrote: post #22

Earlier quoted context omitted.

You may wish to search for "readability at Google". Here is one article: https://www.moderndescartes.com/essays/readability/ (I have not read this article closely, but it is about the right concept, so I provide it as a starting point since "readability" writ large can be an ambiguous term.)

See https://abseil.io/tips/ for some idea of the kinds of guidance these kinds of teams work to provide, at least at Google. I worked on the “C++ library team” at Google for a number of years. These roles don’t really have standard titles in the industry, as far as I’m aware. At Google we were part of the larger language/library/toolchain infrastructure org. Much of what we did was quasi-political … basically coaxing…

This is a really cool insight, thank you!

> Half of the tips above were probably written by interested people from the engineering org at large and we provided the platform and helped them get it published.

Are you aware how those engineers established their recommendations? Did they maybe perform case studies? Or was it more just a distillation of lived experience type of deal?

Re: Patterns for Defensive Programming in Rust

#35

Post by kazinator »

stouset wrote: post #11

Good article, but one (very minor) nit I have is with the PizzaOrder example. struct PizzaOrder { size: PizzaSize, toppings: Vec , crust_type: CrustType, ordered_at: SystemTime, } The problem they want to address is partial equality when you want to compare orders but ignoring the ordered_at timestamp. To me, the problem is throwing too many unrelated concerns into one struct. Ideally instead of using destructuring t…

Decomposing things just to have different equality notions doesn't generalize.

How would you decompose a character string so that you could have a case-insensitive versus sensitive comparison?

:)

Re: Patterns for Defensive Programming in Rust

#36

Post by rolandog »

Y_Y wrote: post #5
rolandog wrote: post #4

Earlier quoted context omitted.

As someone unfamiliar with Rust (yet! it's on my ever growing list of things I'd like to absorb into my brain), unwrap_or_else() sounds like part of the "What You See Is What I Threatened the Computer To Do" paradigm.

> INTERCAL has many other features designed to make it even more aesthetically unpleasing to the programmer: it uses statements such as "READ OUT", "IGNORE", "FORGET", and modifiers such as "PLEASE". This last keyword provides two reasons for the program's rejection by the compiler: if "PLEASE" does not appear often enough, the program is considered insufficiently polite, and the error message says this; if it appear…

Oh wow! That's amazing! "I came to learn Computer Science, but I left with good bedside manners".

Re: Patterns for Defensive Programming in Rust

#38

Post by tialaramex »

kstrauser wrote: post #29
quotemstr wrote: post #19

The tech industry is full of brash but lightly-seasoned people resurrecting discredited ideas for contrarianism cred and making the rest of us put down monsters we thought we'd slain a long time ago. "Defensive programming" has multiple meanings. To the extent it means "avoid using _ as a catch-all pattern so that the compiler nags you if someone adds an enum arm you need to care about", "defensive" programming is go…

For a second I thought you were advocating for something of those, and I had a rant primed up. Yes. Defensively handle all the failure modes you know how to handle, but nothing else . If you're writing a service daemon and the user passes in a config filename that doesn't exist, crash and say why. Don't try to guess, or offer up a default config, or otherwise try to paper over the idea that the user asked you to do s…

There's probably a "Pay it forwards" lesson from Rust's diagnostics too.

So much end user software tries to be "friendly" by just saying "An error occurred" regardless of what's wrong or whether you can do anything about it. Rust does better and it's a reminder that you can too.

Re: Patterns for Defensive Programming in Rust

#39

Post by svat »

perching_aix wrote: post #16
vlovich123 wrote: post #14

Earlier quoted context omitted.

There are. All the big tech companies have them. It’s just difficult to accomplish when you have millions of lines of code.

Is there an industry standard name for these teams that I somehow missed then?

Not exactly the question you asked, but you may want to read the chapter on “Large-Scale Changes” in the “Software Engineering at Google” book: https://abseil.io/resources/swe-book/html/ch22.html

Re: Patterns for Defensive Programming in Rust

#40

Post by ninkendo »

Dowwie wrote: post #18

I'm not reading a solid argument as to not use "..Defaults()" because doing so suggests that you may introduce a bug and therefore should be explicit about EVERYTHING instead? Ugh. Hard disagree.

Care to say why you disagree?

Using ..Default::default() means “whatever additional fields are added later, I don’t care”. Which is great until someone needs to add a field to the struct, and they rely on the compiler to tell them all the places that don’t have a value for the field (so they can pass the right value depending on the situation.) Then the callers with Default are missed, and bugs can result.

Any time you say “I don’t care what happens in the future here”, you better have a good reason for that to be the case, IMO.

Post reply on HN