> I don't see a future where C survives

I've been seeing those exact words for decades now, and C is still going strong. Every few year a new language comes, somes writes something in it, that was written in C before, someone might even write a basic OS in it, and after a few years, that language is almost forgotten, a new one is here, and again, someone is writing something in it, but in the end, we still use C for the things we used it 10, 20, for some, even 30 years ago.

Usage of C in new projects has fallen dramatically in the latest decades. It used to be the case that C was considered a general purpose programming language and applications such as Evolution were written in it. Today big applications in C are increasingly rare, and Rust is only accelerating this trend - nobody wants to have buffer overflows anymore.

Do you have a citation? Genuinely curious.

> lack of package manager, common build system, good documentation.

This is where C is superior to virtually every other language. It has K&R to start with [1], a wealth of examples to progress from there, man pages, autotools, cmake, static and shared libraries.

> good standard library.

It should have hash tables at least, but it isn't bad.

[1] Which is still the best language book ever written (yes, it has some anti patterns, you unlearn them quickly).

Huh? In what way is C’s books, documentation or build system superior to that found in other languages? Most languages have plenty of good books written about them. And plenty of code examples online. I can’t speak for other languages but I find MDN (Javascript) and the rust docs consistently better than C’s man pages. Ruby’s documentation is great too.

As for build systems, autotools is a hilarious clown car of a disaster. You write a script (automake) to generate a huge, slow script (configure) to generate a makefile to finally invoke gcc? It is shockingly convoluted. It seems more like a code generation art project than something people should use. CMake papers over it about as well as it can, but I think cmake is (maybe by necessity) more complex than some other entire programming languages. In comparison, in rust “cargo build” will build my project correctly on any platform, any time, with usually no effort on my part beyond writing the names and versions of my dependencies in a file.

And as for package management, C is stuck in the 80s. It limps by, but it doesn’t have a package manager as we know them today. There’s no cargo, gems, npm, etc equivalent. Apt is no solution if you want your software to work on multiple distros (which all have their own ideas about versioning). Let alone writing software that builds on windows, Mac and Linux.

So no, C is not superior to other modern languages in its docs, build system or package manager. It is vastly inferior. I still love it. But we’ve gotten much, much better at making tooling in the last few decades. And sadly that innovation hasn’t been ported back to C.

> in rust “cargo build” will build my project correctly on any platform

I've got a parts drawer full of controllers that says it won't.

You are conflating consistency of package management and library behavior across platforms with platform support.

When it comes to microcontrollers rust is currently at the mercy of LLVM support and vendors.

> It should have hash tables at least

https://man.openbsd.org/ohash_init.3

What of it?

> Those functions are completely non-standard and should be avoided in portable programs.

Sure, it has not been standardized, it is not part of the standard library, so what? Did the world stop? I mean, practically speaking, who cares? Implement it, or find libraries that did. There are plenty. I posted this one because it exists for an OS; OpenBSD, since 1999. Plus, AFAIK ohash is portable enough. It consists of 2 files, and you can compile it with -std=c89. Only the bounded attribute is ignored.

If you want I could have brought up hcreate, hdestroy, and hsearch:

> The functions hcreate(), hsearch(), and hdestroy() are from SVr4, and are described in POSIX.1-2001 and POSIX.1-2008.

Happier?

I use stb myself, so I have no qualms with that. The point is rather that GP was discussing praise for C’s standard library, and even the most portable single-file include-only dependency remains just that: an external dependency that isn’t part of the C standard library (and no, posix isn’t C).

Does it make much of a difference though? Take the hyped Rust for example. Most useful stuff is in crates, i.e. an external dependency. No one seems to have a problem with that.

Personally I do not mind using libraries typically installed by the Linux distribution's package manager anyways.

If the question is whether or not I think the C standard library could be improved, then yes, I would say it could, but I do not want it to have a hash table and all sorts of stuff like that, because there are lots and lots of ways to implement them, and they might not suit my needs. C is great, because you can build it from the ground up (if you want to) to make it specifically for your use case. It gives you the building blocks. I believe I have a comment regarding this somewhere, that I like C because it does not implement stuff for you that is in some ways "generalized", which is often a bad thing. This is my problem with "it should have hash tables at least". You cannot implement it in such a way that it suits everyone's needs.

Rust not having a good standard library is a huge problem. This increases the risk of a rust codebase due to the high number of third party dependencies.

I only said that "I do not mind using libraries typically installed by the Linux distribution's package manager", which was in respect to C.

As far as Rust goes, yes, I do not like that crates are full of one-liners, and so forth. It shares the same problems that npm has. I ran cargo build on many Rust projects before. No way.

So what are the antipatterns?

> I don't see a future where C survives

Meanwhile C is running strong since the 70s.

> the lack of package manager

