7 ms·

I hope there aint gonna be ecosystem fragmentation When there are a fews compilers with significant market share then developers are those who lose, lose that

I hope there aint gonna be ecosystem fragmentation When there are a fews compilers with significant market share then developers are those who lose, lose that handy dev. experience of solid and consistent ecosystem I hope it will be used only where necessary

wofo 4y ago
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.
- GrayShade 4y ago
  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 https://github.com/rust-lang/rustc_codegen_gcc
  - masklinn 4y ago
    A rust implementation for people who don’t like rust seems like a strange take.
    - cstrahan 4y ago
      Not too strange. Imagine the reverse: a C compiler written in Rust. There is an awful lot of software in C that I want to use, but I really dislike C itself. If I found some deficiency in C compilers and felt the need to write my own, I certainly would prefer to write it in Rust. It would be a C implementation for people who don't like C.
- hawk_ 4y ago
  No borrow checking is effectively a dialect of Rust?
  - kibwen 4y ago
    Without a borrow checker, at best it can be considered a code generator for pre-certified Rust source code. Possibly useful, but you'd still need to have rustc in the loop.
- Myrmornis 4y ago
  It seems like an odd idea to release a Rust compiler without a borrow checker. Isn't there a high risk that it will confuse users into thinking they have the usual Rust guarantees at run-time?
  - rapsey 4y ago
    Borrow checker is compile time. There is no reason to have multiple implementations.
    - Myrmornis 4y ago
      Yup, it's compile-time, and gives you run-time guarantees.
  - jamincan 4y ago
    I think the expectation for now is that people will develop an app with rustc and then use gcc to compile to targets that aren't yet supported by llvm.
  - tuetuopay 4y ago
    This can be very useful for platforms where rustc is not available due to LLVM not supporting them. Take a project, build it with rustc, and if it builds, you know it passes the borrow checker. It is then safe to build it for your actual target with gcc. This would limit the outcry when some software adds a dependency on Rust, like the python crypto thing of a few years back, or the Linux kernel.
    - GrayShade 4y ago
      Why not use this instead? https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc
      - tuetuopay 4y ago
        This will still use the official rustc frontend. For what I described above, this is not an issue, it would totally work. However, there are cases where having a pure gcc implementation (frontend + backend) is beneficial. As others have mentioned, vendors have the standard practice to fork gcc for their hardware, but not necessarily rustc nor libgcc used by rustc_codegen_gcc. This means that rust will be possible on those platforms for free thanks to gcc-rs. Another point is the bootstrapping of the compiler. rustc has a quite complex bootstrap process that depends on python, while afaik gcc only relies on shell scripts. It is much easier to port gcc than rustc to a new host platform. This is useful when you want to compile code directly on your target and don't want to rely on cross compilation. cross compiling is a tricky thing to do, and while rust fares pretty well there, as soon as it uses native C libraries, it all falls apart (e.g. try cross compiling a project that has dependencies on libss, libpq and the like). In such case, native compilation may be the only viable option. And most of the times, GCC is the first thing to be ported, so you would not need to wait for a rustc port.
- mkj 4y ago
  Lacking a borrow checker is a temporary thing, no point reinventing the wheel. I think the intent is that eventually it'll use the same library as Rust (maybe Polonius, or perhaps plans will change)
- amaranth 4y ago
  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 https://github.com/rust-lang/polonius
  - wofo 4y ago
    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/ https://rust-gcc.github.io/
- eloff 4y ago
  That could be a feature. I'm making a joke, but it would be tempting sometimes when the program is correct but the borrow checker can't figure that out. The borrow checker and I don't get along all that well, even two years into the relationship.
