GCC Rust Approved by GCC Steering Committee • Hacker News Board

Re: GCC Rust Approved by GCC Steering Committee

#141

Post by kragen » Mon, Jul 11, 2022, 6:56 PM UTC

dolni wrote: post #78

nicoburns wrote: post #75

Earlier quoted context omitted.

> free as in speech, not beer I can never remember which way around this is. I think the "beer" is supposed to be free in the monetary sense and "speech" is supposed to be free in the rights/liberty sense, but the analogy doesn't actually convey this: - Speech is normally both monetarily free and (in certain places) a right - Beer is normally neither monetarily free or a right. But may make you "feel" free, which is…

The first amendment to the US Constitution provides very strong protection for the right to free speech. Presumably that is the origin of "free as in speech".

Re: GCC Rust Approved by GCC Steering Committee

#142

Post by tomjakubowski » Mon, Jul 11, 2022, 6:58 PM UTC

zetaposter wrote: post #102

faisal_ksa wrote: post #98

What is the benefit of having multiple compilers for programming languages? Is there a scenario where a GCC compiled rust program would do something that an LLVM one can't do? Doesn't this cause fragmentation in the rust ecosystem? P.S.:I understand that people can work on any project they want. And I don't have the right to tell them not to. I'm just curious about the technical reasons for having multiple compilers.

1. GCC has more backends than LLVM. 2. Competition is good in general. 3. I expect this will trigger inconsistencies between GCC and rustc; because Rust doesn't really have a specification. Which will force both parties to discuss and solve them.

Being on gcc, a long-lived platform, also helps ensure the survival of the language even if development of the current compiler (or LLVM) dies or withers.

Re: GCC Rust Approved by GCC Steering Committee

#143

Post by not2b » Mon, Jul 11, 2022, 7:02 PM UTC

charcircuit wrote: post #120

sicp-enjoyer wrote: post #106

Earlier quoted context omitted.

One advantage is it forces the language to articulate standards instead of the implementation defining the feature set. Standards tend to give stability and longevity to the language, as well as making it possible to write new compilers and make it more portable.

That sounds a little circular. The benefit of alternate compilers is that it makes making alternate compilers easier. For stability compilers already have a large incentive not to break old programs. For longevity I don't really see how a standard affects it that much. For being more portable you do not need an entirely knew compiler.

The reason it isn't circular is that if there is one implementation, even with good documentation, there will inevitably be lots of corner cases where the implementation does something, but it isn't written down anywhere. Independent implementations will discover many of these issues and they get clarified as part of the standards process.

So you can't really produce a high quality standard with only one implementation. You'll miss important details.

Re: GCC Rust Approved by GCC Steering Committee

#144

Post by dagmx » Mon, Jul 11, 2022, 7:07 PM UTC

superkuh wrote: post #122

Hopefully this will slow down development of new Rust features to a reasonable pace. Instead of Rust devs writing code that requires a new compiler every 3 months it'll be more like every year or two. Almost useable.

This is an odd take that I feel is rooted in a misunderstanding.

rust intentionally has a fairly rapid release schedule, so that you don't end up with a big release every year that introduces several possibly breaking changes.

Features aren't randomly scheduled for each release. Instead each release is a snapshot of what's been stabilized by that point.

If you prefer some arbitrary concept of stability, then you can quite easily lock to any version of rust this far and ignore any new versions till something catches your fancy.

Re: GCC Rust Approved by GCC Steering Committee

#145

Post by pjmlp » Mon, Jul 11, 2022, 7:11 PM UTC

fweimer wrote: post #132

pjmlp wrote: post #72

Earlier quoted context omitted.

Yes, hence having its own column on cppreference, or a special flavour of bitcode for watchOS. In what concerns Apple, I think they mostly care about the C++ support needed to keep LLVM going, the C++14 based dialect for Metal Shading Language, and the subset used across IO and DriverKit. For everything else there is Objective-C and Swift. Then Google apparently drop off clang after the ABI break votes didn't went th…

On the GCC side, there are no plans to stop supporting building applications using Clang and libstdc++ (that is, using the libstdc++ installed headers and the GCC-built libraries/shared objects). Therefore, a question mark next to libc++ doesn't necessarily threaten the long-term viability of Clang as a C++ compiler. (I assume your Abseil comment is actually about libc++.)

