Global type inference is not a positive in my book. In my experience it becomes very hard to understand the types involved if they are not explicit at systems boundaries.

I can also imagine that it must be hard to maintain, like sometimes the types must accidentally change

Being hard to maintain and having no static types at all, did not stop Python rising to conqueror the world. Type inference allows us to at least give those users the succinctness they are used to, if not the semantics. Those who like explicit types can add as many annotations as they need in OCaml.

> Those who like explicit types can add as many annotations as they need in OCaml.

They cannot add it in other people's libraries.

> did not stop Python rising to conqueror the world

I wasn't talking popularity, I was talking maintainability. Python is not a stellar example of maintainability (source: maintained the Python API for a timeless debugger for 5 years).

Python's ubiquity is unfortunate, thankfully there seems to be a movement away from typeless signatures, both with Python's gradual typing (an underwhelming implementation of gradual typing, unfortunately) and Typescript.

> They cannot add it in other people's libraries.

Does it matter that much how the internals of someone else's library are implemented? The tooling will tell you the types anyway and module interfaces will have type signatures.

> Python's ubiquity is unfortunate,

Well that we can agree on!

There’s a trade off - was the mistake here or there? The type checker cannot know. But for those few cases you can add an annotation. Then the situation is, in the worst case, as good as when types are mandatory.

> But for those few cases you can add an annotation.

not in other people's code. My main concern is that gradual typing makes understanding other people's code more difficult.

Idiomatic Haskell warns against missing signatures[1], Rust makes them mandatory. Rather than global inference, local inference stopping at function boundaries is the future, if you ask me.

[1]: https://wiki.haskell.org/Type_signatures_as_good_style

Huh? If you are consuming code you can’t change from someone else, then I presume this is a published package? Then the IDE will tell you the types.

> the situation is, in the worst case, as good as when types are mandatory

The worst case is actually worse than when types are mandatory, since you can get an error in the wrong place. For example, if a function has the wrong type inferred then you get an error when you use it even though the actual location of the error is at the declaration site. Type inference is good but there should be some places (ex. function declarations) where annotations are required.

The lack of function overloading was really the only thing holding OCaml back 15 years ago. Last I checked, there was no interest in changing this.

That can't really be the main reason, Rust is doing just fine without it.

Rust has overloading via traits.

That's an entirely different concept imo. Overloading in Rust would be to have separate `Vec::new()` and `Vec::new(capacity: usize)` functions, which is not allowed.

Case in point: Java does allow exactly this, while also allowing classes to implement interfaces very similarly to how Rust structs can implement traits. Rust code sometimes uses traits to achieve similar results, like the `slice::get(index: SliceIndex<[T]>)` function, but the example above can't be done.

I think the GP meant polymorphism. Rust traits being static ad hoc polymorphism. I thought it was possible, though, to achieve the same thing with Functors. Just the standard library deliberately didn't and chose to have things like 'print_int', 'print_string' and so on instead of a Print Functor.

Yes functors would be the way in OCaml, but there's no implicit context resolution that implicitly resolves such symbols within a Functor the way you can in Rust or Haskell. This missing implicit context resolution makes for bad ergonomics, particularly for any kind of numerical code, which tend to be the very first kinds of things that new programmers try in a new language. "Hey, why do I need to use + in one case and +. in another? This is dumb, OCaml is not a serious language."

In OCaml the integer operations are implemented using LEA instructions, and the floats are boxed. The language is not really suitable for numerical code...

I'm not familiar with ocaml, but the LEA thing can reasonably be fixed by a better compiler, no? Is there no LLVM backend for ocaml?