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

231–240 of 300 posts

Re: GCC Rust Approved by GCC Steering Committee

#231

Post by jcranmer »

cogman10 wrote: post #169
msbarnett wrote: post #93

Earlier quoted context omitted.

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

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

You still have a limited window of 8 registers. Need 9 simultaneous live values? Oops, too few registers! In order to encode infinite registers, you need to be able to support referring to an arbitrary number of registers at once, which means you need an arbitrary-length register number specifier... have fun handling that in hardware!

Re: GCC Rust Approved by GCC Steering Committee

#232

Post by thrown_22 »

steveklabnik wrote: post #225
thrown_22 wrote: post #219

Earlier quoted context omitted.

>What is the benefit of having multiple compilers for programming languages? Rust will need a standard. The main reason why I don't take it seriously is that code written 5 years ago will often not compile today. For a language that pretends to be a systems language that is a non-starter. If you can't guarantee a 40 year shelf life of your code then no one working on systems cares. People working on systems in the wi…

> code written 5 years ago will often not compile today. citation needed. Yes, there's a few programs that relied on unsound things for which this is true, but that's a relatively small part of the overall amount of code.

>but that's a relatively small part of the overall amount of code.

Yes and?

Systems programming isn't front end JS work where breaking things doesn't matter. It's no surprise that Rust came out of the browser space. Only people who don't take their work seriously could ever think the above is a justification and not a red flag for never using it.

I welcome Rust becoming ossified in GCC so I can build 30 year old code without modification like I can in C. Until then, it's a toy for people with more time than responsibility.

Re: GCC Rust Approved by GCC Steering Committee

#233

Post by Tyr42 »

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…

Racket?

Re: GCC Rust Approved by GCC Steering Committee

#234

Post by cogman10 »

jcranmer wrote: post #231
cogman10 wrote: post #169

Earlier quoted context omitted.

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

> 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. You still have a limited window of 8 registers. Need 9 simultaneous live values? Oops, too few registers! In order to encode infinite registers, you need to be able to suppo…

> The only missing piece is moving overflow values onto and off of the stack.

Already addressed and not really that hard of an issue to solve. Hardware already has all the logic embedded in it to be able to load or store memory into/from registers.

The logic would mirror the logic done by compilers when they are allocating registers and deciding what needs to be evicted to the stack.

The only missing piece is where that memory should be, but that's really as simple as having either the OS or the application logic allocate a special memory region for the purpose of register evictions and loads.

Re: GCC Rust Approved by GCC Steering Committee

#235

Post by dahart »

cmurf wrote: post #174
Beltalowda wrote: post #163

Earlier quoted context omitted.

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

Do many/most people really think they should have the ability to repair it? I'm not sure because they keep buying products where it's expressly not possible to repair it yourself or by a competent 3rd party. So I'm not really sure it has any more meaning than free software means no cost rather than "no one and everyone owns the software".

> Do many/most people really think they should have the ability to repair it?

“Ability” is the wrong word here, why did you use that word? It’s ambiguous and misleading, that’s why it’s called the right to repair.

Yes most people do assume they have the right to modify and fix something they “own”, whether it’s a car or a computer or anything else. Don’t you think it’s surprising and non-obvious that you might not be allowed to repair something you paid for and own, even when you know how to repair it? Whether they ever intend to repair something, and whether they have the knowledge to repair something, are both irrelevant to whether they have the legal right to repair something.

> they keep buying products where it’s expressly not possible to repair it yourself or by a competent 3rd party.

Most people have no intention of repairing their technical purchases themselves, and that’s perfectly fine. Most people also don’t care about right to repair laws even if it affects them. The point of right to repair laws is to establish the common sense standard that consumers are allowed to legally modify their purchases, and companies will no longer be allowed to go out of their way to prevent repairs or make them difficult (also and perhaps especially wrt 3rd parties), and also that companies and lawmakers will no longer be able to make customizing and repairing purchased products illegal as has been done in the past.

Re: GCC Rust Approved by GCC Steering Committee

#236

Post by guipsp »

mbStavola wrote: post #199

I have mixed feelings about the idea of a GCC frontend for Rust. On one hand, having frontend diversity for a language helps bring new people into the language; think of the groups who can't use Rust because it doesn't support certain targets or can't integrate with their existing toolchain. There is a lot of talent that could be brought into Rust just by virtue of them being able to be included and the less barriers…

This does clarify that concern: https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...

Re: GCC Rust Approved by GCC Steering Committee

#237

Post by kibwen »

j16sdiz wrote: post #140

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

The Rust type system wonks are highly motivated to precisely specify the entire type system, including the borrow checker. A new Types Team was formed earlier this year with the goal of producing a specification against which new type system features can be prototyped for soundness before being approved (borne out of, among other things, frustration with the long-unstable and long-incomplete "specialization" feature, which nobody has yet found a sound formulation for).

Re: GCC Rust Approved by GCC Steering Committee

#238

Post by ATsch »

pjmlp wrote: post #205
ATsch wrote: post #127

Earlier quoted context omitted.

Adding a GCC backend for Rust (rust-codegen-gcc) does this already. I do not personally see the point of writing another frontend in C++.

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.

Re: GCC Rust Approved by GCC Steering Committee

#239

Post by dahart »

bastardoperator wrote: post #115
mistrial9 wrote: post #53

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

GNU is pretty clear: To understand the concept, you should think of “free” as in “free speech,” not as in “free beer.” We sometimes call it “libre software,” borrowing the French or Spanish word for “free” as in freedom, to show we do not mean the software is gratis.

It might seem clear to those of us who’ve heard the whole story, but free speech isn’t a great analogy at all, which means this will always require a lengthy explanation to someone new to the concept. Free speech is a constitutionally protected right in the US (and something else in other countries) that comes with a list of limitations and exceptions, while “free software” is not in general a legally protected right, and in GNU’s implementation requires a viral license that eliminates some kinds of freedom, e.g., it’s specifically and explicitly not public domain. It’s fine to clarify that “free” doesn’t mean money in this case, but that’s hardly a clear explanation of what it does mean.

Re: GCC Rust Approved by GCC Steering Committee

#240

Post by topspin »

faisal_ksa wrote: post #98

What is the benefit of having multiple compilers for programming languages? Is there a scenario where a GCC compiled rust program would do something that an LLVM one can't do? Doesn't this cause fragmentation in the rust ecosystem? P.S.:I understand that people can work on any project they want. And I don't have the right to tell them not to. I'm just curious about the technical reasons for having multiple compilers.

> What is the benefit of having multiple compilers for programming languages?

I'll give you one, or two, depending on what you'd like to count. At some point in the conceivable future we'll be able to compile some meaningful Rust code base with both compilers and measure; a.) how long it takes to compile and b.) the performance of the compiled code.

Obviously that will induce what it always has: incentive to improve.

Post reply on HN