5 ms·

> Rust has had ten years since 1.0. It changes in backward compatible ways. For some people, they want no changes at all, so it’s important to nail down which s

by QuiEgo 1y ago

> Rust has had ten years since 1.0. It changes in backward compatible ways. For some people, they want no changes at all, so it’s important to nail down which sense is meant. I’d love to see rust be so stable that MSRV is an anachronism. I want it to be unthinkable you wouldn’t have any reason not to support Rust from forever ago because the feature set is so stable.

aw1621107 1y ago
> I want it to be unthinkable you wouldn’t have any reason not to support Rust from forever ago because the feature set is so stable. What other languages satisfy this criteria?
- hoppp 1y ago
  Fortran, cobol, C or other old languages that stopped changing but are still used.
  - aw1621107 1y ago
    All three of the languages you list are still actively updated. Coincidentally, the latest standard for all three of them is from 2023(ish): - C23: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf - Cobol 2023: https://www.incits.org/news-events/news-coverage/available-now-2023-edition-of-isoiec-1989-cobol https://www.incits.org/news-events/news-coverage/available-n... (random press release since a PDF of the standard didn't immediately show up in a search) - Fortran 2023: https://wg5-fortran.org/N2201-N2250/N2212.pdf https://wg5-fortran.org/N2201-N2250/N2212.pdf C2Y has a fair number of already-accepted features as well and it's relatively early in the standard release cycle: https://thephd.dev/c2y-hitting-the-ground-running https://thephd.dev/c2y-hitting-the-ground-running
    - pklausler 1y ago
      Can’t compile with just a PDF file, though.
      - aw1621107 1y ago
        Yes, compilers will take some time to implement the new standards. C23 seems to have decent support from a few compilers, with GCC leading the pack: https://en.cppreference.com/w/c/compiler_support/23.html https://en.cppreference.com/w/c/compiler_support/23.html gcobol supports (or at least aims to support?) COBOL 2023: https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcobol/gcobol.html https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcobol/gcobol.html. Presumably there are other compilers working on support as well. Intel's Fortran compiler and LFortran have partial support for Fortran 2023 (https://www.intel.com/content/www/us/en/developer/articles/technical/fortran-language-and-openmp-features-in-ifx.html https://www.intel.com/content/www/us/en/developer/articles/t..., https://docs.lfortran.org/en/usage/ https://docs.lfortran.org/en/usage/). I'd guess that support both from these compilers and from other compilers (Flang?) would improve over time as well..
        pklausler 1y ago
        Flang does already support warnings for features that have breaking changes in F’2023.
        aw1621107 1y ago
        Glad to hear it! Didn't turn up anything obvious in my brief search, but I was expecting some work towards newer standards at least.
        pklausler 1y ago
        Why would you expect that? There are few incentives to work on features that nobody is using.
        aw1621107 1y ago
- QuiEgo 1y ago
  This is extremely common in the embedded and systems programming space, which Rust is otherwise attractive to use in. For example, a very popular library in the systems/embedded space, cjson, works with C89. FreeRTOS works with C99. This is a very common pattern in major libraries. It is very rare that taking a dependency could force you to update your toolchain in the embedded space. Toolchain updates invalidate your entire testing history and make you revalidate everything, which is often a giant PITA when your testing involves physical things (ex you may have to plug and unplug things, put the system in chambers that replicate certain environmental conditions, etc).
  - aw1621107 1y ago
    I feel like that's ever-so-slightly different from what GP was talking about. Beyond the potential hyperbole ("unthinkable", "any reason"), I think there's a difference between "we support C89 because nothing in later standards is useful/interests us" (which is what I interpreted GP to be talking about) and "we support C89 because we want to support platforms/compilers that don't support C99/later". cjson looks like an example of the latter, at least: > cJSON is written in ANSI C (C89) in order to support as many platforms and compilers as possible. And if you look through the issues/PRs you can see there was at least nominal interest in moving to later standards, though it seems those plans never came to fruition. Not entirely sure about FreeRTOS, but something similar wouldn't surprise me all that much.
    - QuiEgo 1y ago
      Sure, I think we’re essentially looking at the same thing from different angles. They are saying the changes in the C standard are minor enough that forcing people to upgrade isn’t worth the costs, such as losing compatibility with old toolchains for niche platforms. So they stay on an old C version. It would be amazing if Rust was as the point where people were ready to have conversations like that. New versions of Rust add so many handy, useful features the cost of staying on old Rust versions is very high right now. Or put differently, the ROI of picking up new versions of Rust is very very VERY good. So most packages do. Going back to the bigger picture issue though: it’s very common in embedded to lock your toolchain and very rarely change it. This is very desirable to drive down risk and testing burden. It would be sweet if this was more easy to do in Rust. If I need to take an update to a dependency to pick up a bug fix, as it stands today, there’s a good chance these days that I’m going to hit something in the chain that bumped MSRV and will force me to update. In real-world embedded projects using Rust, you end up with painful options: - chase MSRV of deps and keep on new Rust. Adds risk and testing burden. - minimize deps and reimplement everything yourself. Adds lots of cost. - use C and incur all of the memory safety risks, and assorted foot guns In the end, Rust still feels worth it, but it’d be super nice to not have to make that trade.

