Hacker News Reader

Comment by habitue | Hacker News Reader

Started watching, but "C89 is the safe option for long lived software" kind of turned me off. There are plenty of safe long lived stable languages out there where you dont have to manually manipulate memory. At the very least, this guy should be advocating for Java.

But even that's too far really. Like it or not, "shiny fad" languages like Python & Javascript have been around forever, support for them isn't going away, this should be a non-concern at the architectural level. (Bigger language concerns: is it performant enough for my expected use? Does it have strong types to help with correctness? Can I hire programmers who know it? etc)

View on HN

It really depends. I was at talk of architect of car company when he was talking about need to develop and support a car software for 20-30 years - few years before release, 10-20 years of production, and the critical fixes after end of support. And it includes not only soft itself, but all compilers, etc.

> languages like Python & Javascript have been around forever, support for them isn't going away

??? Python 2 went out of support five years ago.

I mean C89 has no support, it's not getting an update or a bugfix, the standard is what it is. So if vendor support is your overriding concern, you should be constantly updating your software to LTS versions.

I meant support in terms of there's an active community of people using the language and building things with it. It's not going to die as a language like Algol 68 or Pascal.

Is there an active community of people using Python 2 and building things with it? Meanwhile, there are plenty of actively maintained compilers for C89.

C89 still has an active community of people using the language and building things with it.

In addition to this, its existence and validity is still relied on by basically every other language via standard library, transient dependency, or calling convention. Heck, practically every C++ project probably depends on it.

The Linux Kernel, ffmpeg, SQLite, curl and many others chose C89 and often consider using C99, but most do not. Each of those projects also write at-length via newsletter or blog as to why they’re still not quite ready to update (and sometimes why they are.)

The Linux kernel and ffmpeg require C11.

Yes, “chose” in past-tense (and that whole clause about the tension displayed in public communications of these projects contemplating the change.

Both projects made this change in the last couple years. ffmpeg still requires c99 compatibility for their headers, and may indefinitely.

When Linux was created, there was not much choice. In reality, most active projects moved on and only projects with relatively extreme portability requirements stick with C89, mostly because MSVC does not support anything later properly.

I think that’s fair, but I also believe that the same things that make C89 meet “extreme portability requirements” are why Eskil still uses it.

Should everyone? No, probably not.

Yes, but also because he made it work well for him. He also understands that most of the innovations in programming languages is actually not nearly as useful as people think and often does more harm than good. Rejecting newer C standards is a bit too extreme in my opinion, as C is very slowly evolving already.

I have two different compilers that implement C89 on my computer right now and I know of at least one other. How much support do you require before you consider something supported?

Reply on news.ycombinator.com