I can’t speak for OCaml, but type inference provides a lot of benefit in Rust. I already have too many keystrokes as it is, and forcing me to be explicit about everything would just add to the stress of using a keyboard.
I agree that types should be explicit at API boundaries. That’s precisely where you want to catch misuse.
As for the point about inference making code harder to read: I suppose that’s true if you spend a lot of time reading code outside of your editor where you also must know what the types are. But that just sounds like a bad workflow in general. Why are you avoiding using a better tool for the job? Modern code review tools like Github even support LSP-like features to solve this problem; and if your language isn’t supported… just pull the feature branch to review it.
He explicitly states that its not that bad in Rust because all functions must have type annotations. Its only a problem if your functions are huge (they shouldn’t). I think thats the correct way to go. Local variables can be inferred but anything else should be annotated.
Modern code review tools like Github even support LSP-like features to solve this problem; and if your language isn’t supported… just pull the feature branch to review it.
But now your requiring more tools and effort on the reviewer over, just reading the code.
I was already assuming I was working on the same codebase. I am not going to stash my work, checkout the branch and wait for the LSP to start up (if it’s working) just to confirm that your types aren’t doing anything weird. I’d rather just have them annotated correctly in the first place and just read the PR and trust the CI.
You don’t need to restart your LSP to switch to a new branch. You also don’t need an LSP to find the types.
Even with all of these issues aside, I can’t think of the last time I was reviewing a PR where it wasn’t clear from context what the types were, or they were irrelevant.
wth is your position then? If I can know the types from just looking at the code then it must have adequate type annotations and none of this matters. If I can’t tell the types and I have to pull the code locally to figure it out then I’m not starting the review on a good foot.
I think people here are thinking about type inference in a very local scope and not at a public function level which I understood the author to be complaining about.
If I can know the types from just looking at the code then it must have adequate type annotations and none of this matters
That’s not really true. It depends on the language. In Rust, it’s common to read a function without any explicit types except for the arguments and return type. So you may not know what types are used in the body without referring to the signatures of functions called.
If I can’t tell the types and I have to pull the code locally to figure it out then I’m not starting the review on a good foot.
It’s rare that knowing the types is critical to actually reviewing the code. Types are mostly for the compiler to help you. When reading the code, it’s more important that you see idioms, descriptive names, and test cases. There are rare occasions where it’s necessary to determine a type to resolve some ambiguity in how the code works, and in those cases, there are tools to help you do this (usually the same tools you use while writing code, e.g. LSP editor plugins and grep).
I think people here are thinking about type inference in a very local scope and not at a public function level which I understood the author to be complaining about.
In my very first comment, I said I can’t comment on OCaml. I am only really speaking on Rust here, where you have local inference and mandatory function type signatures.
It’s really weird to me to base any decisions around how much typing you have to do.
Typing is such a small part of programming I really don’t get it.
Typing is a huge part of programming. Have you heard of RSI? People invest hundreds (sometimes thousands) of dollars in ergonomic keyboards just to overcome RSI pain. If you’re younger than 30 you might not be impacted by this, but many people who have been typing every day for over a decade are realizing it’s not sustainable without proper ergonomics.
Readability and maintainability are core imo.
I don’t think you sacrifice these by having local type inference. It’s never been an obstacle for me.
I can’t speak for OCaml, but type inference provides a lot of benefit in Rust. I already have too many keystrokes as it is, and forcing me to be explicit about everything would just add to the stress of using a keyboard.
I agree that types should be explicit at API boundaries. That’s precisely where you want to catch misuse.
As for the point about inference making code harder to read: I suppose that’s true if you spend a lot of time reading code outside of your editor where you also must know what the types are. But that just sounds like a bad workflow in general. Why are you avoiding using a better tool for the job? Modern code review tools like Github even support LSP-like features to solve this problem; and if your language isn’t supported… just pull the feature branch to review it.
He explicitly states that its not that bad in Rust because all functions must have type annotations. Its only a problem if your functions are huge (they shouldn’t). I think thats the correct way to go. Local variables can be inferred but anything else should be annotated.
But now your requiring more tools and effort on the reviewer over, just reading the code.
This should be completely negligible if you are writing code in the same code base.
I was already assuming I was working on the same codebase. I am not going to stash my work, checkout the branch and wait for the LSP to start up (if it’s working) just to confirm that your types aren’t doing anything weird. I’d rather just have them annotated correctly in the first place and just read the PR and trust the CI.
You don’t need to restart your LSP to switch to a new branch. You also don’t need an LSP to find the types.
Even with all of these issues aside, I can’t think of the last time I was reviewing a PR where it wasn’t clear from context what the types were, or they were irrelevant.
wth is your position then? If I can know the types from just looking at the code then it must have adequate type annotations and none of this matters. If I can’t tell the types and I have to pull the code locally to figure it out then I’m not starting the review on a good foot.
I think people here are thinking about type inference in a very local scope and not at a public function level which I understood the author to be complaining about.
That’s not really true. It depends on the language. In Rust, it’s common to read a function without any explicit types except for the arguments and return type. So you may not know what types are used in the body without referring to the signatures of functions called.
It’s rare that knowing the types is critical to actually reviewing the code. Types are mostly for the compiler to help you. When reading the code, it’s more important that you see idioms, descriptive names, and test cases. There are rare occasions where it’s necessary to determine a type to resolve some ambiguity in how the code works, and in those cases, there are tools to help you do this (usually the same tools you use while writing code, e.g. LSP editor plugins and grep).
In my very first comment, I said I can’t comment on OCaml. I am only really speaking on Rust here, where you have local inference and mandatory function type signatures.
It’s really weird to me to base any decisions around how much typing you have to do.
Typing is such a small part of programming I really don’t get it.
Can you elaborate?
Readability and maintainability are core imo.
Typing is a huge part of programming. Have you heard of RSI? People invest hundreds (sometimes thousands) of dollars in ergonomic keyboards just to overcome RSI pain. If you’re younger than 30 you might not be impacted by this, but many people who have been typing every day for over a decade are realizing it’s not sustainable without proper ergonomics.
I don’t think you sacrifice these by having local type inference. It’s never been an obstacle for me.