by QuiEgo 1y ago

aw1621107 1y ago

> I want it to be unthinkable you wouldn’t have any reason not to support Rust from forever ago because the feature set is so stable. What other languages satisfy this criteria?

hoppp 1y ago
Fortran, cobol, C or other old languages that stopped changing but are still used.
- aw1621107 1y ago
  All three of the languages you list are still actively updated. Coincidentally, the latest standard for all three of them is from 2023(ish): - C23: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf - Cobol 2023: https://www.incits.org/news-events/news-coverage/available-now-2023-edition-of-isoiec-1989-cobol https://www.incits.org/news-events/news-coverage/available-n... (random press release since a PDF of the standard didn't immediately show up in a search) - Fortran 2023: https://wg5-fortran.org/N2201-N2250/N2212.pdf https://wg5-fortran.org/N2201-N2250/N2212.pdf C2Y has a fair number of already-accepted features as well and it's relatively early in the standard release cycle: https://thephd.dev/c2y-hitting-the-ground-running https://thephd.dev/c2y-hitting-the-ground-running
  - pklausler 1y ago
    Can’t compile with just a PDF file, though.
    - aw1621107 1y ago
      Yes, compilers will take some time to implement the new standards. C23 seems to have decent support from a few compilers, with GCC leading the pack: https://en.cppreference.com/w/c/compiler_support/23.html https://en.cppreference.com/w/c/compiler_support/23.html gcobol supports (or at least aims to support?) COBOL 2023: https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcobol/gcobol.html https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcobol/gcobol.html. Presumably there are other compilers working on support as well. Intel's Fortran compiler and LFortran have partial support for Fortran 2023 (https://www.intel.com/content/www/us/en/developer/articles/technical/fortran-language-and-openmp-features-in-ifx.html https://www.intel.com/content/www/us/en/developer/articles/t..., https://docs.lfortran.org/en/usage/ https://docs.lfortran.org/en/usage/). I'd guess that support both from these compilers and from other compilers (Flang?) would improve over time as well..
      - pklausler 1y ago
        Flang does already support warnings for features that have breaking changes in F’2023.
        aw1621107 1y ago
        Glad to hear it! Didn't turn up anything obvious in my brief search, but I was expecting some work towards newer standards at least.
        pklausler 1y ago
        Why would you expect that? There are few incentives to work on features that nobody is using.
        aw1621107 1y ago
QuiEgo 1y ago
This is extremely common in the embedded and systems programming space, which Rust is otherwise attractive to use in. For example, a very popular library in the systems/embedded space, cjson, works with C89. FreeRTOS works with C99. This is a very common pattern in major libraries. It is very rare that taking a dependency could force you to update your toolchain in the embedded space. Toolchain updates invalidate your entire testing history and make you revalidate everything, which is often a giant PITA when your testing involves physical things (ex you may have to plug and unplug things, put the system in chambers that replicate certain environmental conditions, etc).
- aw1621107 1y ago
  I feel like that's ever-so-slightly different from what GP was talking about. Beyond the potential hyperbole ("unthinkable", "any reason"), I think there's a difference between "we support C89 because nothing in later standards is useful/interests us" (which is what I interpreted GP to be talking about) and "we support C89 because we want to support platforms/compilers that don't support C99/later". cjson looks like an example of the latter, at least: > cJSON is written in ANSI C (C89) in order to support as many platforms and compilers as possible. And if you look through the issues/PRs you can see there was at least nominal interest in moving to later standards, though it seems those plans never came to fruition. Not entirely sure about FreeRTOS, but something similar wouldn't surprise me all that much.
  - QuiEgo 1y ago
    Sure, I think we’re essentially looking at the same thing from different angles. They are saying the changes in the C standard are minor enough that forcing people to upgrade isn’t worth the costs, such as losing compatibility with old toolchains for niche platforms. So they stay on an old C version. It would be amazing if Rust was as the point where people were ready to have conversations like that. New versions of Rust add so many handy, useful features the cost of staying on old Rust versions is very high right now. Or put differently, the ROI of picking up new versions of Rust is very very VERY good. So most packages do. Going back to the bigger picture issue though: it’s very common in embedded to lock your toolchain and very rarely change it. This is very desirable to drive down risk and testing burden. It would be sweet if this was more easy to do in Rust. If I need to take an update to a dependency to pick up a bug fix, as it stands today, there’s a good chance these days that I’m going to hit something in the chain that bumped MSRV and will force me to update. In real-world embedded projects using Rust, you end up with painful options: - chase MSRV of deps and keep on new Rust. Adds risk and testing burden. - minimize deps and reimplement everything yourself. Adds lots of cost. - use C and incur all of the memory safety risks, and assorted foot guns In the end, Rust still feels worth it, but it’d be super nice to not have to make that trade.