Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC Rust Approved by GCC Steering Committee

gcc.gnu.org

Post reply on HN
Print view View original

261–270 of 300 posts

Re: GCC Rust Approved by GCC Steering Committee

#261

Post by dleslie »

maxwell86 wrote: post #260
dleslie wrote: post #197

Earlier quoted context omitted.

Because that doesn't use the GCC frontend interface, requiring build tools and embedded toolchains to be modified to understand the rust compiler interface. By using GCC it's just another language that the existing toolchain can understand.

The Rust module system is radically different from C and C++ and other similar languages in the embedded space. Every build system that has added support for Rust, which aren't many, had to be radically modified to achieve that. None of these supports the GCC Rust frontend, but all of them support the Rust frontend. So if you actually wanted to build any >100 LOC Rust project for embedded targets not supported by LLV…

Cargo support for gccrs is part of this project:

https://github.com/Rust-GCC/cargo-gccrs

Moreover, modules are less interesting to me in embedded development, for which I'm interested in access to Rust's borrow checker for gaining certainty of small portions of larger projects, which are written in other languages.

Re: GCC Rust Approved by GCC Steering Committee

#262

Post by damagednoob »

mbStavola wrote: post #213
mcdonje wrote: post #210

Earlier quoted context omitted.

Pretty sure you have it backwards. GCC isn't going to be a front end for rust; rust is going to be a front end for GCC. As I understand it, the point of both GCC and LLVM are to handle those implementation specific behaviors so programming language developers don't have to handle that concern. I don't expect this to fracture the language, but simply to provide the ability to use the language in more places.

Sorry, to be clear, I'm referring to the CPP reimplementation of the Rust compiler that uses GCC as a backend (gccrs). My concern with fragmentation is that this is essentially a reimplementation of Rust in another language (C++) targeting a different backend (GCC). It's only natural for there to be differences between the two, especially over a long period of time. There is a separate initiative that may be more in…

I think what will prove more important than standards will be a common suite of tests used by all implementations. Sun used to have TCK[1] that was used by a few implementations.

[1]: https://en.m.wikipedia.org/wiki/Technology_Compatibility_Kit

Re: GCC Rust Approved by GCC Steering Committee

#264

Post by [deleted] »

damagednoob wrote: post #262
mbStavola wrote: post #213

Earlier quoted context omitted.

Sorry, to be clear, I'm referring to the CPP reimplementation of the Rust compiler that uses GCC as a backend (gccrs). My concern with fragmentation is that this is essentially a reimplementation of Rust in another language (C++) targeting a different backend (GCC). It's only natural for there to be differences between the two, especially over a long period of time. There is a separate initiative that may be more in…

I think what will prove more important than standards will be a common suite of tests used by all implementations. Sun used to have TCK[1] that was used by a few implementations. [1]: https://en.m.wikipedia.org/wiki/Technology_Compatibility_Kit

[deleted]

Re: GCC Rust Approved by GCC Steering Committee

#265

Post by pjmlp »

rightbyte wrote: post #221
thrown_22 wrote: post #219

Earlier quoted context omitted.

>What is the benefit of having multiple compilers for programming languages? Rust will need a standard. The main reason why I don't take it seriously is that code written 5 years ago will often not compile today. For a language that pretends to be a systems language that is a non-starter. If you can't guarantee a 40 year shelf life of your code then no one working on systems cares. People working on systems in the wi…

We are still arguing whether to bump the C standard from 89 to 99 where I work. I kinda like the pacing with C. Or as Wikipedia puts it: "C17 addresses defects in C11 without introducing new language features."

Hopefully you won't have K&R C by the time you adopt C23 then.

Re: GCC Rust Approved by GCC Steering Committee

#266

Post by pjmlp »

Aissen wrote: post #263

Just like Mozilla's browser might be eventually a footnote in history (I hope not), this too has a potential impact greater than Open Source Security's main project (grsecurity). Kudos.

At 3% market share it looks it might be eventually become true, and it is my favourite browser still.

Re: GCC Rust Approved by GCC Steering Committee

#267

Post by pjmlp »

jerf wrote: post #40
bombcar wrote: post #24

Earlier quoted context omitted.

Would it ever make sense to build a chip/vm (something like the JVM) designed to run the intermediate code directly?

Generally, no. The IR will be tuned for compiler purposes, not execution purposes. It can be possible but it won't be optimal. For instance, the IR will probably retain type information that generally CPUs don't care about, since they live in a world of bits. The IR will have been designed knowing it is upstream of optimization code, so it won't be something that is already optimal, it'll be something designed to be…

And yet we are in the middle of adoption of hardware memory tagging architectures, as last resort to fix C and the languages copy-paste compatible with it, the irony.

Re: GCC Rust Approved by GCC Steering Committee

#268

Post by pjmlp »

hedora wrote: post #96
outside1234 wrote: post #2

Why would someone want this? (Honest question)

Competition. GCC had laughably bad error messages before LLVM caught on. Even then, LLVM generated terrible code compared to GCC. There's a similar competition going on with open source linkers (which are finally going multi-threaded). Both compiler toolchains currently blow pre-LLVM GCC out of the water (and GCC development has noticeably accelerated since LLVM came out). I'm not sure which one is better at which C+…

And now clang is lagging in C++20 support, and modules will come in 2 to 3 years as per roadmap (right after C++23 is done), while VC++ already has them, and GCC head is catching on relatively fast.

Re: GCC Rust Approved by GCC Steering Committee

#269

Post by pornel »

ByteJockey wrote: post #244
pornel wrote: post #176

Earlier quoted context omitted.

It won't be. They plan to use the exact same code! Rust is designed to compile fine without any borrow checking (it reduces it to the C level of safety, but valid programs generate valid code). GCC will compile itself without a borrow checker. Then it will compile the existing borrow checker written in Rust, and then recompile itself with borrow checking.

> They plan to use the exact same code! Did they announce a change of plans? Their website just says that they have no plans for a borrow checker (i.e. it's not required to actually implement rust). From the website for the project: > There are no immediate plans for a borrow checker as this is not required to compile rust code and is the last pass in the RustC compiler. This can be handled as a separate project when…

The "separate project" you mention is integration of Polonius: https://lwn.net/Articles/871283/

Re: GCC Rust Approved by GCC Steering Committee

#270

Post by pornel »

ArrayBoundCheck wrote: post #253
ByteJockey wrote: post #244

Earlier quoted context omitted.

> They plan to use the exact same code! Did they announce a change of plans? Their website just says that they have no plans for a borrow checker (i.e. it's not required to actually implement rust). From the website for the project: > There are no immediate plans for a borrow checker as this is not required to compile rust code and is the last pass in the RustC compiler. This can be handled as a separate project when…

Quoted post unavailable.

If my information was inaccurate or out of date, you could have corrected me. I find your antagonizing cheer hurtful, and such a mean comment is unhelpful. Please be kinder.
Post reply on HN