That's a pretty weird takeaway considering the long and detailed post on OCaml's issues that motivated a full rewrite: https://blog.darklang.com/leaving-ocaml/

> 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.

The point is that the community’s interest appears to be in abstract language design and not building software products.

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).

As mentioned elsewhere, I believe that automatic memory management + affine types will win in what concerns masses adoption.

Rust has been the catalyst to force language designers to look more seriously into affine types, but its use can only be justified in "no way GC/RC" scenarios like MISRA.

Overall, I think the big win for Rust is when you need low-level, low-cost, low-memory, high-performance applications, at the cost of anything else. Rust is a great replacement for low-level C.

Unfortunately, those are not the features that you care about most in a compiler. In a compiler, your priorities are ease of extension, ease of specification, and ease of transformation. The last thing you want in a compiler language is to worry about ownership when trying to implement expression-rewriting optimizations. Conversely, OCaml is excellent at these things.

Its use can be justified elsewhere, but it should always be understood that manual memory management is always going to be more difficult.

The problem I see, and the reason I sometimes reach for rust when I don't really require manual memory management, is that nothing else is really better for strongly-typed statically-compiled self-contained executables.

Go: it's got the convenience and packaging and ecosystem, but an absolute shit type system.

F#: carries around the baggage of the CLR, and the best tooling is Windows-exclusive. Type system is good but not as good as others.

Scala: absolutely amazing type system, but lots of unneeded stuff too. JVM packaging is a huge pain, and pretty heavy weight. Native compilation options are few and have slow executables in comparison.

OCaml: tiny ecosystem, multicore is always one year away, some weird ergonomic choices.

Haskell: lazy, IO has terrible ergonomics, and the community consists of pie-in-the-sky type theorists.

I would kill for a Dotty-like (Scala 3) native programming language that could omit all of the bullshit that was required to fit into the JVM and work with java libraries.

The state of natively compiled GC'd languages is actually pretty bad, at least ones with an ecosystem/job opportunities.

You either have to run into the same problem as dark when it comes to libraries and ecosystem (ocaml, haskell, D, etc), use go and give up any nice language features, or run on a VM and deal with all the issues of packaging/weight (clr, jvm).

When packaged alongside the binary, VM for all purposes is just the language runtime,e.g. natively compiled Java.

I just don't think natively compiled Java is there yet. It's not trivial to get it working and the ecosystem isn't ready for it yet.

There are certain things that just work (i.e. quarkus, which I have a web service running on 13 mb of ram), but I have never been able to successfully compile to native on my own because of library dependencies. Getting things like Weld or H2 to work is pretty difficult.

It is there since 2000.

AOT compilation has been a feature of most commercial JDKs, specially the ones targeted at embedded development like PTC and Aicas.

jlink potentially helps with weight.

Don't forget SML. A wonderful, simple language with great compilers and multithreading, but little tooling I'd library support.

To me, it looks like the sweet spot might be RC + weak references, which in terms of ease of use is close enough to a tracing GC as to not matter, + the ability to tune away the RC ops in specific circumstances, for example using affine types.

One reason to use Rust is speed. For example https://www.phoronix.com/scan.php?page=news_item&px=Facebook...

Of course, not all projects have this as a high order concern, but some do, and it can make sense to use Rust for those.

This does not mean much without the context. On the top, it is usually the libraries where most of the speed is wasted. In Java you can create HFT programms yet an average Hadoop project is 10 - 50 times slower in terms of latency for a specific operation. It is not a problem with the JVM of Java as a language as much it is a problem with code quality in user libraries.

I don’t think dotnet is faster than rust or anything overall, but ASP.NET Core is 6th is the techempower composite rankings and first or second I believe in the plain text benchmark. This is excluding the large amount of performance work that has gone into the soon to be released .NET 5.

dotnet and Rust are essentially neck and neck on plain text. On any benchmark that actually does work though, dotnet is nowhere to be found (less than half the performance of actix).

Yea, actix is definitely faster than ASP.NET Core and in many benchmarks it is 2x performance wise. My only point really was that ASP.NET core offers better performance compared to almost any other widely used web framework out there. Additionally, performance improvements have and continue to be a focus, with steady progress to show for it.

Speed is also a reason not to use it, as programming and compilation are relatively slow in it.