Hacker News Reader

Comment by naasking | Hacker News Reader

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.

View on HN

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?

Reply on news.ycombinator.com