sseagull 4y ago
I’ve come to the conclusion that fragmentation is inevitable as a language gets popular. People think differently, have different ideas for how to do things, need it to work for their particular use case, etc. Fragmentation and bloat are a result. I am willing to bet it will happen rust as it gets used more and more. Then the treadmill will start again with a new language. (Sorry if that’s jaded. I’ve been fighting with python build systems lately. What a nightmare)
- hardware2win 4y ago
  Counter example: .net c# One compiler for 99%, one package manager, one base classes liberary, one cli, etc.
  - ptx 4y ago
    One Microsoft Way.
- thesuperbigfrog 4y ago
  >> 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/ https://ferrous-systems.com/ferrocene/ The Ferrocene Rust draft spec is out: https://spec.ferrocene.dev/ https://spec.ferrocene.dev/ As Rust continues to improve and be more widely used and adopted, there will be multiple implementations. As you've stated, it is inevitable as Rust gets popular. (For example, if Rust becomes popular enough to displace niches that C and C++ have occupied, when will Microsoft release a Rust toolchain? When will Intel release a Rust toolchain? And so forth.) Standards help to better define what a Rust toolchain should do and what it means to be a conforming Rust implementation.
  - sseagull 4y ago
    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.
JoshTriplett 4y ago
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 there can't be bugs in either rustc or gccrs, and rustc will deeply appreciate bug reports found through this level of inspection of its behavior, but nonetheless this is a stated goal of the gccrs folks. - They plan to explicitly provide messaging, potentially even in compiler error messages, to the effect of "if gccrs doesn't compile a crate that does compile on rustc, that's a bug in gccrs, not a bug in that crate; do not report it as a bug in that crate or ask crate developers to work around gccrs limitations". So, I think the gccrs folks are doing everything they can to avoid fragmentation, short of the project not existing at all.
- 3836293648 4y ago
  They don't have to extend the language to create fragmentation. Being far enough behind rustc is enough
  - cesarb 4y ago
    > Being far enough behind rustc is enough But rustc itself can be far enough behind rustc, as the MSRV debate shows.
  - masklinn 4y ago
    You can already do that. Some libraries wilfully restrict their MSRV for backwards compatibility or distro compatibility (e.g. Debian stable provides 1.48).
  - JoshTriplett 4y ago
    No argument there, but I think the third point helps address that somewhat.
bayindirh 4y ago
I disagree. 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. On the other hand, I acknowledge that LLVM kickstarted GCC development and made it better in thousand ways better, agile and flexible-minded (in terms of developers maintaining it). Similarly, having two Rust compilers, nudging each other to be better is a great way to make a language more general, widely accepted, resilient and more free & open. Also Rust well be much more stressed and tested as a result. > I hope it will be used only where necessary I hope both will be used widely, and make Rust a better language with much better accessibility.
- deleted 4y ago
  [deleted]
- hardware2win 4y ago
  >We need competition There is - between langs. Compiler engineers can use ideas from other lang's compilers. C# e.g
  - bayindirh 4y ago
    I think having a GPL implementation of a language makes it more future proof. I don't want to be able compile some source only with "rustc-v_ancient-company_name-internal_fork-no_you_cant_have_its_source" version. Programming languages with single compilers tend to be not used in my area of work and research (HPC and Scientific Computing). Hence, I'd rather have multiple compatible, yet independently implemented compilers, per language.
    - mustache_kimono 4y ago
      > I don't want to be able compile some source only with "rustc-v_ancient-company_name-internal_fork-no_you_cant_have_its_source" version. Yeah, it's not like Google (and dozens of others) has/have an internal fork of Linux, which never gets merged back. I'm not certain the GPL butters any parsnips here. > Hence, I'd rather have multiple compatible, yet independently implemented compilers, per language. You identified it. The problem is compatibility, and again Linux is a good negative example where ostensibly we have a language spec and multiple compilers, but Linux for years would only compile on one compiler. Multiple compilers and "competition" doesn't solve compatibility. It makes it more difficult. Although I'm sure there will be benefits, I'm not certain the GPL/GCC will make compatibility any easier. It hasn't so far.
