Live data from Hacker News

Compiler Development: Rust or OCaml?

hirrolot.github.io

31–40 of 107 posts

Re: Compiler Development: Rust or OCaml?

#32
post #26

Earlier quoted context omitted.

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

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…

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.

Re: Compiler Development: Rust or OCaml?

#33
post #32

Earlier quoted context omitted.

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…

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…

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.

Re: Compiler Development: Rust or OCaml?

#34
post #32

Earlier quoted context omitted.

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…

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.

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

Re: Compiler Development: Rust or OCaml?

#35

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 beautif…

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

Re: Compiler Development: Rust or OCaml?

#36
post #28

Earlier quoted context omitted.

Personally, it’s not so much that I disagree. It’s more that Ocaml has a top notch ecosystem for compiler writing. That’s probably by far its strongest point with library like Menhir having few equivalent in different ecosystem. Not that there is anything wrong with Rust if you are ready to pay the price of having so much low level things to deal with.

Can you explain what Menhir does better than other parser frameworks? For what it's worth, I'm not a huge fan of parser frameworks. I tend to prefer hand written parsers, either via a combinator library or fully manually. Rust has a pretty darn good ecosystem too btw. chumsky for parsing, rowan for syntax trees, salsa for incremental computation, miette for errors, inkwell/walrus for code generation.

It can generate elegant and efficient parsers for LR(1) grammars.

> I tend to prefer hand written parsers, either via a combinator library or fully manually.

That’s common with people used to languages which provide poor parser generators.

Re: Compiler Development: Rust or OCaml?

#37
post #36

Earlier quoted context omitted.

Can you explain what Menhir does better than other parser frameworks? For what it's worth, I'm not a huge fan of parser frameworks. I tend to prefer hand written parsers, either via a combinator library or fully manually. Rust has a pretty darn good ecosystem too btw. chumsky for parsing, rowan for syntax trees, salsa for incremental computation, miette for errors, inkwell/walrus for code generation.

It can generate elegant and efficient parsers for LR(1) grammars. > I tend to prefer hand written parsers, either via a combinator library or fully manually. That’s common with people used to languages which provide poor parser generators.

What makes them more elegant than the average parser? How’s the error recovery? Can you parse into high fidelity syntax trees efficiently?

I don’t know of many production compilers that use parser generators

Re: Compiler Development: Rust or OCaml?

#38
post #34

Earlier quoted context omitted.

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.

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

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

Re: Compiler Development: Rust or OCaml?

#39
post #21

This starts out as a fair comparison but evolves pretty quickly towards a one-sided recommendation for Ocaml. I'm quite sure that there are _some_ advantages of Rust that are not listed here and would be curious to learn more about them too.

Even the written tone feels biased > Here is CPS conversion written in Rust vs > The same algorithm in idiomatic OCaml

Sounds to me like they are comparing bad code and good code, not the languages themselves.

Re: Compiler Development: Rust or OCaml?

#40
The author doesn't seem to have much experience in writing Rust.

For instance, passing RefCell by value as their code does makes no sense (just use u32...), and the code seems to have a lot of clones, most of which are probably unnecessary, while not having a single instance of the "mut" keyword.

In fact, I'm pretty sure it's completely broken, since their gensym doesn't do what they want, due to their wrong use of clones and refcells (it should take an &mut u32 and just increment it).

And definitely not idiomatic at all.

Post reply on HN