Like many things… it depends.

Type inference is wonderful for prototyping and writing short lived tools - it is an unnecessary expense for mature projects with a large number of developers on it.

At my shop we have a concept of “one off” routes that are written to accomplish a specific task and intended to be run once. A few of these are run repeatedly but with the understanding that these routes are unmaintained and exempt from automated testing requirements (we’ve got a separate bucket for routes that are only rarely invoked but are complex enough and frequently enough used to get test coverage). For stuff like those one off scripts I’ll never block a PR for omitting typing - while I absolutely will in our regular codebase.

The big problem with this take is that they seem to assume it is an all or nothing feature.

Personally I love how rust does it, types are inferred inside a body of a function where they matter less and are generally unambiguous (you need to specify them if they are ambiguous) as you often don’t care as much about the exact type you have. But on function parameters are return types they are never inferred as these form the contract to the rest of your program and a unexpected change to one of these can result in your code breaking somewhere else entirely.

Personally I never really use the automatic type annotations in IDEs, they just add noise I rarely care about.

I’m just glad that type inference can improve this sort of situation a bit:

ConfigManager configManager = new ConfigManager();

Author has paper rejected by territorial reviewer who expects everyone to cite their shitty type inference research.

Author drops type inference diss track in response.

You know what really sucks?

When I have a method that returns a Foo and like 300 places it gets called.

And then I change it to return an ever so slightly different Bar

Ah, now I need to go and update the code in 300 places cause the return type changed.

“Can’t you just sed your codebase?”

Maybe, but it could cause some serious unintended dawizard

In Rust and Haskell you have to at least annotate the parameter types and return type of functions.

In OCaml type inference is a lot more powerful: you don’t have to annotate function signatures

Actually, Haskell and OCaml have this in common. Only Rust requires parameter types of the three.

I could do

add2 a b = a + b
main = do
    putStrLn $ "5 + 3 = " ++ (show $ add2 5 3)

And that would work

I prefer type inference. It’s extra clutter that can often be abstracted away with good variable and method names. If it quacks the way I need it then that’s one less thing I need to hold context of in my head.

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.

To me this is an argument for why Go should not add type inference to function/method declarations. Go is like Rust (I guess, I haven’t used Rust) - type inference works for declaring a variable (or const) and generic type parameters but not for type declarations, methods, functions, etc. I was in the “more inference is always better” camp but now I’m thinking Go has the perfect level of inference. Except for function literals/lambdas. I really want go to infer the argument and return types when I’m passing a function literal/lambda to a function.

let foo = [("a", 1), ("b", 2)].into_iter().collect();

let foo: Vec<_> = [("a", 1), ("b", 2)].into_iter().collect();

let foo: HashMap<_, _> = [("a", 1), ("b", 2)].into_iter().collect();

That’s false for closures (or unnamed/inline) functions with context because their type is unique and so you just can’t write their type and that’s not a lang’s fault - that’s logically correct side-effect by-design.