C Is Still Everywhere | Hacker News Reader

C Is Still Everywhere

toptal.com

36 pointspausmfib12 comments

The most difficult thing I find about C is the (apparent) lack of libraries and packages. With other languages I know where to go to find libraries for anything I need, but I never know where to look with C. As a result I never really use it.

A boilerplate project with testing, common libs for data structures, and pointers to useful resources like extra libs, would be really cool. :)

That said if I had to do something nowadays that I would use C for, I'd probably just pick up Rust.

> The most difficult thing I find about C is the (apparent) lack of libraries and packages

I really am not sure if this is a joke or not, but almost every major library has a C interface. Almost all packages in your distro if you use linux have development versions that ship libraries that usually are linkable by C. In fact the wealth of libraries usable from C is usually noted as its main strength.

What exactly are you missing, and have you tried googling? The GNU organization and similar all produce libraries(like https://www.gnu.org/software/gsl/) that are mostly usable from C.

Coming from a different language, the idea that the OS provides your libraries is a radical departure. Generally a modern developer working in any other language will look to github along with the languages package repository for libraries.

Anecdotally the types of libraries shippable with the OS represent a specific category of application which doesn't encompass many developers needs. (Although on the other side, github does not provide usable drivers for most operating systems... your mileage may very).

Even so, github does have a ton of very very popular C libraries(like https://github.com/nothings/stb). I was bringing up the OS provided ones since they claimed not to be able to find any. My main point is that it is patently absurd to claim that they could not find C libraries.

Further: https://github.com/oz123/awesome-c as another example of the many many C libraries you could find.

The next pain point is that most of those libraries have custom build processes etc. This is a far cry from what most developers work with. Conan is making progress, but the overlap of C projects which also work with Conan appears small.

Many practical C projects seem to simply fork any dependencies they want to use and stick them in their own internal repo/build process.

You should be really careful about using libraries from distribution package managers because none of them can resist screwing with the source, which often times makes them unusable. Even the vendors themselves say don’t screw with the packages and maintainers do it anyway.

Then you’re not doing a whole lot of C. The most difficult thing for me is having to flip between posix, make, clang, gcc, ld, ar, and ranlib man pages, and Apple’s “archived” documentation which by the way, despite the way they name it isn’t deprecated, it’s the only primary source for understanding dylibs.

Oh and it’s so poorly documented in practice that you have to cross reference it with codebases to see how the tooling is actually used in practice, then peel back all the weird quirks from those authors.

That’s the hard part.

Googling for a C library isn’t.

In other news: screwdrivers still everywhere.

Anyone waiting for the death of C is delusional. It’s the best (often the only) tool for many jobs and will always underpin most of the world’s operating systems and low levels of user space. A few counter examples don’t invalidate this point.

Perhaps this is better stated as "Standard/slot screws/drivers are everywhere." There are places where newer interfaces are more appropriate.

I really hate to be right here, but Rust is picking up traction and has passionately growing fan base…..

Major C projects that took 20+ years to develop won't be all replaced in a couple of years, but that doesn't mean the replacement hasn't started. C was the best/only option for almost a half of a century, so it has built a lot of momentum and legacy, but the niches where it's the best/only tool continue to shrink.

C is unusual that it doesn't have a single 1:1 replacement, and few C projects are being directly rewritten in something else. Instead, C is getting sidelined, and not growing into new areas where the software is moving. Many other languages are now an obvious choice for things that used to be C's domain. I remember in the early 90s desktop apps were primarily in C (assembly and Pascal second), but nowadays apps can be written in a variety of languages, including scripting ones, or even entirely displaced by webapps. For early web services, if Perl was too slow, C was the second choice. Now C has been pushed to lower-level plumbing, and even that started being eroded by golang and Rust. Even games that used to be strictly C/C++ territory have moved to C++ engine + scripting (with the proportion of scripting growing). Unity games use C# (e.g. I was shocked that BeatSaber, a low-latency VR game, is in C#).

I've been similarly waiting for the demise of x86. x86 used to be the best/only option for a very long time, and is still having a momentum in desktops, but a whole new, larger mobile computing world has sprung without it.

I am doing some research for a personal project and wanted to integrate a tiny and fast http server. Most of the good and suitable open source code are built with C. You want small + fast, C, C++ and Pascal is still the way to go.

Reply on news.ycombinator.com