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

GCC Rust: GCC Front-End for Rust

github.com

Post reply on HN
Print view View original

121–130 of 179 posts

Re: GCC Rust: GCC Front-End for Rust

#121

Post by vlovich123 »

Blikkentrekker wrote: post #82
thesuperbigfrog wrote: post #25

Earlier quoted context omitted.

>> The only way to do this properly, if desirable, is to make GCC an official backend of the main frontend. That will defocus some progress that happens with LLVM (every feature has to be implemented on both backends) and can make dev lives hard (eg “oh this problem comes up with GCC so use the LLVM backend “) No. The correct way is to create a Rust language specification that describes what the correct behavior is.…

Such standardized specifications are typically a response to many divergent implementations existing and a need to standardize a common ground between them. Few languages find such specification before that time. Python also lacks it despite some competing implementations, since none actually diverge enough from CPython .

PyPy famously diverges from it a lot (namely for native modules).

Standardization is helpful for tool building and experiments (ie here are the invariants we’ll never change). Languages don’t work that way and seeing how C/C++ have evolved (or really failed to do so at a meaningful pace), I’m under the impression (clearly unpopular due to the downvotes) that standardization and multiple competing tool chains are the cause of a lot of unnecessary complexity (not just within the language but also users of said language).

Re: GCC Rust: GCC Front-End for Rust

#122

Post by unanswered »

Nullabillity wrote: post #96
unanswered wrote: post #27

Earlier quoted context omitted.

It also looks rather incomplete. Are they not planning on implementing borrowck? If chalk/polonius were ready and had a C API the roadmap would begin to make sense.

Makes sense to me. As mrustc[0] mentions, implementing validation in a secondary compiler is much less important, because you can always just run the reference implementation as a glorified linter in the meantime. [0]: https://github.com/thepowersgang/mrustc

That's what I don't get. I looked through the available documentation briefly and didn't see any mention that this is intended to be a `mrustc`; it really seems to want to be a `rustc`. I'm not aware of other GCC frontends being less than complete compilers for their respective languages, and while I think that "rust without borrowck" is an interesting point in design space (discriminated unions, generics, macros, traits, closures), "rust without borrowck" is not rust.

Re: GCC Rust: GCC Front-End for Rust

#125

Post by tele_ski »

piinbinary wrote: post #120

Don't try to compile this with `make -j` - I tried, and my system ran out of ram and swap and started OOM killing things. I have 16 threads and 32gb of ram. Running `make -j4` seems safe thus far.

did you try make -j16 since you have 16 cores? -j with no number means spawn as many parallel jobs as possible which could be hundreds or thousands depending on the project, I learned this the hard way a while ago myself when I used $(nproc) incorrectly on a project, got the same OOM/swapping death spiral!

Re: GCC Rust: GCC Front-End for Rust

#126

Post by djur »

ncmncm wrote: post #113
ibraheemdev wrote: post #67

There was a thread posted on the rust forum a while back that laid out the goals of this project [0]: > A friend of mine (Luke) has been talking about the need for a Rust frontend for GCC to allow Rust to replace C in more places, such as system software. To allow some types of safety-critical software to be written in Rust, the GCC frontend would need to be an independent implementation of Rust, since the relevant s…

It would be a grave error to have coded the Rust frontend to Gcc in C (or, as written above, "in c"). Gcc is now a C++ codebase, and new components should be coded in modern C++, for better productivity, performance, safety, and maintainability. (You might prefer not to consider modern C++ more productive, performant, safe, and maintainable than C (and reflexively downvote), but the statement remains true: Gcc did tr…

gccrs is written in C++, so no worries there.

Re: GCC Rust: GCC Front-End for Rust

#127

Post by varajelle »

Guvante wrote: post #53
varajelle wrote: post #22

Earlier quoted context omitted.

> There is absolutely no reason why the GCC front-end needs to be written in Rust. How about memory safety and fearless concurrency?

No one is saying that rustc should be rewritten in C. They are saying that an alternative compiler front-end in an alternative language is sensible.

No one is saying that someone said rustc should be rewritten.

Re: GCC Rust: GCC Front-End for Rust

#128

Post by varajelle »

turminal wrote: post #117
steveklabnik wrote: post #78

Earlier quoted context omitted.

This is the way that very few languages work. Python is a great example of an extremely popular, mature language that does not work this way. It is unclear that most people think that this sort of process is required for “maturity.” If this is the benchmark, then among popular languages you basically have C, C++, C#, JavaScript, and... is that it?

The other languages without a spec don't market themselves a C/C++ replacement or as systems languages. Having a webapp depend on a CPython implementation detail is very different from having a kernel depend on an implementation detail of a language without a spec that was used to implement it. And languages actually stack on top of each other. Imagine depending on a CPython implementation detail that depends on an i…

Linux uses GCC extensions. So the Linux kernel depends on the implementation of a compiler already.

Re: GCC Rust: GCC Front-End for Rust

#129

Post by varajelle »

turminal wrote: post #57
not2b wrote: post #30

Earlier quoted context omitted.

Strongly disagree. It will only benefit the language to have more than one quality implementation. C++ has benefited hugely by the competition between g++ and clang; both compilers have gotten much, much better. To be fair, it will take a while before the GCC Rust front end is competitive, but for some purposes it doesn't have to be, like bootstrapping. If "progress" means "rapidly add more and more new features in e…

>If "progress" means "rapidly add more and more new features in each release", multiple implementations will slow things down This has to happen at some point anyway otherwise we'll just get another C++. And I don't think Rust would benefit from that. New languages are designed to fix problems with the old ones, not to replicate them after all. I just hope the designers will choose that point wisely.

> otherwise we'll just get another C++.

I don't see why this is a bad thing. I'm a C++ developer, and I like C++. (I like rust as well)

Re: GCC Rust: GCC Front-End for Rust

#130

Post by Dylan16807 »

volta87 wrote: post #102
masklinn wrote: post #40

Earlier quoted context omitted.

> Some famous examples being the loop optimization miscompilation, and &mut T currently not being marked noalias. I don't think that's a case where Rust "doesn't have LLVM semantics" since the miscompilation was reproduced in standard C. Rather that rust is actively and ubiquitously leveraging otherwise rarely-exercised LLVM features, revealing a bunch of bugs (either leftovers or breakages) in them.

Notice that in C and C++ loops that might not terminate are UB, while in Rust they are just infinite loops. So there is a significant difference in semantics between Rust and C/C++ here.

Loops that do nothing and don't terminate.

If your loop infinitely writes the number 70 to an atomic int, it's fine.

Post reply on HN