GCC Rust Approved by Steering Committee, Beta Likely Next April (phoronix.com) 51
Phoronix reports:
The GCC Steering Committee has approved of the GCC Rust front-end providing Rust programming language support by the GNU Compiler Collection. This Rust front-end will likely be merged ahead of the GCC 13 release next year.
The GCC Steering Committee this morning has announced that the Rust front-end "GCC Rust" is appropriate for inclusion into the GCC mainline code-base. This is the effort that has been in the works for a while as an alternative to Rust's official LLVM-based compiler. GCC Rust is still under active development but is getting into shape for mainlining.
The hope is to have at least "beta" level support for the Rust programming language in GCC 13, which will be released as stable around April of next year.
The GCC Steering Committee this morning has announced that the Rust front-end "GCC Rust" is appropriate for inclusion into the GCC mainline code-base. This is the effort that has been in the works for a while as an alternative to Rust's official LLVM-based compiler. GCC Rust is still under active development but is getting into shape for mainlining.
The hope is to have at least "beta" level support for the Rust programming language in GCC 13, which will be released as stable around April of next year.
Probably should have been a linux rust prereq (Score:5, Insightful)
It arguably doesn't make sense to use Rust in Linux until gcc can compile it. I'm not saying any license prohibits it, but it seems to somewhat defeat the purpose of using the GPL if you can't use a GPL'd compiler to compile the sources.
Re: (Score:2)
It will make tooling easier but also llvm may provide better object code for a while.
The Zig people are doing some cool language-fluid things leveraging llvm flexibility.
I wouldn't mind seeing Zig kernel modules either. Their principles are good for security.
Re: (Score:3)
Pretty much, yes. Also makes Rust a bit more professional (which is clearly needed) bu providing a 2nd source for a compiler.
Re: (Score:2)
I always compile C++ I write on at least 2 versions of gcc seperated by a good few years and clang because its amazing how some compiler versions won't pick up coding errors even with -Wall -Wextra -pedantic given and also the differences in behaviour under optimisation (often caused by a program bug, not a compiler one).
Re: (Score:3)
While I do not use C++ (looked at it around 20 years ago, found the design to be pretty bad and hard to remember), this is interesting. Is your take that at the root of this are bugs, a too complex standard, changes in the standard or something else?
Re: (Score:3)
It's all of the above. C++ compilers issue more warnings because they get better at rejecting language constructs that are technically illegal, programming patterns that are hazardous in practice, and new language features. But most of the benefit of using compilers that are significantly different in age is to detect accidental uses of new or deprecated language features that limit the portability of the code.
Re: (Score:2)
But most of the benefit of using compilers that are significantly different in age is to detect accidental uses of new or deprecated language features that limit the portability of the code.
Good point. Although that reminds me a bit with the mess on the web, where some web sites do not work in standards conforming browsers because they only tested with some browsers in some versions. Just had to switch browsers for two (!) online shops because both were behaving erratically. (The art of giving good error messages also seems to be lost on the web completely.)
Re: (Score:2)
Well C++ is too syntatically complicated now but thats another argument. The main issue for me is that the gcc devs seem to constantly change what they consider to be syntatic errors/warnings or what the error level should be. Also some things that should be warnings seem to be missed entirely (eg unused variables) on certain versions of gcc though its improved again recently.
Re: (Score:2)
Ok, so apparently the problem is too fuzzily defined or too complex (and there are probably some big egos in the mix too). Will be interesting to see how much Rust on gcc suffers from this problem.
Re: (Score:2)
While I do not use C++ (looked at it around 20 years ago, found the design to be pretty bad and hard to remember)
Imagine if you'd devoted 6 months of that time to learning it properly...
Re: (Score:1)
While I do not use C++ (looked at it around 20 years ago, found the design to be pretty bad and hard to remember)
Imagine if you'd devoted 6 months of that time to learning it properly...
Nope. Absolutely no regrets. Learned Python instead. C++ is a mess and not fit to be used as a general-purpose language. Apparently it is not fit as a systems language either or it would have had some real success there. Of course, I learned OO with Eiffel, so I am a biased. Once you have seen it done right, wannabee attempts cannot impress you anymore.
Re: Probably should have been a linux rust prereq (Score:2)
Ironic you like Python then as its OO system is a dogs dinner dragged screaming from Perl. Having to use self. everywhere is a joke.
Re: (Score:2)
Ironic you like Python then as its OO system is a dogs dinner dragged screaming from Perl. Having to use self. everywhere is a joke.
And there you just outed yourself as being incompetent. Python (like Eiffel) uses "conform" inheritance. Requires a clue to understand it and experience to use it competently, but then it is by far superior.
Re: Probably should have been a linux rust prereq (Score:2)
Never heard of conform inheritence and neither has google. Pythons OO is snack ugly hack whatever made up phrase you want to use to describe it.
Re: (Score:2)
Having to use self. everywhere is a joke.
That is basically my only critics on Python.
The absurd thing is:
a) the python haters do not even know about it, they think "white space" is bad
b) you have to declare self as a variable/parameter in every method, and it can have any name you want. It is only by convention that everyone calls it "self"
Re: (Score:2)
White space with syntatic meaning is an extremely bad idea.
>It is only by convention that everyone calls it "self"
It doesn't matter what you call it. Having to reference all instance variables inside the instance with a prefix is assinine.
Re: (Score:2)
What would have been a less asinine way to distinguish use of an instance variable from use of a local variable or global variable?
Re: (Score:2)
Oh I dunno, use different names maybe?
Adding instance members after the fact (Score:2)
That'd be fine if the language provided tooling for editors to query what local variable names would and would not shadow member names at a given point in the source code. But with Python's ability to dynamically add a new member to an instance, I can't think of any way to prove that a name of a local variable of a method of a class happens to be different from the name of any member of any instance of that class that may exist.
Re: (Score:2)
Perhaps someone who isn't aware of what members exist in a class shouldn't write code to add members to it. Just a thought.
Re: (Score:2)
The methods of a class in Python are written by the author of the class. The extra members are added by users of the class. These are often different people.
Re: (Score:2)
Python libraries come as source code. They can view the damn code. And if python doesn't give errors if you try to duplicate a class variable or method then thats another failure of the language.
Re: (Score:2)
Using whitespace to change semantics [slashdot.org] is idiotic. [slashdot.org]
Re: (Score:2)
It does not change semantics.
That is the damn problem with you stupid ignorant idiots.
It defines semantic.
Re: (Score:2)
Found the amateur who thinks these define "different" semantics: (Hint: They DON'T.)
Whether that code block is aligned on column 1 or N does NOT change functionality.
Whether the code is indented or not does NOT change functionality.
Whitespace is for PEOPLE, not the compiler. As such, we optionally use EXTRA whitespace to communicate to OTHER programmers so that they can easily read blocks.
Python was designed
Re: (Score:2)
You answered to the wrong person.
However, I disagree.
While white space is designed for people: it makes perfectly sense to use it in the compiler, too. Hence we have Python, and millions of coders loving it.
Did you fail your parsing Comp. Sci class?
You never took one. Or why do you think I failed or not? Hm?
I suggest to read up about languages as simple as assembly, Fortran, and COBOL, and why whitespace is significant in those languages.
Sigh, the uneducated youth. Now get of my lawn. D^HU^HM^HB^HA^HS^HS^H
P
Re: Probably should have been a linux rust prereq (Score:2)
Speaking as someone who did spend the 6 months⦠itâ(TM)s still ugly as hell, even after youâ(TM)ve figured out how to deal with it. Just because I can now understand the convoluted syntax, doesnâ(TM)t make the syntax any less convoluted.
Re: (Score:2)
Speaking as someone who did spend the 6 months⦠itâ(TM)s still ugly as hell, even after youâ(TM)ve figured out how to deal with it. Just because I can now understand the convoluted syntax, doesnâ(TM)t make the syntax any less convoluted.
Thanks, that nicely validates my decision to not do it. Of course it gives you hard to acquire expert skills, so doing it may also have had benefits.
Re: (Score:2)
Imagine you come to a job interview and exclaim: "I devoted 6month to C++" ...
Re: (Score:2)
Re: (Score:2)
You seem to ignore the fact that zero part of Linux is written in Rust currently.
It's irrelevant to the point being made.
Why is your reaction to every Rust news as if Linux switched all source code to Rust overnight?
Mu. When did you stop beating your wife? [wikipedia.org]
Re: (Score:2)
It's irrelevant to the point being made.
What part of Linus and the developers are PLANNING to include it at a future date is not clear? No one has said Rust is ready to be part of Linux now. No one.
Mu. When did you stop beating your wife? [wikipedia.org]
You never addressed the point. Why is your point from the stance that Linux has already converted to Rust instead of the reality that zero part of the kernel is written in Rust currently. There is a lot of work that needs to be done and many steps need to be taken before Rust in Linux is a reality.
Your point is as idiotic as this:
Me: Next year, I plan
Re: (Score:2)
You just want to bitch about me bitching, so you've invented a way to be mad about it. Go ahead and be mad.
Re: (Score:2)
You just want to bitch about me bitching, so you've invented a way to be mad about it. Go ahead and be mad.
Again, I am pointing out how inane your complaint is: 1) Linus has said specifically that there were testing Rust in the future. They have not converted to Rust. 2) Linus does not control GNU. 3) There is a long way to go before Rust makes it part of Linux if ever. You don't want to acknowledge reality, that is on you.
Good. (Score:5, Insightful)
I don't care for Rust but have more than one compiler for a language is always a good thing. I hope the Rust committee decides to write a formal specification, so that this isn't eternally beta software that badly lags behind the official compiler.
Re: (Score:2)
I think this is less of an issue than might appear. While Rust does not have an official spec, it does have an official change management process. So, it's always clear what changes are about to happen to new versions of Rust well before they actually do.
And even where "copy the main compiler" is the only option, Rust uses a process where changes are released to nightly well before they are stabilized which they have to be enabled as a feature. In some cases, this happens years before the change is finally
Re: (Score:2)
Rust uses a process where changes are released to nightly well before they are stabilized which they have to be enabled as a feature.
Yeah, that's not a good thing. It should be proposed (with a working implementation), debated, made part of a specification, implemented using the specification, thoroughly tested, and only then should it be released.
Re: (Score:2)
Yeah, that's not a good thing. It should be proposed (with a working implementation), debated, made part of a specification, implemented using the specification, thoroughly tested, and only then should it be released.
Changes are proposed in an RFC which includes a specification for the change. The RFC gets accepted, following discussion. An implementation is produced, either after or in parallel to this process. At a certain point, the RFC and the implementation gets merged to nightly. At this point, any one is free to use it in their own code using nightly (with, of course, few forward compatibility guaranteed), so it can be tested. Features are bug fixed, or updated in an iterative process. Eventually, the "release" h
Re: (Score:2)
The important question is if after an implementation is available, can the RFC then later be rejected or even removed? There are some idea that look good on paper but once you actually get to use them then you realize they aren't what you hoped.
Anyway, I hope that the Rust STL utilizes feature testing and has alternative implementations that exclude specific features. Regardless, I do think that GCC Rust people should re-implement the Rust features and STL by using only the RFC specifications to ensure the
Re: (Score:2)
Yes, of course. That an implementation ends up on nightly and is made available as a feature is not guarantee that it will ever get merged to stable. Once on stable, of course, it's much harder to remove because of the forward compatibility guarantee. Breaking changes only happen on release of an edition (every 3 years). So it's a big thing.
GCC isn't going to implement the standard library anyway, so that's not so relevant. They aren't even going to re-implement all of the language independently. Things lik
Re: (Score:2)
I don't care for Rust but have more than one compiler for a language is always a good thing. I hope the Rust committee decides to write a formal specification, so that this isn't eternally beta software that badly lags behind the official compiler.
I don't car for rust, because the development environment is so bloody painful to use.
If they make GCC compile rust, then it might be less obnoxious to build and I will be forced to find things I don't like about the language itself.
Re: Good. (Score:2)
So use a different development environment? Rust supports many.
Re: (Score:2)
I'm talking about the (very very slow) compiler along with the byzantine file trees it makes along the way. Not some IDE crutch. The eye candy won't speed up the edit, compile, test cycle any to be any faster than the command line.
Can't help but increase use of the language (Score:5, Insightful)
If people will be able to compile rust out of the box on linux distros instead of having to manually install rustup and rustc which would probably end up in the "Can't be bothered right now" category for a lot of current C/C++ devs (whom Rust seems to be aimed at) then they'll be more inclined to give it a go.
gcc most likely also violating the rust trademark (Score:3)
the same logic that applies to debian's distribution of the existing rust compiler would also make distribution of gcc violate the Trademark owned by the Mozilla Foundation.
https://bugs.debian.org/cgi-bi... [debian.org]
Re: (Score:2)
Should Mozilla try to bully makers of actually compatible Rust compilers, that could be an early nail into Rust's coffin.
Re: (Score:3)
Mozilla don't own the trademark any more, I think. It's owned by the Rust Foundation.
The thread is worth reading. The bug report was marked as serious, but the first response is "I don't think it's a big deal".
Re: (Score:2)
Well, if this is only about naming, they can just label it with another ("IronOx", "FeO"), and mention it is supposed to be compatible.
Should Mozilla try to bully makers of actually compatible Rust compilers, that could be an early nail into Rust's coffin.
A rusty nail?
Re: gcc most likely also violating the rust tradem (Score:2)
On a related note, "feo" means ugly (and other negative connotations) in Spanish. It would not go unnoticed.
Re: (Score:2)
And MAME means SUCKS in Spanish, but it hasn't hurt the adoption rate of the emulator there.