Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust front-end merged in GCC trunk

gcc.gnu.org

Post reply on HN
Print view View original

81–90 of 135 posts

Re: Rust front-end merged in GCC trunk

#81

Post by cesarb »

3836293648 wrote: post #70
JoshTriplett wrote: post #36

Earlier quoted context omitted.

The gccrs developers have talked at length with Rust developers towards the same aim: they don't want to create fragmentation either. Among other things, the gccrs developers have said in multiple places both public and private: - They aren't going to fork or extend the language; they'll work with the normal Rust language evolution process. - They're treating rustc as the reference for correct Rust. This doesn't mean…

They don't have to extend the language to create fragmentation. Being far enough behind rustc is enough

> Being far enough behind rustc is enough

But rustc itself can be far enough behind rustc, as the MSRV debate shows.

Re: Rust front-end merged in GCC trunk

#82

Post by shakow »

stefantalpalaru wrote: post #79
shakow wrote: post #77

Earlier quoted context omitted.

> Because single implementation languages are toys ‶Toys″ like Go, OCaml, arguably Ruby & PHP, Perl, Erlang, Kotlin, ...

> ‶Toys″ like Go https://gcc.gnu.org/onlinedocs/gccgo/

Honestly curious, I know it exists, just like there used to be GCJ, but have you seen it being actually used?

Re: Rust front-end merged in GCC trunk

#83

Post by nine_k »

3836293648 wrote: post #69
rayiner wrote: post #58

Earlier quoted context omitted.

Because single implementation languages are toys. Any real language will have a multiplicity of implementations for different purposes. GCC has a ton of development resources behind it; processor makers are familiar with it and often turn to it to bring up new processors and ISAs, etc. Having a GCC front end is a big step in Rust becoming more popular as a systems language.

This simply isn't true. Only C/C++ people have ever cared about having multiple implementations and have to cling to the catastrophe that those two standards are because of it.

Somehow Python people, Java people, Ruby people, JavaScript people managed to produce multiple independent high-quality implementations.

Re: Rust front-end merged in GCC trunk

#84

Post by shakow »

bayindirh wrote: post #80
shakow wrote: post #77

Earlier quoted context omitted.

> Because single implementation languages are toys ‶Toys″ like Go, OCaml, arguably Ruby & PHP, Perl, Erlang, Kotlin, ...

Go has a GCC implementation (which I use). PHP has alternative VMs and specialized servers for serving it fast and in encrypted manner (they are closed sourced), tho. Kotlin runs on JVM, which has at least three fully compliant implementations. Erlang is a specialized language and telecommunications platform. It’s something different.

> PHP has alternative VMs and specialized servers for serving it fast and in encrypted manner (they are closed sourced), tho.

Well, if they are not public, it does not really have any influence on language specification.

> Kotlin runs on JVM, which has at least three fully compliant implementations.

And Rust runs on x86 which has myriad of implementations; still, we're talking about the language compiler, not the underlying runtime.

> Erlang is a specialized language and telecommunications platform. It’s something different.

How so? It's a language built over a runtime, just like Java. I don't see how the specifics of the runtime have to do with anything.

Re: Rust front-end merged in GCC trunk

#85

Post by ilayn »

rayiner wrote: post #58
skitter wrote: post #37

I have asked this question before, but why write an entirely new frontend, which is an enormous task if you want to reach a similar quality to rustc? rustc_codegen_gcc¹ adds gcc as a backend to rustc alongside llvm, miri and (wip) cranelift. As a result, it always works with the newest version of rust and is already nearly complete after less work. ¹ https://github.com/rust-lang/rust/tree/master/compiler/rustc...

Because single implementation languages are toys. Any real language will have a multiplicity of implementations for different purposes. GCC has a ton of development resources behind it; processor makers are familiar with it and often turn to it to bring up new processors and ISAs, etc. Having a GCC front end is a big step in Rust becoming more popular as a systems language.

Multiple implementations brought only trouble and frustration to the masses and endless opportunities for companies to exploit feature lock-ins (borland anyone?) . If anything drives people mad more than anythong are gcc vs clang vs msvc vs this or that issues. Just the whole complex numbers or quad precision issue is the best example from math handling. It is basically very unsuccessful stakeholder management to say the least. One of the main reasons for us to switch to Rust is not having multiple implementations.

Re: Rust front-end merged in GCC trunk

#86

Post by wofo »

amaranth wrote: post #66
wofo wrote: post #9

Earlier quoted context omitted.

I think this is more of an attempt of making Rust compilable on platforms not supported by LLVM, not an attempt to replace the existing compiler. The GCC frontend, for instance, does not implement the borrow checker, so you should only use it to compile Rust code you know is correct according to the official Rust compiler.

This is eventually going to be a feature-complete compiler, targeting a specific rustc version. I believe the plan is to use polonius [1], presumably as an "optional" feature so they can build a stage 1 without it, use that to build polonius, then build the final compiler with it included. [1] https://github.com/rust-lang/polonius

You are right, this much more ambitious than I though! Here is more information about the project, for the curious: https://rust-gcc.github.io/

Re: Rust front-end merged in GCC trunk

#87

Post by nine_k »

bayindirh wrote: post #80
shakow wrote: post #77

Earlier quoted context omitted.

> Because single implementation languages are toys ‶Toys″ like Go, OCaml, arguably Ruby & PHP, Perl, Erlang, Kotlin, ...

