Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Compiler Development: Rust or OCaml?

hirrolot.github.io

Post reply on HN
Print view View original

81–90 of 107 posts

Re: Compiler Development: Rust or OCaml?

#81

Post by josephg »

gottlobflegel wrote: post #80
josephg wrote: 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.

Ah yep, my mistake. I’ve missed out on the recursive inner evaluation. Traits might work better here, but it’s not so obvious.

In any case, I stand by all the other points I’ve made in my comment.

Re: Compiler Development: Rust or OCaml?

#82

Post by tyg13 »

solomonb wrote: post #68
tyg13 wrote: post #60

Earlier quoted context omitted.

I don't think anyone was claiming the author was being intentionally deceiving, just that they're not very good at writing idiomatic Rust. The first thing I'd suggest, as someone who's done their fair share of Rust compiler dev, is to stop using `Box` and `Ref` everywhere. Terms should not own their child terms; the idiomatic way to handle this is to use an arena and typed IDs, and pass a reference to the arena when…

So the solution to writing idiomatic code in the language whose essential feature is the ownership semantics and borrow checker is to not use the ownership semantics and borrow checker?

This is sort of a flippant response, but I'll answer it seriously.

The premise of this question is incorrect: you can't not use the borrow checker in Rust. Instead, you are satisfying the borrow checker by ensuring at the point of use (deref of the ID) that there is valid data by providing a provably-live reference to the arena in which it was allocated.

In another language like C/C++, you'd just use a raw pointer, which is ergonomically-nice, but there's no guarantee that it actually points to a valid object. Rust forces you toward a solution that is guaranteed to be safe, and logically makes sense when you think about it -- nodes in a graph should not own other nodes in the graph; instead, they should be owned by the graph itself, and other nodes should simply hold references to each other. This is how you tend to implement safe and efficient graphs in C++ anyways, the only difference being that in Rust your references are indices, whereas in C++ your references are raw pointers.

Re: Compiler Development: Rust or OCaml?

#83

Post by klodolph »

hardwaregeek wrote: post #66
klodolph wrote: post #64

Earlier quoted context omitted.

You use the generated parser as a platform for experimentation. If you know the language, and you have a bunch of users, and you are writing a parser for it, by all means, write a parser by hand and give it the best error recovery that you can muster. If you are developing a language and want to do a bunch of experiments, it pays dividends to use a parser generator. And then there is the whole space of DSLs and mini-…

That's great and I agree for these use-cases a parser generator makes sense. But that doesn't answer my question about what makes these parsers particularly elegant. Nor does it seem to be a benefit specific to Mehnir, since any parser generator has the quick iteration speed. I don't mean to blame you for that; you are answering a question about something that you did not say. But I find it frustrating that Mehnir se…

I didn’t intend to answer your question—your comment had multiple aspects to it and I am responding to one part of it, rather than every single part of it.

My main take on the “which language do I write my compiler in” conversation is that some of the various code transformation passes are just more convenient to write in a language which makes it easy to use both mutation and garbage collection, which puts OCaml above both Rust and Haskell. I think parsing is an easier problem to solve in the first place.

Re: Compiler Development: Rust or OCaml?

#84

Post by tucnak »

josephg wrote: post #81
gottlobflegel wrote: post #80

Earlier quoted context omitted.

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.

Ah yep, my mistake. I’ve missed out on the recursive inner evaluation. Traits might work better here, but it’s not so obvious. In any case, I stand by all the other points I’ve made in my comment.

You know how hard it is to take someone seriously after they embarrass themselves like that while also trying to bring somebody's code down, & ultimately being wrong?

Re: Compiler Development: Rust or OCaml?

#85

Post by 59nadir »

brmgb wrote: post #36
hardwaregeek wrote: post #30

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.

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

The vast majority of real languages have hand-rolled parsers and there is no real reason they shouldn't.

Re: Compiler Development: Rust or OCaml?

