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

91–100 of 179 posts

Re: GCC Rust: GCC Front-End for Rust

#91

Post by Blikkentrekker »

unanswered wrote: post #85
Blikkentrekker wrote: post #64

Earlier quoted context omitted.

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.

Because tools and businesses are not titles that qualify for intellectual property, a piece of software is.

I do not italicize Google the company either, but I do that of Google the search engine.

The titles of scientific research papers are also typically italicized.

Re: GCC Rust: GCC Front-End for Rust

#92

Post by [deleted] »

steveklabnik wrote: post #36
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 general sentiment of the community and leadership is that this project is a good thing, so you are unlikely to get your wish.

[deleted]

Re: GCC Rust: GCC Front-End for Rust

#93

Post by zabzonk »

steveklabnik wrote: post #88
zabzonk wrote: post #84

Earlier quoted context omitted.

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

Well, I agree that standardisation and "maturity" (whatever that may mean) are not connected, but I think most C and C++ programmers (to name two very widely used languages that I personally have a lot of knowledge of) find the respective standards for those languages very helpful, and somewhat lament the lack of formal standards for other languages they may use.

Re: GCC Rust: GCC Front-End for Rust

#94

Post by steveklabnik »

zabzonk wrote: post #93
steveklabnik wrote: post #88

Earlier quoted context omitted.

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

Well, I agree that standardisation and "maturity" (whatever that may mean) are not connected, but I think most C and C++ programmers (to name two very widely used languages that I personally have a lot of knowledge of) find the respective standards for those languages very helpful, and somewhat lament the lack of formal standards for other languages they may use.

Yes. I do think that standardization is generally good. I am pro Rust getting a specification! I just think it is one pro among many, and not something required for success.

Re: GCC Rust: GCC Front-End for Rust

#95

Post by Ericson2314 »

A bit off topic, I hope someday GCC's build system gets overhauled. A huge advantage of LLVM is that it is quite easier to rebuild the runtime libraries without rebuilding the compiler. With GCC that's a pain, unless one takes the time to re-package GCC very carefully like https://github.com/richfelker/musl-cross-make and https://exherbo.org/.

Maybe getting some new GCC devs in there with projects like this would help with that?

Re: GCC Rust: GCC Front-End for Rust

#96

Post by Nullabillity »

unanswered wrote: post #27
yorwba wrote: post #4

The timeline looks rather ambitious https://github.com/Rust-GCC/gccrs/milestones

It also looks rather incomplete. Are they not planning on implementing borrowck? If chalk/polonius were ready and had a C API the roadmap would begin to make sense.

Makes sense to me. As mrustc[0] mentions, implementing validation in a secondary compiler is much less important, because you can always just run the reference implementation as a glorified linter in the meantime.

[0]: https://github.com/thepowersgang/mrustc

Re: GCC Rust: GCC Front-End for Rust

#97

Post by IainIreland »

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?

In a past life I worked on a COBOL compiler for IBM.

There is a COBOL specification, but AFAIK nobody actually implements it fully. Implementations pick and choose new features based on customer demand.

Also, COBOL is dominated by large legacy codebases, which means that if there's a discrepancy between an implementation and the specification, the users normally don't want it fixed, because they may have written code that depends on the "incorrect" behaviour and it's a lot of work to audit.

IBM built a new backend for its COBOL compiler using the optimizer from their JVM. IIRC by the time I left it generated code that was ~2x faster than the old compiler, but uptake was still slow because of migration concerns. In particular, we spent a lot of time working on features to help guarantee that code with some forms of undefined behaviour would have the same result as the old version.

Re: GCC Rust: GCC Front-End for Rust

#99

Post by cbmuser »

oconnor663 wrote: post #14
faitswulff wrote: post #5

I'm not sure if what I'm asking makes sense, but since it's written for a new backend, would the authors have to bootstrap it using a different toolchain? I guess what I'm asking is, could they use the LLVM Rust to build the GCC frontend or do they have to start all over with a different base language to get a first working version of a rust compiler?

The LLVM-based Rust compiler uses a lot of unstable/nightly-only Rust features internally. So even if this project got to the point where it could compile all stable Rust programs, I think it would take quite a bit more work than that to be able to compile `rustc` itself. (It might be that the unstable stuff is mostly in the standard library and not the compiler itself? Does it make a difference?)

Isn‘t mrustc already able to compile rustc?

Re: GCC Rust: GCC Front-End for Rust

#100

Post by volta87 »

potatochup wrote: post #98

Does this mean that compilation target currently supported by GCC would now allow rust to target that architecture? Specifically I'm thinking of PPC cores with the VLE extension, which LLVM does not support (as far as I'm aware).

llvm does support ppc64le cores with VSX extension; if thats what you mean

in fact, IBM uses LLVM proper as its own compiler backend for its ppc processors

Post reply on HN