I Support GCC-Rs | Hacker News Reader

I Support GCC-Rs

chorman64.medium.com

74 pointslukastyrychtr43 comments

As someone who has had to deal with legacy C++ compilers from multiple platforms, I didn't have the luxury of dropping compilers I didn't like but instead had to program to the lowest common (working) denominator of those frontends.

For a frontend to be taken seriously, I see the following questions needing to be addressed:

- How long until the frontend is viable?

- What will it take to keep the frontend is viable?

- How far will each frontend lag in shipping lang/lib features?

- What is the relative user upgrade cadence of each frontend?

- How do developers test multiple frontend versions?

- How do developers workaround frontend bugs?

- How do we communicate out frontend support for crates, especially if crate authors take the approach of this person and drop support as they become a problem for them?

A GCC backend for rustc is a smaller, well scoped target that can more easily be kept up-to-date (I would hope, upstreamed in Rust) that resolves a lot of the pressing needs (platform support).

For any finite resource allocation, I see getting a GCC backend to be a priority for quick wins and then focus on gcc-rs as an experimental hedge against future problems.

> For any finite resource allocation, I see getting a GCC backend to be a priority for quick wins and then focus on gcc-rs as an experimental hedge against future problems.

Doesn't that only work if it's the same people working on all those things? AFAIK, it's different people doing the different projects. You can't just re-assign open-source developers however you want.

Yes, people can work on what they want and good for them, it helps build a healthy community.

What my point is more about the conversation for the larger community of what we want to prioritize and put in the effort to support. If we have the opportunity to influence where people gravitate to, which should it be? If companies want to come in and sponsor work, where would we, as a community, want that to go?

Also if gcc-rs "makes it", the cost will shift from that one or two developers to the whole community. We will need to test our projects against multiple versions of each frontend, our projects will need to advertize what they support, Rust will need to get compiler vendor and versions flags for us to conditionalize compilation to handle discrepancies and bugs, and crate authors will need to carry around these compiler conditionals.

You can't directly re-assign those developers, but you can try to influence their decisions. It's not only about the current developers either, but also potential new contributors that may be considering either project.

That it was perceived necessary to write this indicates something very wrong.

A healthy response to news of another compiler for your new language is, "Wonderful! People are demonstrating their belief in the future of our language with a big time investment! Another compiler will help us validate our language specification, which will be badly needed when we go to ISO to ask for a Rust standard Working Group."

It is just possible that a second compiler could be twice or (as happened with Pascal and C++!) 100 times faster. Faster builds would mean thousands of hours saved for users of the language—even, potentially, for people working on the old compiler!

A second implementation of the standard library could offer similar benefits.

More implementations is an absolute prerequisite to language maturity. All languages not doomed get them. It will be a net good for Rust not to be doomed.

The problem is that there are fewer qualified contributors that project authors would like. Every piece of code which is written and becomes used needs people to contribute continued effort. Else the project dies, and the efforts put into it, and into depending on it, are wasted.

That said, I think that C++98 is a terrible language. I would understand targeting C++11. I would understand targeting the last version of OCaml which GCC4 can build. But the number of footguns C++98 introduces would make it for me a worse choice than plain C.

C++98 is less fun to code in than C++11, which is less fun than C++20.

But with modern-style library support, C++98 can be quite safe and usable, at least single-threaded. But some things are unavoidably verbose. The only serious functional lack is moves, but that is a performance optimization. C++98 code can be upgraded to current whenever the perceived need to hang back dissipates.

That said, implementing another compiler just for the sake of bootstrapping convenience would be powerfully silly: if you code a new Rust compiler, it should be the very best Rust compiler you can write, and better on at least some axes than the flagship one.

Coding it in C++17 or 20 would be just good sense: Religion notwithstanding, C++ is a mature and powerful language well suited to the task.

One real peculiarity of churn around bootstrapping is that, given good support for cross compilation, you hardly ever need to bootstrap at all. So if that is a thing that worries you, work supporting cross-compiling is your most productive course.

Agreed, although some C++11 goodies like smart pointers, STL and RAII were already a thing in pre-C++98.

Just because it is C++98, it isn't a recipe to write C with a C++ compiler.

GCC-RS will never have the same level of investment as rustc, which means that either it'll rot or the entire ecosystem will rot due being tied down waiting for it to catch up.

Also, the Rust community at large is not at all enthusiastic about handing the language over to ISO. The design-by-comitee-based, incrementalist, waterfall throw-it-over-the-wall-every-3-years approach is pretty much the exact opposite of the continuous delivery-based way Rust is developed, and arguably one of the main reasons why C++ sucks.

There is absolutely no slightest hint of "throw it over the wall" in ISO C++ development. The compiler implementers and heaviest users work deeply and collaboratively together to bring each Standard to readiness. Each new C++ Standard is a markedly better language than any before. A mature language, C++ necessarily evolves more slowly than Rust does, but Rust will soon become more stable, too, ISO or no.

What does it mean when you feel a need to lie about your perceived competition?

