Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC Rust Approved by GCC Steering Committee

gcc.gnu.org

Post reply on HN
Print view View original

201–210 of 300 posts

Re: GCC Rust Approved by GCC Steering Committee

#201

Post by superkuh »

dagmx wrote: post #144
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…

This is the perspective of a developer. I am trying to explain the perspective of an open source desktop user who's ran into the backwards incompatibility in 4 out of 5 rust tools I've attempted to compile for use.

The Rust language is fine. Great, even. Most Rust devs are bleeding edge types that always use the latest features. Hopefully this changes as Rust matures.

Re: GCC Rust Approved by GCC Steering Committee

#202

Post by pjmlp »

apple4ever wrote: post #196
tomjakubowski wrote: post #142

Earlier quoted context omitted.

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.

GCC support of Objective-C is very very poor.

It is at the level NeXT was forced to contribute back to upstream.

Re: GCC Rust Approved by GCC Steering Committee

#203

Post by pjmlp »

trimir2022 wrote: post #130
charcircuit wrote: post #120

Earlier quoted context omitted.

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.

Being able to specify a language outside an implementation is extremely useful to prevent hidden logical inconsistencies between different parts of the language, and makes the language more robust. It also allows people to design new backends (looking at CUDA LLVM backends)by finding out the right abstraction to support performance. For example, implementing a C or C++ compatible CUDA backend required the C++ committ…

Actually it was the other way around, CUDA was fixed to follow C++11 memory model.

There are a couple of CppCon talks on the subject.

Re: GCC Rust Approved by GCC Steering Committee

#204

Post by pjmlp »

steveklabnik wrote: post #134
ithkuil wrote: post #133

Earlier quoted context omitted.

Why do libraries not work across compilers of the compilers are implementing a standard? Are they perhaps not really implementing a standard?

Simply having a document called "a standard" doesn't mean that: 1. the standard covers everything you wished it would cover 2. every implementation implements the standard, with no bugs 3. the standard doesn't itself contain incoherent or contradictory things Standards are a tool, not magic interoperability sauce.

Hence the existence of standard certification for compilers as business.

Re: GCC Rust Approved by GCC Steering Committee

#205

Post by pjmlp »

ATsch wrote: post #127
daptaq wrote: post #103

Earlier quoted context omitted.

Doesn't GCC support more architectures than LLVM? Wasn't that the issue a while back with the Rust dependency that a cryptography module for Python introduced?

Adding a GCC backend for Rust (rust-codegen-gcc) does this already. I do not personally see the point of writing another frontend in C++.

Dependency on an existing Rust compiler during GCC bootstrap process.

Re: GCC Rust Approved by GCC Steering Committee

#206

Post by [deleted] »

mbStavola wrote: post #199

I have mixed feelings about the idea of a GCC frontend for Rust. On one hand, having frontend diversity for a language helps bring new people into the language; think of the groups who can't use Rust because it doesn't support certain targets or can't integrate with their existing toolchain. There is a lot of talent that could be brought into Rust just by virtue of them being able to be included and the less barriers…

[deleted]

Re: GCC Rust Approved by GCC Steering Committee

#207

Post by pjmlp »

cogman10 wrote: post #171
jerf wrote: post #104

Earlier quoted context omitted.

" Even then, while access to GPGPUs is now pretty much universal, GPGPU programming still feels like it is in the stone ages. Despite being a thing for over 10 years." I'd be interested in reading an article from someone who has been doing it for 10 years as to why that is the case. I have theories but nowhere near enough direct experience to evaluate. (My hypothesis is that the extreme parallelism makes it so very t…

My hypothesis is more cynical. We have 4 major GPGPU manufactures (Apple, Intel, AMD, nVidia) and none of them want to make creating an open standard easy. There is no reason why nVidia should support OpenCL the same way that AMD does, they want people to write CUDA. There's no reason for Apple to support OpenAAC like Intel does, they want people to write Metal... etc. These 4 companies are trying to push everyone in…

AMD and Intel don't care enough about OpenCL to actually provide the same tooling and libraries that CUDA does.

OpenCL 2.x was a failure, hence why OpenCL 3.0 is basically 1.2 with everything else from 2.x marked as optional.

Re: GCC Rust Approved by GCC Steering Committee

