Advantages of OCaml over Rust

[ryanslade]

This is an honest question and not an attempt to troll

In what categories of applications do you believe OCaml would outshine Rust?

[bluddy]

I don’t know that most people here (including myself) are qualified to answer this question. From what I do know of Rust, you still have the mental overhead of keeping track of linear types and their lifetimes. This is very powerful, but also a burden when trying to do things that don’t need the highest performance level possible. Rust also doesn’t give you garbage collection by default – you have to add it in using a library, which is probably not as convenient. Finally, Rust really compromised in terms of syntax: its original syntax was functional, but it eventually adopted a more C++ like syntax since those were the programmers they were trying to lure to the language.

Most applications will probably be simpler to program in OCaml rather than in Rust. At the same time, if you’re writing an OS or a performance critical tool, Rust will guarantee performance around the level of C++, making the extra cognitive burden worthwhile.

[BrendanLong]

I know the Rust people are working on this, but last time I used it, async code was much harder to write in Rust than in OCaml. I think Rust is prioritizing efficiency in ways that make it hard to describe the types of async return values, while in OCaml the return type is generally straightforward ('a Lwt.t or 'a Deferred.t). It remains to been seen if a sufficiently smart Rust compiler can fix this (they’re certainly trying).

My experience with Async libraries has also been better in OCaml, although Rust seems to be catching up.

[shonfeder]

The first half of this video gives a whirlwind tour of OCaml’s strengths and numerous applications: Fast, Flexible and Functional Programming with OCaml.

Since one of OCaml’s most outstanding application areas is as a meta language for implementing other languages, it’s worth noting that the original Rust compiler was written in OCaml.

[ryanslade]

Thanks for linking that video, it was very interesting.

[shinzui]

I’ll try to answer since Rust and OCaml are currently my two favorite languages.

I think OCaml’s most significant advantages over Rust are:

1. It’s more suited for pure functional programming. Although Rust supports FP constructs, most Rust code is imperative.

2. Rust’s compiler (rustc) is very slow. There is a lot of work being done to speed it up, but I doubt it would match OCaml’s.

3. You can build web apps in OCaml through ReasonML.

4. I think OCaml’s syntax is more elegant even though I’ve programmed in C-like languages most of my career.

Having said all that, I think Rust has a lot of advantages over OCaml that I hope the OCaml community will address in the future.

[spreadLink]

Would you mind elaborating what you like in rust more? I’ve dabbled with it a little bit so I’m somewhat interested in what features there are to toy around with.

[perry]

I can immediately name some things for which Rust is clearly better suited. Some of them are because it is not a garbage collected language.

For example, even after decades of work on the matter, garbage collection still remains unsuitable in modern operating system kernels that operate with real time constraints, and, although I can imagine constructing such a kernel in Rust, because it does not use garbage collection, I would have difficulty imagining constructing one in OCaml. (Note that if one doesn’t have anything more than the mildest of real time requirements, OCaml is probably fine for such purposes. The bulk of applications do not have such requirements.)

Memory constrained environments are also a problem for garbage collection. It is often claimed in papers that garbage collected systems operate with even better overall throughput than systems without it, but those papers rarely mention that to do this, one needs much more memory that one does for manual management. Sometimes this is not an issue, but in many environments, it is absolutely an issue. People also often pretend that budgets aren’t a thing, but if you’re selling something at a $10 price point, another $0.30 worth of parts are actually a big deal, and even if you’re selling someone a device like an iPhone, more RAM means more power which means less battery life, and thus, garbage collection is not something one uses lightly.

(None of this is to say that I don’t love OCaml. I’m doing my work in OCaml these days. However, it isn’t the right tool for every job.)

[smolkaj]

I would say OCaml outshines Rust whenever you don’t need to be extremely careful about low level details such as memory management.

OCaml sacrifices some control for convenience. It is the nicer language to use whenever you don’t need that extra control.

Rust gives you full control, but has to sacrifice some convenience. A lot of applications will be a whole lot more painful to write in Rust as a result.

In conclusion, use OCaml if you can, and use Rust if you must.

