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

161–170 of 300 posts

Re: GCC Rust Approved by GCC Steering Committee

#161

Post by kelnos »

yjftsjthsd-h wrote: post #158
j16sdiz wrote: post #140

The rust borrow checker is under-specified (for a good reason). Can forsee lots of incompatible with two implementation

What good reason would there be for under-specifying it, that would create problems? Like, I can see wanting to leave flexibility in the implementation, but then different implementations should be fine if they both match what spec there is. The only problem would be if one implementation is more strict than it "admits" to being (in its written spec), which is a problem anyways.

I think there are two things that could be specified here:

1. What the borrow checker protects against, and what constitutes valid code.

2. What the borrow checker can actually prove is valid code.

#2 tends to be much less than #1, because the compiler can only be so smart, and if it can't prove something correct (even if it might be correct), it takes the safe route and refuses to compile the code.

#1 is probably pretty well specified, or at least wouldn't be hard to write down if someone really wanted to. #2 is a moving target, because the borrow checker in rustc gets smarter with some releases, and compiles code that it used to reject (because it's been taught to understand that code better and can prove it correct). So it's a lot harder to specify exactly what kinds of code the borrow checker will accept and reject.

I could easily see a situation where gcc-rust claims to support all the language and stdlib features that a particular version of rustc supports, but has subtle differences in borrow checker behavior that causes it to reject some code that rustc accepts (or accept some code that rustc rejects). The behavior isn't incorrect, per se, but it would be frustrating for developers.

It's also possible there could be similar issues with lifetime analysis.

Re: GCC Rust Approved by GCC Steering Committee

#162

Post by sicp-enjoyer »

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…

> No real first-party improvement to the language in almost three decades

That sounds like a benefit to me :)

However, I think that's due to the general lack of interest in Lisp. You can see the C++ community has a similar ANSI standard and updates it every few years.

> Massive fragmentation in the compiler ecosystem

I wouldn't call it massive. They are pretty consistent, up until things like POSIX and FFI APIs. Let's agree there is some fragmentation. Isn't this still a better situation than if nothing was guaranteed?

Re: GCC Rust Approved by GCC Steering Committee

#163

Post by Beltalowda »

atonse wrote: post #154
Beltalowda wrote: post #151

Earlier quoted context omitted.

I'm not so sure about that; I've certainly met plenty of people who did not understand it. HN is not representative of the wider tech community. And "free as in speech, not beer" actually does little to clarify it IMHO; it only works well if you're already familiar with the concept, but if you're not it only adds to the confusion (free speech is about the freedom to say what you want, so free software is about being…

There are probably even fewer people that know what right to repair is. Free software just isn’t enough anymore because the licenses limit your freedom too. (and even my choice of the word “limit” here will be controversial between the Apache/MIT and the *GPL crowds). Don’t have an easy answer :-)

Right to repair has been all over the news, including mainstream news, and least in tech circles it's fairly well known. And while there are undoubtable many people who don't know what it means, the basic idea is quite obvious from just those three words: "if I bought something, I should have the ability to repair it".

The problem is that merely right to repair doesn't cover all of Free Software so it will never catch on with the hard-core FSF crowd who seem to think that the only possible step is one giant leap to a Free Software utopia and than any smaller step in that direction is "unethical".

Re: GCC Rust Approved by GCC Steering Committee

#164

Post by sicp-enjoyer »

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?

They typically do, unless they are wrapping C libraries or making platform specific API calls.

Re: GCC Rust Approved by GCC Steering Committee

#165

Post by cosmiccatnap »

Typical desktop Linux is compiled with gcc and even if rust features in gcc lag behind rustc this is still a great step in the direction of one of the larger goals many of us want from rust which is to replace C as a memory safe systems language for OS kernel and embedded projects.

A big part of getting a sane environment to build rust Linux modules is having it easily integrate with the gcc toolchain.

There seems to be some contention around if this is a good idea for rust as a language itself and my counter to that would be that there are billions of people on the planet and the work integrating rust into gcc doesn't detract in any way I can see from the continued development of rust as a language, it just helps to make it more viable for many use cases and therefore increase it's footprint and overall support.

Re: GCC Rust Approved by GCC Steering Committee

