5 ms·

The nice(r) thing about bootstrapping GCC is that there are many alternative implementations of C and C++ already existing.

by clort 8y ago

ploxiln 8y ago
And you can build GCC-8 with GCC-4.8, whereas rust seems to require at least the previous version of rust. It would be reasonable for rust 1.19 to be able to build the latest release for the next couple of years ... rust 1.19 is less than 18 months old! Surely rust was an OK language 18 months ago?
- steveklabnik 8y ago
  Rust’s standard library makes heavy use of unstable features that may change from release to release. We’ve been slowing down the requirements over time; the current policy is that you can build any stable with the previous release. Maybe someday we’ll slow it down further, but there’s no plans to do so any time soon.
- hsivonen 8y ago
  Bootstrapping is done rarely but ongoing compiler development is done all the time. It seems like a bad idea to optimize for bootstrapping at the cost of not being able to use the best Rust has to offer in compiler development today.
  - ploxiln 8y ago
    The benefit is to stable software distributions, and also to from-scratch software stack builds in diverse environments. As a software engineer who has been interested in reliable and understandable software systems for a couple decades, I find the Rust trend of following the web-ecosystem and completely abandoning software support after a couple of months to be _nuts_. Look, I'm a reasonable guy. I don't insist on being compatible with Linux 2.4, I don't insist on working with a compiler and system libraries from 2006, I don't reject all bundling completely. But working with stuff from a few years ago would be very helpful to lots of projects and efforts, and is what I've come to expect from high quality software distributions and libraries, like Debian stable, the linux kernel, GCC, libpng, sqlite3, etc etc. (The linux kernel is a huge project and maybe the fastest-moving in existence, and you can build the very latest release with GCC-4.7!)
    - zozbot123 8y ago
      > I find the Rust trend of following the web-ecosystem and completely abandoning software support after a couple of months to be _nuts_. If Rust was a "traditional" project and not following web-ecosystem practices, it would still be issuing 0.x releases though - the language itself is quite far from true maturity (the "2018" version has only just gained NLL, and there are plenty of deeply-impacting features in the pipeline, at various stages of development). So it's six of one, half a dozen of the other...
      - acqq 8y ago
        To save others searching; The mentioned NLL is: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.... “non-lexical lifetimes”
        steveklabnik 8y ago
        For a simpler explanation, see https://doc.rust-lang.org/edition-guide/rust-2018/ownership-and-lifetimes/non-lexical-lifetimes.html https://doc.rust-lang.org/edition-guide/rust-2018/ownership-... (the guide says beta but it’s in stable now, that will be fixed soon.)
  - mook 8y ago
    That seems perfectly reasonable for unstable software in heavy development, which Rust might very well be. Unfortunately that also means it shouldn't be used as part of anything stable, which makes using it in Firefox a terrible idea. Think of it as LLVM declaring it has a hard dependency on the Linux kernel from last week (that isn't in a release yet).
- mjw1007 8y ago
  I suppose letting the compiler-writers use new language features gives the usual advantages of "dogfooding" your own product.
