Live data from Hacker News

Compiler Development: Rust or OCaml?

hirrolot.github.io

71–80 of 107 posts

Re: Compiler Development: Rust or OCaml?

#71

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

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

Re: Compiler Development: Rust or OCaml?

#72
post #41

Compilers are in this weird spot where they are really mathematically defined programs (which OCaml excels at implementing), while also having high runtime efficiency as a requirement (the reason why C/C++ are such prominent languages for compilers). With such requirements, I think a point that is fair to make is that Rust acts as a great middle-ground. It avoids the cost of automatic memory management and provides l…

I am not sure that the runtime efficiency of the compiler binary is that important. People like fast compile times, but that is more to do with language design than the choice of language for the compiler. You could write a compiler for Pascal in Python or another very slow language and it would be faster than a Rust or C++ compiler written in Rust or C++. That is because those languages have designs that make compil…

Almost every compiler is fast on toy-sized programs. E.g. the standard Java compiler is pretty fast, and uses little resources.

It becomes visible when you build a large project: you notice that when you face 100k LOCs, efficiency of every compiler's part starts to matter, and RAM usage may grow to uncomfortable levels if your compiler does not care enough.

Re: Compiler Development: Rust or OCaml?

#73
A lot of people here say that the Rust version is non-idiomatic and likely not even working.

So the answer apparently is simple: between two languages, for an important project use the one which you wield best.

Re: Compiler Development: Rust or OCaml?

#74
post #48

I normally love articles comparing programming languages at real tasks, but this article seems very low quality to me. The author clearly doesn't understand how rust thinks about programs. Instead, they're trying to pretend that rust is an alternate syntax for ocaml and being surprised to find it comes up short. The same article could easily be written the other way around. We could start with a high performance rust…

> Can be flattened, to approximately halve the length of the program like this No it can't. You're missing the recursive call to `eval`.

It looks like if let guards could help with flattening it in nightly but not in stable[1]:

https://rust-lang.github.io/rfcs/2294-if-let-guard.html

[1] https://github.com/rust-lang/rust/issues/51114

Re: Compiler Development: Rust or OCaml?

#75
post #41

Compilers are in this weird spot where they are really mathematically defined programs (which OCaml excels at implementing), while also having high runtime efficiency as a requirement (the reason why C/C++ are such prominent languages for compilers). With such requirements, I think a point that is fair to make is that Rust acts as a great middle-ground. It avoids the cost of automatic memory management and provides l…

I am not sure that the runtime efficiency of the compiler binary is that important. People like fast compile times, but that is more to do with language design than the choice of language for the compiler. You could write a compiler for Pascal in Python or another very slow language and it would be faster than a Rust or C++ compiler written in Rust or C++. That is because those languages have designs that make compil…

> I am not sure that the runtime efficiency of the compiler binary is that important.

If the compiler is for JIT, then efficiency will be important.

Re: Compiler Development: Rust or OCaml?

#76
post #34

Earlier quoted context omitted.

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.

You can browse compiler source code here with type annotation and code navigation if you like https://htzh.github.io/browse-ocaml/ . The editor plugins typically don't work on the compiler itself. These annotations and links were generated fairly painlessly from Ocaml compiler features (most hard work done by the compiler already).

Re: Compiler Development: Rust or OCaml?

#77
post #5
post #3

The article has fair points, but after trying OCaml and Rust... I chose Rust. Without going into huge amounts of detail, a compiler is more than simply a parser/ast/code generator and there are other aspects to consider such as the richness of the ecosystem, editor support, etc. Also, I suspect the author is more familiar with OCaml than Rust as you wouldn't typically box everything but likely use an arena for the AS…

Can you write an equivalent piece of code that shows why Rust wins here with more familiarity and leveraging the ecosystem? With compilers I don't think there is a huge amount of using the ecosystem. I think what TFA does is a good case study in trying to be objective: write it both ways and compare.

[deleted]

Re: Compiler Development: Rust or OCaml?

#78
post #58
post #48

I normally love articles comparing programming languages at real tasks, but this article seems very low quality to me. The author clearly doesn't understand how rust thinks about programs. Instead, they're trying to pretend that rust is an alternate syntax for ocaml and being surprised to find it comes up short. The same article could easily be written the other way around. We could start with a high performance rust…

Your example is more concise but the error message "{term} invalid" is less descriptive than the author's. What would be the idiomatic way for the function `eval` to provide good error messages in Rust?

I would probably put a trait implementatoin on Value that does `.invert_bool`, and have that panic. That way eval is just `eval(m).invert_bool()` and if it panics it panics.

What you really probably want is to make this a Result type-returning thing, and then have have `not` be a function of type Value -> Result, and then you can do not(eval(m)) and panic at the top-level.

Re: Compiler Development: Rust or OCaml?

#79
post #76

Earlier quoted context omitted.

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

You can browse compiler source code here with type annotation and code navigation if you like https://htzh.github.io/browse-ocaml/ . The editor plugins typically don't work on the compiler itself. These annotations and links were generated fairly painlessly from Ocaml compiler features (most hard work done by the compiler already).

Thanks for the links! I'll try to give it a read sometime.

But also, the editor plugins don't work on the compiler itself? Why's that? So you can't use Merlin on the OCaml compiler? That doesn't seem great.

And what's with the syntax highlighting being funky? The highlighter appears to think that a lot of these files have unterminated comments or string literals.

Re: Compiler Development: Rust or OCaml?

#80
post #48

I normally love articles comparing programming languages at real tasks, but this article seems very low quality to me. The author clearly doesn't understand how rust thinks about programs. Instead, they're trying to pretend that rust is an alternate syntax for ocaml and being surprised to find it comes up short. The same article could easily be written the other way around. We could start with a high performance rust…

Notice from the definition of `Term`

enum Term { Bool(bool), Not(Box), ... }

that your code simply does not typecheck. `Not` expects a `Box`, not a `Value`.

It's also worth noting that one would probably want to consider something like

Not(Not(Bool(true)))

a valid term, which your implementation wouldn't.

Post reply on HN