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

61–70 of 135 posts

Re: Rust front-end merged in GCC trunk

#61

Post by bayindirh »

hardware2win wrote: post #57
bayindirh wrote: post #51

Earlier quoted context omitted.

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

> I dont think it is valid concern in $currentYear

I don't care about $currentYear. My concern is about $nextDecade earliest, and future doesn't look bright from my perspective.

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

A foundation created by Microsoft for a Microsoft's cash cow language on Microsoft's OSS entanglement platform. Yes.

> but also it is oss.

I'm not talking about OSS, I'm talking about Free Software.

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

This is not what happened with clang vs g++/gcc. Also we have Intel's, Microsoft's and Portland groups compilers side by side for decades.

> 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

I prefer implementing language correctly in a compiler to force others to the same, spec-compliant behavior.

Otherwise compilers and languages divert, and lack of alternatives make everything much more complicated in the long run.

Re: Rust front-end merged in GCC trunk

#62

Post by bayindirh »

mustache_kimono wrote: post #56
bayindirh wrote: post #51

Earlier quoted context omitted.

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…

> 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 compilers and "competition" doesn't solve compatibility. It makes it more difficult. Although I'm sure there will be benefits, I'm not certain GPL will make compatibility easier. It hasn't so far.

What GPL brings to the table is strict openness, not compatibility. I can share my code and say that "It builds right on this $GPLd_Compiler", and people can get it and build it. This is what I like to bring to the table for anything I release.

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

Re: Rust front-end merged in GCC trunk

#63

Post by tuetuopay »

GrayShade wrote: post #34
tuetuopay wrote: post #31

Earlier quoted context omitted.

This can be very useful for platforms where rustc is not available due to LLVM not supporting them. Take a project, build it with rustc, and if it builds, you know it passes the borrow checker. It is then safe to build it for your actual target with gcc. This would limit the outcry when some software adds a dependency on Rust, like the python crypto thing of a few years back, or the Linux kernel.

Why not use this instead? https://github.com/rust-lang/rustc_codegen_gcc

This will still use the official rustc frontend. For what I described above, this is not an issue, it would totally work. However, there are cases where having a pure gcc implementation (frontend + backend) is beneficial.

As others have mentioned, vendors have the standard practice to fork gcc for their hardware, but not necessarily rustc nor libgcc used by rustc_codegen_gcc. This means that rust will be possible on those platforms for free thanks to gcc-rs.

Another point is the bootstrapping of the compiler. rustc has a quite complex bootstrap process that depends on python, while afaik gcc only relies on shell scripts. It is much easier to port gcc than rustc to a new host platform. This is useful when you want to compile code directly on your target and don't want to rely on cross compilation. cross compiling is a tricky thing to do, and while rust fares pretty well there, as soon as it uses native C libraries, it all falls apart (e.g. try cross compiling a project that has dependencies on libss, libpq and the like). In such case, native compilation may be the only viable option. And most of the times, GCC is the first thing to be ported, so you would not need to wait for a rustc port.

Re: Rust front-end merged in GCC trunk

#64

Post by gpderetta »

hardware2win wrote: post #57
bayindirh wrote: post #51

Earlier quoted context omitted.

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

It is already a concern with, for example, clang.

Re: Rust front-end merged in GCC trunk

#65

Post by hardware2win »

bayindirh wrote: post #61
hardware2win wrote: post #57

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

> I dont think it is valid concern in $currentYear I don't care about $currentYear. My concern is about $nextDecade earliest, and future doesn't look bright from my perspective. > Nowadays languages like e.g c# are partially created by community and foundations (.net foundation) on github A foundation created by Microsoft for a Microsoft's cash cow language on Microsoft's OSS entanglement platform. Yes. > but also it…

>This is not what happened with clang vs g++/gcc. Also we have Intel's, Microsoft's and Portland groups compilers side by side for decades.

What? Cpps ecosystem is the most developer hostile ecosystem that Ive ever used

I wouldnt want to write in it even if my salary was multiplied by 1.5

