Still, I'd pick either over Scala. Superior compilation times, cleaner syntax, less complex. Haskell also just feels excessively clever.

I had hoped Rust would be "OCaml but for systems programming" and it sort of is, -- but the borrow checker and memory safety features, as neat as they are, add a lot of mental overhead.

Unfortunately to be a real-world SML user these days is a very isolating proposition, because although there are some really nice implementations (MLton, PolyML), to a first approximation there are zero libraries.

    - OCaml vs Haskell: eager vs lazy  (=> memory consumption is more predictable)
    - OCaml vs Rust: OCaml has a GC (=> comfort) OCaml has tco (could not resist this ;) )
    - OCaml vs Clojure: vastly superior typing system. (=> less bugs)
    - OCaml vs Kotlin: no JVM needed.
    - OCaml vs C++: more safety. once it compiles it will not segv.
    - OCaml vs Go: vastly superior typing system. (=> less bugs)
    - OCaml vs Python: vastly superior type system, way better performance.

Lots of mainstream languages simply fail this test and make it feel like intellectual poverty or that there's extreme, turgid, boilerplate required for a weak imitation of the features (see the idiomatic class-hierarchy encoding of ADTs in large projects - such as LLVM - in C++, for example).

It's absolutely no surprise that more mainstream languages are picking up a match-like construct and lighter encodings of discriminated sums. So, it really comes to what else you wish to be burdened with when compiling an OCaml-like mental model to X in your head: Tagged unions a-la C? Class hierarchies for ADTs in C++? The travesties of std::variant? Monad transformers in Haskell? Lazy evaluation? No static typing at all? Caring about memory management and ownership? Box and Arc-ing recursive components of ADTs? Writing your own arena allocator? Compiling to the JVM? Spotty TCO support?

OCaml is just a nice, fairly simple (at its core, at least), language that captures the essence of the ML family, compiles to native (and bytecode and, transitively, JavaScript), has great tooling (opam, dune, ocamllex, memhir, etc.), great libraries (official LLVM bindings, for example), and a great community. Lots of OCamlers are well aware of other potential languages that somewhat suit their style of programming, they just don't want to be burdened by the other stuff.

I have no horse in this race, but claiming it to be "vastly superior" and implying "less bugs" makes it sound like this is a logical consequence, when you're actually staying on one side of an endless debate that to me doesn't have clear winners. For instance, from the little I've learned about Clojure, they claim the lack of a "vastly superior type system" is a feature, not a bug, and it's a result of a fundamental difference in some beliefs about how to write correct software.

From this I wonder how misrepresentative your other comparisons are as well. But don't get me wrong, OCaml is probably my "favorite language I've never actually used" (I've never "actually used" Clojure in "real projects" either).

- I'm very specific about when I use None

- I'm a big fan of named function arguments

- I like to think my naming of things is pretty good, as are my conventions for parameters

- I try to handle all possible cases (what I mean here is I do and if I don't I made a mistake)

I use tests very sparingly in personal projects, but yet I haven't really felt their absence. If I ever write a piece of particularly hairy code (metaprogramming comes to mind... lord) I'll write a quick script testing some cases and then delete it.

Anyway, all that is to say I think part of dynamic programming is you build an immune system for this stuff.

I usually avoid bugs in python code by rewriting in bash (at 1-10% the size of the original python, since bash's error handling can be set to "always do the right thing" with "set euxo pipefail")

If bash is a bad fit for the rewrite, go usually works. I don't work on linear algebra software much these days. Python seems to be a good option for that.

I think Python gets bailed out a lot because those things turn out to be a lot of programming these days. The people who have a beef w/ Python are those who've worked with it on large, old codebases. This is a tough job for any language though like, raise your hand if you've ever worked on a large, old codebase in C++ or Java that you liked.

Usually when people push microservices I'm quick with Conway's law, saying "this is a tech solution to an organizational problem that won't actually make a difference", and I think I'm right about that. But I think I've been ignoring that a really nice thing about microservices for engineers is you can keep using languages like Python on small codebases, and at least mentally and emotionally avoid the feeling of working on a huge monolith. That counts for something.

You can if they are motivated to learn. Unless you are offering Jane Street levels of compensation; and in return, the candidate is willing to believe, or pretend to believe that company's shtick about OCaml being so categorically superior as a general-purpose development language so as to leave all the others in the dust -- most likely they won't be.

OK, I'll grant that if you have that "magic skill" then you can in fact recruit developers for niche languages.

Most companies don't, as we know, and frankly it's amazing to me how incoherent their communications are throughout their so-called hiring process.

https://www.benjamistan.tech/2022/06/26/wasting-time-in-tech...

You pick one regardless of language. Not sure what's your point here.

I would like to confirm that fact, by comparing productive output..

'Producing code' to measure 'superiority' is about as useful a metric as counting lines of code to measure productivity.