- Tuna-Fish 8y ago
  Absolutely no-one of the rustaceans I personally know want to write a single more line of pre-1.31 rust. NLL is a major ergonomics change, that makes all the simple things so much better.
  - ploxiln 8y ago
    I completely believe you - but think about how absurd that is. Why did any of them want to write any rust a month ago? Were all rust users really naive/dumb to think that rust 1.29 was any good at all? Only 2 months later they never want to write Rust 1.29 ever again! I can be quite productive with C and Python from 10 years ago. Most Go I programs I write happen to be compatible with Go-1.7 from 2016, but I could go back to Go-1.4 from 2014 without much trouble if I had a reason to. Coincidentally, you can build the latest Go toolchain with Go-1.4, which was the last version written in C. I guess the Golang authors are just superhuman engineers, huh ...
    - steveklabnik 8y ago
      I think your parent is exaggerating a bit, but this is just generally true of any release with a bug feature in it that people are excited to use. Now that it exists, why would you not want to use it? For context, Rust 1.31 is sorta like the Go 2 release. It’s a much bigger deal than regular releases.
      - ploxiln 8y ago
        If you're writing a toy/exercise, sure, have fun, I support that. It's part of developing your skills and thinking about software. If you're writing infrastructure, please don't. (e.g. Firefox ... or the toolchain itself) I'm one of those guys with no particular interest in Go 2. I really have plenty to work with already.
      - gilnaa 8y ago
        It's not always up to me which compiler version I use. Some organizations change compilers very slowly, and you can't assume you always have the most updated compiler. For example, when writing a library for my org I assumed that GCC 5.4 (2016) is a reasonable lower bound, and I used the appropriate set of supported C++11 features, and twice I had to downgrade as different teams notified me they had older and older compilers. (and couldn't upgrade)
sitkack 8y ago
But is GCC multi-bootstrapped using those alternate compilers? Do they all arrive at the same fixed point?

The nice(r) thing about bootstrapping GCC is that there are many alternative implementations of C and C++ already existing.

by clort 8y ago

The nice(r) thing about bootstrapping GCC is that there are many alternative implementations of C and C++ already existing.

ploxiln 8y ago

And you can build GCC-8 with GCC-4.8, whereas rust seems to require at least the previous version of rust. It would be reasonable for rust 1.19 to be able to build the latest release for the next couple of years ... rust 1.19 is less than 18 months old! Surely rust was an OK language 18 months ago?

steveklabnik 8y ago
Rust’s standard library makes heavy use of unstable features that may change from release to release. We’ve been slowing down the requirements over time; the current policy is that you can build any stable with the previous release. Maybe someday we’ll slow it down further, but there’s no plans to do so any time soon.
hsivonen 8y ago
Bootstrapping is done rarely but ongoing compiler development is done all the time. It seems like a bad idea to optimize for bootstrapping at the cost of not being able to use the best Rust has to offer in compiler development today.
- ploxiln 8y ago
  The benefit is to stable software distributions, and also to from-scratch software stack builds in diverse environments. As a software engineer who has been interested in reliable and understandable software systems for a couple decades, I find the Rust trend of following the web-ecosystem and completely abandoning software support after a couple of months to be _nuts_. Look, I'm a reasonable guy. I don't insist on being compatible with Linux 2.4, I don't insist on working with a compiler and system libraries from 2006, I don't reject all bundling completely. But working with stuff from a few years ago would be very helpful to lots of projects and efforts, and is what I've come to expect from high quality software distributions and libraries, like Debian stable, the linux kernel, GCC, libpng, sqlite3, etc etc. (The linux kernel is a huge project and maybe the fastest-moving in existence, and you can build the very latest release with GCC-4.7!)
  - zozbot123 8y ago
    > I find the Rust trend of following the web-ecosystem and completely abandoning software support after a couple of months to be _nuts_. If Rust was a "traditional" project and not following web-ecosystem practices, it would still be issuing 0.x releases though - the language itself is quite far from true maturity (the "2018" version has only just gained NLL, and there are plenty of deeply-impacting features in the pipeline, at various stages of development). So it's six of one, half a dozen of the other...
    - acqq 8y ago
      To save others searching; The mentioned NLL is: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.... “non-lexical lifetimes”
      - steveklabnik 8y ago
        For a simpler explanation, see https://doc.rust-lang.org/edition-guide/rust-2018/ownership-and-lifetimes/non-lexical-lifetimes.html https://doc.rust-lang.org/edition-guide/rust-2018/ownership-... (the guide says beta but it’s in stable now, that will be fixed soon.)
- mook 8y ago
  That seems perfectly reasonable for unstable software in heavy development, which Rust might very well be. Unfortunately that also means it shouldn't be used as part of anything stable, which makes using it in Firefox a terrible idea. Think of it as LLVM declaring it has a hard dependency on the Linux kernel from last week (that isn't in a release yet).
mjw1007 8y ago
I suppose letting the compiler-writers use new language features gives the usual advantages of "dogfooding" your own product.
Tuna-Fish 8y ago
Absolutely no-one of the rustaceans I personally know want to write a single more line of pre-1.31 rust. NLL is a major ergonomics change, that makes all the simple things so much better.
- ploxiln 8y ago
  I completely believe you - but think about how absurd that is. Why did any of them want to write any rust a month ago? Were all rust users really naive/dumb to think that rust 1.29 was any good at all? Only 2 months later they never want to write Rust 1.29 ever again! I can be quite productive with C and Python from 10 years ago. Most Go I programs I write happen to be compatible with Go-1.7 from 2016, but I could go back to Go-1.4 from 2014 without much trouble if I had a reason to. Coincidentally, you can build the latest Go toolchain with Go-1.4, which was the last version written in C. I guess the Golang authors are just superhuman engineers, huh ...
  - steveklabnik 8y ago
    I think your parent is exaggerating a bit, but this is just generally true of any release with a bug feature in it that people are excited to use. Now that it exists, why would you not want to use it? For context, Rust 1.31 is sorta like the Go 2 release. It’s a much bigger deal than regular releases.
    - ploxiln 8y ago
      If you're writing a toy/exercise, sure, have fun, I support that. It's part of developing your skills and thinking about software. If you're writing infrastructure, please don't. (e.g. Firefox ... or the toolchain itself) I'm one of those guys with no particular interest in Go 2. I really have plenty to work with already.
    - gilnaa 8y ago
      It's not always up to me which compiler version I use. Some organizations change compilers very slowly, and you can't assume you always have the most updated compiler. For example, when writing a library for my org I assumed that GCC 5.4 (2016) is a reasonable lower bound, and I used the appropriate set of supported C++11 features, and twice I had to downgrade as different teams notified me they had older and older compilers. (and couldn't upgrade)

sitkack 8y ago

But is GCC multi-bootstrapped using those alternate compilers? Do they all arrive at the same fixed point?