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

51–60 of 135 posts

Re: Rust front-end merged in GCC trunk

#51

Post by bayindirh »

hardware2win wrote: post #47
bayindirh wrote: post #43

Earlier quoted context omitted.

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

I think having a GPL implementation of a language makes it more future proof. I don't want to be able compile some source only with "rustc-v_ancient-company_name-internal_fork-no_you_cant_have_its_source" version.

Programming languages with single compilers tend to be not used in my area of work and research (HPC and Scientific Computing). Hence, I'd rather have multiple compatible, yet independently implemented compilers, per language.

Re: Rust front-end merged in GCC trunk

#52

Post by thesuperbigfrog »

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…

>> I’ve come to the conclusion that fragmentation is inevitable as a language gets popular.

That's what language standards are for.

The Ferrocene project is working on standardizing Rust and creating a safety-critical version of the Rust toolchain:

https://ferrous-systems.com/ferrocene/

The Ferrocene Rust draft spec is out:

https://spec.ferrocene.dev/

As Rust continues to improve and be more widely used and adopted, there will be multiple implementations. As you've stated, it is inevitable as Rust gets popular. (For example, if Rust becomes popular enough to displace niches that C and C++ have occupied, when will Microsoft release a Rust toolchain? When will Intel release a Rust toolchain? And so forth.)

Standards help to better define what a Rust toolchain should do and what it means to be a conforming Rust implementation.

Re: Rust front-end merged in GCC trunk

#53

Post by skitter »

whyarewheher wrote: post #40
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...

Why not do it? There are lots of reasons to have multiple implementations of a language, one of them being gcc is much easier to bootstrap than rustc

rustc got bootstrapped already, so download it. If you want to run the compiler itself on a new architecture, cross-compile. If you still decide to bootstrap it again, that's something that will only need to be done once. And even in that case, you can use the second implementation that already exists, mrustc.

Re: Rust front-end merged in GCC trunk

#54

Post by mustache_kimono »

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. I'm not using (even avoiding) LLVM based toolchains, and not touching Rust even with a 100 foot pole because of that.

I'm interested in this. Could you elaborate on why you are not using Rust? Because there is no competition in the language, or because there is not an alternate compiler, or because you don't like LLVM?

Re: Rust front-end merged in GCC trunk

#55

Post by UncleEntity »

zozbot234 wrote: post #19
masklinn wrote: post #14

Earlier quoted context omitted.

Lots of rarer or older architectures are not in LLVM e.g. alpha, ia64, HP-PA. The LLVM backends which do exist for such also tend to have been exercised less and thus me more buggy (I think PPC/spe had a fair amount of issues there but it might have gotten better). You can see something of a summary over on https://builds.Debian.org/status/package.php?p=rustc&suite=s... the BD-Uninstallable entries are unsupported ar…

> Lots of rarer or older architectures are not in LLVM e.g. alpha, ia64, HP-PA. If there are people who care about these historical architectures, they can do the work to maintain them in LLVM. That's how m68k support was added.

So in order to use rust you also have to become a compiler developer?

Re: Rust front-end merged in GCC trunk

#56

Post by mustache_kimono »

bayindirh wrote: post #51
hardware2win wrote: post #47

Earlier quoted context omitted.

>We need competition There is - between langs. Compiler engineers can use ideas from other lang's compilers. C# e.g

I think having a GPL implementation of a language makes it more future proof. I don't want to be able compile some source only with "rustc-v_ancient-company_name-internal_fork-no_you_cant_have_its_source" version. Programming languages with single compilers tend to be not used in my area of work and research (HPC and Scientific Computing). Hence, I'd rather have multiple compatible, yet independently implemented comp…

> I don't want to be able compile some source only with "rustc-v_ancient-company_name-internal_fork-no_you_cant_have_its_source" version.

Yeah, it's not like Google (and dozens of others) has/have an internal fork of Linux, which never gets merged back. I'm not certain the GPL butters any parsnips here.

