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://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.
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.
>> 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".
Generally you'll find built-in vector and matrix types in languages designed for technical computing, such as FORTRAN, MATLAB/Octave, Julia, Chapel, etc.
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.
> 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")
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.
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.
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.
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.
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.
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.
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).
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?
It's frustrating that the way Twitter hides tweets causes the archive to lose information. That thread is actually really interesting, but it's missing a whole bunch of tweets!
Graydon talks about how companies aren't willing to fund risky work, and that Rust would have never been a thing if he hadn't invested massive amounts of personal time into it.
My limited experience at large companies suggests the engineer has to basically have a working prototype developed off the clock before anyone listens. And this matches what I know about corporate R&D mostly following public investment in government & academic speculative work.
I know were you are comming from, but it was very much not the only thing. The elegant model of C pointers to model memory and CPUs are definitely good aspects of C as well as its speed, transparency and overall simplicitity.
Trying to claim that Dennis Richie's design is just bad as you constantly do in any thread mentioning C is just completely missing the point and couldn't be more wrong. One thing is pointing out problems of C and another very different is saying that the only thing going for C is UNIX.
If UNIX had won by being a successful commercial product instead of winning for being free beer, I might agree, but usually people don't look into the mounth of horses given as presents.
My wishlist is something that is essentially coffeescript for rust, basically rust without semicolons or the borrow checker. The ruby syntax is not specifically important, but generally desirable. Ideally it would transpile individual files directly to rust with a GC or RC boilerplate sprinkled into it, then run the full rust compiler.
Nim and Crystal are nice, but are not rust under the hood.
This would open rust up more to smaller brained devs like me who can't do full rust full time. I think it's generally underestimated how valuable this would be to establishing the rust utopia we all want to see.
Honestly, if you remove the borrow checker from Rust, it’s radically not Rust any more. I hold that the defining feature of Rust is its ownership model; and there’s nothing left of that without the borrow checker. (You could assign similar semantics and just not check them, but without the ability to check them they’re completely useless.) Most of Rust’s design hinges upon the ownership model, and most features that it has are there at least in significant part to make the ownership model work or be tolerable. To be sure, you could create a dynamic/scripting language with algebraic data types (enum) and a struct/impl divide; even traits are possible, though mix generics in and it’ll be decidedly bothersome to achieve any sort of speed, yet you kinda need generics for traits to make sense over classical OOP (there’s a reason scripting languages tend to go for classes and such—Rust-style traits work excellently compiled, but not so well dynamic). But you’re talking about converting such code into Rust, and I say: without ownership modelling and the borrow checker you have absolutely no chance of converting it to anything but completely unsafe Rust code (as in: Rust will slow you down and gain you nothing, you should generate something like C instead). And you can’t just sling GC at it: Rust is really quite poorly equipped for that style of box-everything GC code, and the only ways of making it work at all will perform very badly.
The goal is to abstract away the borrow checker for the business logic of software I write, not for the borrow checker to be absent from a rust compiler. I still want everything that is rust, I just want an alternative to php/ruby/python that is natively integrated into rust and the full rust ecosystem.
The borrow checker is pervasive. You can’t just abstract it away. There’s a reason it’s explicit.
If you think it’s possible, try designing what it would look like, and what it would compile your code to. You will quickly find that it can’t work without losing the quintessence of Rust completely (and a lot of performance).
I think this and the original post misunderstands what the borrow checker fundamentally is. The only way to "abstract the borrow checker" is to write another language on top of Rust.
After using Rust a lot, the borrow checker is not that bothersome actually. Exist MANY more things that are far more significant as causes to fear Rust:
- Is actually complex language!
- It has weird, inconsistent inter-mixed between traits, generics, macros, procedural macros, elides, alias, type alias...
- The ways async/await is introduced, multiply the complexity, is super-infectios, and I can't say you can do "fearless concurrency" anymore.
I'd like generators too. You'll notice that yield is reserved (although of course unlike C++ Rust actually can just take new keywords anyway, because it has a way to spell identifiers that are now keywords) so one day Rust will likely have generators.
But you can't have one way to do macros unless that way is proc macros or you're willing to give up on the power of proc macros. The proc macro is just much too powerful (and thus dangerous) to give people something else and have it be satisfactory.
And I don't think auto-clone is a good idea. That's a potentially expensive operation, it's worth taking the time to admit to yourself that you are choosing to pay that price when you use it. This also means when you forgot that you'd need a clone you're reminded there and then (by the resulting diagnostics) to make the decision, whereas with auto-clone in those cases it just mysteriously has worse performance than you expected (because there's a silent clone)
> although of course unlike C++ Rust actually can just take new keywords anyway, because it has a way to spell identifiers that are now keywords
C and C++ introduce new keywords all the time, by prefixing them with "_" and a capital letter. If you want the nice spelling you need to use a header. E.g. "_Complex". "co_await" etc are operators.
It's possible you're one of the two kinds of "C/C++ programmers" and so you've assumed that since this is how C prefers to introduce things it must be how C++ does it too, but not so.
C++ 20 introduced concepts. In C++ 17 "concept" is a perfectly reasonable name for an identifier. Maybe it's a class, a variable, a free function, all fine. In C++ 20 that's a reserved word and can't be used as an identifier.
Rust does not have this problem, a 2015 function named "await" is somewhat annoying to use from Rust 2018 or later where "await" is a keyword, but it's only annoying it isn't actually difficult.
Sounds like Swift. Compiles to machine code, reference counted, has a stable ABI, tries to aim for software correctness with its optionals. Lacks data race safety but tries to alleviate it with actors and potentially an ownership system in the future.
The goal is to abstract away the borrow checker for the business logic of software I write, not for the borrow checker to be absent from a rust compiler.
Nobody wants to see a Rust utopia. That sounds like a monoculture nightmare. Do you want a Java utopia? A C utopia? A C# utopia? A Haskell utopia? There is no utopia, just a bunch of different choices! It's fine for there to be different languages for different tasks, just like you're legally allowed to own more than one hammer. Please don't follow the hype that you should be using Rust when you clearly don't want to. Rust is just another tool, and only the best tool for a minority of jobs. There are plenty of other excellent choices.
> basically rust without semicolons or the borrow checker
The thread spells out OCaml as the main inspiration for Rust, and fits the "without the borrow checker" part. Plenty of semicolons in it, however. F# offers a similar experience with fewer semi-colons, but I can't see how removing semi-colons help make the language more accessible.
Really the only mandatory semicolons in OCaml are in data structures: `let my_list = [1; 2; 3]`. In code, they can all be replaced with appropriate `let` bindings.
I prefer asking for video rental store design. The fact that it's a dead business relic relieves from any performance consideration and allows focusing on meaningless "fun". There are no bad answers. It's interesting just to see how people envision a project top-down. Some people go for the DB, some are more OO oriented...
I had thought I remembered seeing something about how rust actually started in Graydon's apartment pre-2010. But then, later on, everything I saw said it was started at Mozilla, and I thought maybe I misremembered. But I was right!
It isn't rare at all for the origins of successful products to be claimed by multiple parties. I've had a first row seat to some people making off with my work and taking credit for it. Somewhat entertaining when they are asked pointed questions about how it all works and the fall right through the floor into the basement.
I think I remember that before there was git, I was following the monotone project of which Graydon was the lead. I think I remember when he left monotone to work on some new language for Mozilla, which was Rust.
Wild, I had no idea. I sat next to some of the Mozilla Research people working on Rust when it was new so I just assumed that was where it started. In retrospect it makes sense that it was a personal project that pivoted into an official one, since emscripten was (afaik) the same.
"That dude" is the person who created it, so he would know. And if you knew him at all or followed Rust's development at all or even just read some of his comments on reddit when this topic comes up, you'd know that you were wrong: https://www.reddit.com/r/rust/comments/450zy7/comment/czuixj...
> The Rust CoC has been in place since day one. [...] I wrote it before releasing any code, before even agreeing to work on such a project for Mozilla.
The "you might even say 2006" links to Graydon (aka 'that dude')'s initial commits. There's no discrepancy here. The Rust Project, aka the whole apparatus around developing Rust, started at Mozilla in 2010. The language was a personal project for just Graydon before that. They're two related but distinct things, and you could argue "Rust" started at either of them, depending on in what sense you mean.
That Graydon started Rust on his own in 2006 is not disputed by anyone with knowledge of the facts, including the very post you linked.
You also in your original comment said Mozilla picked it before 2006, which is also impossible and simply incorrect.
Doesn't matter when it was added. It was still a poor idea and remains so today. The "CoC phase" will be a thing we look back to being a transient period of oddness in the software industry. CoCs are weapons used by the privileged against the unprivileged.
This is what happens when you use the (wiki) encyclopedia to write your paper. It's a paraphrase of "First appearing in 2010, Rust was designed by Graydon Hoare at Mozilla Research". See me after class!
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.