Advantages of OCaml over Rust

Community
61

Interesting, not ran across this language yet…

  • C++, D, and Rust have operator overloading, so the + operator might call a function.

Uh, operators are functions, this always bugs me when someone says this, overloading or not, operators are still functions… >.>

The initialization value of global variables is evaluated at compile-time.

Hmm, looks like it has a built in interpreter to run zig code at compile-time as it calls a function for it, wonder what the limits of that are…

However any type can be made into an optional type by prefixing it with ?

Looks kotlin’y, auto detection of when tested, etc…

Any functions that need to allocate memory accept an allocator parameter.

Interesting, I like that the allocator has to be passed around, makes it very easy to override on a case-by-case basis, definitely something rust got wrong. However it needs to be optionally passed in and 99% of the time you don’t care. In addition, the allocator signature appears… insufficient for proper memory allocation that isn’t coming from a simple x86-like HEAP or so… In addition, how do you free that same memory with the right allocator without passing the allocator everywhere around with it?

Manual memory management

Woo, but what ways does it have to enforce managing it, or any other resource for that matter, properly?

defer/errdefer

Ogod, don’t like this stuff, it makes it so easy for the user to forget it…

catch

Looks like just an optional deconstructor for returned error values, why not make that generic like rust did…

break

Wait what, really? This is just a goto here…

try

Oh hey, it’s Rust’s try! macro, except that rust is getting rid of it because ? is better.

unreachable

This just looks like Rust’s panic!() rather than an actual unreachable declaration (which in rust will significantly effect codegen). This really needs to be renamed…

Built in stacktraces on everything

Hrmm, wonder what cost this adds…

Types are values

Interesting, so it definitely has an interpreter at compile-time

typeinfo

Oh yay, and every type is carrying reflection information with it, that’s going to add a pointer to anything passed around via pointers needlessly…

comptime

Ah, forcing a function to run at compiletime can be done via the comptime keyword, guess that’s just like constexpr in C++ but in some other contexts.

Resource Management

So the language has no resource management to speak of, short of easy-to-forget defer/errdefer calls (which of course constrain the lifetime to the scope only).

Overall it feels more like Go with a bit more training wheels and less GC and more manual resource management of the failed pointer variety, does not feel like a Rust/C++ replacement.

Disclaimer: I’m an OCaml dev for ~10 years off and on, C++ dev for 30 years, Rust dev for ~2 months, plus a ton of other languages jobs depending

62

I’m also following Zig’s development. It’s not at all aimed at being a C++ replacement, but a C replacement (i.e. trying to be simple and “entirely fit in your head”). The lack of borrow checking stems from that, you can’t really have a minimalistic C-level language that also gives your the sophisticated type system of Rust.

On the other hand, it has non-null pointers, bound checking, dependent types instead of macros (typeinfo is entirely introspection at compile time afaik — a lot like D) and an interesting error system that is a kind of custom effect system miles ahead of errno. I could see it used for runtime systems, embedded databases, etc. where rust would have to use a lot of “unsafe” anyway.

edit: I think the thing that worries me most in Zig, for now, is the lack of RAII. It’s at odds with generics.

2 Likes
63

Yeah it looks like an interesting little language, a lot like Go but actually useful sans GC. I’m going through the blogs and they make a few very unfound statements specifically about Rust (the author seems to talk about rust a lot I’m noticing), like an alignment issue (which I just tested and does not exist, the compiler forces the array to the same alignment as the unsafe i32 casting now, though it may not have a year ago), binary size (I’ve an embedded rust program in <6kb in size and supposedly rust can’t do anything below ~26kb or something like that for embedded systems), etc… It’s very odd…

I’m keeping the language on my radar for whenever a new micro project comes up, might write something in a few languages including it to see how it compares, but as it is, the lack of type system usefulness I don’t see making it safe for my main work, I prefer languages that make maintenance easy, and over 35 years I’ve learned that crappy type systems harm that more than anything else (why do you think I like ocaml). ^.^

64

Zig looks like it could (eventually?) provide a safer and easier way of writing OCaml C stubs. It can call C libraries without any ceremony and has a growing stdlib. Has anyone experimented with this already?

Regarding Rust, I’m curious to know what parts of the ecosystem, if there are any, you miss when you’re working with OCaml. If we put the following aside:

  • Core language and syntax pros/cons. Traits, metaprogramming, etc.
  • Advantages such as additional safety, parallelism, performance
  • Simply enjoying learning and writing Rust

And focus on libraries and tooling Rust might’ve gotten an edge over OCaml because of the increase in interest and community size instead of technical differences, what are some specific projects you’d like to see in OCaml (or any OCaml libraries that need catching up to do)?

I mainly work on web and native applications targeting end-users, and in this context, I can’t help but feel like OCaml ecosystem is full of gems that have a clear edge over equivalent libraries and tools I’ve used in other languages. Plus, the language itself hits the sweetest spot I’ve experienced so far.

I’m not bothered by the hype around Rust at all, I think it’s adoption is good for the software industry in general. I’m mainly interested in finding out what cool stuff I could be missing out on and practicing my OCaml implementing them. Beating the averages and all.

