I'm curious why you quote this like it's a fact when it's an opinion. The understanding of type inference used as the basis for making the argument in that blog post is superficial. Type inference doesn't just allow you to leave off type information from variables. A good inference engine will infer the most generic type for variables (and functions!), it's a discovery that you can query the compiler for in order to do type driven development.
A full rebuttal of this blog post would take much longer, but suffice to say inference does the exact opposite of what they are claiming; it increases readability and usability.
If type inference damaged readability, we would expect companies/projects that use languages such as OCaml and Haskell where type inference is possible but not mandatory to have policies against it in their style guides. In my experience with OCaml, the widely agreed on style is to only annotate types of functions that are part of some public interface (although since this annotation is necessary to define the public interface of a library, it's not even necessarily true that type inference impairing readability is the primary reason for this).
Also, if lack of type annotations were a common problem, you would expect Java programmers who switch to Python to frequently want to annotate all their types. But as far as I know this is not the case: even now that mypy is becoming popular, people only annotate the types that it can't infer.
Companies do have policies against using type inference (e.g., the use of var in C#).
But how would companies/people know if it damaged readability? There has been little research on this (a few studies are currently in peer review!) and our intuition about such things is often inaccurate. There are so many other confounding factors that it is hard to isolate just type inference/annotations.
> Companies do have policies against using type inference (e.g., the use of var in C#).
That's a language that historically has not had type inference. Any examples of companies mandating type annotations in historically type-inferred languages?
Yes! Any company that has adopted MyPy or TypeScript often have policies for this. One team I spoke to at Facebook said that any new code should have type annotations. I believe Dropbox had a nice blog post about new code should have type annotations too. It is hard to get these details from companies/teams (and be allowed to talk about it).
That's because (a) these are not historically type-inferred languages–runtime typechecking doesn't count as type inference–and (b) the gradual typechecking approaches like Mypy and TypeScript often have a lot of type inference issues which force people to try to overcome them with manual annotations.
In languages with even reasonably good type inference you'll find that the idiom is not to annotate types at the very least inside function bodies. And in OCaml, which has principality of type inference i.e. the types it infers cannot be overridden and corrected by manual annotation, the idiom is to not annotate implementation files at all.
Do they mandate that only function types (and any ambiguous ones) should be annotated, or that all types (i.e. including those of local variables which mypy can infer) should be? I strongly suspect the former, which implies that they view type annotations more as a necessary evil to allow type checking rather than a benefit in their own right. After all, there was nothing stopping people putting "type annotations" in Python 2.5 code if you wanted, by writing `x = get_thing_count() # int`. But AFAIK no-one did that until annotations could actually be used to check type safety.
Typescript will infer the 'any' type by default in a lot of cases, that's the reason teams will mandate type annotations. It's really just not the same thing. These are bolt on type systems to dynamic languages where if you fail to put a type annotation you're actually losing information. That's not the case in Haskell, type inference causes no loss of precision for types.
I don’t agree with readibility (there are pros and cons, ie. terser code vs. implicit types) but, at least in Haskell, it improves usability by inferring the most generic type to your expression.
Agree on what? "Type inference" is a broad feature, feel free to post the resources.
edit:
In Haskell it goes beyond just locally inferring variables, it enables a new type of development with typed holes that feels more like a back and forth conversation with the compiler. I don't see how "I can leave the types off my C# variables" has anything to do with that.
A full rebuttal of this blog post would take much longer, but suffice to say inference does the exact opposite of what they are claiming; it increases readability and usability.