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

81–90 of 179 posts

Re: GCC Rust: GCC Front-End for Rust

#81

Post by chubot »

tumdum_ wrote: post #76
rectang wrote: post #13

Earlier quoted context omitted.

Glad you're going slow on the stable ABI and resisting the pressure to put out something half-baked. The C++ ABI is horribly fragile and complex. Unless the pitfalls of C++ can be avoided, making no ABI promises is better.

No stable ABI makes distributing shared libraries harder :/

If you want to distributed stable shared libraries, you write to the C ABI, not the C++ ABI.

Likewise Rust users should write to the C ABI for stabled shared libraries. (I believe there are a bunch of mechanisms to do that, though I'm not really a Rust user)

For example look at what KDE does: https://community.kde.org/Policies/Binary_Compatibility_Issu...

Yes, you have to do a lot of extra work. That's working as intended.

It's sort of an oxymoron to expect to use every C++ or Rust feature in your user-facing ABI and have it be stable. They are incredibly rich languages, with drastically different notions of "function" than C has (let alone other constructs like data layout)

Re: GCC Rust: GCC Front-End for Rust

#82

Post by Blikkentrekker »

thesuperbigfrog wrote: post #25
vlovich123 wrote: post #12

What I really hope is that the Rust community doesn’t go out of its way to make this easier. Communicate and let value come back but there’s an significant amount of value in keeping a single backend relies on. CPython has done the Python community a lot of good by keeping one official compiler/tool chain (despite the great work done by projects like JPython/PyPy). The only way to do this properly, if desirable, is t…

>> The only way to do this properly, if desirable, is to make GCC an official backend of the main frontend. That will defocus some progress that happens with LLVM (every feature has to be implemented on both backends) and can make dev lives hard (eg “oh this problem comes up with GCC so use the LLVM backend “) No. The correct way is to create a Rust language specification that describes what the correct behavior is.…

Such standardized specifications are typically a response to many divergent implementations existing and a need to standardize a common ground between them.

Few languages find such specification before that time.

Python also lacks it despite some competing implementations, since none actually diverge enough from CPython.

Re: GCC Rust: GCC Front-End for Rust

#83

Post by steveklabnik »

chubot wrote: post #81
tumdum_ wrote: post #76

Earlier quoted context omitted.

No stable ABI makes distributing shared libraries harder :/

If you want to distributed stable shared libraries, you write to the C ABI, not the C++ ABI. Likewise Rust users should write to the C ABI for stabled shared libraries. (I believe there are a bunch of mechanisms to do that, though I'm not really a Rust user) For example look at what KDE does: https://community.kde.org/Policies/Binary_Compatibility_Issu... Yes, you have to do a lot of extra work. That's working as int…

(There are mechanisms to do this, yes)

Re: GCC Rust: GCC Front-End for Rust

#84

Post by zabzonk »

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?

I wouldn't say it's a benchmark, but surely Pascal, Fortran and COBOL (to name but three) are all standardised?

Re: GCC Rust: GCC Front-End for Rust

#85

Post by unanswered »

Blikkentrekker wrote: post #64
stouset wrote: post #32

Earlier quoted context omitted.

I don’t know why you’re italicizing LLVM, gcc, and Rust, but I (and perhaps others) find it relatively jarring as my brain automatically parses it as emphasis even though it clearly isn’t intended to be. I only bring it up because it pretty drastically harms readability (for me at least, and to a degree I frankly find surprising). Just thought you may want to know.

This is indeed a point of contention among different styles of whether software titles should be italicized. Though the position that they should uniformly be is the minority one, it is certainly used by some outlets with considerable weight, and I believe it to be the consistent one if titles of books and films are too. Some style guides make the even more inconsistent distinction that only titles of video games be…

The video games example seems consistent to me; we regularly italicize the names of plays (for example) but not the names of tools and businesses.

Re: GCC Rust: GCC Front-End for Rust

#86

Post by IshKebab »

chubot wrote: post #81
tumdum_ wrote: post #76

Earlier quoted context omitted.

No stable ABI makes distributing shared libraries harder :/

If you want to distributed stable shared libraries, you write to the C ABI, not the C++ ABI. Likewise Rust users should write to the C ABI for stabled shared libraries. (I believe there are a bunch of mechanisms to do that, though I'm not really a Rust user) For example look at what KDE does: https://community.kde.org/Policies/Binary_Compatibility_Issu... Yes, you have to do a lot of extra work. That's working as int…

Yes you should do that now but only because Rust doesn't have a stable ABI. If/when it does then there's nothing wrong with distributing shared libraries using the Rust ABI, just like there isn't really anything wrong with doing it in C++ nowadays as long as you don't use bleeding edge C++ stuff. The C++ ABIs are pretty stable.

Re: GCC Rust: GCC Front-End for Rust

#87

Post by [deleted] »

ibraheemdev wrote: post #67

There was a thread posted on the rust forum a while back that laid out the goals of this project [0]: > A friend of mine (Luke) has been talking about the need for a Rust frontend for GCC to allow Rust to replace C in more places, such as system software. To allow some types of safety-critical software to be written in Rust, the GCC frontend would need to be an independent implementation of Rust, since the relevant s…

[deleted]

Re: GCC Rust: GCC Front-End for Rust

#88

Post by steveklabnik »

zabzonk wrote: post #84
steveklabnik wrote: post #78

Earlier quoted context omitted.

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?

I wouldn't say it's a benchmark, but surely Pascal, Fortran and COBOL (to name but three) are all standardised?

There are more languages that have standards, sure, but the languages you mention, at this point, and in general, are mostly relegated to historical maintenance and maybe some very specific niches. To me personally, a “mature” language that’s not really being used isn’t the goal. And if developers truly believed standardization was valuable, you’d expect this property to give them a significant leg up against the sorts of languages like Ruby, Python, PHP, Perl, TypeScript, etc.

That being said, I do think, considering it longer, there are languages that I am missing, like SQL, and ones that have a spec, even if it’s not under an ECMA/ISO process, like Java and Go, that I was forgetting.

I still think that using this as a necessary condition for “maturity” is misguided.

Re: GCC Rust: GCC Front-End for Rust

#89

Post by [deleted] »

balnaphone wrote: post #43
stouset wrote: post #32

Earlier quoted context omitted.

I don’t know why you’re italicizing LLVM, gcc, and Rust, but I (and perhaps others) find it relatively jarring as my brain automatically parses it as emphasis even though it clearly isn’t intended to be. I only bring it up because it pretty drastically harms readability (for me at least, and to a degree I frankly find surprising). Just thought you may want to know.

This is common nomenclature to enhance readability in fields that have a large number of neologisms and proper nouns, such as some technical domains, medicine, investment banking, and so on. It's particularly useful when names are in the same language as the base language (e.g. in English "Peter" is easily recognized as a name, but "better fish" means something in the language, but can also be used as a proper noun,…

[deleted]

Re: GCC Rust: GCC Front-End for Rust

#90

Post by chubot »

IshKebab wrote: post #86
chubot wrote: post #81

Earlier quoted context omitted.

If you want to distributed stable shared libraries, you write to the C ABI, not the C++ ABI. Likewise Rust users should write to the C ABI for stabled shared libraries. (I believe there are a bunch of mechanisms to do that, though I'm not really a Rust user) For example look at what KDE does: https://community.kde.org/Policies/Binary_Compatibility_Issu... Yes, you have to do a lot of extra work. That's working as int…

Yes you should do that now but only because Rust doesn't have a stable ABI. If/when it does then there's nothing wrong with distributing shared libraries using the Rust ABI, just like there isn't really anything wrong with doing it in C++ nowadays as long as you don't use bleeding edge C++ stuff. The C++ ABIs are pretty stable.

there isn't really anything wrong with doing it in C++ nowadays as long as you don't use bleeding edge C++ stuff

That's the whole point of the KDE doc I linked. It's not a reasonable strategy to use unrestricted C++, just like it's not a reasonable strategy to use unrestricted Rust. You actually have to design an ABI, not just rely on the compiler to do it for you.

I thought there was a GNOME doc too, but I couldn't find it. The point remains: there are lots of things in C++ that people who care about stability don't use at their ABI boundaries.

Post reply on HN