1 Like
65

Generally, I don’t think it’s a question of technical issues at all, or missing functionality as such.

The Rust community is much younger than the OCaml community but seems to have grown at a far faster rate. I think this is at least partially because it has a strong dedication to good documentation, user-friendly tooling, and rapid development. Importantly, it has a dedication to being pleasant and friendly to people who want to contribute. If one wanted OCaml to grow fast, it would be necessary to have similar policies. I don’t think that’s going to happen, at least any time soon.

I’ll expand on two issues in particular, though all are important.

  1. OCaml’s documentation is not very good — and in some parts of the ecosystem, it’s absolutely awful — but there is open disdain from many people about making the documentation better, and certainly disdain for making it good enough for beginners. One claim I have seen from some people is that they do not find more thorough documentation necessary (after all, they already understand how things work) and that more verbose documentation would only slow them down. Thus, beginners exposed to Rust learn the language much more easily, and many exposed to OCaml find it more difficult than it needs to be.
  2. Problem reports and pull requests in the OCaml compiler/stdlib ecosystem often take years to resolve. There are many pull requests outstanding for relatively small changes that have reasonable consensus and yet which have been open for years will likely remain open for years to come. It isn’t a question of careful consideration, but rather one of general apathy about processing such things in a timely way. This is demoralizing to contributors. It is easy to make an ecosystem moribund by taking forever to act on contributions, and relatively easy to make it friendlier by acting on them efficiently. Rust is much more welcoming of contributions, and the community devotes a lot of energy to making sure that contributors are treated respectfully and their contributions are handled efficiently. This tends to mean that you end up with more good contributors over time.

I do not see either of these issues being fixed. There isn’t even consensus that the two of them are problems; indeed, many people will disagree with me. I suspect that it will be easy for people to argue why these are in fact good things about OCaml (“our documentation is good for experts”, or “it’s appropriate that compiler changes get careful consideration”). And of course, perhaps I’m even wrong.

That said, I think Rust will continue to grow rapidly compared to OCaml. This does not mean OCaml is doomed or anything like that; I’m not a deep pessimist and not about to stop using the language. However, I suspect that it is unlikely that the community will make the commitment needed to being “friendly” and thus we can expect that growth will continue to be slow, and thus the labor pool available for working on improvements will continue to be limited.

8 Likes
66

Could you please point exactly to occurrences where there was open disdain in improving the documentation ?

There may be disagreements on how documentation should be written or structured but I don’t think there was any disdain from anyone at any point in the idea of improving documentation or background material.

Please stop propagating myths about the OCaml community, you are hurting it.

2 Likes
67

Maybe I didn’t phrase my question very well, because I think you’re answering to a claim I didn’t make. I’m not asking why OCaml sucks or what can we do to increase its adoption. It was simply a query for “what are some new shiny stuff I can try stealing from Rust, and can make OCaml more fun and/or productive for me”.

Reading the posts from last year again, it seems like this topic highlighted the lack of an http2 implementation, and maybe as a result of this topic we now have one: https://github.com/anmonteiro/ocaml-h2. I found some other stuff in https://ocamlverse.github.io/content/help_needed.html that seems to have been partly resolved. In the meantime, Rust ecosystem have moved forward quite a lot.

Yeah, maybe I was also a little bit curious about increasing adoption of Rust from seasoned OCaml/FP developers, but I hope it’s not simply about sheer frustration and bad documentation. I mostly assumed that it targets a niche in their daily workflows that languages like OCaml or Haskell didn’t serve very well. At the very least, I find the development pace and documentation quality perfectly ok for a community of this size.

1 Like
68

I think that the shiny stuff we could try stealing from Rust would be their extremely effective mechanisms for expanding their user community, which would lead to a lot more cool things being built for the benefit of everyone. Yes, I understand that isn’t what you were asking.

2 Likes
69

Reason and BuckleScript community alone produced so many cool things that can only taken away from my cold dead hands, so I strongly disagree here. My first encounter with OCaml was through that, and ReasonReact, and everything that came after that was cherry on top. I can name lots of “killer OCaml apps” for the work I do. Just the last few commenters on this topic alone produced so many high quality and well-documented libraries I thoroughly enjoy using.

I haven’t been a part of this community long enough to have a concern about its size or direction, if there should be some. Maybe it’s because I’m used to being part of even smaller language communities with tiny industry adoption, or maybe because I’m not a person that usually thinks about things like “community building”, “growth”, “beginner-friendliness”. But still, I disagree with the alarmist attitude. I already got back so much more than my money’s worth from what little investment I’ve made learning OCaml.

edit: I’m getting off topic quite a bit, but bear in mind that I’m a newcomer who’s looking at OCaml community from outside most of the time. And I explicitly want to grow more and be a part of “the labor pool available for working on improvements” you mentioned, no matter how small it is at the moment. Because of this, I guess I’m inclined to strongly disagree with your statements and won’t get convinced of them easily :slight_smile:

1 Like
70

I as well; OCaml is a very productive language to work in. That’s a reason I still use it and will continue to do so. I think, however, people often are too tribalistic about such things, and as a result, fail to look at the flaws in the projects they are associated with very realistically in favor of being supportive of their affiliation group. I think it is generally better to look at such things in a clear eyed way; it makes it easier to make rational decisions.