A lot of compilers where all of them have different lang. features implemented, various bugs, quirks, wtfs, various perf. characteristics (e.g intel's generating faster code)

Long as hell compilation times. This is fundamental problem yet still that diversity didnt manage to solve it

Many package managers

And mediocre lang by modern standards on top of that. Minefield++ would fit it better.

>Otherwise compilers and languages divert, and lack of alternatives make everything much more complicated in the long run.

Theres still competition between langs

I bet Rust helped cpp improve more than gcc clang diversity

I also dont fully understand why you treat lang as a standard instead of product

Re: Rust front-end merged in GCC trunk

#66

Post by amaranth »

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.

This is eventually going to be a feature-complete compiler, targeting a specific rustc version. I believe the plan is to use polonius [1], presumably as an "optional" feature so they can build a stage 1 without it, use that to build polonius, then build the final compiler with it included.

[1] https://github.com/rust-lang/polonius

Re: Rust front-end merged in GCC trunk

#67

Post by ptx »

hardware2win wrote: post #50
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…

Counter example: .net c# One compiler for 99%, one package manager, one base classes liberary, one cli, etc.

One Microsoft Way.

Re: Rust front-end merged in GCC trunk

#68

Post by bayindirh »

hardware2win wrote: post #65
bayindirh wrote: post #61

Earlier quoted context omitted.

> I dont think it is valid concern in $currentYear I don't care about $currentYear. My concern is about $nextDecade earliest, and future doesn't look bright from my perspective. > Nowadays languages like e.g c# are partially created by community and foundations (.net foundation) on github A foundation created by Microsoft for a Microsoft's cash cow language on Microsoft's OSS entanglement platform. Yes. > but also it…

>This is not what happened with clang vs g++/gcc. Also we have Intel's, Microsoft's and Portland groups compilers side by side for decades. What? Cpps ecosystem is the most developer hostile ecosystem that Ive ever used I wouldnt want to write in it even if my salary was multiplied by 1.5 A lot of compilers where all of them have different lang. features implemented, various bugs, quirks, wtfs, various perf. characte…

C++ is an old language, and may not be evolved the best way possible, because it set the path, didn't follow a trail opened by another language.

The ecosystem's state is different depending on your perspective and what you are trying to achieve with it. While C++ is touted as a general purpose language, it's overkill for most of today's tasks. I use C++ to write high performance and low level code. It's my favorite language to work with, but I'm not using it blindly for everything.

As a person who worked with C++ a lot, and still developing something (which I'll eventually open source) for almost a decade, I can say that most of the things you say are not completely correct.

> different lang. features implemented, various bugs, quirks, wtfs, various perf. characteristics...

You can opt to not use any of the compiler extensions and have a completely portable code. Said code compiles in GCC, LLVM on macOS and possibly in MSVC, and uses CPU at its highest potential (verified on Linux with perf, in turn verified by timing on macOS). Intel's compiler creates fast code for Intel's processors, but it needs intel's patched libraries, etc. It's not worth it most of the time, and GCC already creates pretty fast code. In my discipline compiler cross-compatibility is king. So Intel's is not that important for our case.

> Long as hell compilation times. This is fundamental problem yet still that diversity didnt manage to solve it.

You can re-compile only the changed parts in any compiler for ages. This shaves a lot of time from compilation and linking times. Again this is neither novel, nor new.

> Many package managers

The idea of packages born with Java for enterprise software and became ubiquitous after that. Languages have their own package managers to prevent this, but it doesn't always work. Having an "official" package manager doesn't prevent from bringing in a "New and Improved (TM)" package manager to the ecosystem. Also, Rust is a young language. C++ is well, 35 years old? It's inevitable that we have better solutions for the issues we have at hand.

> And mediocre lang by modern standards on top of that. Minefield++ would fit it better.

It's a language with unfettered low level access. It's a sharp knife (or fighter jet). Learn how to handle it, and it won't bite. It's never guaranteed to be fluffy like Go, Python or memory-safe (to a point) like Rust by adding hard barriers.

On the other hand, being semi-conscious about what you're doing prevents 99% of the problems in C++. Said code had memory leak once, during initial development, and fixed on the spot (I test my code with Valgrind), and is memory-sane since that day. That code is not something simple. It's a scientific application which makes your cores and memory controller saturate. It takes every bit of performance offered by your system and converts into science.

> Theres still competition between langs

Yes, but that's another matter, which is not subject of this discussion.

> I also dont fully understand why you treat lang as a standard instead of product.

Because a language is a language. Not different from mathematical notation or human language. Compiler is the product, which transpiles that language to another language (incl. machine code) to run on your PC, mouse, microwave or plant based biologic computer. Compiler is the product. Language is just a language. Sets of rules, a standard even (like C++ is an ISO standard).

Re: Rust front-end merged in GCC trunk

#69

Post by 3836293648 »

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.

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.

Re: Rust front-end merged in GCC trunk

#70

Post by 3836293648 »

JoshTriplett wrote: post #36
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

The gccrs developers have talked at length with Rust developers towards the same aim: they don't want to create fragmentation either. Among other things, the gccrs developers have said in multiple places both public and private: - They aren't going to fork or extend the language; they'll work with the normal Rust language evolution process. - They're treating rustc as the reference for correct Rust. This doesn't mean…

They don't have to extend the language to create fragmentation. Being far enough behind rustc is enough
Post reply on HN