Having a Rust compiler is probably unavoidable

Posted Nov 25, 2024 9:17 UTC (Mon) by glaubitz (subscriber, #96452)
In reply to: Having a Rust compiler is probably unavoidable by pbonzini
Parent article: NonStop discussion around adding Rust to Git

> I don't think the complexity of the Rust language is particularly important with respect to porting it. The frontend is free and permissive, and Rust does not impose on the backend any more requirements that C++.

The problem is that the Rust developers can agree on a stable language specification which makes implementing a compliant alternative compiler such gccrs nearly impossible.

Having a Rust compiler is probably unavoidable

Posted Nov 25, 2024 15:35 UTC (Mon) by matthias (subscriber, #94967) [Link] (4 responses)

This is exactly what pbonzini said. Development of a new frontend is hard, which is what gccrs is doing. If you just want a compiler on your architecture you should take the existing compiler and add another backend. This is what rustc-codegen-gcc is doing. Another bonus is, that once you have done that most of the changes on the frontend will not require any changes on the backend any more. Gccrs however while have to reimplement all new features on their own frontend.

Having a Rust compiler is probably unavoidable

Posted Nov 26, 2024 13:06 UTC (Tue) by glaubitz (subscriber, #96452) [Link] (3 responses)

> This is exactly what pbonzini said. Development of a new frontend is hard, which is what gccrs is doing.

It's hard because Rust upstream cannot agree on a stable language but decided to keep changing the language all the time.

> If you just want a compiler on your architecture you should take the existing compiler and add another backend. This is what rustc-codegen-gcc is doing.

Which has been promised to be usable for at least two years now. It's still not usable.

> Another bonus is, that once you have done that most of the changes on the frontend will not require any changes on the backend any more. Gccrs however while have to reimplement all new features on their own frontend.

Currently rustc requires LLVM support for a given architecture which is almost only possible for architectures backed by big corporations as LLVM upstream requires people actively supporting a backend.

The M68k backend is only possible because people (which includes me) have created a funding campaign through Patreon and OpenCollective.

Having a Rust compiler is probably unavoidable

Posted Nov 26, 2024 15:14 UTC (Tue) by kleptog (subscriber, #1183) [Link]

> It's hard because Rust upstream cannot agree on a stable language but decided to keep changing the language all the time.

ISTM that C/C++ aren't really stable either as they keep coming up with new revisions and compilers keep inventing new extensions. I'm guessing the problem is not the lack of stability, but the rate of change?

That does make it hard for competing back-ends to keep up, but I expect the rate to reduce as all the pending ideas are worked out. That should make it easier in the long term.

Having a Rust compiler is probably unavoidable

Posted Dec 5, 2024 21:34 UTC (Thu) by ssokolow (guest, #94568) [Link]

Which has been promised to be usable for at least two years now. It's still not usable.

According to the repo's Insights tab on GitHub, it wavers between a one-man project and a two-man project at any given time (depending on whether bjorn3 or GuillaumeGomez is contributing in addition to antoyo) and, as the progress reports show, they're also busy writing patches to be upstreamed into libgccjit to flesh out the API they depend on.

Having a Rust compiler is probably unavoidable

Posted Dec 12, 2024 21:30 UTC (Thu) by sunshowers (guest, #170655) [Link]

As a Rust developer with several popular crates to my name, I'm not really interested in supporting compiler frontends other than rustc. I think backends are the right way to go.

Note that Rust doesn't make breaking changes. There's not going to be a completely unchanging language for many years, because the language is still quite incomplete. Meanwhile, I'm going to continue being part of teams that ship projects and deliver value to users, in ways that are simply not possible in other languages.