Hacker News Reader

Comment by orangetuba | Hacker News Reader

So if you take a Python program and you add the mental effort of having to deal with static types, lifetimes, the borrow checker and performance considerations, and this added mental effort actually allows you to write the program faster?

That is incredible. It's like being able to carve- and install a door from a slab of wood faster than installing a prefabricated door.

View on HN

Ongoing maintenance and feature development on top of an existing code base is easily 10x the amount of time and effort of starting a new project greenfield. Even modest improvements in long-term readability and maintainability have disproportionately beneficial effects, even if the initial cost is somewhat high.

In my personal experience, once you're proficient in Rust, the initial cost is not somewhat high because those improvements in your ability to reason about your code base start snowballing quickly. And the long-term effects are enormous. I have literally picked up a project I hadn't worked on in years, made sweeping changes to the internals, and had every test pass in a pretty comprehensive suite the very first time it compiled.

This line of reasoning is utterly alien to me. If your types add mental overhead, you’re doing something wrong. You should be able to rely on the typechecker to check invariants for you, decreasing mental overhead. You have to think about types anyway, especially in an untyped language, where you can’t rely on the typechecker.

The leap from thinking about your program with inheritance to thinking about your program with traits is large and cannot be overstated.

It's one of the reasons why Python developers don't like working in Ruby, for example.

Having types lets you get better editor completion and such; I'd say Rust pushes you into bottom-up design, which I find significantly more productive than top-down too; doing bottom-up design is much trickier in a dynamic language, though, because changes to one of your "bottom layers" break upper layers in a way that the compiler/interpreter can't see

Depends, maybe time to first run is lower in python, but time to a robust/quality solution could be a very different story.

I code faster in types languages. I find typed code easier to read and understand. A lot of writing new code is just reading and understanding existing code.

So the claim doesn’t sound so crazy to me. For me at least, types remove mental overhead, they don’t add to it. I can’t count the times I’ve been reading through untyped (or inaccurately typed) python code and have had to jump a dozen levels deep just trying to figure out if a function can or cannot return null.

Reply on news.ycombinator.com