Odin allows type inference at the declaration level `foo := 1` for example, and a few other places, largely from the constant system. 1 can be an integer, float, or even a matrix, given the larger context.
What I meant was implicit type conversion. Integers do not automatically cast as booleans in Odin, as an example.
That depends on your goal. Want to move fast and break things? Then type inference is great. Want to build things that are solid and reliable? Type inference can be a very bad thing in the wrong hands and most hands are the wrong hands.
How is type inference for "moving fast and breaking things" but not for building solid and reliable things? I'm not quite sure we're talking about the same concept here.
Having been a professional OCaml developer, a long time ago, I found out that too much type inference gets into the way of proper documentation and, to some extent, proper naming conventions. Once code stabilized, we started annotating everything, as in languages with much more limited support for type inference, because it made finding type-level (and sometimes runtime) issues easier.
I'm comfortable with Rust's choice to infer types only within a function, OCaml does sound like it has too much inference. But I think the GP was just confused about vocabulary and what they're really talking about is coercion and they originally wrote "minimal type inference" instead of "minimal type coercion". I think they subsequently corrected to "minimal implicit type conversions" which, is basically just more words for the same thing.
Unwanted type coercions are an infamous problem in C and C++.
How is that a pro? That's a net negative.