Type inference has usability problems (2019)

3 points by abhin4v


mond

Eeehh. I guess the article is from 2019, but as far as I can tell it's nowadays possible to configure your LSP / editor setup to show you the types inline if it's necessary for your workflow. IIRC even Helix supported this.

Also, a bit of a nitpick, but doesn't make the author look credible: Type inference in Go (or e.g. C++) is very different from the type inference used in e.g. Rust.

It just doesn't seem well-researched, this feels more like a twitter post-type rant.

jana

What immediately came to my mind is that at least in Rust, type inference isn't always optional. In the case of opaque (existential) types for example, or return type inference with Default::default() (though you could argue that falls under what the author finds unhelpful). Especially with opaques, the whole point is that you cannot easily name the type and it's implementation is deliberately opaque, purposefully limiting the provided API surface. A powerful pattern.

antiwizardaktion

Minor nit-pick, but I think it’s worth distinguishing between type inference and using type inference to omit type signatures. In a language like agda I can write a function with “holes” in its type signature and then using my editor’s agda mode I can have my computer fill in these holes using inference. The end product is a program with explicit type signatures, but I had the benefit of not having to compute (or write) these types signatures myself. I think having a type system and type checker which supports inference is a pure win when possible, whether we should use this machinery to omit type signatures in source code is another matter.