Go has a GCC implementation (which I use). PHP has alternative VMs and specialized servers for serving it fast and in encrypted manner (they are closed sourced), tho. Kotlin runs on JVM, which has at least three fully compliant implementations. Erlang is a specialized language and telecommunications platform. It’s something different.

For PHP, there is HVVM which, AFAICT, can run vanilla PHP and is open.

TruffleRuby is a thing, as is JRuby.

Implementing Erlang without implementing its VM and the whole infrastructure, which is a much larger task than merely a VM like Python's.

Re: Rust front-end merged in GCC trunk

#88

Post by ajross »

skitter wrote: post #37

I have asked this question before, but why write an entirely new frontend, which is an enormous task if you want to reach a similar quality to rustc? rustc_codegen_gcc¹ adds gcc as a backend to rustc alongside llvm, miri and (wip) cranelift. As a result, it always works with the newest version of rust and is already nearly complete after less work. ¹ https://github.com/rust-lang/rust/tree/master/compiler/rustc...

The same reasons given[1] for "why write clang when gcc works fine", mostly? Multiple implementations of a language force rigor in the specification[2], find edge cases in implementations, and promote healthy competition in performance.

[1] The good reasons, anyway. Please no GPL screaming.

[2] Something that IMHO rust has historically been kinda bad at. Even now there remains no clear specification I can find that explains exactly what behavior the borrow checker will admit vs. reject.

Re: Rust front-end merged in GCC trunk

#89

Post by dataflow »

rayiner wrote: post #71
3836293648 wrote: post #69

Earlier quoted context omitted.

This simply isn't true. Only C/C++ people have ever cared about having multiple implementations and have to cling to the catastrophe that those two standards are because of it.

Oh, “only C/C++ people.” I.e. the people who wrote almost all the systems code in the last 40 years. Just those people.

> Because single implementation languages are toys. Any real language will have a multiplicity of implementations for different purposes.

I think that's what the parent was replying to, not somehow claiming C/C++ people are insignificant.

Re: Rust front-end merged in GCC trunk

#90

Post by m_nyongesa »

bayindirh wrote: post #60
mustache_kimono wrote: post #54

Earlier quoted context omitted.

> We need competition. I'm not using (even avoiding) LLVM based toolchains, and not touching Rust even with a 100 foot pole because of that. I'm interested in this. Could you elaborate on why you are not using Rust? Because there is no competition in the language, or because there is not an alternate compiler, or because you don't like LLVM?

It's mostly a personal choice. Any piece of software I write is opened up, and licensed with GPL. I don't want my software dependent on a non-GPL toolchain to ensure its long term sustainability. I also try to choose GPL licensed libraries, and include everything required to build my code (incl. external libraries) inside my repository. In the end I want someone to be able to just clone the repo, and run make, or GCC…

I upvoted you. I have no idea why your comment received downvotes.

I responded in a similar way to a conversation about Julia less than a week ago.

For people who have trouble understanding this reasoning, a message from the GCC mailing list (https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html) provides some of the explanation, which I reproduce here:

In the free software movement, we campaign for the freedom of the users of computing. The values of free software are fundamentally different from the values of open source, which make "better code" the ultimate goal. If GCC were to change from a free compiler into a platform for nonfree compilers, it would no longer serve the goal of freedom very well. Therefore, we had to take care to prevent that.

(See http://www.gnu.org/philosophy/open-source-misses-the-point.h... for more explanation of the difference between free software and open source. See also https://thebaffler.com/salvos/the-meme-hustler for Evgeny Morozov's article on the same point.)

The Clang and LLVM developers reach different conclusions from ours because they do not share our values and goals. They object to the measures we have taken to defend freedom because they see the inconvenience of them and do not recognize (or don't care about) the need for them. I would guess they describe their work as "open source" and do not talk about freedom. They have been supported by Apple, the company which hates our freedom so much that its app store for the ithings _requires_ all apps to be nonfree. (*)

The nonfree compilers that are now based on LLVM prove that I was right -- that the danger was real. If I had "opened" up GCC code for use in nonfree combinations, that would not have prevented a defeat; rather, it would have caused that defeat to occur very soon.

For GCC to be replaced by another technically superior compiler that defended freedom equally well would cause me some personal regret, but I would rejoice for the community's advance. The existence of LLVM is a terrible setback for our community precisely because it is not copylefted and can be used as the basis for nonfree compilers -- so that all contribution to LLVM directly helps proprietary software as much as it helps us.

The cause of the setback is the existence of a non-copylefted compiler that therefore becomes the base for nonfree compilers. The identity of that compiler -- whether it be LLVM, GCC, or something else -- is a secondary detail. To make GCC available for such use would be throwing in the towel. If that enables GCC to "win", the victory would be hollow, because it would not be a victory for what really matters: users' freedom.

If you think we ought to "compromise" on this point, please see http://www.gnu.org/philosophy/compromise.html.

The only code that helps us and not our adversaries is copylefted code. Free software released under a pushover license is available for us to use, but available to our adversaries just as well. If you want your work to give freedom an advantage, use the leverage available to you -- copyleft your code. I invite those working on major add-ons to LLVM to release them under GNU GPL version-3-or-later.

* If a binary is made from published source code, but you can't install your binary of a modified version of that source code, the binary is proprietary even if the source code is free. (See http://www.gnu.org/philosophy/free-sw.html.) A binary in Apple's app store may be made from published free source code, but under Apple's rules and Apple's DRM, the binary can't be free.

Post reply on HN