I also find it hard to spot why OCaml is the natural "step up" for creating real world applications instead of Haskell, Rust, Clojure or even Kotlin, C++, Python and Go.
- 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.
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.
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 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.
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.