[hardwaregeek]

I skimmed the article, and comparing the two programs, yes, the OCaml one is shorter and more elegant. But it also reads like a math magic spell. There's no type annotations for me to figure out what the heck each term is. The naming conventions lean extremely terse. Perhaps it's my lack of experience with OCaml, but it doesn't feel as legible.

The Rust one reads like...well a program. A program that's not as beautiful, but is very much designed to be taken apart, debugged, improved, etc.

I fully agree that if you're writing pure, recursive, data structure manipulations, OCaml is likely a better fit. It's closer to mathematical notation and I see the elegance in that. But if I were to take that data structure manipulation and turn it into a compiler with thousands of lines that I navigate with an IDE, with logging, with annoying little edge cases, with dozens of collaborators, I'd choose Rust.

[grumpyprole]

> There's no type annotations for me to figure out what the heck each term is

You can add additional annotations in OCaml if you want, or just query the type of a term in Merlin.

> a compiler with thousands of lines that I navigate with an IDE, with logging, with annoying little edge cases, with dozens of collaborators, I'd choose Rust.

Why? OCaml supports logging and IDEs. Simple elegant code without the burden of manual memory management, makes it better able to cope with edge cases, being taken apart and refactored etc. Less of the complexity budget has already been spent.

[jasinjames]

I like that term "Complexity Budget" a lot. I'm going to steal that one!

[brmgb]

I think it’s your inexperience talking here as programs in both languages here use mostly the same naming conventions and abbreviations, the main difference being that Ocaml is its usual terse and to the point while Rust is well far less terse

[hardwaregeek]

Yeah isn't that my point? Rust isn't trying to be short or elegant. There's no zen of Rust. There are elegant aspects of Rust, but it's not a central goal. Whereas with OCaml it's trying to be elegant. It's encouraging people to write a program where you read it, go "wait, how does that work?", then re-read it and marvel at the beauty of it.

To be clear, elegance is important. A language absent of elegance would be a bore to write (cough Java cough). But too much elegance and it can eclipse the legibility of the language. No type annotations is elegant. Is it legible? Not in my opinion. But perhaps it is in yours.

[brmgb]

It is definitely very legible here and at least as legible as the Rust equivalent. It’s actually a lot more legible than the Rust equivalent here to be fair.

The Ocaml program is mostly matching followed by a chain of operations. It’s far removed from elegance for elegance sake. Meanwhile Rust is handicapped by the machinery it forces you to deal with as a lower level language introducing life time.

Type annotations are a non issue. They are systematically provided in Ocaml in a different file than the code. This header file is not provided here because well it’s a blog post.

[hardwaregeek]

I suppose that's ultimately in the eye of the beholder. I suspect that if this compiler were to be 10x, 100x bigger, you'd see a pretty big difference. Like rustc, as massive as it is, is pretty legible as compilers go.

[brmgb]

I will take any of the dozen of sometimes very large compilers written in Ocaml above rustc personally but to each their own.

[hardwaregeek]

I'd love links to them! I tried reading the OCaml compiler source but quickly got overwhelmed.

[liampulles]

Conversely, I'm not familiar with Rust, and Rust looks pretty illegible to me. Probably we need more experience with these languages before we judge.

[whimsicalism]

> There's no type annotations for me to figure out what the heck each term is.

If types can be perfectly inferred, I don't see why I wouldn't take advantage of it. Whatever Ocaml IDE you use will easily be able to tell you the types anyways

[Karliss]

I have no problems with type interference that happens within limited scope. Once you get into territory of type interference across multiple functions you get a similar problem as c++ template errors (before c++20), where the compiler can tell that types aren't correct but it's not clear where the actual mistake was made: did you pass a wrong value with with wrong type to a function at the top, did you use a wrong function call 5 levels deeper or did you access a wrong property somewhere in the middle. I am not sufficiently familiar with Ocaml to tell how much of a problem it's for the specific example in article, but I have some experience with C++ template errors and I remember similar problem in Haskell if type annotations were used too sparingly. Not every programing language will have as bad looking errors as c++ templates, but even if errors are short it doesn't change the inherent problem that compiler can't know what the intention behind large block of type interfered region was. More explicit types split the type interference into smaller regions which means that error message will be closer to the actual place of mistake made by programmer, it also allows checking each region individually for correctness.

[nine_k]

The problem is that the article is not an IDE. It would be nice to add some explicit annotations.