> Hence, I'd rather have multiple compatible, yet independently implemented compilers, per language.

You identified it. The problem is compatibility, and again Linux is a good negative example where ostensibly we have a language spec and multiple compilers, but Linux for years would only compile on one compiler.

Multiple compilers and "competition" doesn't solve compatibility. It makes it more difficult. Although I'm sure there will be benefits, I'm not certain the GPL/GCC will make compatibility any easier. It hasn't so far.

Re: Rust front-end merged in GCC trunk

#57

Post by hardware2win »

bayindirh wrote: post #51
hardware2win wrote: post #47

Earlier quoted context omitted.

>We need competition There is - between langs. Compiler engineers can use ideas from other lang's compilers. C# e.g

I think having a GPL implementation of a language makes it more future proof. I don't want to be able compile some source only with "rustc-v_ancient-company_name-internal_fork-no_you_cant_have_its_source" version. Programming languages with single compilers tend to be not used in my area of work and research (HPC and Scientific Computing). Hence, I'd rather have multiple compatible, yet independently implemented comp…

>I don't want to be able compile some source only with "rustc-v_ancient-company_name-internal_fork-no_you_cant_have_its_source" version.

I dont think it is valid concern in $currentYear

Nowadays languages like e.g c# are partially created by community and foundations (.net foundation) on github

So not only isnt it fully tied to company, but also it is oss.

>Hence, I'd rather have multiple compatible, yet independently implemented compilers, per language.

I dont because it permanently decreases developer experience and the value added is not something that could not be achieved with single compiler

I mean if you see room for improvement then go ahead and make PR instead of creating yet another compiler with its own bugs, quirks and wtfs

Re: Rust front-end merged in GCC trunk

#58

Post by rayiner »

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...

Because single implementation languages are toys. Any real language will have a multiplicity of implementations for different purposes. GCC has a ton of development resources behind it; processor makers are familiar with it and often turn to it to bring up new processors and ISAs, etc. Having a GCC front end is a big step in Rust becoming more popular as a systems language.

Re: Rust front-end merged in GCC trunk

#59

Post by pornel »

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...

FSF wants to support Rust as a first-class language in GCC, which means their own implementation and ability to bootstrap without dependence on other projects.

Having two independent implementations is good for finding code depending on compiler bugs. The development will also highlight where the Rust language is not documented/specified enough yet.

The GCC implementation may end up with a different design, and perhaps faster compile times, or at least we'll know whether Rust is inherently slow to compile, or is that just rustc. Rustc supporting multiple back-ends can't have as close integration with GCC's back-end as GCC's own front-end.

Re: Rust front-end merged in GCC trunk

#60

Post by bayindirh »

mustache_kimono wrote: post #54
bayindirh wrote: post #43

Earlier quoted context omitted.

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. I'm not using (even avoiding) LLVM based toolchains, and not touching Rust even with a 100 foot pole because of that. I'm interested in this. Could you elaborate on why you are not using Rust? Because there is no competition in the language, or because there is not an alternate compiler, or because you don't like LLVM?

It's mostly a personal choice. Any piece of software I write is opened up, and licensed with GPL.

I don't want my software dependent on a non-GPL toolchain to ensure its long term sustainability. I also try to choose GPL licensed libraries, and include everything required to build my code (incl. external libraries) inside my repository.

In the end I want someone to be able to just clone the repo, and run make, or GCC, or what it needs to be run. So, the code is just dependent on the compiler and its standard libraries when obtained by someone.

Lastly, I find LLVM's supporters and general ecosystem slightly hostile towards GCC, and want to replace it anywhere and everywhere possible. I'm a free software advocate, and I prefer LLVM and GCC just to be interchangeable.

Hence I only use languages which GCC supports exclusively or has GPL compilers/interpreters. Working on HPC makes this easier for me.

Post reply on HN