how do they do that effectively without a spec? just curious.

@elliptic I'm compiler engineer, so I don't know. But on a general note, I don't believe it's any difference from what other kinds of engineers do: you have user docs that explain how it should work and an implementation against which you can compare yours. That should be enough.

In fact, it's the only way to produce a usable spec: from two independent implementation specifying corner cases as they're uncovered. Writing a whole spec from blank never works.


i know @sir has some specific views on this probably... but, in the absence of an actual spec, i guess:


... becomes the de facto spec? the whole thing kind of makes my head spin.


if i read you correctly, gcc being able to build rust code will help rust arrive at a point where agreement will be reached on what features should be supported and what the output should be like.

@elliptic kind of. I'm not describing any rigorous process with a guaranteed outcome. I'm just saying that Rust core team sitting down and saying "all right, let's write a formal spec" has less chance of covering all the corner cases than a completely separate team trying to write an independent implementation that work as expected.

Same as HTML5 spec produced from reverse engineering the behavior of available browsers is a much more useful spec than what W3C could came up with before that.

Just to note that this isn't the first alternative Rust compiler.
There is already mrustc: github.com/thepowersgang/mrust

Admittedly, this one is far from complete. It's mostly intended for bootstrapping rustc and cargo, and it doesn't do borrow-checking at all (with the assumption that the code has been previously compiled by rustc and therefore is already correct).

@friend @isagalaev

sure. what i was getting at is, how does anyone know how "complete" it is without a spec to verify against?

using ivan's analogy (but earlier than html5 obviously), when internet explorer was the dominant browser, it wasn't compliant with web standards in many ways. it was microsoft's vision of the web experience, not a standards-based one.

@elliptic @friend which just shows that "complete" in a spec-adhering sense is not a requirement for something to be useful (and heavily used). Most software is incomplete as we all know :-)

@elliptic @isagalaev well, standards emerge after the are multiple implementations, not before. Look at C history

@mkpankov @isagalaev

no i get that, i understand most things (certainly as anything pertains to ritchie, thompson, et al).

in my mind, the k&r was a spec.

c in that context also had an underlying de facto implementation as the core language of an operating system, and it still took a long time for ansi c to get done.

rust has none of those things going for it yet.

it'll probably eventually end up fine, just curious how someone like graydon or toolchain devs see that playing out.

@elliptic @isagalaev
Just a couple nitpicks from me
k&r was "the rust programming language".
Rust also has Redox OS. Not that this or PDP-10 Unix were mainstream

@mkpankov @isagalaev


the key difference here is, the k&r was only available in print, and was only updated once, 10 years later (also 1 year before ansi c was established), and hasn't been since. also the creator of the language was the co-writer of the book, which made it stick.

i'm not arguing against the way rust is doing anything, btw. just wondering out loud how it will go for the way rust is doing it.

@elliptic @isagalaev The person behind the project briefly touches upon this subject in the penultimate paragraph of (this blog post)[embecosm.com/2021/01/12/gcc-ru].

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!