4 ms·

Is it really that painful to write "String" each time? You spend at least a fraction of a second anyway to verify that you're writing the right thing, to recons

Is it really that painful to write "String" each time? You spend at least a fraction of a second anyway to verify that you're writing the right thing, to reconsider if you should use an object or constant or refactor the function to work with a Boolean instead of a naked string; why is writing out the type such a big deal everytime this topic comes up? I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors.

silluk 6y ago
To me it's not the trivial cases like this that make type inference useful. It's when you get longer types like `Arc<Mutex<HashMap<String, String>>>`. Granted, that could be solved with a `type` declaration (or `typedef` in C++) but it's still convenient to be able to say: `let mut x = Arc::new(Mutex::new(HashMap::new()));` and let the compiler figure out the rest based on usage.
wtetzner 6y ago
> Is it really that painful to write "String" each time? I find it more painful to read code that has too many type annotations. I also find it painful to read code that has too few, so I'd argue there's a bit of an art to it. But languages that have type inference but allow type annotations at least allow you to try to hit that balance.
leshow 6y ago
> I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors. Type inference doesn't make these errors go away. And about your other point, it's unfair to look at just a simple case of writing "string" or not as the only thing inference provides. Although I'd argue that leaving out types where possible helps readability-- it's really the more elaborate cases or intermediate steps during a longer transformation that inference helps with. Not to mention the fact that inference in closures is also really nice.

silluk 6y ago

To me it's not the trivial cases like this that make type inference useful. It's when you get longer types like `Arc<Mutex<HashMap<String, String>>>`. Granted, that could be solved with a `type` declaration (or `typedef` in C++) but it's still convenient to be able to say: `let mut x = Arc::new(Mutex::new(HashMap::new()));` and let the compiler figure out the rest based on usage.

wtetzner 6y ago

> Is it really that painful to write "String" each time? I find it more painful to read code that has too many type annotations. I also find it painful to read code that has too few, so I'd argue there's a bit of an art to it. But languages that have type inference but allow type annotations at least allow you to try to hit that balance.

leshow 6y ago

> I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors. Type inference doesn't make these errors go away. And about your other point, it's unfair to look at just a simple case of writing "string" or not as the only thing inference provides. Although I'd argue that leaving out types where possible helps readability-- it's really the more elaborate cases or intermediate steps during a longer transformation that inference helps with. Not to mention the fact that inference in closures is also really nice.