In fact, there is no such competition: literally hundreds pick up coding C++ professionally for each individual who so much as tries out Rust. The fast rise of Rust has no detectable effect on the growth of C++ usage, even 40 years on. Rust's and C++'s coexistence will last for as long as Rust is used at all.

You are welcome not to like C++, but lying about it says more about you than about it.

The fate of Gcc-Rs will be determined by future events unknown to you or to anyone else. It could become critically important to Rust's own future, someday.

I think you severely overestimate how many C++ professional developers exist in the real world. You're likely outnumbered 3:1 by Web Developers or Python Developers already.

According to the StackOverflow survey, C++ is at 25% popularity (which btw means C++ barely misses being in the Top 10 and fails to outdo PHP) and Rust is at 5%. If you restrict this to professional coders, then C++ falls to 20% popularity and Rust is at 4%, so roughly the same difference; 5 coders saying they use C++, 1 coder saying they use Rust.

Now in the same survey, people could also rank languages into loved/wanted/dreaded. In this section Rust has been the top loved language for 5 years straight (80%~), and C++ usually only breaks the top 10 in the dreaded category.

That means that for every coder that says they love C++, there is two coders saying the love Rust more.

That there is hundreds picking up C++ over everyone picking up Rust is a dream fantasy of someone stuck in the 2010s.

Are you familiar with the concept of selection bias? Citing an online survey suggests not.