My Abseil comment is about where Google now rather sees their employees spending time on C++ libraries for them.

At least from the comments I sometimes see flying by on Reddit.

Re: GCC Rust Approved by GCC Steering Committee

#146

Post by tialaramex » Mon, Jul 11, 2022, 7:14 PM UTC

pjmlp wrote: post #123

lenkite wrote: post #80

Earlier quoted context omitted.

Yep, the perma-frozen ABI decision sounded the death-knell for C++. Basically the committee committed collective hara-kiri with that decision. Thou Shalt Not Progress! It's so extraordinarily, mind-bogglingly stupid. But I guess it is time for the ageing C++ queen to pushed out of the mortal coil and let Princess Rust grab her long-overdue system crown.

Princess Rust has no proper throne on the kingdom of binary libraries.

Without ABI change C++ is trapped forever with bad decisions. In some cases these are decisions which were bad twenty years ago and are still bad today but should be fixed, in other cases these are decisions which were probably the right call twenty years ago but now you'd choose differently.

Did you know on MSVC a std::mutex is so huge it needs more than one cache line ? Obviously Microsoft aren't stupid, they know how to fix that... but it would change the ABI so they can't touch it.

And so the Zero Cost Abstraction promise "Don't pay more than it would cost if you did it yourself" becomes "Eh, just do it yourself" everywhere - C++ programmers learn to hand roll all the basic stuff they need, because ABI stability has ensured the standard library mechanisms are slow, or bloated, or both.

Re: GCC Rust Approved by GCC Steering Committee

#147

Post by marcodiego » Mon, Jul 11, 2022, 7:15 PM UTC

faisal_ksa wrote: post #98

What is the benefit of having multiple compilers for programming languages? Is there a scenario where a GCC compiled rust program would do something that an LLVM one can't do? Doesn't this cause fragmentation in the rust ecosystem? P.S.:I understand that people can work on any project they want. And I don't have the right to tell them not to. I'm just curious about the technical reasons for having multiple compilers.

It instantly inherits support for all OS's and architectures GCC support plus a lot of optimizations and debug information.

Re: GCC Rust Approved by GCC Steering Committee

#148

Post by colejohnson66 » Mon, Jul 11, 2022, 7:18 PM UTC

rayiner wrote: post #99

colejohnson66 wrote: post #13

Earlier quoted context omitted.

At a high level, GCC and LLVM are divided into two ends: the front and the back. The front end takes the source code and turns it into some form that's language agnostic (e.g. LLVM bitcode). The back end takes those structures and turns it into machine code. This allows the compiler to be modular. Old compilers didn't use this concept. So a C->x86 compiler and a Fortran->x86 one couldn't share code as easily. And if…

How “old” are we talking about here? Multiple language front ends sharing a common IR is a concept that dates to the 50s: https://academic.oup.com/comjnl/article/22/3/226/408542 (click through to the pdf)

Being a concept and having papers written about it doesn't imply an actual implementation

Re: GCC Rust Approved by GCC Steering Committee

#149

Post by kangalioo » Mon, Jul 11, 2022, 7:18 PM UTC

klez wrote: post #31

fbanon wrote: post #4

Quoted post unavailable.

Care to elaborate?

Maybe referring to the fact that GCCRS duplicates a ton of effort by reimplementing the frontend (parser, borrow checker, error messages etc.) for questionable benefit since you could keep the existing frontend and just swap out the LLVM backend for GCC (as done by the rustc_codegen_gcc project).

Re: GCC Rust Approved by GCC Steering Committee

#150

Post by duckerude » Mon, Jul 11, 2022, 7:19 PM UTC

tomjakubowski wrote: post #142

zetaposter wrote: post #102

Earlier quoted context omitted.

1. GCC has more backends than LLVM. 2. Competition is good in general. 3. I expect this will trigger inconsistencies between GCC and rustc; because Rust doesn't really have a specification. Which will force both parties to discuss and solve them.

Being on gcc, a long-lived platform, also helps ensure the survival of the language even if development of the current compiler (or LLVM) dies or withers.

Does it? GCC's Java frontend died and is no longer shipped, they need maintainers like any other compiler.