Rust front-end merged in GCC trunk

Post by globalreset » Wed, Dec 14, 2022, 6:06 PM UTC

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.

Post by cstrahan » Wed, Dec 14, 2022, 6:16 PM UTC

masklinn wrote: post #93

GrayShade wrote: post #21

Earlier quoted context omitted.

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.

Post by catiopatio » Wed, Dec 14, 2022, 7:32 PM UTC

ajross wrote: post #88

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

Post by surajrmal » Wed, Dec 14, 2022, 8:25 PM UTC

pornel wrote: post #109

simplotek wrote: post #106

Earlier quoted context omitted.

> since it enables a lot of cool tooling What leads you to believe that the lack of alternatives leads to enabling "a lot of cool tooling"? > and great new features are introduced quickly in the official implementation. That has zero to do with existing only a single implementation, and everything to do with having developers working on unstable releases and a poor job thinking things though by writing stuff down bot…

> What leads you to believe that the lack of alternatives leads to enabling "a lot of cool tooling"? Rust projects have settled on Cargo, which gives them uniform way of building, testing, getting dependencies, docs generation ( https://docs.rs ), IDE support, etc. ( https://lib.rs/development-tools/cargo-plugins ) Contrast this with C which has several compilers and plenty of build systems to choose from, often more…

Post by hejaodbsidndbd » Wed, Dec 14, 2022, 8:30 PM UTC

simplotek wrote: post #105

411111111111111 wrote: post #99

Earlier quoted context omitted.

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

> (...) such as Typescript It seems you're oblivious to the fact that projects such as swc[1] exist, and have been adopted by projects such as deno. [1] https://swc.rs/ > Elixir etc I'm not familiar with Elixir nor am I in a googling mood. Nevertheless that was an awfully short list. Why is that?