Eh, it has it's charms, but I don't really see a place for it where another language wouldn't be an equally good or better fit. There is a glut of good choices, and only so many novel problems that 95% of industry ever actually faces.
Maybe when multicore sees the light of day, there might be some interesting possibilities. It is really hard to not say "why not just use go/node/racket/haskell/fsharp/rust/zig/etc. when you are on a timeline and you aren't Jane Street...
> I don't really see a place for it where another language wouldn't be an equally good or better fit.
Parsers/interpreters/compilers/static analyzers. It's solidly established here. The Web Assembly reference implementation is written in OCaml for example.
> "why not just use go/node/racket/haskell/fsharp/rust/zig/etc"
I think Python, Java, C# or even PHP will come up before F#, Rust, Zig, Racket and Haskell. As for the answer, you can just use the same language pretty much everywhere. I think OCaml is probably the most versatile language of the lot. You can program in any way you want, target pretty much anything you want. How important is it, to be able to use the same language everywhere? I honestly don't know.
> when you are on a timeline and you aren't Jane Street...
I'm not sure what you mean exactly with "on a timeline", I guess it's a reference to the lack of libraries/documentation? If that's the case, I don't know how much it matters once you're experienced with the language. I'm not saying libraries don't matter at all, that would be silly. You don't want to do JSON parsing or a HTTP server yourself. But for small stuff, you can just write a bit more code that you would usually do. It's going to be way smaller than a full library, and it's going to be easier to use since you don't have to learn a new library. This is however just me thinking about it, I don't have any hard data on this, and would love to know if some exists.
For soupault, library availability was actually a key factor: lambdasoup [1] is one of the best HTML parsing libraries if you want to automatically edit element trees, not just extract data from them.
The single case when I couldn't find a library that would really suit my needs is a TOML parser. The only TOML library for OCaml that existed when I started soupault (To.ml) has incompatibilities with the TOML spec and I categorically disagree with its design.
My solution was to write a new TOML library [2] for my own use and for the benefit of the community. It uses OCaml functors to allow the user to plug their own bignum and calendar libraries if needed and I think it's much easier to use.
Well, the topological sort library [4] also counts (sort of): there are generic graph libraries that already implement sorting, I wanted it to produce user-friendly error messages about cycles or non-existing dependencies, and to take a simple assoc list rather than a custom graph type, so I also made my own.
It's used for sorting "widgets" (page processing steps) according to dependency lists that users can specify in the config (like `after = ["foo", "bar"]`).
Other than that, one thing I really like about OCaml is that the compiler team and most library maintainers are considerate towards downstream users with respect to compatibility.
The Lua interpreter [3] that soupault uses for its plugin API is a revived 20 year old research project. It only needed minor modifications to build with recent compiler versions.
> The Lua interpreter [3] that soupault uses for its plugin API is a revived 20 year old research project. It only needed minor modifications to build with recent compiler versions.
That's one of the other strengths of OCaml that I didn't mention, especially compared to more recent languages. The language has been around for a long time, and is probably going to be around for a long time.
OK, give me one that has: (1) A Hindley-Milner type system with type inference, (2) Native or JIT compilation with good runtime speed, (3) Easy-to-understand execution model, and (4) garbage collection.
- OCaml has all of them, hands down. It is even getting reasonable parallel processing support as of recently.
- Haskell has beautiful implementations of 1, 2, and 4, but definitely not 3, which often leads to hilarious memory leaks.
- Rust has 1, 2, and 3, but 4, while possible, is not really ergonomic, and compile times are the longest.
- Typescript (with Ramda for kicks) has 3 and 4, and almost 3, but still not really 1.
- Java has 2, 3, and 4, but sadly not 1, and programming with immutable values is possible but the stdlib often resists it.
Common Lisp with Coalton added on will get you all of those.
I have dreams that the new java record classes will take the world by storm, but I imagine years of refuctoring getters and setters will be a hard habit to break for the community.
If you get past the quirks of the syntax, it's a really nice language, deserving more popularity in the industry (it's already popular in CS circles).