[dmpk2k]

Alleged? Come now.

Beginners face the following problems: there's multiple standard libraries, many documents are barely more than type signatures, and data structures aren't printable by default. Experts also face the problem of a very tiny library ecosystem, and tooling that's often a decade behind more mainstream languages (proper gdb support when?). OCaml added multicore support recently, but now there is the whole Eio/Lwt/Async thing.

I used to be a language nerd long ago. Many a fine hour spent on LtU. But ultimately, the ecosystem's size dwarfs the importance of the language itself. I'm sympathetic, since I'm a Common Lisp man, but I don't kid myself either: Common Lisp isn't (e.g.) Rust. I like hacking with a relic of the past, and that's okay too.

[ernst_klim]

TBH I think it's rather a post-hoc rationalization of why the language is not popular.

> there's multiple standard libraries

Scala has a far more fragmented ecosystem with Cats, Scalaz, Zio and Akka. C++ and Java have a bunch of stdlib extensions like boost, Guava, Apache Commons etc.

> many documents are barely more than type signatures

Can be said of most of Java, Kotlin, Scala, Erlang etc etc. Just compiled javadocs, sometimes with a couple of unhelpful lines.

> data structures aren't printable by default

Neither they are in C++

I think the real reason it's not popular is that there are languages which solve more or less the same problems of system programming but look far more familiar to an avg. programmer who was raised on C++ and Java.

[dmpk2k]

Maybe it's post-hoc?

I wanted to use OCaml since 2002, since it was a GC'd language with good performance, achieving a lot with relatively few lines of code. Being a language nerd, I was (am?) positively inclined to the language. Yet there was always something that made it notably less pleasant to solve my current problem in than in than some other language.

If it had trouble getting traction with me, that's bad news.

Meanwhile the mainstream has progressed a lot since 2000. GC is the standard, closures are normal, pattern matching and destructuring are increasingly so. While HM-style type inference is not mainstream, local type inference is (and I'm no longer convinced that global type inference is the way). Algebraic data types aren't unusual anymore.

A few years back I just threw in the towel and went with Rust; this happened after I volunteered to improve OCaml's gdb support (including DWARF hell), which went nowhere. I wish Rust compiled faster, and a GC'd language is usually more productive for my problems, but in every other regard it stole what should have been OCaml's thunder. And when popular successor languages eventually appear, they'll do it even better.

[creata]

Off-topic: What language would you say is the closest thing to "Rust with a GC"?

(Rust has refcounting, but it's slow, and needing to handle cycles manually limits its usefulness.)

[whats_the_buzz]

The closest thing to "Rust with a GC" in my mind is Ponylang or just Pony:

https://www.ponylang.io/ https://github.com/ponylang/ponyc

The Pony community is here:

https://ponylang.zulipchat.com/

Pony's garbage collection and runtime can yield performance faster than C/C++/Rust because the compiler eliminates data races at compile time, and thus no locks are needed.

It features implementations of Dmitri Vyukov (www.1024cores.net) algorithms for work stealing and Multi-producer single consumer queues that use only a single atomic instruction to read. The designer, Sylvan Clebsch, is an ex-game-developer and ex-high-frequency-trading-infrastructure engineering lead; he knew what he was doing when he designed the language for high performance on multicore systems.

On the other hand, you do have to re-wire your thinking to think in terms of Actors and their state, and this is kind of hard to wrap one's head around if you are used to Go's CSP or the popular async/await approaches -- it is a somewhat different paradigm.

[hollerith]

GC was standard already in 2000: Perl, Python, Ruby, Java and JS all had GC from day 1.

[dmpk2k]

Crappy GC for most of them, but... fair point.

[brabel]

You probably know it, but Common Lisp May be a bit dated but it’s extremely modern in terms of features since you can add almost any feature to the language in libraries! I use it exactly because it’s old and battle tested and I don’t need to wait years for a language designer to give me a feature , I can just add it myself, though these days it has everything done already!

[StopDisinfo910]

> there's multiple standard libraries

There is only one standard library and it shipped with the compiler.

> data structures aren't printable by default

So? That’s the case with most languages. Ocaml has a deriver to make types printable and a REPL which automatically prints for testing.

> tooling that's often a decade behind more mainstream languages

Opam is a fully featured package manager, dune works fine, bucks2 supports Ocaml.

> proper gdb support when?

Ocaml has had a rewindable debugger since approximately forever.

> OCaml added multicore support recently, but now there is the whole Eio/Lwt/Async thing.

Lwt was the default and everyone agrees eio is the future now that effects are there. Async is a Janestreet thing with pretty much no impact on the language outside of Janestreet.

Honestly, I maintained my initial point. Ocaml alleged frictions were always widely overstated.

When I was writing Ocaml professionally 15 years ago, there was no dune and no opam and it was already fairly easy to use the language.