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

291–300 of 300 posts

Re: GCC Rust Approved by GCC Steering Committee

#291

Post by ruuda »

steveklabnik wrote: post #61
ruuda wrote: post #49

Earlier quoted context omitted.

Another reason besides platform support, is bootstrapping and verifiable builds. rustc can only be built by a recent rustc, so it is a pain to bootstrap from source if you don't want to trust a big binary.

https://github.com/thepowersgang/mrustc is already providing that; it targets 1.54 right now, which is farther along than this project (though obviously that may not be always true in the future).

Ah, I didn't realize it could do 1.54 now, neat! Last time I looked at the state of bootstrapping rustc in Nix and Guix, mrustc could only do 1.20-something, and you had to build a dozen rustcs to get to the current version. Does mrustc keep up now though? With 1.63 in beta it's still quite a chain to build from 1.54.

Re: GCC Rust Approved by GCC Steering Committee

#292

Post by FrankHB »

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?

There are simply lacking of such strong requirements in language standards. C/C++ even have the specific "linkage" concept to abstract the binary details under the source form away. And you may know, many libraries are distributed by binaries.

The standards implying binary compatibility rules are about ABI (application binary interface), which usually depend on the ISA (instruction-set architecture) or the OS (if any) being used. You cannot have the unique one once there are multiple ISAs/OSes supported. Even when you only want to rely on some external "exchanging" representations not tied to specific ISAs, there are already plenty of candidates: CLI, JVM, WebAssembly... Plus there are more than one executable (and mostly, runtime loadable) image formats widely used (PE/COFF, ELF, Mach-O ...). You will not have the unique combination, and any attempts to ensure it "work across compilers" in that way will likely finally just add a new instance not fully compatible to existing ones, making it more fragile.

Re: GCC Rust Approved by GCC Steering Committee

#293

Post by FrankHB »

samatman wrote: post #138
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.

A language with one implementation can't really be said to have a specification. It may have a very detailed accompanying technical documentation of what the implementation is supposed to do, this may be called a specification, but a specification deserves the name with a minimum of two implementations.

This is technically incorrect. A programming language can be designed with specification in mind, even with a formal one (e.g. SML). It is just true that the specification is not likely effectively verified before more than one real implementations landed, if it is not formally verified. (Anyway, verification by testing of existing implementations _is_ the fallback where people cannot afford the cost of formal methods.)

Re: GCC Rust Approved by GCC Steering Committee

#294

Post by FrankHB »

nrclark wrote: post #15
sdfhdhjdw3 wrote: post #11

What does a "front-end" mean exactly, in this context?

Compilers are often implemented as a front-end/back-end split. The front-end compiles your input language (C, C++, Rust, etc) down to a low-level language called an Intermediate Representation. Then the back-end of the compiler optimizes the IR and compiles it into object code. A family of compilers will usually share the back-end. This kind of split allows for deduplication across different compilers in the same fam…

In some stricter sense, back-end is for target-depending stuff like ISA-dependent code generation. A great deal of work in both GCC and LLVM is in the so-called mid-end. Both have more than one IRs in the pipeline after the front-end.

Re: GCC Rust Approved by GCC Steering Committee

#295

Post by FrankHB »

tialaramex wrote: post #146
pjmlp wrote: post #123

Earlier quoted context omitted.

Princess Rust has no proper throne on the kingdom of binary libraries.

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…

This is not the only case. It harms not only performance, but also conformance, e.g. https://developercommunity.visualstudio.com/t/unable-to-move....

Microsoft is stupid enough since the first decision of the implementation impacting the ABI is made. There was no one enforcing such bad decisions shipped into the productions at the very beginning. Both libstdc++ and libc++ have more flexible rules to preventing ABI breakage.

Re: GCC Rust Approved by GCC Steering Committee

#296

Post by kstrauser »

bzxcvbn wrote: post #224
kstrauser wrote: post #47

Earlier quoted context omitted.

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?

Nope. It settled in my head before it was renamed in 1999: https://gcc.gnu.org/wiki/History#Reunification

Re: GCC Rust Approved by GCC Steering Committee

#297

Post by ArrayBoundCheck »

pornel wrote: post #270
ArrayBoundCheck wrote: post #253

Earlier quoted context omitted.

Quoted post unavailable.

If my information was inaccurate or out of date, you could have corrected me. I find your antagonizing cheer hurtful, and such a mean comment is unhelpful. Please be kinder.

No post body was provided.

Re: GCC Rust Approved by GCC Steering Committee

#298

Post by mistrial9 »

chrisoverzero wrote: post #86
nicoburns wrote: post #75

Earlier quoted context omitted.

> free as in speech, not beer I can never remember which way around this is. I think the "beer" is supposed to be free in the monetary sense and "speech" is supposed to be free in the rights/liberty sense, but the analogy doesn't actually convey this: - Speech is normally both monetarily free and (in certain places) a right - Beer is normally neither monetarily free or a right. But may make you "feel" free, which is…

It’s not as complex as you’re choosing to make it. When someone tells you, “There’s free beer at Oktoberfest,” is your first thought that the beer has no monetary cost, or that the beer is unencumbered by particular legal restrictions? Now someone tells you, “There’s free speech at Oktoberfest.” Is your first thought that there’s no monetary cost to expression, or that the expression is unencumbered by particular leg…

pssst - there are two different words in German for these concepts

Re: GCC Rust Approved by GCC Steering Committee

#299

Post by chlorion »

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…

Thanks. I'm going to install guile and tinker around with it! So far it looks pretty good.

Re: GCC Rust Approved by GCC Steering Committee

#300

Post by ByteJockey »

pornel wrote: post #269
ByteJockey wrote: post #244

Earlier quoted context omitted.

> They plan to use the exact same code! Did they announce a change of plans? Their website just says that they have no plans for a borrow checker (i.e. it's not required to actually implement rust). From the website for the project: > There are no immediate plans for a borrow checker as this is not required to compile rust code and is the last pass in the RustC compiler. This can be handled as a separate project when…

The "separate project" you mention is integration of Polonius: https://lwn.net/Articles/871283/

I appreciate the link, thank you.
Post reply on HN