#86

Post by memefrog »

nine_k wrote: post #72
memefrog wrote: post #47

Earlier quoted context omitted.

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.

Yes, some compilers are slow on large programs because they don't scale well. Others aren't, because they do. That's what I said.

Re: Compiler Development: Rust or OCaml?

#87

Post by 59nadir »

CollinEMac wrote: post #8

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.

To some degree a lot of people are now finding OCaml via dev YouTube influencers who highlight OCaml without actually having used it. There's a lot of enthusiasm, kind of like how lots of people were loving and super excited about Rust without ever using it even for toy programs.

Edit:

I have used OCaml in production and currently I don't see a point to doing it again for the vast majority of problems. From a holistic language + runtime point of view OCaml occupies a space where it's not useful enough from a runtime perspective to replace any of the more convenient languages that exist and not low-level enough to fill the spot of any of the good alternatives in that space. Modularity-wise functors are nice but ultimately plenty of alternatives exist even it the lower-level languages.

With all that said, people should probably use the hell out of it if they're excited. It's a bit tiring seeing the constant stream of misinformation regarding alternatives to OCaml, though. There are good reasons it's losing out in industrial use to even languages like Haskell.

Re: Compiler Development: Rust or OCaml?

#88

Post by fauigerzigerk »

memefrog wrote: post #47
beaub wrote: 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…

>People like fast compile times, but that is more to do with language design than the choice of language for the compiler.

People like fast compile times and people either like to use (or are forced to use) languages that are inherently slow to compile. That's exactly why compiler performance is absolutely critical.

Re: Compiler Development: Rust or OCaml?

#89

Post by foldr »

tyg13 wrote: post #60
reikonomusha wrote: post #43

Earlier quoted context omitted.

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

I don't think anyone was claiming the author was being intentionally deceiving, just that they're not very good at writing idiomatic Rust. The first thing I'd suggest, as someone who's done their fair share of Rust compiler dev, is to stop using `Box` and `Ref` everywhere. Terms should not own their child terms; the idiomatic way to handle this is to use an arena and typed IDs, and pass a reference to the arena when…

IIRC The Rust compiler just uses Cell for child terms, which is a somewhat lighter weight solution that still allows mutation.

Edit: Either I remembered wrong or it's changed. Now it uses some kind of custom wrapper around Box: https://github.com/rust-lang/rust/blob/master/compiler/rustc... So actually, the Rust compiler itself uses owned children in its AST!

Re: Compiler Development: Rust or OCaml?

#90

Post by brmgb »

hardwaregeek wrote: post #66
klodolph wrote: post #64

Earlier quoted context omitted.

You use the generated parser as a platform for experimentation. If you know the language, and you have a bunch of users, and you are writing a parser for it, by all means, write a parser by hand and give it the best error recovery that you can muster. If you are developing a language and want to do a bunch of experiments, it pays dividends to use a parser generator. And then there is the whole space of DSLs and mini-…

That's great and I agree for these use-cases a parser generator makes sense. But that doesn't answer my question about what makes these parsers particularly elegant. Nor does it seem to be a benefit specific to Mehnir, since any parser generator has the quick iteration speed. I don't mean to blame you for that; you are answering a question about something that you did not say. But I find it frustrating that Mehnir se…

> with a good example of how it's better than any other parser generator.

I already told you that it has full support for disambiguating LR(1) grammar and still generating a parser which is easy to read. How do you want me to paste a full parser in a HN comment?

Most generators only support LALR(1) grammar which is limiting and don’t deal with corner cases as gracefully.

I get that you are hell bent on wanting Rust to prevail here but Rust will always be a subpar experience for wiring anything which doesn’t strongly benefit for its low level primitive. Rust has annoying semantics and a convoluted syntax. I can bear with that when the performances are needed but writing a compiler in it is just unnecessary pain. It’s also one of the only thing for which I would actually use Ocaml.

Post reply on HN