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

61–70 of 107 posts

Re: Compiler Development: Rust or OCaml?

#61

Post by whimsicalism »

hardwaregeek wrote: post #24

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

Re: Compiler Development: Rust or OCaml?

#62

Post by bilboa »

zem wrote: post #22
telios wrote: post #9

I don't quite follow the algorithm here, but I'm not sure the `gensym` Rust implementation works as expected. `RefCell::clone` does not return a copy of the reference; it returns a new `RefCell` with the current `RefCell`'s value, resulting in duplicate IDs. However, a `RefCell` isn't even necessary here, since a `Cell` would do just fine - and you'd pass around a reference to that `Cell` instead of cloning it. It do…

> it seems a bit odd to complain about this when that's what Rust is for that's the point of the article - rust gives you a lot of low-level control, but if you don't actually need that control then you're paying the cost in ergonomics for nothing.

Exactly. I did get the impression that the author is more familiar with OCaml than Rust. However I don't think they were claiming Rust's greater low-level control makes it inferior to OCaml in general. They're just saying it makes it less suitable for writing compilers, since (in the author's opinion) this level of low-level control isn't necessary for that task.

Re: Compiler Development: Rust or OCaml?

#63

Post by freeopinion »

tester756 wrote: post #50
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…

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

Did Microsoft rewrite their C++ compiler in C#?

Re: Compiler Development: Rust or OCaml?

#64

Post by klodolph »

hardwaregeek wrote: post #37
brmgb wrote: post #36

Earlier quoted context omitted.

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

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-languages you encounter, where beautiful error messages are a nice-to-have, but you would rather ship a generated parser and move on to more important work.

It’s easy to focus on compilers from the perspective of familiar languages like writing compilers for Rust or for OCaml, but you may end up writing a compiler that gets used by a much smaller number of people, for smaller tasks.

Re: Compiler Development: Rust or OCaml?

#65

Post by yberreby »

As someone who wrote a fair amount of Rust and OCaml code, I have to agree with the author.

While working at Routine (YC W21), I was tasked with porting our core library to iOS to minimize duplication of business logic. This was a lucky opportunity to write something resembling a compiler: it took in schemas described with our in-house data exchange library and generated C (for FFI) and Swift code (for the end users, i.e., iOS developers).

Since Routine uses OCaml for everything (which was a big motivator for joining the company—I wanted to see how that would work out), I wrote it in OCaml. The end result is a 3-5k LOC project. It's by no means a full compiler, but it was lots of fun to write. The language got in the way incredibly rarely. On average, it made my life a lot easier. We did encounter our fair share of issues, mostly due to the cross-compilation tooling[1], third-party libraries, and intricacies of FFI. Those do take their toll on sanity.

I tried my hand at writing small compilers / interpreters in Rust, and the experience was nowhere near as smooth. It was fun, and the runtime performance is definitely there, but the ergonomics aren't the same. I especially miss first-class modules whenever I code in something other than OCaml now.

  [1]: we initially used esy [2], flirted with Nix, and eventually switched to opam-cross-ios [3].
  [1]: https://github.com/esy/esy/
  [2]: https://github.com/ocaml-cross/opam-cross-ios

Re: Compiler Development: Rust or OCaml?

#66

Post by hardwaregeek »

klodolph wrote: post #64
hardwaregeek wrote: post #37

Earlier quoted context omitted.

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

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 seems to be cited as this fantastic cornerstone of the OCaml ecosystem when I haven't been presented with a good example of how it's better than any other parser generator. Not just my parent comment (who also decided to cast aspersions on my knowledge), but others in the OCaml community too.

Re: Compiler Development: Rust or OCaml?

#67

Post by JonChesterfield »

tester756 wrote: post #50
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…

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

Any compiler that gets used at runtime (branded JIT, usually) ends up growing performance hacks or being written from scratch to run quickly. Javascript is prone to using multiple compilers based on how frequently code was executed. That's also what the whole -O0 -O3 -flto -thin-lto -pgo etc flags are about, granting permissions to burn different amounts of time during compilation.

It's really easy to accidentally write code that walks off a performance cliff on unexpected input, but that's likely to get hacked around if someone reports it as slow compilers do annoy people.

Re: Compiler Development: Rust or OCaml?

#68

Post by solomonb »

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…

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?

Re: Compiler Development: Rust or OCaml?

#69

Post by stouset »

timeon wrote: post #59
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

> The Rust and OCaml code from the article looked decent to me > RefCell I'm not sure.

For the uninitiated, this is a completely harmless choice. But it suggests a potential lack of understanding of some pretty fundamental parts of Rust.

Re: Compiler Development: Rust or OCaml?

#70

Post by ben-schaaf »

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…

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

Post reply on HN