[darrenldl]

OCaml is a lot easier to use, if you’re dealing with mostly immutable structures.

But Rust’s borrow checker absolutely helps when you’re writing a lot of mutable code with parallelism, where automatic memory management does not deal with incorrect ownership issues. These things would still need to be manually reasoned with in OCaml.

One last advantage of OCaml over Rust I might add would be Mirage OS, admittedly this is more about the eco system rather than the design of OCaml.

[perry]

In conclusion, use OCaml if you can, and use Rust if you must.

Yah, in most ways, I’d say that the two are some of the best options out there right now.

[mars0i]

About GC and real-time constraints, I’d guess that Jane Street, at least, has some applications where response times are important. I think I remember reading a remark by @Yaron_Minsky that JS likes OCaml partly because of the control that GC tuning parameters gives them, but I can’t find it now. And there has been relatively recent work on improving latency in the OCaml GC, apparently partly in response to Jane Street’s interest:

Building a lower-latency GC

None of this conflicts with points @perry, @smolkaj, and @darrenldl made about memory management and Rust (a language I know almost nothing about, anyway).

[perry]

About GC and real-time constraints, I’d guess that JS has some applications where response times are important.

I can’t think of one such JS application. [Edited to add: I read “JS” here as “JavaScript” and apparently “Jane Street” was meant.]

Note that when I’m talking about hard real time, I’m not discussing “the user will be irritated by pauses” or even “the bread oven might shut off a second late” but “the rocket might explode”. Say you’re SpaceX and you’re building something that has to go from supersonic speeds to zero in a matter of seconds during landing and has to precisely steer several rocket engines in the course of that tiny period of time. Or, say, you’re directly controlling the sparkplugs in an internal combustion engine with software and need accurate timing down at or below the microsecond level. I understand the desire to use garbage collected languages in such environments, but it simply isn’t practical.

That’s fine, though, most applications are not like this, and as an alternative, one can generate hard real time code from a high level functional description (and indeed, some people like Adam Chlipala’s group at MIT have successfully generated formally verified low level code for such things in Coq.)

[smolkaj]

I can’t think of one such JS application.

JS does algorithmic trading. I wouldn’t be surprised if they did have some tough real time constraints.

[perry]

I am frankly surprised to hear anyone is doing the real-time part of HFT stuff in JavaScript, but now that you’ve informed me they are, I’m going to silently shudder off in the corner for a while.

[bluddy]

JS = Jane Street, not javascript.

[perry]

JS = Jane Street, not javascript.

Oh! If that’s what’s being referred to, I’m under the impression, given that they build hardware, that although almost everything there is OCaml, the stuff that has to respond in real time is probably doing the work in hardware…

[mars0i]

JS = Jane Street, not javascript.

Yeah. After the original post, I realized that I’d ended up with “JS” in the first sentence, and revised it to say “Jane Street”. @perry must have seen the original version, and read it in a natural way. My fault for posting too quickly.

[Yaron_Minsky]

Oh! If that’s what’s being referred to, I’m under the impression, given that they build hardware, that although almost everything there is OCaml, the stuff that has to respond in real time is probably doing the work in hardware…

Nope! We write a ton of soft-real-time applications in OCaml, where we have programs that turn around packets in single-digit microseconds, and process millions of transactions per second on a single-core OCaml program.

You need to adopt a very particular programming style where you allocate very little and promote nothing; but OCaml is actually a hospitable home for such programs, once you learn how to write them.

I used to think that linear and affine types were going to be more important for writing these kinds of applications. But while these programs have to recycle objects and therefore need to be cognizant of lifetimes, the disciplines around this tend to be very simple, and I don’t know of any bugs we’ve hit because of these cases. So I’m now less sure that that’s the place I want to spend my type-system complexity budget…

y

[bluddy]

You need to adopt a very particular programming style where you allocate very little and promote nothing; but OCaml is actually a hospitable home for such programs, once you learn how to write them.

I’d love to see an article about this programming style. I personally can’t imagine avoiding allocation in OCaml.