[woevdbz]

I like the language, but I'm not sure that it actually targets any mainstream application. If you look at something like golang, it's very geared towards online server work bc that's what the language maintainers wrote it for, hence a lot of focus on GC-induced tail latency. Python and its package distribution system are great for glue code that's going to pick from a wide library of modules. C++ is amazing for portability and performance / zero cost abstractions. Java has its weird cult in enterpriseware and also is an OK glue layer for mobile UI stuff.

Comparatively, OCaml was initially written with symbolic operations in mind, and thus I personally think it's a great language for writing parsers, compilers, modeling systems etc. The type system makes it easy to avoid certain kinds of common errors in those programs and the tail latency of GC operations is typically not as important for those applications as overall throughput. I don't think that heavy symbolic computations are a mainstream target though. To be clear I think that's absolutely OK for a language not to aim for mainstream use; but if one wishes for mainstream use, then it's important to be clear about the kinds of use-cases within mainstream that will be targeted.

It has been a while since I played with the language though, so maybe things have changed since. Happy to learn more if I'm wrong and OCaml now has a clear mainstream target use case in mind.

[yawaramin]

Why does OCaml need a 'clear mainstream target use case in mind'? It's a general-purpose language. It can be used for anything that Java, Go, or Python can be used for, and many things that C++ can be used for to boot.

Sure, OCaml's heritage is descended from a theorem prover helper language, but that doesn't meant it's forever stuck at that use case. Python was originally an educational teaching language, nowadays it's a data science and glue language. None of that was planned out in advance by the Python folks.

In fact even if you ask the Go team, Go is arguably the most targeted language of the ones you listed, in terms of its use case--and they were surprised that a lot of their userbase came from ex-Python devs who wanted something more reliable and efficient!

OCaml with version 5 is just hitting its stride. With the advances in the language, the multicore support, and tooling, it's going to be competitive with Rust for many use cases. It's worth the wait to see where it goes.

[thinkharderdev]

I think to gain adoption any general purpose language needs a clear niche to gain a foothold. If you are choosing a tech stack then choosing a language that is not already widely adopted is always a risk. The tooling is usually inferior, there are not necessarily high-quality libraries in domains you care about and you pay a cost in training new employees in a new tech stack.

Java was an OO, garbage collected language that supported (sort of...) hot swapping code. Go was a reasonably performant, garbage collected language that compiled to static binaries and has great cross-platform support. Some grad student decided to write Spark in Scala so you had to use it for Spark jobs Rust is a systems programming language with zero-cost abstractions and no GC that allow you to write mostly memory-safe code.

What is the killer feature of OCaml that makes it worth the investment?

[yawaramin]

OCaml has many (almost all) of the advantages that you attributed to the other languages, and adds many more besides. What makes them 'killer features' for those languages but not for OCaml?

[thinkharderdev]

Nothing really, but they are mainstream languages and OCaml is (currently) not. So if you really need one of those then there is already a more widely adopted option that gives it to you. It's not that OCaml is bad (I like it a lot) it's that to adopt it you need a really compelling reason to do so.

[woevdbz]

Not saying it needs to be planned in advance, but that there needs to be a very strong competitive advantage in some use case, not just checking the feature boxes. Continuing on the case of Python users moving to Go, they're probably not doing so for interactive use-cases or avec to scientific libraries...

Does checking the concurrency box make OCaml an awesome choice for some use case?

You mention Rust for example but that language is sort of built around a zero cost abstraction principle, which is very much not the case of OCaml, so I still think it's going to be viewed as risky for highly performance sensitive work.

[yawaramin]

Yeah I mentioned Rust because it's muscling its way in to many use cases which don't really need 'zero-cost abstractions' and can definitely afford a GC, e.g. say microservices. A lot of work has been (and continues to be) put into OCaml to make it very competitive in these areas.

For truly performance-sensitive work of course people are going to choose C/C++/Ada/Rust.