Hacker News Reader

Comment by jvanderbot | Hacker News Reader

We're 4 years away from the time when TFA predicts no new projects will begin with C.

I wonder how the claim holds up? Certainly not well in the embedded space, and Rust mainline kernel development seems still a few years away at least.

I'd argue there's some transition in space fsw to c++, but that's not really significantly different than C+classes, since most c++ features and std:: are not allowed.

When does automotive, iot, and other spaces anticipate tansitioning?

View on HN

> We're 4 years away from the time when TFA predicts no new projects will begin with C.

I'm not sure if this is representative, but most of my recent FLOSS projects have all been C89 libraries.

The rationale is that it's trivial to add C bindings in any language, it's extremely fast to build, and it runs everywhere.

This is the exact reason I build and ship using C89.

In your case, how much compatibility is lost from using C99 over C89? (I'm comfortable with C99 and still write some low-level multiplatform code in it, but losing the ability to declare variables where they're first used is a bridge too far for me...)

Just for reference, projects like SQLite use C99.

IMO, targeting C89 is only warranted when you know for a fact it's needed. After all, not only is C99 a good improvement but toolchains stuck on C89 are not the type of toolchain I'd want to support.

> In your case, how much compatibility is lost from using C99 over C89?

Until somewhat recently C89 was the latest version of C that was supported by the MSVC compiler. Support for C99 was always terribly broken and Microsoft chose to claim it did supported C99 but without supporting mandatory features, which meant they did not in fact supported C99.

This sad state of affairs only changed significantly in 2020, with a lowkey announcement.

https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...

They claimed support for C99 to the extent required for ISO C++ compliance, plus some features critical for a couple of their developers.

Likewise, even with the updated C11 and C17 support, it isn't 100% there, only good enough, because C++ is what matters for Windows developers when not using .NET.

FWIW I’ve seen space FSW instances where both std:: was allowed and forbidden. One instance was soft real-time FSW running on a customized Linux. Most (sane) C++ was allowed, exceptions were not disabled, just disallowed, std:: was allowed during initialization, but not past that, memory allocation was only allowed during initialization as well, although a stray allocation at runtime was only fatal in testing, not during flight. It was logged in both cases and considered a critical issue. PR reviews had strict checklist rules regarding allowed syntax/features. It was very productive using all of the necessary C++ features, within reason, to write code.

To be fair to the author, the claim is that it's at least a decade away.

Automotive standards like AUTOSAR have been using C++ for quite some time and now are looking into Rust as well.

https://www.autosar.org/news-events/details/autosar-investig...

Note that MISRA is also adopting AUTOSAR on their standards.

> We're 4 years away from the time when TFA predicts no new projects will begin with C.

True, but AFT gives us at least 8 years.

Reply on news.ycombinator.com