Hacker News Reader

Comment by alilleybrinker | Hacker News Reader

Gleam is written in Rust and is a nice example (besides Rust itself) of what it looks like to write a language in Rust. By my own tracking (https://github.com/alilleybrinker/langs-in-rust) Gleam is one of the most popular languages written in Rust and is one of the few top languages in that list which isn't a reimplementation of an existing language!

View on HN

I feel like making programming languages is an area where Rust can really make use of its advantages without the commonly cited pitfalls. You won't be dealing with any I/O other than filesystem APIs (outside of making a standard library or something), so you can entirely avoid needing to decide whether to use async or not, and you can go pretty far just using value types and copying without it being a likely performance bottleneck. Most languages won't use much concurrency in their compiler either; Rust itself parallelizes builds per crate with Cargo, which invokes rustc separately for each compilation unit.

I'm sure some people might read all this and conclude that they might as well just use OCaml or Haskell, and those are really good languages for compilers too! The tooling and ecosystem make Rust more appealing to me personally though, and I suspect that there are probably others who would find Rust's ecosystem a bit more approachable as well.

Modern compiler tooling that supports IDEs are almost all incremental, so all that async machinery and multithreading can be put to use there as well.

I think Haskell or OCaml would do a better job on the ADTs for a parse tree. When doing this, I found Rust's enums... anemic... and got very annoyed by the awkwardness of having to Box recursive types. I was reaching for the ability to continue to be able to pattern match on nodes while attaching common attributes (line numbers, etc.) and ended up having to bury everything 1 level deep in a struct which ended up feeling awkward.

That and Rust's iterators are terrible at introducing ownership agony.

In any case, I've ... done it (https://github.com/rdaum/moor/blob/main/crates/compiler/src/...) but can't say I liked it.

I do really like "pest" as a parser generator though. In general, yes, the Rust ecosystem is bigger/richer, and growing.

You are not wrong on that level, i have been slowly writing a language in Rust anc all these point are deeply felt.

And yet... The Rust ecosystem win. Easily. For a simple reason.

Salsa. Oh and also clap. Lsp bindings. Ungrammar. Miette. Clap. Parsers. Etc

At every level the Rust packages are far better and allow to drastically reduce the cost of building this stuff.

Haskell has equivalents to all of those libraries, and much more. And they are probably easier to use and more powerful.

Can you link some of those libraries? I’ve always found it harder to find well-maintained libraries that solve compiler problems in Haskell as opposed to Rust.

I spent 6 months exploring the Haskell ecosystem for these. The answer is no.

They are nowhere as easy. At the very least because their documentation is usually non existent or non comprehensible.

> Rust itself parallelizes builds per crate with Cargo, which invokes rustc separately for each compilation unit.

Rust’s frontend now has support for running in parallel on nightly (they haven’t announced on the blog yet). But your point stands, Rust got pretty far all these years while keeping things simple and single threaded.

Are you seriously touting "make -jN" as an amazing rust benefit?

Reply on news.ycombinator.com