What do you call linux distro's package managers then? I mean, in distributions like Debian you can even download a package's source code with apt-get.

>What do you call linux distro's package managers then?

If you want to count them as package managers, they're by far the worst ones of all the well known languages (with some notable exceptions e.g. guix's and nixos's).

They're not portable between distributions or even different versions of the same distribution (!), since it's non-trivial to install older versions of libraries (or, hell, different versions of the same library at the same time). Not to mention that it's a very manual and tedious process in comparison to all the other language specific package manager. 'Dependency hell' is a problem virtually limited to distro package managers (and languages like C and C++ that depend on them).

Getting older, unmaintained C programs to run on Linux is an incredibly frustrating experience and I think a perfect demonstration of how the current distro package manager approach is wholly insufficient.

> If you want to count them as package managers, they're by far the worst ones of all the well known languages (with some notable exceptions e.g. guix's and nixos's).

The have the only feature I care about: cross-language dependency management.

Unless you are suggesting to reimplement everything in each language and then make users install ten different XML parser, SSL implementations, etc. just because not-implemented-in-my-favorite-language syndrome.

Only on platforms where UNIX is the name of the game.

Those are features which makes C flexible on main-stream platforms and also usable for so many other platform where other languages just don't/won't work.

Those features are not unique to C, they are just cargo culted as such.

I don't see C being in much worse shape than C++ with respect to build system and package manager. It's slow going, but progress seems to be happening there.

Are you saying both are doomed? Or is there some scenario where C++ survives without C?

I think both are, long term (think FORTRAN where it’s not particularly popular but a lot of existing code is maintained and not rewritten).

C++ is actually in a slightly better spot ironically because it’s harder to integrate with. If you have a C program you can pretty easily start replacing parts with Rust. You can’t do the same with C++ which insulates it better in that sense.

Reports of Fortran's death (latest standard 2018) are greatly exaggerated (much like C). It's receded to a niche, but it's still a very important niche (numerical, HPC). Hopefully, the development of a new Fortran front end for LLVM (from PGI/Nvidia?) pans out, as this would fill a gap in LLVM's offerings, and provide more competition for ifort and gfortran.

You’re proving my point. FORTRAN is a niche language. C++ is still mainstream. It will recede but not completely disappear

I don’t see a great future for C++ either

I definitely like the "lack of package manager, common build system". For me, having those is a negative for a language like rust.

You see, my OS already comes with those, and I expect to use them. I have the Debian package system: dpkg, apt, aptitude, and so on. It's a big mess when other software tries to steal that role. I have the traditional build systems and more: make, cmake, autoconf, scons, and so on. If I'm building a large project with multiple languages, I'm going to use one of those tools. If a language wants to fight me on that, I'm not interested in that language.

SQLite alone has a support contract through 2050.

C survives.

C will survive, if just for embedded/systems programming where you need a "portable assembly language" that can run on the simplest CPUs.

That's because of sunk-cost rather than design.

Thanks to LLVM and GCC you can happily write embedded code in a higher level language, but the vendors don't bother supporting it because a lot of embedded coding isn't really what we would call software (no tests etc.)

Toolchains are one side, but garbage collection and big standard libraries are also a big reason. Anything with under a MB of RAM has a choice of several modern languages, but it is still basically just C, C++, Rust, Lua or MicroPython.

D works fine on microcontrollers.

I don't think anyone was going to write their fridge's code in Haskell anyway.

The higher level languages are kind of the problem though. I need things like the ability to know the layout of my structs.

Rust, D, Whatever let you control the layout of your struct.

Even C#, actually!

As much as I dislike C

> There are only two kinds of languages: the ones people complain about and the ones nobody uses.

This unfortunately seems to mostly hold true.

Porque no los dos? There are a few languages that nobody uses and also everybody seems to complain about.

Complaining about language doesn't seem off topic here:

"Porque" means Because. "Por que" means Why.

> mostly

MUMPS.

Unfortunely until we get rid of UNIX/POSIX clones, C will be kept around.

So not in my lifetime.

Or at least not in Torvalds' lifetime. His views on replacements for C are legendary. It would be interesting to see his comments on this proposal.

Torvalds himself might have a different opinion:

People have been looking at that for years now. I’m convinced it’s going to happen one day. It might not be Rust, but it’s going to happen that we will have different models for writing these kinds of things

https://thenewstack.io/linus-torvalds-on-diversity-longevity...

> the lack of package manager

Just use nix or even apt. Both of them are MUCH better when compared to trash like npm or cargo which do not even check for signatures.

> common build system

Such as make? There is also Ninja/Meson if you prefer.

> I don't see a future where C survives

if C dies then what replaces it?

Perhaps a combination of a language like Zig (a 1:1 replacement for situations where you really do want a lot of manual low-level control) and higher-level languages like Rust eating into more and more of the use cases.