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

71–80 of 179 posts

Re: GCC Rust: GCC Front-End for Rust

#71

Post by pjmlp »

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.

In some extent, given the use of macros and Haskell like libraries, it is already another C++.

Besides, if Rust doesn't become another C++, it won't fulfil the industry needs that C++ caters for, thus while it might become a success in some domain, it won't replace C++ in the OS and GPGPU SDKs.

Re: GCC Rust: GCC Front-End for Rust

#73

Post by [deleted] »

oconnor663 wrote: post #14
faitswulff wrote: post #5

I'm not sure if what I'm asking makes sense, but since it's written for a new backend, would the authors have to bootstrap it using a different toolchain? I guess what I'm asking is, could they use the LLVM Rust to build the GCC frontend or do they have to start all over with a different base language to get a first working version of a rust compiler?

The LLVM-based Rust compiler uses a lot of unstable/nightly-only Rust features internally. So even if this project got to the point where it could compile all stable Rust programs, I think it would take quite a bit more work than that to be able to compile `rustc` itself. (It might be that the unstable stuff is mostly in the standard library and not the compiler itself? Does it make a difference?)

[deleted]

Re: GCC Rust: GCC Front-End for Rust

#75

Post by thesuperbigfrog »

not2b wrote: post #33
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.…

It doesn't even have to stop progress. C++ does a new rev of the standard every 3 years. Rust has editions, which is a similar but less rigorous concept, and which could be made more rigorous.

Exactly. The C++ standard (https://isocpp.org/std/the-standard) is the specification that describes what a compiler must do to implement a particular "version" of C++ (for example, C++ 20).

Just as there is a C++ standard and multiple C++ compilers that implement the standard, there should be a Rust standard and multiple implementations.

This is the way that mature languages work.

Re: GCC Rust: GCC Front-End for Rust

#76

Post by tumdum_ »

rectang wrote: post #13
steveklabnik wrote: post #10

Earlier quoted context omitted.

The work on a spec is already going as fast as it reasonably can be. A stable ABI is unclear.

Glad you're going slow on the stable ABI and resisting the pressure to put out something half-baked. The C++ ABI is horribly fragile and complex. Unless the pitfalls of C++ can be avoided, making no ABI promises is better.

No stable ABI makes distributing shared libraries harder :/

Re: GCC Rust: GCC Front-End for Rust

#77

Post by steveklabnik »

tumdum_ wrote: post #76
rectang wrote: post #13

Earlier quoted context omitted.

Glad you're going slow on the stable ABI and resisting the pressure to put out something half-baked. The C++ ABI is horribly fragile and complex. Unless the pitfalls of C++ can be avoided, making no ABI promises is better.

No stable ABI makes distributing shared libraries harder :/

Everything is tradeoffs. Stable ABI can also lead to other issues, like performance problems. C++ is dealing with some of these right now, and there are some situations (very very micro benchmarks, to be clear) where Rust is faster than C++ due to ABI issues.

Re: GCC Rust: GCC Front-End for Rust

#78

Post by steveklabnik »

thesuperbigfrog wrote: post #75
not2b wrote: post #33

Earlier quoted context omitted.

It doesn't even have to stop progress. C++ does a new rev of the standard every 3 years. Rust has editions, which is a similar but less rigorous concept, and which could be made more rigorous.

Exactly. The C++ standard ( https://isocpp.org/std/the-standard ) is the specification that describes what a compiler must do to implement a particular "version" of C++ (for example, C++ 20). Just as there is a C++ standard and multiple C++ compilers that implement the standard, there should be a Rust standard and multiple implementations. This is the way that mature languages work.

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?

Re: GCC Rust: GCC Front-End for Rust

#79

Post by Blikkentrekker »

steveklabnik wrote: post #10
ognarb wrote: post #2

This is very cool, maybe this could push the rust community to have a formal specification and a stable ABI in the future.

The work on a spec is already going as fast as it reasonably can be. A stable ABI is unclear.

Does it not already have them if the programmer elect for it by choosing `repr(C)`, or is there more to it than that?

Re: GCC Rust: GCC Front-End for Rust

#80

Post by steveklabnik »

Blikkentrekker wrote: post #79
steveklabnik wrote: post #10

Earlier quoted context omitted.

The work on a spec is already going as fast as it reasonably can be. A stable ABI is unclear.

Does it not already have them if the programmer elect for it by choosing `repr(C)`, or is there more to it than that?

You are exposing an imprecision in the way that this is usually talked about, yes. If you are willing to use the C ABI, then you can use a combination of that repr and annotations on your functions and produce a shared object in Rust with a stable ABI.

What people usually mean here is that Rust would have its own stable ABI, that you would get “for free,” without needing to do that work. (It’s never actually free of course... but that’s yet another detail that is usually papered over when people talk about this.)

Post reply on HN