> One of my biggest annoyances was how often OCaml folks talk about Fancy Type System problems, instead of how to actually build products and applications. In other communities for similar languages (ReasonML, Elm, F#), people talk about building apps and solving their problems. In OCaml, it feels like people spend an awful lot of time discussing Functors.
In whatever case, it appears that the author's preference was F# > Rust > OCaml.
I don't have a problem with garbage collectors in general, but that's only one facet in deciding a language. There are lots of more important facets, and OCaml fares pretty poorly at these (e.g., tooling, ecosystem, community, pace of improvement, mindshare, etc).
And for language toolchains in particular, I wouldn't lock myself into a language with suboptimal performance--it's too hard to back out of that decision later, and it's easy enough to recoup some of that pace of development from Rust by just refcounting everything today if necessary (optimize it later).
> OCaml fares pretty poorly at these (e.g., tooling, ecosystem, community, pace of improvement, mindshare, etc).
I think this is unfair and OCaml has a lot going for itself. The fact that it also has an active academic community of people who care about Fancy Type Systems does not strike me as an intrinsic downside.
To me, OCaml has a very different paradigm from most languages, and that can be a big strength. Implementing something in OCaml after you've written out the types can feel like you are doing a duet with the compiler.
Setting up an OCaml build system for the first time is an absolute nightmare. There are a number of tooling issues with OCaml that require a lot of work to figure out and work around. It is not batteries-included, either.
Once set up, though, I agree that it drives very much forward. In compiler writing in particular, it allows you to express the things you care about (ASTs and transformations over them) with next to no effort.
A few years ago this was still true, but since then Dune (originally called jbuilder) has dramatically changed the ease with which OCaml projects can be set up.
As for batteries included, there are several options for foundational libraries; I found there to be too many choices rather than too few when I first started developing in OCaml.
Maybe things have progressed in the intervening years, but I found dune/jbuilder to be complicated and poorly documented. I've forgotten many of the issues I had with it, but IIRC there were a couple of different configuration formats (S-expressions and something else?) and the examples online never worked out of the box.
As for foundational libraries, I agree that there were too many choices, but IMO fragmentation in the standard library is a bad thing (you need to know how to interop between them as you integrate third party libraries that use different standard libraries). Never mind the confusion that creates for newbies.
Moreover, for newbies, getting editor integration working well, understanding the unfamiliar (to put it nicely) syntax, and a myriad of other challenges without good documentation are other significant obstacles.
These are pretty significant downsides, and as much as I like the upside of a nice type system, I don't need it to build a product, but I need good tooling and a good ecosystem and a healthy supply of developers. I can ship a product with Go or Python (languages with impoverished type systems)--there might be more bugs but finding and fixing bugs is manageable--but OCaml presents significant challenges.
> The fact that it also has an active academic community of people who care about Fancy Type Systems does not strike me as an intrinsic downside.
No one is arguing that this is a downside. The downside is that there aren’t many people who care about making useful software, or at least there is a relative dearth of content devoted to that end.
> To me, OCaml has a very different paradigm from most languages, and that can be a big strength. Implementing something in OCaml after you've written out the types can feel like you are doing a duet with the compiler.
I actually agree with this, but as much as I love a good type system, it’s gravy. I can ship software with Go because it has a decent runtime, tooling, ecosystem, learning curve, mindshare, etc even despite its simplistic type system; however, it’s much harder to do the same in OCaml. Also, there are languages like Rust with great type systems and concern about the more ruggedly practical concerns of software development.
I think a GC is almost always the most important facet. Can you name a set of languages that doesn't include Rust, some with GCs and some without, where the most different pairs are the same in terms of having a GC or not?
I don't understand the question. I wouldn't say having a GC is the most important facet--I'd rather have good tooling and ecosystem. Of the mainstream languages without GCs, Rust is the only one with good tooling and ecosystem (or arguable C/C++ have "good ecosystem" but the tooling makes it prohibitively difficult to integrate well). Further, the other GC-less languages have a lot of other issues, such as poor error messages and bad ergonomics. Basically success correlates with having a GC, but this is a classic case of correlation != causation.
> I don't have a problem with garbage collectors in general, but that's only one facet in deciding a language.
In the same sense that the president of the US is only one voice on US policy. If you've been writing OCaml and then you want to change your project to another language, you will most definitely miss the garbage collector. All of a sudden you have to solve problems a second time in a different way, which is something you wouldn't have to do using F#. There's no way I'd shift a serious project from GC to non-GC unless I had absolutely no choice.
> In OCaml, it feels like people spend an awful lot of time discussing Functors.
I mean, if you want to use OCaml and not even bother to want to learn about functors, which are fundamental to the module system, then I don't know what to say. It would be somewhat like wanting to use Java and not learn how to use classes.
I suppose someone who had no exposure to OOP would say the same to a group discussing a object-based approach to solving a problem.
That said, the OCaml community is very interested in using the type system to eliminate entire classes of errors (eg,"make illegal states unrepresentable"). Rust community is the same. Jane Street has built a multi-billion dollar company using this approach. If you view such as "abstract language design", then your loss.
To be clear, the claim isn't that other communities never discuss academic concerns, but that they are also interested in the practical aspects of building software products while OCaml is (more or less) singularly focused on the academic aspects.
Yes, the Rust community is interested in the academic aspects of eliminating classes of errors, but it's also very interested in addressing pragmatic problems. Consider all of the sites for Are We (Web | GameDev | IDE | etc) Yet as well as the remarkable progress they've made in such a short time. Rust's entire history fits in the amount of time that OCaml has been struggling to solve parallelism.
> Jane Street has built a multi-billion dollar company using this approach. If you view such as "abstract language design", then your loss.
That's really great for Jane Street, but it's really not the badge of honor you (and the rest of the OCaml community) think it is that a single company has managed to muster some success with your preferred language in its 25 year history. It also doesn't do much to illustrate that the OCaml community is broadly interested in practical matters--only that one community has done, and they have done a lot of work to make OCaml manageable (like Google has done with Go, except that Go enjoys marketshare outside of Google).
> One of my biggest annoyances was how often OCaml folks talk about Fancy Type System problems, instead of how to actually build products and applications. In other communities for similar languages (ReasonML, Elm, F#), people talk about building apps and solving their problems. In OCaml, it feels like people spend an awful lot of time discussing Functors.
In whatever case, it appears that the author's preference was F# > Rust > OCaml.
I don't have a problem with garbage collectors in general, but that's only one facet in deciding a language. There are lots of more important facets, and OCaml fares pretty poorly at these (e.g., tooling, ecosystem, community, pace of improvement, mindshare, etc).
And for language toolchains in particular, I wouldn't lock myself into a language with suboptimal performance--it's too hard to back out of that decision later, and it's easy enough to recoup some of that pace of development from Rust by just refcounting everything today if necessary (optimize it later).