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

221–230 of 300 posts

Re: GCC Rust Approved by GCC Steering Committee

#221

Post by rightbyte »

thrown_22 wrote: post #219
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.

>What is the benefit of having multiple compilers for programming languages? Rust will need a standard. The main reason why I don't take it seriously is that code written 5 years ago will often not compile today. For a language that pretends to be a systems language that is a non-starter. If you can't guarantee a 40 year shelf life of your code then no one working on systems cares. People working on systems in the wi…

We are still arguing whether to bump the C standard from 89 to 99 where I work. I kinda like the pacing with C.

Or as Wikipedia puts it: "C17 addresses defects in C11 without introducing new language features."

Re: GCC Rust Approved by GCC Steering Committee

#222

Post by trimir2022 »

pjmlp wrote: post #203
trimir2022 wrote: post #130

Earlier quoted context omitted.

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.

Partially correct, even now, SG1 in C++ fixes a lot of things in C++ specification to allow for CUDA like approaches.

Re: GCC Rust Approved by GCC Steering Committee

#223

Post by tialaramex »

pjmlp wrote: post #204
steveklabnik wrote: post #134

Earlier quoted context omitted.

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.

Like the Goldman Rep says in The Big Short, "If you offer us free money, we ARE going to take it..."

Re: GCC Rust Approved by GCC Steering Committee

#224

Post by bzxcvbn »

kstrauser wrote: post #47
syvon wrote: post #23

Earlier quoted context omitted.

A common misconception is that GCC stands for GNU C Compiler, but it stands for GNU Compiler Collection. Perhaps why you did not realize ;)

GNU C Compiler was the original name. A lot of us probably never bothered updating our mental acronym tables.

You mean to tell me that the acronym settled in your head between March and December 1987 and you never reconsidered since then?

Re: GCC Rust Approved by GCC Steering Committee

#225

Post by steveklabnik »

thrown_22 wrote: post #219
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.

>What is the benefit of having multiple compilers for programming languages? Rust will need a standard. The main reason why I don't take it seriously is that code written 5 years ago will often not compile today. For a language that pretends to be a systems language that is a non-starter. If you can't guarantee a 40 year shelf life of your code then no one working on systems cares. People working on systems in the wi…

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

Re: GCC Rust Approved by GCC Steering Committee

#226

Post by steveklabnik »

not2b wrote: post #216
tialaramex wrote: post #114

Earlier quoted context omitted.

Worse than not being completely "language independent" sometimes LLVM's Intermediate Representation is not well defined at all. This is most common where C++ (as the main consumer of these semantics) doesn't define certain semantics, or, the semantics it standardises are just impossible to optimise so nobody really delivers them (ie they don't always work in your C++ programs when you compile them with actual modern…

This is incorrect. C and C++ have aliasing rules; the compiler is allowed to assume that your magic pointer does not alias an object that otherwise you had no reason to believe could be aliased. Google "strict aliasing rule" to learn the details. Essentially, C and C++ already have a version of provenance for pointers and references, but it isn't identical to the Rust version. Because some old codebases pull tricks o…

As a small point of order here (not saying you're wrong, just to elaborate a bit):

* Rust doesn't have strict aliasing/tbaa

* Rust does have "restrict" semantics (in C via the keyword and in C++ via common vendor extensions)

And yeah, Rust is considering a provenance model that's different than PNVI-ae.

Re: GCC Rust Approved by GCC Steering Committee

#228

Post by zozbot234 »

pjmlp wrote: post #152
tialaramex wrote: post #146

Earlier quoted context omitted.

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…

Doesn't matter, binary libraries are a big deal for many businesses, regardless of ABI constraints in C and C++ languages and compilers. Either Rust wants to play on that field, or it doesn't. Microsoft has broken their ABI plenty of times, and VS vNext might be when the next break will take place, which was initially planned for VS 2022. Bashing C and C++ ABI issues on HN will do very little for those businesses to…

You can write and use binary libraries in Rust, you're just restricted to using the stable C ABI to interface across separately-built components. Spoiler: You'll want to do this anyway, because it's required for any sort of C-compatible FFI regardless of language.

Re: GCC Rust Approved by GCC Steering Committee

#229

Post by jcranmer »

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?

Typically, some library features contain things that require cooperation with a specific compiler to work correctly. Consider something like std::is_standard_layout in C++, or java.lang.Object in Java, or std::panic::catch_unwind in Rust.

Re: GCC Rust Approved by GCC Steering Committee

#230

Post by chlorion »

melony wrote: post #131
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.

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…

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 either don't implement the the modern standard, don't have useful extensions for real world programming or are simply immature and don't have enough people working on them to get them into a nice state. In practice it's very difficult to use Scheme for anything non-trivial because of these issues.

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. Until we get a new dialect that solves these issues Lisp is going to be more or less dead and irrelevant.

Post reply on HN