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

71–80 of 135 posts

Re: Rust front-end merged in GCC trunk

#71

Post by rayiner »

3836293648 wrote: post #69
rayiner wrote: post #58

Earlier quoted context omitted.

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.

This simply isn't true. Only C/C++ people have ever cared about having multiple implementations and have to cling to the catastrophe that those two standards are because of it.

Oh, “only C/C++ people.” I.e. the people who wrote almost all the systems code in the last 40 years. Just those people.

Re: Rust front-end merged in GCC trunk

#72

Post by mustache_kimono »

bayindirh wrote: post #62
mustache_kimono wrote: post #56

Earlier quoted context omitted.

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

> Yeah, it's not like Google (and dozens of others) has an internal fork of Linux... Doesn't matter for completely internal stuff. My concern is public code requiring non-public toolchains to compile. I have experienced this enough during the decades. I don't want to fight with this again. Google doesn't want to touch Linux for their devices anymore, so they're building Fuchsia, but let's not digress... > Multiple co…

> What GPL brings to the table is strict openness, not compatibility.

I kinda wonder where this has been an issue with LLVM re: non-public toolchains, and public code where it wouldn't also be an issue with GCC. FWIW I definitely could see it being an issue in HPC/graphics/ML.

> I also wonder whether people would be this reactive to this issue if $company announced a closed source compiler with strict rustc compatibility.

Call me dense -- I guess I don't understand precisely what you're getting at. I don't think anyone would use a closed source compiler with strict rustc compatibility without a pretty big carrot. I think the issue here is strictly compatibility/divergence. Although I'm personally less of a fan of GCC/GPL/FSF, I think a new compiler is great so long as it doesn't (completely) ruin some of the nice things about a single implementation system, and why rust_codegen_gcc seems much more appealing.

Many Rust people don't want to live in the C/C++ compiler world, because they don't have to. "Oops this code won't build with GCC" is a battle they'd just as soon avoid.

Re: Rust front-end merged in GCC trunk

#73

Post by rob74 »

3836293648 wrote: post #69
rayiner wrote: post #58

Earlier quoted context omitted.

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.

This simply isn't true. Only C/C++ people have ever cared about having multiple implementations and have to cling to the catastrophe that those two standards are because of it.

The catastrophe was that the C/C++ specification left too many things open for interpretation. Regarding "Only C/C++ people": there is at least one more language (Go) that has two implementations (the gc compiler and a gcc backend).

Re: Rust front-end merged in GCC trunk

#74

Post by eloff »

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.

That could be a feature. I'm making a joke, but it would be tempting sometimes when the program is correct but the borrow checker can't figure that out. The borrow checker and I don't get along all that well, even two years into the relationship.

Re: Rust front-end merged in GCC trunk

#75

Post by gardaani »

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

It's certain that there will be fragmentation. There isn't any gnu project, which hasn't added its own extensions to standards or specs. Few examples: gcc front end for C/C++, bash, grep..

It means that crates.io will have crates which compile only with gcc and its extensions.

Re: Rust front-end merged in GCC trunk

#76

Post by sseagull »

thesuperbigfrog wrote: post #52
sseagull wrote: post #35

Earlier quoted context omitted.

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

Standards are necessary and help of course. But the real power always lies with the implementations. There is no compliance without enforcement.

For example, C++ has a standard, but compliance is all over the place. Even Fortran has the same problem. The web also had a standards body (W3C) but eventually that was completely ignored and became irrelevant.

Re: Rust front-end merged in GCC trunk

#77

Post by shakow »

rayiner wrote: post #58
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.

> Because single implementation languages are toys

‶Toys″ like Go, OCaml, arguably Ruby & PHP, Perl, Erlang, Kotlin, ...

Re: Rust front-end merged in GCC trunk

#78

Post by hgs3 »

stingraycharles wrote: post #24
sp1rit wrote: post #11

Does this mean I can now finally generate object files from .rs sources and link them myself? That is one of the things that rustc is severely lacking.

Out of curiosity, why would you need this?

You're basically asking why you'd want object files. They're a container of (usually) relocatable machine code. You can inspect or modify them with nm [1] or objcopy [2]. You can link them with object files generated from other programming languages to mix languages. Maybe you have a custom linker or environment that requires you to convert an ELF or COFF object file to some custom variant. There are lots of reasons.

[1] https://linux.die.net/man/1/nm

[2] https://linux.die.net/man/1/objcopy

Re: Rust front-end merged in GCC trunk

#79

Post by stefantalpalaru »

shakow wrote: post #77
rayiner wrote: post #58

Earlier quoted context omitted.

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.

> Because single implementation languages are toys ‶Toys″ like Go, OCaml, arguably Ruby & PHP, Perl, Erlang, Kotlin, ...

> ‶Toys″ like Go

https://gcc.gnu.org/onlinedocs/gccgo/

Re: Rust front-end merged in GCC trunk

#80

Post by bayindirh »

shakow wrote: post #77
rayiner wrote: post #58

Earlier quoted context omitted.

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.

> Because single implementation languages are toys ‶Toys″ like Go, OCaml, arguably Ruby & PHP, Perl, Erlang, Kotlin, ...

Go has a GCC implementation (which I use).

PHP has alternative VMs and specialized servers for serving it fast and in encrypted manner (they are closed sourced), tho.

Kotlin runs on JVM, which has at least three fully compliant implementations.

Erlang is a specialized language and telecommunications platform. It’s something different.

Post reply on HN