Strong agree. OCaml's compiler is sofa king good at catching and preventing real bugs that the agents accidentally introduce here and there. It's the same as with humans, except the agents don't complain about the bullshit reasons humans don't like OCaml. They just crank through and produce high quality output.
replyHow's the multicore and async story these days? I remember that was one of the big draws of F# originally, that it had all (or, most of) the type safety features of OCaml but all the mutlicore of dotnet. (Plus it created async before even C# had it). Has OCaml caught up?
replyOCaml has full multicore support with algebraic effects now. The effect system makes things like async very nice as there's no function "coloring" problem: https://discuss.ocaml.org/t/ocaml-5-0-0-is-out/10974
replyBut I don't believe the effects are tracked in the type system yet, but that's on it way.
The type system for effects is an ongoing research effort. For now you get unhandled effect exceptions at runtime.
replyWith Multicore OCaml we gained thread sanitizer support and a reasonable memory model. Combined they give you tools for reasoning about data races and finding them. https://ocaml.org/manual/5.3/tsan.html
Seems like if you're in that boat you'd just want to go with F# though?
replyStrongly agree, plus OCaml has an expressive type system that lets you build abstractions that just aren’t possible with Go. The original article gives poor reasons for choosing Go.
reply