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

91–100 of 300 posts

Re: GCC Rust Approved by GCC Steering Committee

#91

Post by msbarnett »

nicoburns wrote: post #81
dolni wrote: post #78

Earlier quoted context omitted.

The first amendment to the US Constitution provides very strong protection for the right to free speech. Presumably that is the origin of "free as in speech".

Right, but what about "free as in beer"?

"Free-as-in-speech, not free-as-in-beer" is just expecting you the hearer to understand that while event advertisements might prominently feature the words "free beer" as an exciting statement that beer is being given away for zero cost to drive interest, zero cost is not the sense in which "free" is being used in "free software"

Re: GCC Rust Approved by GCC Steering Committee

#92

Post by [deleted] »

nicoburns wrote: post #75
rascul wrote: 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.

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

[deleted]

Re: GCC Rust Approved by GCC Steering Committee

#93

Post by msbarnett »

cogman10 wrote: post #76
jerf wrote: post #40

Earlier quoted context omitted.

Generally, no. The IR will be tuned for compiler purposes, not execution purposes. It can be possible but it won't be optimal. For instance, the IR will probably retain type information that generally CPUs don't care about, since they live in a world of bits. The IR will have been designed knowing it is upstream of optimization code, so it won't be something that is already optimal, it'll be something designed to be…

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.

Re: GCC Rust Approved by GCC Steering Committee

#94

Post by dragonwriter »

nicoburns wrote: post #75
rascul wrote: 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.

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

The culture reference is to commercial goods (like beer) being given away at zero cost as a promotion. (“Beer” is probably not the best example but is conveniently terse; for Boomers, “toasters”—in reference to bank promotions—might be more culturally relevant, for younger generations “-to-play” in reference to F2P games might be, but neither rolls off the tongue as well.)

Re: GCC Rust Approved by GCC Steering Committee

#95

Post by stjohnswarts »

pabs3 wrote: post #19

Another related project is the libgccjit backend for rustc: https://github.com/rust-lang/rustc_codegen_gcc

Lots of people are spending time with libgccjit for compiling Emacs modules to speed them up with the "native compiled" version of emacs. I've tried it with doom emacs and it definitely speeds up things and seems stable enough.

Re: GCC Rust Approved by GCC Steering Committee

#96

Post by hedora »

outside1234 wrote: post #2

Why would someone want this? (Honest question)

Competition.

GCC had laughably bad error messages before LLVM caught on. Even then, LLVM generated terrible code compared to GCC. There's a similar competition going on with open source linkers (which are finally going multi-threaded).

Both compiler toolchains currently blow pre-LLVM GCC out of the water (and GCC development has noticeably accelerated since LLVM came out).

I'm not sure which one is better at which C++ thing these days, but I'll bet GCC Rust will beat LLVM Rust at some important things in a few years (and then vice versa).

Re: GCC Rust Approved by GCC Steering Committee

#97

Post by stjohnswarts »

thealienthing wrote: post #79

Does having rust support for GCC mean potentially faster rust compiler times compared to comping off of LLVM platform?

I mean maybe, sure? I don't think that's their end goal, as their main purpose is to have a gcc version for gcc folks, whether it's faster or slower than llvm isn't a goal though. I think first goal is to get it done and stable and forces in place to keep up with the ever updating Rust spec(s). It would also allow for a much wider number of platforms as gcc compiler is much higher coverage of platforms especially legacy ones.

Re: GCC Rust Approved by GCC Steering Committee

#98

Post by faisal_ksa »

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.

Re: GCC Rust Approved by GCC Steering Committee

#99

Post by rayiner »

colejohnson66 wrote: post #13
sdfhdhjdw3 wrote: post #11

What does a "front-end" mean exactly, in this context?

At a high level, GCC and LLVM are divided into two ends: the front and the back. The front end takes the source code and turns it into some form that's language agnostic (e.g. LLVM bitcode). The back end takes those structures and turns it into machine code. This allows the compiler to be modular. Old compilers didn't use this concept. So a C->x86 compiler and a Fortran->x86 one couldn't share code as easily. And if…

How “old” are we talking about here? Multiple language front ends sharing a common IR is a concept that dates to the 50s: https://academic.oup.com/comjnl/article/22/3/226/408542 (click through to the pdf)

Re: GCC Rust Approved by GCC Steering Committee

#100

Post by davidatbu »

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.

This is answered in various replies to other comments.
Post reply on HN