#166

Post by kelnos »

cozzyd wrote: post #82
tcmart14 wrote: post #59

Earlier quoted context omitted.

A question for curiosity since I don't know much about llvm and specifically the architecture. Does LLVM not support architectures because there is some barrier, or a higher barrier than GCC? And GCC makes it easier to support some architectures or is it just as easy to add the support to LLVM but no one does it because GCC already supports it?

The vendor sometimes does this and GCC is much more standard in the embedded space. And crucially, it's required to be open source. For example, for arm-none-eabi, ARM provides a GCC toolchain ( https://developer.arm.com/Tools%20and%20Software/GNU%20Toolc... ) but makes you purchase the LLVM-based one ( https://developer.arm.com/Tools%20and%20Software/Arm%20Compi... ). Now I'm fairly certain there's an open-source wa…

That's so strange. Rustup does ship with support for baremetal EABI ARM:

    $ rustup target list | grep arm | grep none
    armebv7r-none-eabi
    armebv7r-none-eabihf
    armv7a-none-eabi
    armv7r-none-eabi
    armv7r-none-eabihf
... which means the publicly-available open source version of LLVM also supports it.

Re: GCC Rust Approved by GCC Steering Committee

#167

Post by [deleted] »

charcircuit wrote: post #120
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.

That sounds a little circular. The benefit of alternate compilers is that it makes making alternate compilers easier. For stability compilers already have a large incentive not to break old programs. For longevity I don't really see how a standard affects it that much. For being more portable you do not need an entirely knew compiler.

[deleted]

Re: GCC Rust Approved by GCC Steering Committee

#168

Post by jcpst »

shadowofneptune wrote: post #139
rgoulter wrote: post #89

Earlier quoted context omitted.

> Beer is normally neither monetarily free TBH the main place I've seen the phrase "free beer" is a Simpson's joke: people stand in front of a sign saying "free beer", but after Homer drinks many cups, the sign is revealed in full to say "alcohol-free beer, $5/cup". It's understood that beer normally costs money, so the setup of the joke is that "free beer" is understood without explanation as "beer without costing m…

Beer was once given away at taverns so people would stick around for the food, which had a price adjusted to make up for the beer. Freeware uses this model.

This also works in the inverse. The kimmelweck sandwich has its orgins in the pubs of western New York. Some gave the sandwich for free, and it was so salty that incentive was created for adding some pints to the tab.

Re: GCC Rust Approved by GCC Steering Committee

#169

Post by cogman10 »

msbarnett wrote: post #93
cogman10 wrote: post #76

Earlier quoted context omitted.

I don't think these limitations are ones that really impact hardware all that much. It wouldn't be impossible to create hardware with the concept of "infinite registers" that ultimately gets optimized away. (see: Mill CPU) The bigger issue (IMO) is that the IR for compilers tends to evolve rapidly while hardware is stuck in the mud. Moving the problem of finalizing the IR into the hardware will effectively make it so…

> It wouldn't be impossible to create hardware with the concept of "infinite registers" that ultimately gets optimized away. (see: Mill CPU) I'm not sure that the vaporware Mill CPU acts as an existence proof for anything, to be honest.

It was a PoC that didn't get funding because the advantages it touts aren't nearly useful enough compared to simpler/familiar architectures. That, and it was proprietary which, come on guys, that was never gonna fly (I still have my doubts about RISC-V going very far).

The problem of infinite registers is pretty easily solvable. Heck x87 already has that basic concept down with the stack registers. The only missing piece is moving overflow values onto and off of the stack. It's a fairly easy to solve problem.

That's effectively what Mill proposed in their docs. The "belt" notation was their cute way of doing that.

Re: GCC Rust Approved by GCC Steering Committee

#170

Post by Halan »

mistrial9 wrote: post #53
dleslie wrote: post #8

This is great! Gcc support opens up more platforms, more targets, and the opportunity to more easily integrate with the various common embedded toolchains that are built around gcc. And it's free software, for those that care, this matters.

> free software it seems like this term is misunderstood in English to mean "no money" .. perhaps "Libre Software" is a better starting description here

Maybe for Americans who cannot see further then their noses or that don’t speak any other language
Post reply on HN