gardaani 4y ago
It's certain that there will be fragmentation. There isn't any gnu project, which hasn't added its own extensions to standards or specs. Few examples: gcc front end for C/C++, bash, grep.. It means that crates.io will have crates which compile only with gcc and its extensions.

wofo 4y ago

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.

GrayShade 4y ago
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 https://github.com/rust-lang/rustc_codegen_gcc
- masklinn 4y ago
  A rust implementation for people who don’t like rust seems like a strange take.
  - cstrahan 4y ago
    Not too strange. Imagine the reverse: a C compiler written in Rust. There is an awful lot of software in C that I want to use, but I really dislike C itself. If I found some deficiency in C compilers and felt the need to write my own, I certainly would prefer to write it in Rust. It would be a C implementation for people who don't like C.
hawk_ 4y ago
No borrow checking is effectively a dialect of Rust?
- kibwen 4y ago
  Without a borrow checker, at best it can be considered a code generator for pre-certified Rust source code. Possibly useful, but you'd still need to have rustc in the loop.
Myrmornis 4y ago
It seems like an odd idea to release a Rust compiler without a borrow checker. Isn't there a high risk that it will confuse users into thinking they have the usual Rust guarantees at run-time?
- rapsey 4y ago
  Borrow checker is compile time. There is no reason to have multiple implementations.
  - Myrmornis 4y ago
    Yup, it's compile-time, and gives you run-time guarantees.
- jamincan 4y ago
  I think the expectation for now is that people will develop an app with rustc and then use gcc to compile to targets that aren't yet supported by llvm.
- tuetuopay 4y ago
  This can be very useful for platforms where rustc is not available due to LLVM not supporting them. Take a project, build it with rustc, and if it builds, you know it passes the borrow checker. It is then safe to build it for your actual target with gcc. This would limit the outcry when some software adds a dependency on Rust, like the python crypto thing of a few years back, or the Linux kernel.
  - GrayShade 4y ago
    Why not use this instead? https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc
    - tuetuopay 4y ago
      This will still use the official rustc frontend. For what I described above, this is not an issue, it would totally work. However, there are cases where having a pure gcc implementation (frontend + backend) is beneficial. As others have mentioned, vendors have the standard practice to fork gcc for their hardware, but not necessarily rustc nor libgcc used by rustc_codegen_gcc. This means that rust will be possible on those platforms for free thanks to gcc-rs. Another point is the bootstrapping of the compiler. rustc has a quite complex bootstrap process that depends on python, while afaik gcc only relies on shell scripts. It is much easier to port gcc than rustc to a new host platform. This is useful when you want to compile code directly on your target and don't want to rely on cross compilation. cross compiling is a tricky thing to do, and while rust fares pretty well there, as soon as it uses native C libraries, it all falls apart (e.g. try cross compiling a project that has dependencies on libss, libpq and the like). In such case, native compilation may be the only viable option. And most of the times, GCC is the first thing to be ported, so you would not need to wait for a rustc port.
mkj 4y ago
Lacking a borrow checker is a temporary thing, no point reinventing the wheel. I think the intent is that eventually it'll use the same library as Rust (maybe Polonius, or perhaps plans will change)
amaranth 4y ago
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 https://github.com/rust-lang/polonius
- wofo 4y ago
  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/ https://rust-gcc.github.io/
eloff 4y ago
That could be a feature. I'm making a joke, but it would be tempting sometimes when the program is correct but the borrow checker can't figure that out. The borrow checker and I don't get along all that well, even two years into the relationship.

sseagull 4y ago

I’ve come to the conclusion that fragmentation is inevitable as a language gets popular. People think differently, have different ideas for how to do things, need it to work for their particular use case, etc. Fragmentation and bloat are a result. I am willing to bet it will happen rust as it gets used more and more. Then the treadmill will start again with a new language. (Sorry if that’s jaded. I’ve been fighting with python build systems lately. What a nightmare)

