Hacker News Reader

Comment by brandmeyer | Hacker News Reader

Its also important to note that Rust changed radically in its early life. Here's one of its core authors describing some of the changes they went through (in part) as a result of dogfooding the language in its own compiler, in the context of BitC's failures:

https://news.ycombinator.com/item?id=3750882

The language it had evolved into by 2012 is also radically different from the language it became by 1.0 in 2015.

View on HN

Two other links related to ancient Rust:

* https://github.com/graydon/rust-prehistory -> the code from before the rust-lang/rust repo

* https://youtube.com/watch?v=79PSagCD_AY -> a talk I gave around the 1.0 release (that recording is lost, this is the only other time I gave the talk so it could be recorded) giving my personal perspective on the history.

Oh heck, one more fun one: https://github.com/brson/archaea

That long comment was insightful, comparing how Rust and Go solved (or avoided altogether) similar concerns.

> ..we would have never found these things so early unless we had written the Rust compiler in Rust itself. It forces us to use the language constantly, and we quickly find pain points. I highly encourage all languages to do the same; it's a great way to find and shake out design issues early.

This reminded me of Lisp, meta-circular interpreters, and self-hosted compilers.

Reading up on Rust's beginnings, I learned that:

> The language grew out of a personal project begun in 2006.. [In 2010] work shifted from the initial compiler (written in OCaml) to an LLVM-based self-hosting compiler written in Rust. Named rustc, it successfully compiled itself in 2011.

I know there are many benefits to self-hosting, but I’ve wondered in the past if it biases language design towards compiler-writing. Depending on the language’s primary domain (maybe with Rust it’s less of a concern), compilers as a usecase can be fairly unusual, in terms of both requirements and what makes them ergonomic to write. So if self-hosting inspires you to shape the language to make early accommodations for writing the compiler, that may not necessarily be the best thing in the long run.

Indeed, building a programming language that is supposed to be for systems programming then it makes sense for it to be able to be ergonomic to write compilers in. But if you're building a programming language for building UIs (or any other specific use case), then making it bootstrapping it's own compiler in it's own language seems like a waste of time.

I'm not sure I'd say "waste of time", just that it might pull the language in some directions it might not ought to go in. It would still benefit from the battle-testing, but there might be other "dogfooding" projects that would be more appropriate; the compiler is just a convenient one since you're already doing that work.

I don’t think it’s a waste of time.

Compilers are demanding projects where you need to be intimately familiar with both target and host languages. A self-hosting compiler means that target and host are the same language, and reduces that source of friction.

This makes sense in the abstract - in practice, what compiler-specific features or biases do you think might not be suited for any given general-purpose language?

Compilers are biased, among other things, towards:

- Having a rich, complicated internal model (and having minimal contact with external data; mostly just the code being ingested)

- Recursion

- Being stateless (at the top level anyway; code goes in code comes out)

- Having an enormous amount of semi-regular code (favoring macros and related features)

- Dispatch/polymorphism among very broad type groups (favoring enums and ways of discriminating enums)

Not that any of these things are bad to support in any given language, but every language is a big bag of trade-offs, and focusing on compilers might cause you to choose certain tradeoffs that aren’t as relevant to the way the language will typically be used later on

No specific judgements on Rust (in fact, Rust has ended up seeing a lot of use for compilers and compiler-adjacent projects), just something I’ve been thinking about in general

The most common criticism in practice tends to be a strong aversion to mutability. Compilers can be thought of as a series of pure functions transforming a large immutable data structure, and given the practical issues of mutability (reasoning about it is legitimately hard), this can give a lot of languages a strong aversion to mutability. However, there are some domains where you can't transform the problem space into consume-and-produce-immutable data structures and expect anything close to performant--databases are a good example here.

I think there's definitely an unconscious bias towards compiler design in PL design because of self-hosting; one of the other things that helped Rust immensely was that it also had Servo as an early-language design goal.

> Depending on the language’s primary domain ..

Well yeah most languages do not do that. Besides if any language claiming to be general purpose language to be useful in varied use cases, leaving out compiler, runtime, or GC etc would reflect important shortcomings in language.

> So if self-hosting inspires you to shape the language to make early accommodations for writing the compiler, that may not necessarily be the best thing in the long run.

This is applicable to almost any situation. If a language is designed for say asynchronous web services of 2020s, will be necessarily best thing in long run? With the benefit of hindsight I can say a SOAP programming language designed in 2000 would not have many takers today.

The intended use for Rust was to write a browser engine. So the point still stands.

> I’ve wondered in the past if it biases language design towards compiler-writing.

Yeah this a "well know" problem.

In fact, you will ALWAYS bias the language for what is your ACTUAL first "major" project.

However, I think that "make langs" is in itself a very good thing to be able to do in any lang, even if is high-level, business oriented (a lot of work is alike!) and is only when you wanna to mimic the C-abi or marry with C/C++ (like full integrate LLVM) where things will go sideways (and I bet: Is more a fault of C here, than "making compilers")

>> I know there are many benefits to self-hosting, but I’ve wondered in the past if it biases language design towards compiler-writing

Well I've been waiting for ANY language to embrace 2d, 3d, and 4d vectors as basic types (probably the wrong word). They map perfectly to modern vector registers in SIMD hardware and they are fundamental to all forms of graphics, from text rendering to 3d games, to CAD and any type of physical simulation software. It just seems like language designers figure "anyone can create a type like that with our generic building blocks" and somehow, if we're lucky the compiler will figure out and generate optimal code for it. Oh never mind that different code bases will call these fundamental data types different thing - Vec3, vec3, vector, and have different implemntations, making modules non-reusable across projects...

Yes, language designers and compiler writers are usually very smart people but they do have biases and blind spots just like everyone else. It think Rust is turning out so good because they really spent like 10 years getting it "right".

> basic types (probably the wrong word)

Not too wrong... I think the proper term is "primitive" (as in language primitives), but basic works too.

Zig is working on a SIMD primitive IIRC.

Generally you'll find built-in vector and matrix types in languages designed for technical computing, such as FORTRAN, MATLAB/Octave, Julia, Chapel, etc.

Rust was first implemented in Ocaml. Given that choice and the influence it has had I would say that it was inevitable that Rust would get compiler writer PL features, self-hosting or not.

I'm not sure if there's a better alternative, to be honest. Given how large a portion of the time compiler authors will be writing code for the compiler, many of them might not spend any time working in the language they're designing if it isn't what the compiler itself is written in. If the people who maintained Rust spent all their time writing OCaml and little to none writing Rust, I think that would likely cause far more and worse blind spots than writing Rust all the time but only in a specific domain.

The changelog is also worth a read. It goes all the way back to 0.1 in 2012:

https://github.com/rust-lang/rust/blob/master/RELEASES.md

Rust originally had a garbage collector, right? These days perhaps its biggest claim to fame is its novel approach to memory management (i.e. borrower-checking).

It had both borrow checking and GC for a while.

It's interesting that he invented Rust but hasn't worked on it in 9 years. I'm not sure I'd be able to walk away like that.

Are there any code examples that people know of from when Rust had a more ML-like (in the vain of F# and OCaml) syntax, before Rust transitioned to curly braces?

Heh, dynamic linking and small executables. Funny how things change.

Reply on news.ycombinator.com