Live data from Hacker News

Compiler Development: Rust or OCaml?

hirrolot.github.io

41–50 of 107 posts

Re: Compiler Development: Rust or OCaml?

#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 low-level control while also having a more powerful type system and a more "functional" style.

Brushing off the actual efficiency of the produced binary seems like a huge oversight when dealing with a compiler.

Re: Compiler Development: Rust or OCaml?

#42
post #10
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…

I've been seriously at it with Rust for about six months now and really loving it. What do you mean by "use an arena for the AST?" What is an arena in this context?

If you're curious about arena allocators, look at the rust compiler itself. It uses one for all of its allocations as regular heap allocation was not performant enough.

Re: Compiler Development: Rust or OCaml?

#43
post #13
post #5

Earlier quoted context omitted.

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.

There was nothing objective about the article. The moment I saw seemingly random new lines in the rust for no reason, I knew there was going to be a “line counts!!!!” Sentence. When there was, I stopped reading because it was apparent that all matter of objectivity is completely missing. I don’t even like rust.

It would be nice if somebody could offer what they consider to be an idiomatic Rust solution to this very routine problem in compilation if they believe the author is being intentionally deceiving. The Rust and OCaml code from the article looked decent to me. m

Re: Compiler Development: Rust or OCaml?

#44
post #14

Here are the features that I think are most important for compiler development: 1) built in eval -- this allows you to transpile to the host language which is invaluable for writing small tests 2) multiline string syntax -- for evaling more than just one liners 3) built in associative and sequential arrays (for the ast) 4) first class closures 5) panic support (for aborting early from unimplemented use cases) The AST…

I chose luajit for my language and while I agree with many of your points I really miss a typesystem. Somewhat ironically I'm working on a typesystem for luajit..

I also wish it was a bit more performant, but here it's likely my medium to high level code and not luajit's fault. However running the test suite in plain Lua seem some order of magnitude slower than luajit, so it's a lot faster than plain Lua at least.

Re: Compiler Development: Rust or OCaml?

#45
post #14

Here are the features that I think are most important for compiler development: 1) built in eval -- this allows you to transpile to the host language which is invaluable for writing small tests 2) multiline string syntax -- for evaling more than just one liners 3) built in associative and sequential arrays (for the ast) 4) first class closures 5) panic support (for aborting early from unimplemented use cases) The AST…

Is your project public? I'm curious to see how you would go about writing a transpiler in luajit.

Re: Compiler Development: Rust or OCaml?

#46
post #14

Here are the features that I think are most important for compiler development: 1) built in eval -- this allows you to transpile to the host language which is invaluable for writing small tests 2) multiline string syntax -- for evaling more than just one liners 3) built in associative and sequential arrays (for the ast) 4) first class closures 5) panic support (for aborting early from unimplemented use cases) The AST…

I would add pattern matching. I've found this really helpful for manipulating ASTs by matching multiple levels of the tree and pulling out values simultaneously.

Re: Compiler Development: Rust or OCaml?

#47
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 compilation algorithmically slow, while Pascal was designed to be fast to compile.

Re: Compiler Development: Rust or OCaml?

#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 program (which makes use of arena allocators, internal mutation and any other rust features you love) and then try and convert it line by line into ocaml. We would find that many of rust's concepts can't be clearly expressed in ocaml. The ocaml code would end up uglier and measurably slower than rust. And just like that the article would reach the opposite conclusion - that rust is clearly the better language!

But this is silly.

In general, you obviously can't translate between languages line by line like this and expect to have a good time. A beautiful C program is constructed using different ideas than a beautiful Lua program. And a beautiful Ocaml program is very different from a beautiful rust program.

Some obvious examples of ocaml ideas being overapplied to rust in this article:

1. The types don't really need to be wrapped in Rc here.

2. Rust generally prefers mutable imperative code over applicative code. And if you insist on applicative patterns, functions should take a &Foo.

3. Rust code usually doesn't rely on recursion that much, so the lack of guaranteed TCO isn't something people in the community care about.

4. Rust is optimized for runtime performance over code beauty or code size. Of course rust is less elegant looking than a garbage collected language! The trade is that it should also run faster. But where are the benchmarks to make the comparison fair?

The match example is just straight out bad rust code. This code:

    fn eval(term: &Term) -> Value {
        match term {
            Bool(b) => Value::Bool(*b),
            Not(m) => match eval(m) {
                Value::Bool(b) => Value::Bool(!b),
                _ => panic!("`Not` on a non-boolean value"),
            },
            // ... lots more nested matches & panics
        }
    }
Can be flattened, to approximately halve the length of the program like this:

    fn eval(term: &Term) -> Value {
        match term {
            Bool(b) => Value::Bool(*b),
            Not(Value::Bool(b)) => Value::Bool(!b),
            // ... (all other valid patterns)
            _ => panic!("{term} invalid"),
        }
    }
There's an old saying: "Every programming language you learn should teach you to see programs in a new way". Rust is not a crappy alternate syntax for ocaml any more than ocaml is a crappy, alternate syntax for rust. The only thing I learned from the article is that the author doesn't know rust well enough to evaluate it.

Re: Compiler Development: Rust or OCaml?

#49

Why does it seem like I'm hearing about OCaml all the time now? It could just be frequency bias but it wasn't that long ago that I'd never heard of it and now it seems to be getting a lot of attention online.

> Why does it seem like I'm hearing about OCaml all the time now?

I felt that way about a dozen years ago. These things have cycles, apparently. But they also recently released multi-core OCaml in OCaml 5 which opens some doors for OCaml that were previously not open.

Re: Compiler Development: Rust or OCaml?

#50
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…

>while also having high runtime efficiency as a requirement (the reason why C/C++ are such prominent languages for compilers

I'd want to believe that compiler engineers really put effort into compilers performance, but I just don't buy it.

LLVM, GCC, MSVC, etc, etc all of them touch C/C++ and are slow as hell

For compilers written in other languages I'd say that still LLVM is the bottleneck

>It avoids the cost of automatic memory management and provides low-level control.

What "low-level control" do you need? It is not firmware development.

Btw: Microsoft rewrote their C# compiler from C++ to C#.

Post reply on HN