#208

Post by akoster »

Great news! Hopefully this means that Rust will now support GCC's supported architectures [0] in addition to their own quite impressive and continuously improving list [1] [2], including those that are less popular these days. I hope this will directly help issues experienced by the Debian Ports project [3] [4], Gentoo Linux [5] [6], and possibly Alpine Linux [7] and NetBSD [8].

[0] https://gcc.gnu.org/backends.html

[1] https://doc.rust-lang.org/rustc/target-tier-policy.html

[2] https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

[3] https://web.archive.org/web/20220223133124/https://people.gn...

[4] https://lwn.net/Articles/771355/

[5] https://news.ycombinator.com/item?id=26097153

[6] https://news.ycombinator.com/item?id=26203853

[7] https://wiki.alpinelinux.org/wiki/Architecture

[8] https://www.netbsd.org/ports/#ports-by-cpu

Re: GCC Rust Approved by GCC Steering Committee

#209

Post by cozzyd »

steveklabnik wrote: post #198
cozzyd wrote: post #82

Earlier quoted context omitted.

The vendor sometimes does this and GCC is much more standard in the embedded space. And crucially, it's required to be open source. For example, for arm-none-eabi, ARM provides a GCC toolchain ( https://developer.arm.com/Tools%20and%20Software/GNU%20Toolc... ) but makes you purchase the LLVM-based one ( https://developer.arm.com/Tools%20and%20Software/Arm%20Compi... ). Now I'm fairly certain there's an open-source wa…

Where's the "purchase" part there? I see a download link, and it seemed to download the toolchain? I don't have any projects lying around to actually try it out, but it looks complete? I briefly looked at the license and it seems that if you're getting it for free, then its all good, you just get no support. (I only write Rust on ARM and so am unfamiliar with the various toolchains they offer, honestly.)

Ah, ok I saw this table: https://i.imgur.com/5ofzjC3.png and that trying to download required an account (which is not true for the GCC toolset) and assumed they'd make you pay something. But maybe they just try to trick you into thinking you might have to... (or I am easily fooled).

edit: My legalese is not great, but isn't the the license saying that you can't legally distribute software compiled with the LLVM-based ARM tools if you obtained it for free? Obviously the gcc-based tools can't have such restrictions.

    3.2 NON-COMMERCIAL USE AND FREE OF CHARGE LICENSES: 
     ...
    (b) if you are receiving a Non-Commercial Use License or version (as applicable) of the Arm Tools: 
    (i)  you and your Permitted Users may use the Arm Tools for internal use only; and 
    (ii)  you are not permitted to distribute or sub-license (A) any part of the Arm Tools, or (B) Your Software,
          Your Hardware, or Your Reports developed under this License using the Arm Tools. The Arm Tools shall be
          used only by you and your Permitted Users, and you shall not (except as otherwise authorised in writing by Arm) 
          allow any other third party whatsoever to use the Arm Tools. 

    For the avoidance of doubt, if you are receiving a Non-Commercial Use License and the license is provided to you free of
    charge, the restrictions in both sub-clauses (a) and (b) above will apply to your use of the Arm Tools.
additional edit:

Here's what happens when I try to run armclang:

     $ armclang
     armclang: error: Failed to check out a license.
     The license file could not be found. Check that ARMLMD_LICENSE_FILE is set correctly.
I did not bother to figure out if there's a way to get a license without paying (though I would likely qualify for a non-commercial license as an academic user, but it seems like a pain).

Re: GCC Rust Approved by GCC Steering Committee

#210

Post by mcdonje »

mbStavola wrote: post #199

I have mixed feelings about the idea of a GCC frontend for Rust. On one hand, having frontend diversity for a language helps bring new people into the language; think of the groups who can't use Rust because it doesn't support certain targets or can't integrate with their existing toolchain. There is a lot of talent that could be brought into Rust just by virtue of them being able to be included and the less barriers…

Pretty sure you have it backwards. GCC isn't going to be a front end for rust; rust is going to be a front end for GCC. As I understand it, the point of both GCC and LLVM are to handle those implementation specific behaviors so programming language developers don't have to handle that concern. I don't expect this to fracture the language, but simply to provide the ability to use the language in more places.
Post reply on HN