8 ms·

IMO, rustc_codegen_gcc is much more reasonable in scope. It also stands a chance of actually keeping up with subsequent Rust releases. I would be surprised if g

IMO, rustc_codegen_gcc is much more reasonable in scope. It also stands a chance of actually keeping up with subsequent Rust releases. I would be surprised if gcc-rs ever achieved any traction. Not to say it's not a fun project, but I can't see it replicating rustc.

e3bc54b2 3y ago
It doesn't has to match rustc on nightly, only the 3-yearly releases. That seems doable, considering Rust has slowed down a bit, compared to super fast pace of change in early years. Regardless, it is always good to have alternate implementations, C++ has only benefited from it.
- tialaramex 3y ago
  I'm guessing you aren't a Rust programmer? By "3-year releases" you're probably meaning Editions, but Rust Editions aren't like the C++ Standard, where they're bundling together a bunch of new features† the Edition changes language syntax, usually in small ways. The features people care about are released every six weeks and aren't saved up for new Editions. For example, 1.69 released last week, so now: SocketAddr::new(IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)), 8080) ... is a constant, at compile time the data structure equivalent to 127.0.0.1:8080 is constructed and baked into your binary program. If I write a Rust program which relies on this for a constant, it works fine, because it is constant, but if I try to compile it with Rust 1.68 (from earlier this year) it won't work. If an alternative compiler doesn't have the features of Rust 1.69, then code written for Rust 1.69 won't necessarily work with it. Sometimes such differences will be tiny, other times huge. † And notice that just because say, Modules was a C++ 20 feature, did not mean that you woke up one day in 2020 and had working Modules, C++ 20 is just an ISO document, the features have to get implemented by vendors, and then tested, and then shipped, which can take weeks, or months, or years.
  - deleted 3y ago
    [deleted]
  - proto_lambda 3y ago
    Bad example because that's a library feature and doesn't involve explicit compiler support - in general you're right though, backwards-compatible compiler features (say, GATs) are added regularly and are available for all editions, not just the newest one.
    - epage 3y ago
      Except the library uses nightly features so to pull in newer versions, you have to be up to date with all the unstable compiler features.
  - Karellen 3y ago
    Not parent, but not a rust programmer: > If I write a Rust program which relies on this for a constant, it works fine, because it is constant, but if I try to compile it with Rust 1.68 (from earlier this year) it won't work. How would it not work? If your program compiles and runs with 1.69, then surely that's because it never tries to modify the value. But if your program never tries to modify the value, how would it fail with 1.68?
    - estebank 3y ago
      The GP is missing a small bit of context: because this construct is now const, it can be used in const contexts, like to initialize a static variable. Doing so didn't work in 1.68, but does now in 1.69.
      - phkahler 3y ago
        But older code will still work with the new compiler right?
        mkj 3y ago
        Yes
        estebank 3y ago
        That is the Rust stability commitment: Rust code will always* compile with any subsequent release. * Modulo soundness bugs being fixed. I've personally encountered 2 instances of that since 1.0, and they all occurred before 2017.
    - proto_lambda 3y ago
      > a Rust program which relies on this for a constant https://godbolt.org/z/ceY3q3eW4 https://godbolt.org/z/ceY3q3eW4
      - Karellen 3y ago
        Sorry, I'm not reading 1100 words of privacy policy to get a chance to read whatever that is.
  - phicoh 3y ago
    That sounds a bit like using the latest features in the C or C++ standard, and then be surprised that many compilers cannot compile your code. When a language develops quickly it is a good if people use the latest version to test new features to get experience. When a language become mainstream, change will be much slower. Rust compilers will be shipped with operating systems, and people will write code that can be compiled by those older compilers. There is a lot of C code that targets C99. Because that's what you can rely on if it has to run everywhere.
    - hulitu 3y ago
      > That sounds a bit like using the latest features in the C or C++ standard, and then be surprised that many compilers cannot compile your code. Compiling the Firefox browser is often an exercise in futility because of this. Rust might be the best but not being able to compile existing programs looks really bad.
    - nicoburns 3y ago
      > When a language become mainstream, change will be much slower I wouldn't assume that. JavaScript is about as mainstream as it gets, and that's also on a 6-weekly release schedule. > Rust compilers will be shipped with operating systems, and people will write code that can be compiled by those older compilers. Rust compilers are already shipped with operating systems, but for the most part (a few really foundational crates aside), people are not writing code that can be compiled by those older compilers. They're telling people to install a newer version of Rust. Which is pretty reasonable given how easy it is to manage rustc versions with rustup. This may change with the creation of certified compilers for things like the automotive industry. But then, they're probably pretty used to maintaining their own library ecosystem anyway. > There is a lot of C code that targets C99. Because that's what you can rely on if it has to run everywhere. Yes, but one of the best things about Rust is that you can target the latest compiler version, and it still runs everywhere! That's why people don't like the possibility that this might change with the introduction of gcc-rs. We shouldn't accept crappy C toolchains as the standard.
      - phicoh 3y ago
  - andrepd 3y ago
    > (IpAddr::V4(Ipv4Addr::new( Rust is so simple and clear :3
    - proto_lambda 3y ago
      The C equivalent would be a bunch of `in_addr`/`sockaddr_in`/`sockaddr` handling where you can do something wrong at basically every step of the way. You can't mess up the types in Rust, there's only one way they fit together. Of course if you just want to convert a string to a SocketAddr (returning an error at runtime if it's invalid), you just do `let addr = "127.0.0.1:8080".parse();`.

e3bc54b2 3y ago

It doesn't has to match rustc on nightly, only the 3-yearly releases. That seems doable, considering Rust has slowed down a bit, compared to super fast pace of change in early years. Regardless, it is always good to have alternate implementations, C++ has only benefited from it.

tialaramex 3y ago
I'm guessing you aren't a Rust programmer? By "3-year releases" you're probably meaning Editions, but Rust Editions aren't like the C++ Standard, where they're bundling together a bunch of new features† the Edition changes language syntax, usually in small ways. The features people care about are released every six weeks and aren't saved up for new Editions. For example, 1.69 released last week, so now: SocketAddr::new(IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)), 8080) ... is a constant, at compile time the data structure equivalent to 127.0.0.1:8080 is constructed and baked into your binary program. If I write a Rust program which relies on this for a constant, it works fine, because it is constant, but if I try to compile it with Rust 1.68 (from earlier this year) it won't work. If an alternative compiler doesn't have the features of Rust 1.69, then code written for Rust 1.69 won't necessarily work with it. Sometimes such differences will be tiny, other times huge. † And notice that just because say, Modules was a C++ 20 feature, did not mean that you woke up one day in 2020 and had working Modules, C++ 20 is just an ISO document, the features have to get implemented by vendors, and then tested, and then shipped, which can take weeks, or months, or years.
- deleted 3y ago
  [deleted]
- proto_lambda 3y ago
  Bad example because that's a library feature and doesn't involve explicit compiler support - in general you're right though, backwards-compatible compiler features (say, GATs) are added regularly and are available for all editions, not just the newest one.
  - epage 3y ago
    Except the library uses nightly features so to pull in newer versions, you have to be up to date with all the unstable compiler features.
- Karellen 3y ago
  Not parent, but not a rust programmer: > If I write a Rust program which relies on this for a constant, it works fine, because it is constant, but if I try to compile it with Rust 1.68 (from earlier this year) it won't work. How would it not work? If your program compiles and runs with 1.69, then surely that's because it never tries to modify the value. But if your program never tries to modify the value, how would it fail with 1.68?
  - estebank 3y ago
    The GP is missing a small bit of context: because this construct is now const, it can be used in const contexts, like to initialize a static variable. Doing so didn't work in 1.68, but does now in 1.69.
    - phkahler 3y ago
      But older code will still work with the new compiler right?
      - mkj 3y ago
        Yes
      - estebank 3y ago
        That is the Rust stability commitment: Rust code will always* compile with any subsequent release. * Modulo soundness bugs being fixed. I've personally encountered 2 instances of that since 1.0, and they all occurred before 2017.
  - proto_lambda 3y ago
    > a Rust program which relies on this for a constant https://godbolt.org/z/ceY3q3eW4 https://godbolt.org/z/ceY3q3eW4
    - Karellen 3y ago
      Sorry, I'm not reading 1100 words of privacy policy to get a chance to read whatever that is.
- phicoh 3y ago
  That sounds a bit like using the latest features in the C or C++ standard, and then be surprised that many compilers cannot compile your code. When a language develops quickly it is a good if people use the latest version to test new features to get experience. When a language become mainstream, change will be much slower. Rust compilers will be shipped with operating systems, and people will write code that can be compiled by those older compilers. There is a lot of C code that targets C99. Because that's what you can rely on if it has to run everywhere.
  - hulitu 3y ago
    > That sounds a bit like using the latest features in the C or C++ standard, and then be surprised that many compilers cannot compile your code. Compiling the Firefox browser is often an exercise in futility because of this. Rust might be the best but not being able to compile existing programs looks really bad.
  - nicoburns 3y ago
    > When a language become mainstream, change will be much slower I wouldn't assume that. JavaScript is about as mainstream as it gets, and that's also on a 6-weekly release schedule. > Rust compilers will be shipped with operating systems, and people will write code that can be compiled by those older compilers. Rust compilers are already shipped with operating systems, but for the most part (a few really foundational crates aside), people are not writing code that can be compiled by those older compilers. They're telling people to install a newer version of Rust. Which is pretty reasonable given how easy it is to manage rustc versions with rustup. This may change with the creation of certified compilers for things like the automotive industry. But then, they're probably pretty used to maintaining their own library ecosystem anyway. > There is a lot of C code that targets C99. Because that's what you can rely on if it has to run everywhere. Yes, but one of the best things about Rust is that you can target the latest compiler version, and it still runs everywhere! That's why people don't like the possibility that this might change with the introduction of gcc-rs. We shouldn't accept crappy C toolchains as the standard.
    - phicoh 3y ago
- andrepd 3y ago
  > (IpAddr::V4(Ipv4Addr::new( Rust is so simple and clear :3
  - proto_lambda 3y ago
    The C equivalent would be a bunch of `in_addr`/`sockaddr_in`/`sockaddr` handling where you can do something wrong at basically every step of the way. You can't mess up the types in Rust, there's only one way they fit together. Of course if you just want to convert a string to a SocketAddr (returning an error at runtime if it's invalid), you just do `let addr = "127.0.0.1:8080".parse();`.