cool article! i’ve worked with a bit of both Rust & OCaml and can understand where they’re coming from. i have some gripes with it tho, especially with how it assumes Rust’s typeclasses to be the standard for what’s possible

inline interfaces aren’t a thing

no reason they couldn’t be! assuming it’s just namespacing and not any further meaning.

impl blocks aren’t composable

again, no big technical reason preventing this from being a thing, just aesthetic ones:

impl<T: Eq> {
  fn are_they_eq(a: T, b: T) -> bool { a == b }
}

compile times…

the way modules are done in OCaml and Go basically mandate vtables, which is mostly fine for normal programs, but unacceptable when you want to eke every last bit of performance out at runtime, even if that means longer compile times. ad-hoc polymorphism makes monomorphization easier, and i like it better for that.

Each function stands alone and you have to reason at the function level.

what? no, typeclasses can specify relations between their functions just the same. providing mempty & mappend that typecheck isn’t enough to actually conform Monoid, you need to obey the laws too.

overall pretty good, explains the concepts well, even if it’s biases against my own biases :P

score 2 · canonical