GCC Rust Approved by GCC Steering Committee • Hacker News Board

Re: GCC Rust Approved by GCC Steering Committee

#251

Post by shakna » Tue, Jul 12, 2022, 2:49 AM UTC

chlorion wrote: post #230

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…

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 alternative to Chez is Guile. Emacs can run with Guile, and Guix is built on it. It's got a fairly large community.

Outside of Chez and Guile, there are implementations and communities, but comparatively, they're tiny. Those two are the only big names you need. Like GCC and Clang for C. There are other C compilers. But you only need to know those two.

[0] https://www.scheme.com/

Re: GCC Rust Approved by GCC Steering Committee

#252

Post by ArrayBoundCheck » Tue, Jul 12, 2022, 3:07 AM UTC

thealienthing wrote: post #79

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

No. LLVM is faster than GCC so most likely it'll be slower. If the way the frontend generates code for the backend is completely different then there's a chance it won't be terrible and will have reasonable build speeds. However there's a chance it'll be inconsistent with llvm output but chances are noone will notice or care if it's not buggy

Re: GCC Rust Approved by GCC Steering Committee

#253

Post by ArrayBoundCheck » Tue, Jul 12, 2022, 3:09 AM UTC

ByteJockey wrote: post #244

pornel wrote: post #176

Earlier quoted context omitted.

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.

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

No post body was provided.

Re: GCC Rust Approved by GCC Steering Committee

#254

Post by forgotloginonp4 » Tue, Jul 12, 2022, 3:48 AM UTC

coldtea wrote: post #188

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…

Probably you're overthinking it... "free as in speech, not beer": "free speech", the right to say what you want without legal restrictions from the state "free beer", beer you don't need to pay for Nothing to do with beer making you "feel free" (?) or whatever Then again, free speech is not about being able to modify speech, release your own version of another's speech, and so on (e.g. the US has "free speech" but ML…

Maybe something more comprehendable would be “free as in Postfix, not Gmail” in that anyone can freely implement an MTA or use existing FOSS, which is different from using for free Gmail, Facebook, first 3 months of AOL, first 10 albums from Columbia House, …

https://www.mentalfloss.com/article/28036/its-steal-how-colu...

Re: GCC Rust Approved by GCC Steering Committee

#255

Post by OptionX » Tue, Jul 12, 2022, 4:12 AM UTC

Rust newbie that has used part of his summer to get into Rust. Clarify me on some points.

Does that means than (after merged) I can use gcc to compile rust code right? What are the advantages of this versus using the normal rustc compiler?

All the crate/project management would still be done with cargo? It seems to be a tool very entwined with rust itself, so I wonder if someone uses rust without cargo?

Re: GCC Rust Approved by GCC Steering Committee

#256

Post by pabs3 » Tue, Jul 12, 2022, 4:20 AM UTC

OptionX wrote: post #255

Rust newbie that has used part of his summer to get into Rust. Clarify me on some points. Does that means than (after merged) I can use gcc to compile rust code right? What are the advantages of this versus using the normal rustc compiler? All the crate/project management would still be done with cargo? It seems to be a tool very entwined with rust itself, so I wonder if someone uses rust without cargo?

I think most people would just use the existing Rust infrastructure; rustc etc. The GCC frontend will be useful in situations where you cannot use that; for platforms that LLVM/rustc do not support, when you want to build rustc from source instead of using the rustc binaries etc.

Re: GCC Rust Approved by GCC Steering Committee

#257

Post by pjmlp » Tue, Jul 12, 2022, 5:06 AM UTC

ATsch wrote: post #238

pjmlp wrote: post #205

Earlier quoted context omitted.

Dependency on an existing Rust compiler during GCC bootstrap process.

You already need an existing C++ compiler to bootstrap GCC though I don't see how this is much different. Plus there is already mrustc as a C++ Rust implementatation specifically designed for bootstrapping.

It is one more dependency, not written in C++, and you don't see the difference?

Re: GCC Rust Approved by GCC Steering Committee

#258

Post by pjmlp » Tue, Jul 12, 2022, 5:08 AM UTC

tialaramex wrote: post #223

pjmlp wrote: post #204

Earlier quoted context omitted.

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

I bet Ferrocene will also happily take part of that money.

Re: GCC Rust Approved by GCC Steering Committee

#259

Post by pjmlp » Tue, Jul 12, 2022, 5:14 AM UTC

zozbot234 wrote: post #228

pjmlp wrote: post #152

Earlier quoted context omitted.

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.

Nope, Windows C++ compilers have supported DLLs since Windows 16 bit days.

Some famous C++ frameworks that ship as binaries are OWL, VCL, FireMonkey, MFC, ATL, WinUI.

And WinRT has improved upon classical COM ABI to provide even more data types.

On Windows there is a component market selling libraries for those ecosystems.

Then we have middleware vendors for game consoles as well.

Maybe this isn't a market Rust community cares about and that is fine.

Re: GCC Rust Approved by GCC Steering Committee

#260

Post by maxwell86 » Tue, Jul 12, 2022, 5:44 AM UTC

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.

The Rust module system is radically different from C and C++ and other similar languages in the embedded space.

Every build system that has added support for Rust, which aren't many, had to be radically modified to achieve that.

None of these supports the GCC Rust frontend, but all of them support the Rust frontend.

So if you actually wanted to build any >100 LOC Rust project for embedded targets not supported by LLVM, doing it with the Rust frontend is as easy as just running 1 CLI command to pick its GCC backend.

Doing it with the GCC frontend, would require you to either port one of the build systems to support it, or... give the GCC frontend a CLI API that's 100% compatible with the Rust frontend.