hardware2win 4y ago
Counter example: .net c# One compiler for 99%, one package manager, one base classes liberary, one cli, etc.
- ptx 4y ago
  One Microsoft Way.
thesuperbigfrog 4y ago
>> 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/ https://ferrous-systems.com/ferrocene/ The Ferrocene Rust draft spec is out: https://spec.ferrocene.dev/ https://spec.ferrocene.dev/ As Rust continues to improve and be more widely used and adopted, there will be multiple implementations. As you've stated, it is inevitable as Rust gets popular. (For example, if Rust becomes popular enough to displace niches that C and C++ have occupied, when will Microsoft release a Rust toolchain? When will Intel release a Rust toolchain? And so forth.) Standards help to better define what a Rust toolchain should do and what it means to be a conforming Rust implementation.
- sseagull 4y ago
  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.

JoshTriplett 4y ago

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 there can't be bugs in either rustc or gccrs, and rustc will deeply appreciate bug reports found through this level of inspection of its behavior, but nonetheless this is a stated goal of the gccrs folks. - They plan to explicitly provide messaging, potentially even in compiler error messages, to the effect of "if gccrs doesn't compile a crate that does compile on rustc, that's a bug in gccrs, not a bug in that crate; do not report it as a bug in that crate or ask crate developers to work around gccrs limitations". So, I think the gccrs folks are doing everything they can to avoid fragmentation, short of the project not existing at all.

3836293648 4y ago
They don't have to extend the language to create fragmentation. Being far enough behind rustc is enough
- cesarb 4y ago
  > Being far enough behind rustc is enough But rustc itself can be far enough behind rustc, as the MSRV debate shows.
- masklinn 4y ago
  You can already do that. Some libraries wilfully restrict their MSRV for backwards compatibility or distro compatibility (e.g. Debian stable provides 1.48).
- JoshTriplett 4y ago
  No argument there, but I think the third point helps address that somewhat.

bayindirh 4y ago

I disagree. 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. On the other hand, I acknowledge that LLVM kickstarted GCC development and made it better in thousand ways better, agile and flexible-minded (in terms of developers maintaining it). Similarly, having two Rust compilers, nudging each other to be better is a great way to make a language more general, widely accepted, resilient and more free & open. Also Rust well be much more stressed and tested as a result. > I hope it will be used only where necessary I hope both will be used widely, and make Rust a better language with much better accessibility.

deleted 4y ago
[deleted]
hardware2win 4y ago
>We need competition There is - between langs. Compiler engineers can use ideas from other lang's compilers. C# e.g
- bayindirh 4y ago
  I think having a GPL implementation of a language makes it more future proof. I don't want to be able compile some source only with "rustc-v_ancient-company_name-internal_fork-no_you_cant_have_its_source" version. Programming languages with single compilers tend to be not used in my area of work and research (HPC and Scientific Computing). Hence, I'd rather have multiple compatible, yet independently implemented compilers, per language.
  - mustache_kimono 4y ago
    > I don't want to be able compile some source only with "rustc-v_ancient-company_name-internal_fork-no_you_cant_have_its_source" version. Yeah, it's not like Google (and dozens of others) has/have an internal fork of Linux, which never gets merged back. I'm not certain the GPL butters any parsnips here. > Hence, I'd rather have multiple compatible, yet independently implemented compilers, per language. You identified it. The problem is compatibility, and again Linux is a good negative example where ostensibly we have a language spec and multiple compilers, but Linux for years would only compile on one compiler. Multiple compilers and "competition" doesn't solve compatibility. It makes it more difficult. Although I'm sure there will be benefits, I'm not certain the GPL/GCC will make compatibility any easier. It hasn't so far.

gardaani 4y ago

It's certain that there will be fragmentation. There isn't any gnu project, which hasn't added its own extensions to standards or specs. Few examples: gcc front end for C/C++, bash, grep.. It means that crates.io will have crates which compile only with gcc and its extensions.