The great majority of C++ users probably do not look at StackOverflow, never mind participate in its surveys. (I don't.) It is possible the majority have never even heard of it. The principle online reference for C++ coders is cppreference.com.

You do not need to love C++ to earn your living with it: it is known to work. Objectively, there are, literally, millions of C++ professionals. More retire every year than the total of working Rust coders. That will change, eventually, if Rust catches on.

>Are you familiar with the concept of selection bias?

Yup

>The great majority of C++ users probably do not look at StackOverflow,

That I would like to see a citation for. The plural of "personal anecdote" isn't "proof".

>You do not need to love C++ to earn your living with it: it is known to work.

Did I claim otherwise?

> Objectively, there are, literally, millions of C++ professionals.

Citation needed.

> More retire every year than the total of working Rust coders

Citation needed.

I encourage you to perform your own research. Citing hipster surveys on a beginners' help site has not earned you a passing grade.

Atleast I cited data (there is no reason to sling insults towards the data either). If I'm so wrong, it should be easy to disprove with less biased data from a "professional non-hipster website".

It is not my task in life to disprove my own opinions formed from available data either. If you want to change minds, don't ask others to "do the research yourself", that's just rude.

You personally demonstrate the need to discount actively-misleading data. What's next, Tiobe? If you don't check your own fond biases, who do you expect to perform the service for you? "Strangers on HN, for free", really?

Minds are responsible for their own evolution. Clues are taken or ignored according to personal preference.

You wrote it yourself, Clues taken.

You haven't delivered clues, only anecdotes.

And in terms of my own biases, I only want a solid study with a decent sample size (~5000 shouldn't be an issue on this topic)

"Principal", not "principle". I complain about this mistake when others make it.

Yes, it is very sad that instead of embracing various implementations this has gone down the path of feuds and political wars.

We need stable and free infrastructure. It is unfortunate how few people realize what GCC does for everyone. It certainly ain't perfect, but imagine we only had clang/llvm. Llvm regularly breaks the API and cannot be bootstrapped, AFAIK. Without GCC, I doubt we had android, or capable cheap routers, the whole python and node.js ecosystems would be in a completely different situation, and we would permanently facing the threat of propiatary languages. I support rust in GCC, too (and I am glad that they also have Go support).

> Llvm regularly breaks the API

As opposed to the stable GCC API?

> cannot be bootstrapped

Say what now?

> Llvm [...] stable GCC API

In GCC, the compiler frontends are generally developed in parallel with, and distributed in parallel with the backend. There are some frontends which are distributed separately, but I expect that gcc-rs will be integrated into the mainline gcc source tree once complete. So it's not really an issue in practice. To put it another way: llvm api breakage doesn't affect clang, but it does affect other compilers using llvm.

Gcc is like a BSD, while llvm is like linux (except that linux makes a commitment to compatibility which llvm does not).

Llvm doesn't have a bootstrap target.

What do you mean a bootstrap target? What specifically does gcc provide that clang doesn't?

GCC specifically has bootstrapping as a feature in the build system. They take care to document which older version of GCC is required to build a newer versions. If you pick a version that doesn't rely on C++ (4.x IIRC) you can compile GCC with a very small and general C compiler (tinycc or so). That helps to provide a chain of trust and also gives you access to a new platform if necessary. LLVM only offers cmake so you always need a (full-feature) C++ compiler to build it.

That being said, GCC could make things better by providing a C-only entry point in modern releases, but it's still better than LLVM in that regard.

I don't understand. You could just cross compile LLVM onto a new platform from another host arch. You don't need to have a very long sequence of bootstrap builds, just directly jump.

> LLVM […] cannot be bootstrapped

How? Can't you compile it with GCC?

If I have GCC, I don't need llvm. Try to bootstrap llvm with something else.

> mrustc is not the solution [...] as it’s only capable of building rustc 1.39

This seems like an odd point. Instead of updating mrustc to support a couple of more features every once and a while we should write a whole new frontend? It seems like they are basically solving the same problem, except mrustc has chosen a subset of it (it assumes correct code). Of course GCC-rs also has a subset in a way as most of the codegen is handled by the GCC core.

To be clear I'm not saying that mrustc is a better approach to bootstrapping, but for this specific point is seems that the two approaches are basically equivalent.

There are other reasons given why mrustc is not the solution. Even if mrustc was updated to 1.51 those reasons would not go away.

Thinking about the dangers of subtle incompatibilities, I think the existence of crater[1] could make a huge difference, once alternative implementations are far enough along.

Arguably the nearest thing to a specification for the Rust language at present is "what crater would be happy with".

That seems more useful than thinking of rustc as a reference implementation, because when I read the release notes every now and again they say things to the effect of "this change is technically backwards-incompatible but crater reassures us that it won't cause anyone any trouble".

[1] https://github.com/rust-lang/crater

Crater costs a non-negligible amount of compute time, though, enough that the maintainers only do crater runs occasionally. Adding an entire new compiler toolchain to cover each run isn't ideal.

For the curious, here's the comment that it seems to be referencing:

https://www.reddit.com/r/rust/comments/njckp1/rustc_codegen_...

That comment does have many valid points. Note that the issue at hand isn't whether an alternative implementation of the compiler is viable at all, but rather whether an alternative front-end (i.e. parsing, type checking etc) is desirable. I have to admit that I don't really see any advantages to having multiple frontends, when the one that's already there is open source under a permissive license.

The conversation over gcc-rs online has always seemed weird to me. These are open source projects that aren't really competing for the same resources, people are free to work on what they find interesting and everyone should support their freedom to do so.

That said I think if you had money involved it would be better spent creating LLVM backends than porting yet another language to gcc. I'm not sure "this is time consuming to bootstrap from gcc 4" is a compelling enough argument, at least nowhere near compelling as "this programming language cannot target these processor families because the backend doesn't exist and no one has the time to write one."

> Further, mrustc is only capable of targeting x86. Performing this reduction is thus impossible on riscv or aarch64, and for bootstrapping on these platforms, one would have to build every single version of rustc.

That reminds me.

Couldn't the bootstrapping problem be solved by making an official, certified wasm build of the rust compiler, and distributing a signed binary of that build?

That way your bootstrap chain only needs two steps (wasm interpreter hand-coded in local assembly, running the compiler binary -> actual compiler). It's safe, assuming you trust the source producing the wasm binary, or run a bootstrap chain to produce the binary yourself. It can target any architecture, provided you can get/write a wasm interpreter for it (not too hard).

It certainly doesn't see like a problem where the most cost-efficient solution is to rewrite an entire compiler, frontend and backend, in a different less-convenient language.

The goal for Bootstrappable Builds is to not rely on compiled binaries, except for a small easily auditable 512-byte binary seed, and from there, and source code without any generated files, build an entire Linux distro:

https://bootstrappable.org/ https://bootstrapping.miraheze.org/

Personally I feel like we're missing something (and I did read the article, for the record). I suspect the problem is that they either cannot produce a Rust cross-compiler (but I think that exists?), or such a compiler cannot compile Rust itself correctly for some reason. So in your case, I guess you must not be able to create a `wasm` version of Rust that is capable of compiling the Rust compiler to native code on whatever platform you picked.

Otherwise your logic is basically how other compilers get bootstrapped, just replace `wasm` with some other already-supported platform like x86 - Produce an x86 to ARCH cross-compiler and compile the compiler with the new cross-compiler. The result is a compiler that runs on ARCH.

What you're missing is, mainly, the so-called "Trusting Trust" attack, where a compiler is backdoored such that whenever it's used to compile another compiler, the same backdoor is inserted into that compiler. Thus even assuming good intentions on the part of the current Rust maintainers, a backdoor could hypothetically have been inserted into version X's official compiler binaries at some point, which then infected version X+1, which infected version X+2, and so on. I say hypothetically, because IIRC Rust's bootstrap chain has been replicated, including with mrustc, resulting in identical binaries. There is absolutely no need to re-replicate it on every random architecture. (And even if you did want to do so, qemu already exists and can emulate x86, though wasm might be slightly faster.) But some people have strange ideas about how bootstrapping ought to work...

Ah, I didn't catch the part of the article that pointed out not relying on existing compilers was an explicit goal (Which probably should have been obvious in hindsight). To each his own, it's still a fun project if not particularly practical. But that makes sense then that this probably isn't the only way to bootstrap Rust onto a new architecture.

I think this is seriously underappreciated approach.

Isn’t a big part of why SBCL exists because CMUCL had a similarly gnarly bootstrapping sequence?

>I can choose the compilers I want to support based on the available features and compliance with the standard.

>I support GCC-Rs

What standard will you hold it to with rust, afaik there isn't one.

It's covered in the first few entries in the FAQ: https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...

Reply on news.ycombinator.com