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.
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.
> Sure, I think we’re essentially looking at the same thing from different angles.
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.
> 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.