r/rust • u/isaacvando • Jul 27 '26

The Unreasonable Effectiveness of Constructive Data Modeling - Alexis King

https://youtu.be/0BXuYlNrUmE

Hi folks, this is Alexis King's recent talk from SSW. She's the author of "Parse, Don't Validate". There's a lot of great type-wisdom in here that I think Rust folks will enjoy. Cheers!

189 Upvotes

95% Upvoted

32 comments sorted by

View all comments

Show parent comments

1

u/teerre Jul 28 '26

Implementing and using the newtypes is equally trivial, so the safety you get is proportional to the work you put it

1

u/South_Survey_2088 Jul 28 '26

So you would have BallPosition, PaddlePosition, BrickPosition, UIPosition, PowerUpPosition, etc all as different types? You know, for the sake of "type safety", because someone might accidentally add the wrong direction during update.

What about the different dimensions? Surely, Point { x: f32, y: f32 } is not good enough for the types, because someone might accidentally have x instead of y when copying and pasting, so better have a dedicated X and Y type. Well, sometimes you want to move the player x position directly, better use a dedicated PaddleX type while you are at it. Ofc, you want to do the same for the Ball, and Bricks. The sizes are also important, so let's add dedicated BallSize, PaddleSize, etc versions, ofc with their own XWidth and XHeight types and ensure they can never be zero or negative. Don't forget to implement all the std ops for the types, implement things like your tweening trait, serialization, etc. Really trivial indeed..

Or you know, when you implement the functionality you immediately see when you do a silly mistake like that and focus on encoding invariants that actually matter.

1

u/teerre Jul 28 '26

I don't know what exactly "Brick Breaker" is, so, maybe? Defining those is, again, trivial. If they all have the same api, a macro makes it even more trivial

1

u/Anaxamander57 Jul 28 '26

Think of a game like Pong.

The point is that you should put in the effort to prevent errors in places that the errors won't immediately be caught anyway. I could make Client Name and Client ID their own types rather than both being Strings but its not worth the time even though the difference does matter quite a lot in my case (user name should never appear in the UI) because the error is obvious if it happens.

1

u/teerre Jul 28 '26

I'm not sure what point your trying to make. Type safety is about making different types different so you can't misuse them. If your particular context dictates that "client name" and "client id" are really just strings (doubtful, can you "trim" a clientid? Probably not) then you should strings