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

131–140 of 179 posts

Re: GCC Rust: GCC Front-End for Rust

#131

Post by steveklabnik »

mhh__ wrote: post #106
steveklabnik wrote: post #49

Earlier quoted context omitted.

There are pros to that approach, but also cons. The major con is that keeping the rustc frontend would make an existing Rust compiler be a requirement, and not having that makes bootstrapping easier, which is a major pro. This (among other things) was debated a lot .

> The major con A major con of not sharing is not having a backend at all. It's a lot of work to keep up with a moving target

Yes, that is a theoretical problem, for sure. All choices have pros and cons.

Re: GCC Rust: GCC Front-End for Rust

#132

Post by steveklabnik »

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…

Sure, and people in that space do care more. But it's clearly not a blocker, even for the stuff you're talking about. It's not a hard requirement to get Rust code into Linux, for example. (Not to mention what my sibling talks about, which is very much already true.)

Re: GCC Rust: GCC Front-End for Rust

#133

Post by anfilt »

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…

I disagree with the idea of using C++. Even with some of its more modern features. If I was choosing a compiled language for system development right now I would choose C or Rust.

For starters C++ does not have a stable ABI. Rust plans too have a stable ABI. In either case right now both fall back to the C ABI, but at least its a goal of the rust devs.

C++ is going to be harder to boot strap than either Rust core or C when trying to build a compiler for a new system/platform. C probably is the easiest bootstrap of the 3.

Rust and C are generally more performant than C++ code. Also in the realm of low end micro controllers C code tends to have the smallest binary image size.

In C++ if you need to interact with other languages a lot times your stuck to the C abi which which forces you to avoid a lot C++ features/constructs. As for rust its not an object orientated language and its unsafe blocks generally make it easier to at least keep rust code idiomatic.

C++ is also a massive kitchen sink of a language with many ways to hide gotchas. Probably the worst thing in C is its null terminated strings but C++ also suffers from that. C is simple, and rust has at least so far made good design choices for the most part.

There also choices in the C++ language that are even part of the standard library that seemed like a good idea but with hind sight are not that great of idea. For example operator overloading.

Although we are talking a GCC front end so I would be surprised to see both C and C++.

Re: GCC Rust: GCC Front-End for Rust

#134

Post by moonchild »

bonzini wrote: post #48
wiz21c wrote: post #3

from the readme : > The developers of the project are keen “Rustaceans” with a desire to give back to the Rust community and to learn what GCC is capable of when it comes to a modern language. So what's the answer right now ? How does GCC measures "against" rust ?

Front-end–independent optimizations are still slightly better in GCC than in LLVM.

I wouldn't say 'better'. Certainly, they're different. GCC does better in some ways, but worse in others. Somewhat notably, GCC doesn't do as good of a job at register allocation on some RISC architectures.

Re: GCC Rust: GCC Front-End for Rust

#135

Post by eru »

anfilt wrote: post #133
ncmncm wrote: post #113

Earlier quoted context omitted.

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…

I disagree with the idea of using C++. Even with some of its more modern features. If I was choosing a compiled language for system development right now I would choose C or Rust. For starters C++ does not have a stable ABI. Rust plans too have a stable ABI. In either case right now both fall back to the C ABI, but at least its a goal of the rust devs. C++ is going to be harder to boot strap than either Rust core or…

> If I was choosing a compiled language for system development right now I would choose C or Rust.

I'm not quite sure what systems development has to do with compiler writing? (I assume by system development, you mean something like writing OS kernels etc?)

Eg there are good reasons to stay away from automatic memory management when you are writing an OS, you want control over that. But those reasons hardly apply when you run a simple user space program like a compiler.

Re: GCC Rust: GCC Front-End for Rust

#136

Post by jandrewrogers »

anfilt wrote: post #133
ncmncm wrote: post #113

Earlier quoted context omitted.

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…

I disagree with the idea of using C++. Even with some of its more modern features. If I was choosing a compiled language for system development right now I would choose C or Rust. For starters C++ does not have a stable ABI. Rust plans too have a stable ABI. In either case right now both fall back to the C ABI, but at least its a goal of the rust devs. C++ is going to be harder to boot strap than either Rust core or…

Where did you ever get the idea that C and Rust are more performant than C++ code? Modern C++ produces the fastest code of any language in wide use, empirically, and I don’t think many people would argue that. People don’t use C++ because they love its elegance — who would? — they use it for its raw power and expressiveness.

