I thought this was going to be about non-local type inference (ie. write down a bunch of type equations and iterate until fixed-point) as opposed to simple bott

I thought this was going to be about non-local type inference (ie. write down a bunch of type equations and iterate until fixed-point) as opposed to simple bottom-up inference. The former has benefits, but also disadvantages: sometimes obscure and unintended types can be inferred, and it makes features like "give me the type of this expression" difficult. The author is talking specifically about inferring the type of a variable from the type of the LHS of its initialization. Opinions differ on how much you should use this (he points out Go, and Go is nothing if not opinionated) but there are clear benefits to having it as an option. Suppose you have foo(super_long_name(), x, y, z) and you want to refactor it into var bar = super_long_name() foo(bar, x, y, z) This is only a stylistic change, but if you have to write down variable types, you need a piece of information for the second that you don't need in the first. If the first was not unclear (just long), why should the second be? The type name may also be difficult to write down. It might also be unenlightening. Knowing the type of a variable is not always helpful during normal reading (eg. the types of iterators in C++ or Rust). Also in generic code (eg. templates or macros), you might just not know the type of some expression. I believe this was a major argument in favor of adding auto to C++.