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

91–100 of 135 posts

Re: Rust front-end merged in GCC trunk

#91

Post by mustache_kimono »

m_nyongesa wrote: post #90
bayindirh wrote: post #60

Earlier quoted context omitted.

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

> I have no idea why your comment received downvotes.

I have to agree re: the parent. It's a perfectly fine opinion to hold, though it's one I don't share. I asked and he/she told me.

However, republishing an email by Richard Stallman, just like Richard Stallman, might seem a little excessive.

Why? I think it's because although just as it's fine to be an atheist, it always seems weird when someone brings it up at dinner parties. We were discussing the whys and wherefores of a new Rust compiler. I'm not sure any lengthy expressions of our licensing religion or lack thereof is a positive contribution.

Re: Rust front-end merged in GCC trunk

#92

Post by masklinn »

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

You can already do that. Some libraries wilfully restrict their MSRV for backwards compatibility or distro compatibility (e.g. Debian stable provides 1.48).

Re: Rust front-end merged in GCC trunk

#93

Post by masklinn »

GrayShade wrote: post #21
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.

That's rather rustc_codegen_gcc. gcc-rs is more for people who don't like LLVM and/or Rust. https://github.com/rust-lang/rustc_codegen_gcc

A rust implementation for people who don’t like rust seems like a strange take.

Re: Rust front-end merged in GCC trunk

#94

Post by c0l0 »

Probably a dumb question, but I'd really like to know if this somehow affects/improves Rust's support for dynamic linking in any way (i.e., when comiling Rust code with the GCC-based toolchain, instead of with rustc)?

Re: Rust front-end merged in GCC trunk

#95

Post by simplotek »

pornel wrote: post #59
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...

FSF wants to support Rust as a first-class language in GCC, which means their own implementation and ability to bootstrap without dependence on other projects. Having two independent implementations is good for finding code depending on compiler bugs. The development will also highlight where the Rust language is not documented/specified enough yet. The GCC implementation may end up with a different design, and perha…

> Having two independent implementations is good for finding code depending on compiler bugs.

I'd go as far as to claim that having multiple independent implementations is a basic requirement for any programming language which has any aspirations of being production-ready.

Re: Rust front-end merged in GCC trunk

#96

Post by thesuperbigfrog »

sseagull wrote: post #76
thesuperbigfrog wrote: post #52

Earlier quoted context omitted.

>> I’ve come to the conclusion that fragmentation is inevitable as a language gets popular. That's what language standards are for. The Ferrocene project is working on standardizing Rust and creating a safety-critical version of the Rust toolchain: https://ferrous-systems.com/ferrocene/ The Ferrocene Rust draft spec is out: https://spec.ferrocene.dev/ As Rust continues to improve and be more widely used and adopted,…

Standards are necessary and help of course. But the real power always lies with the implementations. There is no compliance without enforcement. For example, C++ has a standard, but compliance is all over the place. Even Fortran has the same problem. The web also had a standards body (W3C) but eventually that was completely ignored and became irrelevant.

>> Standards are necessary and help of course. But the real power always lies with the implementations. There is no compliance without enforcement.

You are correct.

Compliance depends on the implementation developer / maintainer. If the standard exists and is agreed upon, at least users can petition the implementation developer / maintainer and say "Your implementation does not conform to section 3, paragraph 2, line 1 of the standard. The expected behavior is X, but your implementation does Y. Please fix it."

If a standard does not exist, then who is to say what the correct behavior should be?

If there is a standard, but no one follows it, then perhaps the standard needs to be adjusted. (Why is the standard not being followed? Were bad ideas standardized? Did the standards committee follow after one vendor's implementation to the detriment of other vendors' implementations? etc.)

Re: Rust front-end merged in GCC trunk

#97

Post by simplotek »

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.

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

This comment is so blatantly wrong and detached from reality that it makes me wonder if it's just a good old fashioned troll.

You'd be hard-pressed to find any production programming language which does not have multiple independent implementations.

Re: Rust front-end merged in GCC trunk

#98

Post by choeger »

nine_k wrote: post #83
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.

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

On top of that, there so many lisp implementations, it's not even funny anymore.

Re: Rust front-end merged in GCC trunk

#99

Post by 411111111111111 »

simplotek wrote: post #95
pornel wrote: post #59

Earlier quoted context omitted.

FSF wants to support Rust as a first-class language in GCC, which means their own implementation and ability to bootstrap without dependence on other projects. Having two independent implementations is good for finding code depending on compiler bugs. The development will also highlight where the Rust language is not documented/specified enough yet. The GCC implementation may end up with a different design, and perha…

> Having two independent implementations is good for finding code depending on compiler bugs. I'd go as far as to claim that having multiple independent implementations is a basic requirement for any programming language which has any aspirations of being production-ready.

Thats just silly, there are a lot of production ready languages that only have one full implementation such as Typescript, Elixir etc

Re: Rust front-end merged in GCC trunk

#100

Post by choeger »

shakow wrote: post #77
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.

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

Kotlin is a prime example. You have to download the vendor implementation. There's no way to bootstrap. It's horrible from a tooling perspective.

Any single-implementation language inevitably degrades to the point where the implementation becomes the specification. Shortly afterwards, people can only use the language if their tool chain, operating system, etc. closely match the understanding of the language authors. That's a bad situation to be in.

Post reply on HN