Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC Rust: GCC Front-End for Rust

github.com

Post reply on HN
Print view View original

141–150 of 179 posts

Re: GCC Rust: GCC Front-End for Rust

#141

Post by pjmlp »

ncmncm wrote: post #140
anfilt wrote: post #137

Earlier quoted context omitted.

System programs can be in user space for instance a run time for another language. As for a compiler ideally its easy to port as its kinda of the bed rock to get any other system going. Although a compiler for some architecture or use cases is too large to be self hosted or does not make sense to be self hosted. So its not always a deal breaker for a compiler.

You seem to be confused about what C++ and C are, and even about what Gcc is and its relationship to programs it compiles. C++ is a language defined by ISO committee SC22/WG21 via the Standards 14882, most recently C++20 (superseding C++17). C is defined by SC22/WG14, in the same way. The most widely used implementations of these Standards -- Gcc, Clang, and MSVC -- are in fact the same project in each case (although…

> although MS's implements a long-superceded C Standard).

Not anymore, as of 2020, MVSC supports C11 and C17, with the exception of the C99 features that were dropped in C11, like VLAs.

Previously they were only keeping up with the ISO C features required by ISO C++ compatibility requirements.

Re: GCC Rust: GCC Front-End for Rust

#142

Post by pjmlp »

steveklabnik wrote: post #77
tumdum_ wrote: post #76

Earlier quoted context omitted.

No stable ABI makes distributing shared libraries harder :/

Everything is tradeoffs. Stable ABI can also lead to other issues, like performance problems. C++ is dealing with some of these right now, and there are some situations (very very micro benchmarks, to be clear) where Rust is faster than C++ due to ABI issues.

That affects mostly GCC and clang, other compiler vendors are more happy to break ABI between major releases, as long as they aren't forbidden by ISO C++ specification.

I was already sharing templates and classes across DLLs in Windows 3.x compilers, and keep doing it with VC++ to this day.

On Linux with Qt and Gtkmm projects, and on macOS/iOS with their system frameworks.

Which is the biggest reason I cannot put up with cargo's model to compile every single project from scratch, after git clone.

As we have lengthy discussed, while it might not be a priority right now, it is certainly an adoption block among some Ada, Delphi, Swift, Objective-C, C and C++ communities.

Re: GCC Rust: GCC Front-End for Rust

#143

Post by pjmlp »

steveklabnik wrote: post #78
thesuperbigfrog wrote: post #75

Earlier quoted context omitted.

Exactly. The C++ standard ( https://isocpp.org/std/the-standard ) is the specification that describes what a compiler must do to implement a particular "version" of C++ (for example, C++ 20). Just as there is a C++ standard and multiple C++ compilers that implement the standard, there should be a Rust standard and multiple implementations. This is the way that mature languages work.

This is the way that very few languages work. Python is a great example of an extremely popular, mature language that does not work this way. It is unclear that most people think that this sort of process is required for “maturity.” If this is the benchmark, then among popular languages you basically have C, C++, C#, JavaScript, and... is that it?

Java, https://docs.oracle.com/javase/specs/index.html

Ada, Fortran, Cobol as well.

This is specially relevant in the industrial sector with certified compilers.

Re: GCC Rust: GCC Front-End for Rust

#144

Post by pjmlp »

ncmncm wrote: post #119
pjmlp wrote: post #71

Earlier quoted context omitted.

In some extent, given the use of macros and Haskell like libraries, it is already another C++. Besides, if Rust doesn't become another C++, it won't fulfil the industry needs that C++ caters for, thus while it might become a success in some domain, it won't replace C++ in the OS and GPGPU SDKs.

Rust will not in any case replace C++, in any core application area. Rust might move in alongside C++, in some, in time. Or, Rust could still very possibly fizzle. That would be the normal course of events for a new language, barring a miracle as was dispensed to Javascript, Java, C++, and vanishingly few others. Will Dart survive and thrive? Kotlin? Scala? Clojure? Go? All doubtful, based on prior experience. Having…

> Ada even had $billions in backing, and faded.

Yet, NVidia picked it up over Rust, go figure.

Re: GCC Rust: GCC Front-End for Rust

#145

Post by pjmlp »

vips7L wrote: post #110
pjmlp wrote: post #63

Earlier quoted context omitted.

Given the amount of existing frontends for GCC, even if not included in the main branch, not sure what they imply as modern. Ada, D, Go, Modula-3, Modula-2, C++20

RIP gcj.

Yeah, sadly. The project never had much developers, because tackling AOT compilation for Java, alongside its dynamism, is an effort that requires a full time job, so only the commercial offerings like Excelsior JET were competitive.

Re: GCC Rust: GCC Front-End for Rust

#146

Post by volta87 »

Dylan16807 wrote: post #130
volta87 wrote: post #102

Earlier quoted context omitted.

Notice that in C and C++ loops that might not terminate are UB, while in Rust they are just infinite loops. So there is a significant difference in semantics between Rust and C/C++ here.

Loops that do nothing and don't terminate. If your loop infinitely writes the number 70 to an atomic int, it's fine.

If by "nothing" you mean "nothing but looping", then yes, you are right. Any loop that "just loops" is doing something by definition: looping.

Re: GCC Rust: GCC Front-End for Rust

#148

Post by IcePic »

CameronNemo wrote: post #108
strongdenial wrote: post #26

Earlier quoted context omitted.

Not a requirement for a GCC front-end and certainly not worth sacrificing a potentially faster path to bootstrapping the official compiler implementation. You should be worried about the ease by which various systems can bootstrap and adopt the language, which is a mostly solved problem for C/C++ but not a given for Rust itself. Some maintainers will absolutely refuse bootstrapping off of binary artifacts compiled fr…

Who are these groups who are demanding such easy bootstrapping? OS or distro developers? Programmers working on embedded and/or safety critical systems? I know OpenBSD avoids rust because of the bootstrapping issue, but they also avoid LLVM because of a licensing issue.

OpenBSD uses clang/llvm on most arches by now for the system compiler.

Re: GCC Rust: GCC Front-End for Rust

#149

Post by kzrdude »

jjnoakes wrote: post #124

Ecstatic to see this. Once this stabilizes then I can switch my shop to rust and not look back. If I find some spare time I will absolutely try to find a way to contribute.

Do you mean that you will use this, or just have the alt implementation as a checkbox item? Because - I'm just guessing of course - for this to be a mature alternative compiler we might be looking at 5, 10 years in the future, or never. Just being realistic, things take time to grow (and it's also uncertain how they can ever be able to keep pace with the rapidly developing Rust project).

With all this said, I would love for them to succeed, for multiple reasons. Including <3 GPL.

Re: GCC Rust: GCC Front-End for Rust

#150

Post by souprock »

jdoerfert wrote: post #112
saagarjha wrote: post #104

Earlier quoted context omitted.

C and C++ actually differ in semantics here; C allows infinite loops that are controlled by a constant expression.

Generally, yes. Though, as always, these things are hard to summarize in one sentence and depend on the standard version (pre/post C++11). This post might shed some light on the options we are considering for Clang right now: https://reviews.llvm.org/D94367#2489090

Just what is gained by failing to loop forever? It seems like a really low-value optimization. Nearly always, the optimization would violate the programmer's intent or it would change an ordinary bug into a confusing bug. An infinite loop is not very many bytes on any processor.

The standard may allow the generation of insane code, but a decent-quality compiler does not do so. The standard ought to be fixed.

Post reply on HN