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

171–180 of 300 posts

Re: GCC Rust Approved by GCC Steering Committee

#171

Post by cogman10 »

jerf wrote: post #104
cogman10 wrote: post #76

Earlier quoted context omitted.

I don't think these limitations are ones that really impact hardware all that much. It wouldn't be impossible to create hardware with the concept of "infinite registers" that ultimately gets optimized away. (see: Mill CPU) The bigger issue (IMO) is that the IR for compilers tends to evolve rapidly while hardware is stuck in the mud. Moving the problem of finalizing the IR into the hardware will effectively make it so…

" 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 into their proprietary ecosystem or into an open ecosystem where they have a large say.

I had hoped that SPIR-V would be a good inroad to start fixing some of these problems, but alas, it seems like Apple and nVidia aren't big fans. It's early still, though, so maybe that changes?

Re: GCC Rust Approved by GCC Steering Committee

#172

Post by zokier »

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.

One big benefit in this case is that bootstrapping gcc is somewhat easier than rustc, and presumably gcc-rust can then be used to compile rustc if needed.

Re: GCC Rust Approved by GCC Steering Committee

#173

Post by 3836293648 »

potatochup wrote: post #27
lmkg wrote: post #7

Earlier quoted context omitted.

The main source of interest for GCC Rust is because GCC targets more platforms than LLVM. A partially-overlapping interest is using Rust in Linux: Linux targets non-LLVM platforms, but is also deeply tied to GCC and Rust-for-Linux would have a lower barrier to entry if it doesn't require a second toolchain. Long-term, it's considered a strong signal for the health and viability of Rust if it's not strictly tied to on…

Yup. We have microcontrollers that we'd like to write rust on, but we can't because llvm doesn't support the architecture.

But that's not an argument for GCC-RS, that's an argument for rustc_codegen_gcc. The purpose of GCC-RS is a) licensing and b) fracturing the community to stabilise the language spec, something I'm very doubtful over for at least a few more years.

Re: GCC Rust Approved by GCC Steering Committee

#174

Post by cmurf »

Beltalowda wrote: post #163
atonse wrote: post #154

Earlier quoted context omitted.

There are probably even fewer people that know what right to repair is. Free software just isn’t enough anymore because the licenses limit your freedom too. (and even my choice of the word “limit” here will be controversial between the Apache/MIT and the *GPL crowds). Don’t have an easy answer :-)

Right to repair has been all over the news, including mainstream news, and least in tech circles it's fairly well known. And while there are undoubtable many people who don't know what it means, the basic idea is quite obvious from just those three words: "if I bought something, I should have the ability to repair it". The problem is that merely right to repair doesn't cover all of Free Software so it will never catc…

Do many/most people really think they should have the ability to repair it? I'm not sure because they keep buying products where it's expressly not possible to repair it yourself or by a competent 3rd party.

So I'm not really sure it has any more meaning than free software means no cost rather than "no one and everyone owns the software".

Re: GCC Rust Approved by GCC Steering Committee

#175

Post by genewitch »

duckerude wrote: post #150
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.

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

GCJ is no more? It was being used within recent memory for things, i thought.

I am out of the loop though, so if this is true, that's interesting and a bit weird.

Re: GCC Rust Approved by GCC Steering Committee

#176

Post by pornel »

j16sdiz wrote: post #140

The rust borrow checker is under-specified (for a good reason). Can forsee lots of incompatible with two implementation

It won't be. They plan to use the exact same code!

Rust is designed to compile fine without any borrow checking (it reduces it to the C level of safety, but valid programs generate valid code).

GCC will compile itself without a borrow checker. Then it will compile the existing borrow checker written in Rust, and then recompile itself with borrow checking.

Re: GCC Rust Approved by GCC Steering Committee

#177

Post by nequo »

hedora wrote: post #96
outside1234 wrote: post #2

Why would someone want this? (Honest question)

Competition. GCC had laughably bad error messages before LLVM caught on. Even then, LLVM generated terrible code compared to GCC. There's a similar competition going on with open source linkers (which are finally going multi-threaded). Both compiler toolchains currently blow pre-LLVM GCC out of the water (and GCC development has noticeably accelerated since LLVM came out). I'm not sure which one is better at which C+…

Similar story to Vim/Nvim and maybe partly OpenSSL/LibreSSL. Forking (not all technically forking) is good sometimes.

Re: GCC Rust Approved by GCC Steering Committee

#179

Post by maxwell86 »

dleslie wrote: post #8

This is great! Gcc support opens up more platforms, more targets, and the opportunity to more easily integrate with the various common embedded toolchains that are built around gcc. And it's free software, for those that care, this matters.

The rust compiler can already use GCC as a backend. So I don't see how this opens more platforms than that.

Re: GCC Rust Approved by GCC Steering Committee

#180

Post by maxwell86 »

marcodiego wrote: post #147
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.

Rust already has a GCC backend that can do all that.

This post is about a new front-end.

Post reply on HN