5 ms·

> minimal type inference How is that a pro? That's a net negative.

Mountain_Skies 4y ago
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.
- dunefox 4y ago
  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.
  - Yoric 4y ago
    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. Perhaps that's the GP is referring to?
    - tialaramex 4y ago
      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++.
jessermeyer 4y ago
I should clarify. I may have mistyped. 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.
- dunefox 4y ago
  > What I meant was implicit type conversion. Well, that's something completely different then.

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.

dunefox 4y ago
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.
- Yoric 4y ago
  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. Perhaps that's the GP is referring to?
  - tialaramex 4y ago
    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++.

jessermeyer 4y ago

I should clarify. I may have mistyped. 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.

dunefox 4y ago
> What I meant was implicit type conversion. Well, that's something completely different then.