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

271–280 of 300 posts

Re: GCC Rust Approved by GCC Steering Committee

#271

Post by dolni »

kragen wrote: post #141
dolni wrote: post #78

Earlier quoted context omitted.

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".

No, the idea of freedom of speech predates the US Constitution, by decades, centuries, or millennia, depending on your definition: https://en.wikipedia.org/wiki/Freedom_of_speech#Origins https://en.wikipedia.org/wiki/Freedom_of_thought#/media/File... https://en.wikipedia.org/wiki/Freedom_of_thought#History_of_... https://en.wikipedia.org/wiki/Areopagitica https://en.wikipedia.org/wiki/Freedom_of_the_press#History htt…

Do you think that the free software movement would have adopted "free as in speech" if the US was hostile to free speech?

Re: GCC Rust Approved by GCC Steering Committee

#272

Post by sicp-enjoyer »

shakna wrote: post #251
chlorion wrote: post #230

Earlier quoted context omitted.

Yup I have had the same exact experience with Common Lisp and every time somebody talks about standardization being so great I think back on this. Scheme is suffering from the same issues. Scheme is standardized, but implementations end up being incompatible with each other in subtle ways and the level of fragmentation is very painful. Scheme does get some updates unlike CL I guess, but all of the implementations eit…

> I would much rather have no standard at all, and a single high quality implementation that everyone targeted instead of the current mess for both CL and Scheme. That would be Chez Scheme [0], maintained actively by Cisco, a company that you may have heard of - who also use the language extensively. Racket is porting to using Chez, because it is the industry standard, it's performant, and rock solid. The GNU alterna…

> Racket is porting to using Chez,

I think it already happened in 8.0

Re: GCC Rust Approved by GCC Steering Committee

#273

Post by nickitolas »

dleslie wrote: post #197
maxwell86 wrote: post #179

Earlier quoted context omitted.

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

Because that doesn't use the GCC frontend interface, requiring build tools and embedded toolchains to be modified to understand the rust compiler interface. By using GCC it's just another language that the existing toolchain can understand.

So it's not about platform support, but about toolchain integration? Who benefits from that, projects using C/C++ who want to use a rust library? Or is it about distro package maintainers?

Re: GCC Rust Approved by GCC Steering Committee

#274

Post by nickitolas »

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.

> 1. GCC has more backends than LLVM

Did you mean target platforms? If so, how is this not already addressed by the rustc gcc (Via libgccjit) backend?

Re: GCC Rust Approved by GCC Steering Committee

#275

Post by nickitolas »

ithkuil wrote: post #133
melony wrote: post #131

Earlier quoted context omitted.

Ah, a Lisp user. Common Lisp is Exhibit A for standardization. Every Lisp user claims it is great because of either standardization of advanced features in the days when the Berlin Wall has barely fallen or the mere existence of macros. No real first-party improvement to the language in almost three decades after ANSI standardisation. Massive fragmentation in the compiler ecosystem, rarely do libraries work out of th…

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

Standards are often incomplete, or full of "implementation specific" behaviour, since AIUI standards often end up catering to implementations, instead of the other way around (For example C/C++ standards, you can read a plethora of blog posts about the experience of people trying to contribute to them, and some of the hurdles are related to how strongly tied to existing implementations they are). That means you can often have 2 "standards compliant" compilers that are wildly different. Another reason is compiler extensions. Sometimes a compiler is "standards compliant", but also implements a superset of the standard (Sometimes by default, sometimes under a flag) which means code gets written for that "superset" instead of according to a "standard" (for example, the linux kernel and gcc extensions to C).

Re: GCC Rust Approved by GCC Steering Committee

#276

Post by nickitolas »

akoster wrote: post #208

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…

That is actually going to happen for rustc itself via the rustc_codegen_gcc project (https://github.com/rust-lang/rustc_codegen_gcc), this post is about a different project that writes a "from scratch" rust frontend/compiler for the GCC project in C++ . They both compile rust code with GCC as a backend, but one uses the normal rustc/cargo tools, and the other is a separate compiler with a separate cargo shim.

Re: GCC Rust Approved by GCC Steering Committee

#277

Post by nickitolas »

thealienthing wrote: post #79

Does having rust support for GCC mean potentially faster rust compiler times compared to comping off of LLVM platform?

I doubt it, specially if you compare agains the GCC rustc backend. I would expect most of the difference (If any) to come from the frontend. For example, if it doesn't do borrow checking, it might be able to shave off a bit of time. But at that point, it highly depends on the workload (i.e the code you're compiling). I would expect the vast majority of rust code to bottleneck on codegen, in which case there should be approximately 0 difference. For code bottlenecked on borrow checking (Which I would expect to be an outlier), gccrs should be faster while ignoring borrow checking (Although my understanding is they plan to eventually use polonius for borrow checking, a rust library/project that originally intended to replace the current borrow checker in rustc but still hasn't. In which case, it would probably be faster for some borrow checking and slower for others)

Re: GCC Rust Approved by GCC Steering Committee

#279

Post by dleslie »

nickitolas wrote: post #273
dleslie wrote: post #197

Earlier quoted context omitted.

Because that doesn't use the GCC frontend interface, requiring build tools and embedded toolchains to be modified to understand the rust compiler interface. By using GCC it's just another language that the existing toolchain can understand.

So it's not about platform support, but about toolchain integration? Who benefits from that, projects using C/C++ who want to use a rust library? Or is it about distro package maintainers?

The toolchains support helps embedded developers, mainly. For example, Xtensa and AVR toolchains are generally byzantine monstrosities of makefiles, Python, dialog, etc; so having them be given a low effort means to consume rust is a boon. Ideally, rust is just another source file in the srcdir soup.

That said, gcc supports more platforms than llvm; including esoteric and unpopular desktop configurations.

Personally, I plan to drop this into marsdev as soon as it releases. Writing 32X games in rust sounds like silly fun.

Re: GCC Rust Approved by GCC Steering Committee

#280

Post by steveklabnik »

School-Cotton wrote: post #246
steveklabnik wrote: post #225

Earlier quoted context omitted.

> code written 5 years ago will often not compile today. citation needed. Yes, there's a few programs that relied on unsound things for which this is true, but that's a relatively small part of the overall amount of code.

Doesn’t every implementation of a new function on a standard type possibly break existing code? For example if I have a trait Foo with a function bar, and I impl Foo for HashMap, and then a new version of std comes out that has named something HashMap::bar, now every call to my_map.bar() is ambiguous

In that specific case, the inherent impl is preferred, so there’s no ambiguity. however this can still cause a breaking change if the inherent impl has a different type signature than the trait.

And yes, there are tons of things that can subtly break code. That’s why the rust project runs the entire open source ecosystems’ tests as part of the testing process for the compiler. It’s not all of the code in existence, but it’s pretty good at flushing out if something is going to cause disruption or not.

In practice, the experience that the vast majority of users report to us is that they do not experience breakage when upgrading the compiler.

Post reply on HN