1 Like
71

I don’t think this is true. If it was true, it would be possible to help resolve these cases by contributing to the triaging of issues – pinging people on PRs that fits this criterion, for example. Would you like to provide examples of such PRs? (I’m assuming that the PRs have been reviewed – otherwise of course they cannot be merged – and do not conflict with evolutions in the codebase – otherwise someone needs to fix the conflicts.)

In my personal experience, we are indeed sometimes limited by the a limited bandwidth of people doing reviews and taking actions on PRs (reviewing a proposed change with high quality standards can be a lot of work), and more contributions could of course help – note that most people doing reviews today do so on their free time, or at least instead of work they would get more recognition for; in particular it is very rare to have “please review PRs” on your job description.

There are a few cases of discussions ending up with no consensus, because we don’t know of a solution that has no downsides giving us pause. These issues can be blocked for years, and then revisited when someone comes with an idea that is clearly a big advance over the existing proposals, and then the situation can move fast. One example would be the let ... in .. with exn -> ... syntax that people have tried to propose in various forms over the years, have stalled, and were swiftly replaced by the match .. with exception ... construct which is better on all counts. But there are not “many” issues blocked in this way – fortunately it’s an uncommon situation.

3 Likes
72

I don’t mean to single it out, it just comes to mind without looking, but let-def’s patch for tail recursion mod constructor has taken a very long time. I suspect I could find more without much trouble, but I’m on my phone.

Apathy is perhaps the wrong word, but there’s definitely the appearance of “it’s okay for it to take a few years or longer”. I don’t think I would have the patience myself for that.

73

The tail-recursion modulo cons (TRMC) PR is #181, and I don’t think it fits your description. It has indeed been around for years, but the main reason is that the author has decided to work on other things than making necessary updates (which is perfectly ok, given that this is a contribution on his free time), and also that no one has stepped up to review it so far. Given that most of the delay comes from waiting on the people doing the work (the original author, or someone else willing to help; and a reviewer), I don’t see what could be done differently in our processes to make resolution faster – in particular, pressuring the authors to work more on their free time doesn’t really sound sustainable to me.

Of course we could say “if a PR looks good-in-theory but hasn’t seen much progress in a year, we close it”, and this would have been closed in a timely way, but I fail to see the benefit of that.

1 Like
74

No that’s basically it. I mainly use rust for areas where I don’t want a GC, and/or heavy parallelism.

Honestly, as a ~30 year C++ Primary dev and a ~15 year OCaml hobby/tool dev the thing that attracts me most to Rust is the lifetime system combined with RAII can handle any resource management, unlike GC’s that manage only memory (and in a very… squishy way), basically encoding how I’ve worked with C++ for decades but baking that whole style into the language itself, it “feels” very safe and productive, I don’t have to worry about things or how things are being accessed or anything like that. It’s like taking the type safety of OCaml combining it with the resource management of C++ into a very nice union.

I mainly work on back-end servers and tiny embedded chips, only incidentally front-end stuff when I have to, and OCaml is lacking a lot in these, where C/C++ has reigned king (and quickly upcoming Rust).

My use of OCaml has mostly been for what most use Python for, making Tools to manage things with.

What I think is that’s mostly because it’s the first language that is actually drawing C/C++ devs, which is an absolutely massive ecosystem.

C/C++ absolutely HATE, like teeth-seething chair-throwing hate the C/C++ dependency management and build ecosystems (not through any fault of the languages, but just because it is long since past for any one thing to take over, there is ‘too much’), and if you notice this is where Rust is absolutely shining. C/C++ have loved autogenerated documentation (doxygen has been a long love) and this is also where Rust is shining (baked into the language ecosystem itself).

Rust is also growing as-a-language very quickly, and there are a lot of discussions around the changes made as well, this is also very nice from the usual slow-moving C/C++ improvements.

I still like the OCaml type system more, Rust is lacking very useful features in some way (which you can mostly emulate with more code), but the Uniform Resource Management patterns of RAII and lifetimes blow GC away especially as GC can’t manage sockets or files or GPU connections or anything like that properly, it’s deterministic and comfortable and expected.

I’m not actually a fan of Rust’s syntax, too much like C+±noise, I would prefer OCaml’s, but eh…

This, big time, that’s why I love making tools in it!

6 Likes
75

Recently Rust works hard towards algebraic effects, soundness of the trait system with Chalk(Prologish interpreter), asynchronous programming, and many other interesting things. So it might beneficial for OCaml developers to keep an eye on Rust developments.

9 Likes
76

I’m kind of surprised no one mentioned type inference yet.

OCaml will infer the most general types for almost everything (except for objects with polymorphic methods and functor arguments) whereas Rust requires much more type annotations. The extra boilerplate makes Rust more verbose and less flexible if you end up wanting to change types around.

5 Likes
77

OCaml’s inference is awesome.

Rust generally only requires type declarations on function signatures, everywhere else is optional in one form or another; considering how rust is designed I’m unsure how well it could infer function types in many cases… Hmm…

1 Like