C has not been used for applications where performance is a priority for many years now. C lacks the expressiveness to make many software optimizations practical. I’ve written database engines in both C and modern C++ and it is no contest, C++ is much more concise while producing faster code. People primarily still use C for portability.

Re: GCC Rust: GCC Front-End for Rust

#137

Post by anfilt »

eru wrote: post #135
anfilt wrote: post #133

Earlier quoted context omitted.

I disagree with the idea of using C++. Even with some of its more modern features. If I was choosing a compiled language for system development right now I would choose C or Rust. For starters C++ does not have a stable ABI. Rust plans too have a stable ABI. In either case right now both fall back to the C ABI, but at least its a goal of the rust devs. C++ is going to be harder to boot strap than either Rust core or…

> If I was choosing a compiled language for system development right now I would choose C or Rust. I'm not quite sure what systems development has to do with compiler writing? (I assume by system development, you mean something like writing OS kernels etc?) Eg there are good reasons to stay away from automatic memory management when you are writing an OS, you want control over that. But those reasons hardly apply whe…

System programs can be in user space for instance a run time for another language.

As for a compiler ideally its easy to port as its kinda of the bed rock to get any other system going. Although a compiler for some architecture or use cases is too large to be self hosted or does not make sense to be self hosted. So its not always a deal breaker for a compiler.

Re: GCC Rust: GCC Front-End for Rust

#138

Post by trogdc »

varajelle wrote: post #128
turminal wrote: post #117

Earlier quoted context omitted.

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.

Those are intentional deviations from the standard, and I think there's a reasonable assumption that those stay the same/compatible from version to version. I think the other kind are a bit more problematic, and without a standard it can be difficult to tell whether your assumptions are reasonable.

Re: GCC Rust: GCC Front-End for Rust

#139

Post by bobthebuilders »

unanswered wrote: post #122
Nullabillity wrote: post #96

Earlier quoted context omitted.

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, tr…

You can plug in the borrow checker after writing the base compiler, but you if you block waiting for the borrow checker you get nothing done.

Re: GCC Rust: GCC Front-End for Rust

#140

Post by ncmncm »

anfilt wrote: post #137
eru wrote: post #135

Earlier quoted context omitted.

> If I was choosing a compiled language for system development right now I would choose C or Rust. I'm not quite sure what systems development has to do with compiler writing? (I assume by system development, you mean something like writing OS kernels etc?) Eg there are good reasons to stay away from automatic memory management when you are writing an OS, you want control over that. But those reasons hardly apply whe…

System programs can be in user space for instance a run time for another language. As for a compiler ideally its easy to port as its kinda of the bed rock to get any other system going. Although a compiler for some architecture or use cases is too large to be self hosted or does not make sense to be self hosted. So its not always a deal breaker for a compiler.

You seem to be confused about what C++ and C are, and even about what Gcc is and its relationship to programs it compiles.

C++ is a language defined by ISO committee SC22/WG21 via the Standards 14882, most recently C++20 (superseding C++17).

C is defined by SC22/WG14, in the same way.

The most widely used implementations of these Standards -- Gcc, Clang, and MSVC -- are in fact the same project in each case (although MS's [until recently implemented] a long-superceded C Standard), and are, in fact, themselves C++ programs.

Portability of compilers is not needed, in general, to "get a system going", because cross-compilation is a mature and long-supported technique. Gcc is very frequently ported anyway, for practical reasons, via cross-compilation. Being coded in C++, and capable of compiling and cross-compiling itself, Gcc remains quite portable, as is repeatedly demonstrated by notedly frequent ports.

It is hard to imagine what could be considered a "deal-breaker" in this context. By the evidence, portability of C++ is never a dealbreaker as implementation language for a compiler, as in fact the compilers actually used in "get[ting] any other system going" are, with only rare exceptions, compilers in fact coded in C++.

(Exceptions are found not to be about portability, but about the memory footprint of the resulting compiler, which is not a product of its source language, but rather of the power of the compiler's optimizer, which is not always seen as necessary.)

In any case, the implementation language used for the compiler has absolutely no effect on the stability of an ABI for any target language. ABI stability is a choice made by language designers to favor backward link-compatibility over convenient expression of new features or bug fixes. It is hard for me to imagine the level of confusion that would produce this error.

Post reply on HN