What other languages satisfy this criteria?
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).
> 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.
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.
I sort of lean towards thinking that they aren't exactly the same thing in general, but in the embedded C world they're correlated enough that it can be hard to separate individual influences.
> 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.
Right, and I think that's a not unreasonable position when worded that way! I'm mostly complaining about the hyperbole - "unthinkable" and "any reason" are pretty high standards which I feel are basically impossible to meet in general - as with many things, there are always tradeoffs and the balance will shift over time.
I do wonder what effect LLVM has had, if any, on the Rust ecosystem's general fast pace. Less support for embedded systems means less early ecosystem pressure that might have motivated more stability, or something along those lines.
- C23: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf
- Cobol 2023: 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
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
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
gcobol supports (or at least aims to support?) COBOL 2023: 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/t..., 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..
