Live data from Hacker News

GCC Rust Approved by GCC Steering Committee

gcc.gnu.org

151–160 of 300 posts

Re: GCC Rust Approved by GCC Steering Committee

#151
post #63

Earlier quoted context omitted.

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

The term has been around for decades now, and seems to be fairly well understood in the tech world. It doesn't take much to say "free as in speech, not beer" to the few people left who need to understand it.

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 able to write whatever software you want?)

Now, "free software as in right to repair" would actually clarify it, but trying to get an understandable message out seems to be "unethical" so meh :-/

Re: GCC Rust Approved by GCC Steering Committee

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

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 adopt source code distributions.

Re: GCC Rust Approved by GCC Steering Committee

#153

Hopefully this will slow down development of new Rust features to a reasonable pace. Instead of Rust devs writing code that requires a new compiler every 3 months it'll be more like every year or two. Almost useable.

I'm not sure I fully understand the gripe you have here. Rust releases a new compiler every 6 weeks. Many releases just improve optimization and a handful of newly stabilized APIs, or existing APIs newly made `const`, or whatever. When a big feature is finished, it is put out in the next release.

There is no sense in which this increases the pace at which these new features are developed or released; if Rust released a new version yearly, we'd simply see extremely large releases some years (including, say, the new async/await system) and relatively small releases in others.

What it does mean is that backwards-compatible refinements and bugfixes can be quickly and easily added to the language, which I think is a good thing.

I'd be interested to know what you'd prefer, though!

Re: GCC Rust Approved by GCC Steering Committee

#154
post #63

Earlier quoted context omitted.

The term has been around for decades now, and seems to be fairly well understood in the tech world. It doesn't take much to say "free as in speech, not beer" to the few people left who need to understand it.

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 :-)

Re: GCC Rust Approved by GCC Steering Committee

#155
post #63

Earlier quoted context omitted.

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

The term has been around for decades now, and seems to be fairly well understood in the tech world. It doesn't take much to say "free as in speech, not beer" to the few people left who need to understand it.

> The term [Free Software] has been around for decades now, and seems to be fairly well understood in the tech world.

For you and me, maybe. But no, Free Software is often misunderstood. I had to explain the difference on a group dedicated to Linux the other day.

It is worth pointing out, every time.

Re: GCC Rust Approved by GCC Steering Committee

#156

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…

How do I get free beer at Oktoberfest?

Re: GCC Rust Approved by GCC Steering Committee

#157
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 but "free" should be related to "freedom" more than "not having money." "You're free to use the park," "you're free to use the library." We need more freedom in that sense.

Re: GCC Rust Approved by GCC Steering Committee

#158

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.

Re: GCC Rust Approved by GCC Steering Committee

#159
post #156

Earlier quoted context omitted.

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…

How do I get free beer at Oktoberfest?

You don't, but the point is that if there was "free beer" at Oktoberfest the meaning would be unambiguous.

Re: GCC Rust Approved by GCC Steering Committee

#160

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

Yeah, this would worry me too. It feels like the rustc policy on this is just to make the compiler smarter and smarter so it can accept more code that's actually valid (but couldn't prove was the case in previous versions). That's a great goal, but that makes it really hard to nail down what is and isn't allowed in a particular version of Rust. And if we assume that gcc Rust will always be playing catch-up to rustc, they will probably have a hard time enumerating rustc's borrow checker's behavior precisely enough to be able to replicate its behavior exactly in gcc Rust. So that means some code that rustc is ok with, gcc Rust might not be, and vice versa (even though all the code might be fine).
Post reply on HN