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

Rust front-end merged in GCC trunk

gcc.gnu.org

Post reply on HN
Print view View original

41–50 of 135 posts

Re: Rust front-end merged in GCC trunk

#41

Post by jamincan »

Myrmornis wrote: post #27
wofo wrote: post #9

Earlier quoted context omitted.

I think this is more of an attempt of making Rust compilable on platforms not supported by LLVM, not an attempt to replace the existing compiler. The GCC frontend, for instance, does not implement the borrow checker, so you should only use it to compile Rust code you know is correct according to the official Rust compiler.

It seems like an odd idea to release a Rust compiler without a borrow checker. Isn't there a high risk that it will confuse users into thinking they have the usual Rust guarantees at run-time?

I think the expectation for now is that people will develop an app with rustc and then use gcc to compile to targets that aren't yet supported by llvm.

Re: Rust front-end merged in GCC trunk

#42

Post by mkj »

wofo wrote: post #9
hardware2win wrote: post #8

I hope there aint gonna be ecosystem fragmentation When there are a fews compilers with significant market share then developers are those who lose, lose that handy dev. experience of solid and consistent ecosystem I hope it will be used only where necessary

I think this is more of an attempt of making Rust compilable on platforms not supported by LLVM, not an attempt to replace the existing compiler. The GCC frontend, for instance, does not implement the borrow checker, so you should only use it to compile Rust code you know is correct according to the official Rust compiler.

Lacking a borrow checker is a temporary thing, no point reinventing the wheel. I think the intent is that eventually it'll use the same library as Rust (maybe Polonius, or perhaps plans will change)

Re: Rust front-end merged in GCC trunk

#43

Post by bayindirh »

hardware2win wrote: post #8

I hope there aint gonna be ecosystem fragmentation When there are a fews compilers with significant market share then developers are those who lose, lose that handy dev. experience of solid and consistent ecosystem I hope it will be used only where necessary

I disagree. We need competition. I'm not using (even avoiding) LLVM based toolchains, and not touching Rust even with a 100 foot pole because of that.

On the other hand, I acknowledge that LLVM kickstarted GCC development and made it better in thousand ways better, agile and flexible-minded (in terms of developers maintaining it).

Similarly, having two Rust compilers, nudging each other to be better is a great way to make a language more general, widely accepted, resilient and more free & open. Also Rust well be much more stressed and tested as a result.

> I hope it will be used only where necessary

I hope both will be used widely, and make Rust a better language with much better accessibility.

Re: Rust front-end merged in GCC trunk

#44

Post by kangalioo »

skitter wrote: post #37

I have asked this question before, but why write an entirely new frontend, which is an enormous task if you want to reach a similar quality to rustc? rustc_codegen_gcc¹ adds gcc as a backend to rustc alongside llvm, miri and (wip) cranelift. As a result, it always works with the newest version of rust and is already nearly complete after less work. ¹ https://github.com/rust-lang/rust/tree/master/compiler/rustc...

I've wondered about this for ages and now know: the people who work on GCCRS wouldn't work on rustc_codegen_gcc for one reason or another (familiarity, culture, personal ideals...?). So GCCRS is not "eating away" at available bandwidth and there's no reason not to let GCCRS developers do their thing, even if rustc_codegen_gcc is a more straightforward way of achieving most goals

Re: Rust front-end merged in GCC trunk

#45

Post by [deleted] »

bayindirh wrote: post #43
hardware2win wrote: post #8

I hope there aint gonna be ecosystem fragmentation When there are a fews compilers with significant market share then developers are those who lose, lose that handy dev. experience of solid and consistent ecosystem I hope it will be used only where necessary

I disagree. We need competition. I'm not using (even avoiding) LLVM based toolchains, and not touching Rust even with a 100 foot pole because of that. On the other hand, I acknowledge that LLVM kickstarted GCC development and made it better in thousand ways better, agile and flexible-minded (in terms of developers maintaining it). Similarly, having two Rust compilers, nudging each other to be better is a great way to…

[deleted]

Re: Rust front-end merged in GCC trunk

#46

Post by IshKebab »

skitter wrote: post #37

I have asked this question before, but why write an entirely new frontend, which is an enormous task if you want to reach a similar quality to rustc? rustc_codegen_gcc¹ adds gcc as a backend to rustc alongside llvm, miri and (wip) cranelift. As a result, it always works with the newest version of rust and is already nearly complete after less work. ¹ https://github.com/rust-lang/rust/tree/master/compiler/rustc...

It's probably not hugely useful from a "I want to compile this Rust code" point of view but I imagine it will at least help iron out ambiguities and bugs in the various specs people are working on. I think there's at least MiniRust and the Ferrocene Language Specification:

https://www.youtube.com/watch?v=eFpHadbv34I

https://spec.ferrocene.dev/

Re: Rust front-end merged in GCC trunk

#47

Post by hardware2win »

bayindirh wrote: post #43
hardware2win wrote: post #8

I hope there aint gonna be ecosystem fragmentation When there are a fews compilers with significant market share then developers are those who lose, lose that handy dev. experience of solid and consistent ecosystem I hope it will be used only where necessary

I disagree. We need competition. I'm not using (even avoiding) LLVM based toolchains, and not touching Rust even with a 100 foot pole because of that. On the other hand, I acknowledge that LLVM kickstarted GCC development and made it better in thousand ways better, agile and flexible-minded (in terms of developers maintaining it). Similarly, having two Rust compilers, nudging each other to be better is a great way to…

>We need competition

There is - between langs.

Compiler engineers can use ideas from other lang's compilers.

C# e.g

Re: Rust front-end merged in GCC trunk

#48

Post by kangalioo »

Conan_Kudo wrote: post #3
rwmj wrote: post #2

What are the practical implications of this? Could cargo call GCC? Or would it be like gcj and allow compiled rust libraries & binaries to be distributed? (at least in theory, gcj didn't work out well)

Cargo could call gcc-rs instead of rustc.

The point of GCCRS over rustc_codegen_gcc is to make Rust easier integrateable into other projects and build systems. If you use Cargo anyways, you're much better off using rustc_codegen_gcc

Re: Rust front-end merged in GCC trunk

#49

Post by kangalioo »

skitter wrote: post #33
rapsey wrote: post #4

Earlier quoted context omitted.

More architectures supported at least. Now Rust can really be used anywhere C is used

You don't need to write an new frontend for that, just add libgccjit as a backend for rustc.

Which has been done, and I'm really sad how that effort has been overshadowed hard by GCCRS, when the latter is much more niche in its use case

Re: Rust front-end merged in GCC trunk

#50

Post by hardware2win »

sseagull wrote: post #35
hardware2win wrote: post #8

I hope there aint gonna be ecosystem fragmentation When there are a fews compilers with significant market share then developers are those who lose, lose that handy dev. experience of solid and consistent ecosystem I hope it will be used only where necessary

I’ve come to the conclusion that fragmentation is inevitable as a language gets popular. People think differently, have different ideas for how to do things, need it to work for their particular use case, etc. Fragmentation and bloat are a result. I am willing to bet it will happen rust as it gets used more and more. Then the treadmill will start again with a new language. (Sorry if that’s jaded. I’ve been fighting w…

Counter example: .net c#

One compiler for 99%, one package manager, one base classes liberary, one cli, etc.

Post reply on HN