In the first case, there would be a hard compiler error — rustc would refuse to compile the code until I fixed it.
In the second case, Python would allow the code to run but would potentially produce a runtime TypeError when it reached that point depending on exactly the code does. It might also run fine (e.g. I'm just passing that variable to json.dump()) or produce unexpected output (e.g. I'm passing that code to print() and that worked for int, and str, but then someone called it with None and I didn't want "None" in the output).
The point was that while those differ in how they're implemented, the experience can be fairly similar when you're in the middle of the code-test cycle. My example wasn't the most complicated dynamic typing scenario but it's an example of why this works pretty well: most Python code isn't highly dynamic or dynamic everywhere — typically there are a few places which might be challenging for analysis but there's also a LOT of code which only ever works with a single input type. If your IDE provides feedback on all of that code, you're going to avoid a fair number of other bugs and free up time for the hard parts.
