But I always hear people saying "just use Rust or Zig" - but C is actually a great time, and I'm happy the naysayers didn't put me off.
So, do you, or do you not use C?
If so: why, and what for?
If not: why not, and what do you use instead?
But eventually I grew really tired of handling everything by myself or failing at attempts to enhance C with syntactic augmentations in a sane way. You just plow through finalizations again and again after every change, and invent all sorts of rube goldberg machines to correctly quit a failed function.
C was designed with one-shot programs in mind, which was the default. You just read and write until EOF/error and then exit, simple (akin to Perl which had neither memory management nor GC - your script was just expected to finish soon and not linger for hours). Otoh, modern highly stateful programming is a great PITA in conjunction with C.
Maybe Zig and Rust would do better for me, idk, but somehow I pivoted into non-performance programming. I’m not using anything instead. There’s no “business” in C and no money, unless you’re lucky with a rare low-level job.
Oh, and type declarations look like line noise.
Turbo / Free Pascal is the way to go. Strings are magically created, reference counted and can just be used, to hold gigabytes, even if they contain nulls. Pointers are easy to see and use. Units avoid build hell.
Don't get me started about the importance of whitespace characters in python. Whoever got that idea...!
The prosaic answer is that there are hundreds of languages to choose from. In most cases we choose the one we know because that gets the task done quicker.
In other cases the language is chosen for you; because existing code, or platform limitations or embedded or whatever.
There are lots of things to like about C - but it's slow to write because it's so low-level. Even dealing with strings is painful.
On the other hand it is low-level, so it's fast, and small. In some cases that is important.
Which is all to say that "context matters" and the context matters much (much) more than persons choice. We have lots of languages precisely because we have so many contexts.
But for graphics its been quite enjoyable
A huge amount of important existing software is written in C. If the code is already written or needs to inter-operate with other pieces in many languages I typically write C. There are a also lot of things that can be easier in C because that modern safer languages would stop you from doing foot shooting things that C won't it's quicker sometimes to write or prototype in C.
> If not: why not, and what do you use instead?
A not insignificant part of my career has been fixing bugs in C code that's been around forever. It's almost always the same class of dumb bugs that wouldn't exist in other languages. This is not anecdata the research agrees. No new projects should be started in C there are better tools.
Rust data structures are not defined at all (Unless I'm missing some). For example you can't create a rust string in python and pass it to rust code. In order to pass Rust data to and from another language, you have to create bindings and convert between C strings, arrays, etc + deal with overhead
Zig is the only language I've seen that comes close to matching C in this area. Once it gets a stable release I think many more companies will adopt it.
Now, hardware is so fast speed doesn't matter so much. Many languages such as Python come with nice doco and a standard library that ellipses what C provides. Languages like Rust are in the same league speed wise, are memory safe, run on almost as many platforms and have solved the porting issue. Meanwhile the C standards committee redefining "undefined behaviour" from "implementation defined" to "so whatever we damned well please when we detect it" means you almost have to be an language lawyer to know all it's hidden traps. In other words, the language definition has gone from "a pleasant days reading" to "200k words of formal definition only a compiler writer could love".
Like COBOL, C will be around forever, but the days when it was the best choice for most things passed long ago.
I guess I just haven't felt the need to go down to the metal for the original applications that I write. If I were more into extending hardware or writing new 3D engines for AAA games I suspect I would view this completely differently.
Performance is not enough of a consideration. If you are comfortable writing native JavaScript without a bunch of unnecessary abstractions you can expect your code to be about 4.5x slower than C, or about 12x-20x slower at arithmetic. By far the greatest performance limitation of JavaScript compared to things like C, C++, Rust, or Zig isn't the execution speed, but that it is garbage collected instead of manually memory managed via pointers.
After Visual Studio (first with their Visual Studio Express Editions) became "free" (yeah yeah, not really there are some strings attached tho), I never looked back and used C++ exclusively (more or less; I dabbled in some other "cool" languages here and there, tho).
Rust is just too cumbersome to code in, for not real benefit to me.
At some point Python became really popular in infosec and practically all tools were written in it. It was also used by malware authors. This got me to learn the language and realize that it can do everything for me I need C for, while being a lot faster to develop.
So I mostly left C for Python and later for other higher level labguages.
Nowadays at $WORK I occasionally read and fuzz C code. But don't write it at all.
On my own projects I use C#/Elixir/Python/Perl as they let me make the most of my limited free time.
The reason to pick C is simply because those are all small system programming projects so C is naturally the top pick. I also like C for its simplicity.
J.K., I really admire who uses C, but it's not for me.
Why should I waste time reinventing the wheel and prefer C to nodejs or something like java in the worst case?
Genuine question.
I am "bored" of high level code.
I've been coding full-time for around 2 years, so still feel like I have much to learn, and bored of using other peoples solutions and taking everything for granted.
Coding in C (except strings) feels pretty good, because I can't just reach for a library and download someone elses solution - I build alot from scratch and its rewarding when the thing works.
I feel like I'm learning loads by doing C, as opposed to NodeJs.
Currently making a low-level graphics project that raycasts to form a 2.5D world. Pretty fun, all from scratch
> I am "bored" of high level code
But personally I am very "boring" an truly lazy developer, my only goal is to make shit done asap with good quality. And hi level tools (when you know their limitations and nuances) help you avoid a lot of bugs while delivering great quality for majority of real world application.
I've seen even ruby services handling crazy amount of traffic successfully. Even if it's more expensive cpu/ram wise - there are other tradeoffs that can make it worthwile.
Like, how do JavaScript arrays work under the hood? Etc etc
So, it's either C or C++. C++ because destructors and all that they enable. (Plus access control.)
Garbage collection. Code reuse is difficult in C because of differing systems for memory allocations. Basically an application doesn't really know if a library is done with a buffer and the library doesn't know... but a garbage collector does!
The ideal reusable library in C would be able to use a buffer from the application if the application had one ready. In cases where it had to build up a complex linked data structure you'd like it to pass it custom malloc and free so it can use your arena allocator, etc. In Java (Lisp, Python, etc.) libraries automatically compose with the application without having to think about any of that -- I'd say Java was a revolution for code reuse not because of OO but because of GC.
All the brain melting stuff Rustifarians have to deal with get exponentially harder when you mesh systems together which puts a break on what people can accomplish with it. (Though I guess you can interconnect islands with RC)
Poor conceptualization. C is transitional from ancient language specs like PL/I that were often unimplementable and modern specifications that succeed consistently like Common Lisp, Java and Python. There's a strange circularity in the K&R book that made me struggle with the book in high school and if you look at books like Imperfect C++ that circularity remains with the symptom that there are always important words that are used long before they are defined (RAII is chanted over and over as if it was some magic spell!) Modern language specs show you can start from primitive data types and build everything up in a logical order but I've never seen it done with C.
In normal programming languages you can parse first and deal with the symbol table later but the definition of typedef means the grammar depends on whether or not a symbol has been used, so weirdly the parser has to have access to the symbol table. All adds up to C being the language that puts the C in Cthulhu.
(For all it's faults though, C succeeded where PL/I failed as a portable systems language you could write an OS in)
I write C for the AVR8 Arduino even though it burns me up that C is moving the stack pointer around and doing other meaningless activities to support calling conventions for small programs I write that have no recursive functions and don't need it. I have something that's basically a display controller for persistence of vision displays that composites sprites that are stored in program memory following linked lists. A program like this could use entirely global variables and it would be simple, clear and efficient. Sure it doesn't scale but the thing has just 2K of RAM and I am not writing big programs for it. I'd be happier with the code in assembly, the only reason I haven't rewritten it is that I might want to run it on an ARM or ESP32 board and the C would be portable modulo just a little Harvard architecture weirdness.
So....mempool?
They probably meant this: https://en.wikipedia.org/wiki/Memory_pool
im seriously jelly of people who do it though like the redis guys, haproxy guys, linux guys, lots of giant shoulders my ts code sits upon haha
SoloKeys is an open security key. The 1st version of its firmware was in C, and while building the v2 hardware we decided to also rebuild the firmware in Rust.
- Could have we started in Rust? I'm not sure because embedded Rust was very immature when we started SoloKeys.
- Was it good to move to Rust? Probably, some of the bugs we had in C were the classical overflows that in theory shouldn't happen in Rust. The future will tell.
In summary: SoloKeys is my personal "classical example" of starting in C for various reasons and upgrading to Rust to improve safety. Let's look at the opposite example. :)
Firedancer is a reimplementation of Solana validator in C. The original validator, now called Agave, is in Rust. You can think of: 1) a Solana validator as a single-machine database, and 2) the Solana blockchain as a distributed system where all nodes run the db and independently (try to) run the same transactions on some initial state to (hopefully) produce the same resulting state. By this definition our goal is to make a second implementation of a db node in a different language, we could have chosen any language.
C was chosen for performance, but it's NOT the superficial "C is faster than rust", in fact the goal is to make the Rust implementation reach comparable performance. The difference is in the mental model, where we look at how data flows in the (single machine) system and try to optimize it at all levels. We had C code already for other projects that we repurposed it for Firedancer.
The experience of porting Rust to C has its own complexities, I'm going to list a few. Note that these are not critics to the language nor to the developers. If Solana started in C and we were porting it to Rust we would find some of the same issues and probably more. I'll try to highlight my learnings in case someone else has to port a project from language A to B -- granted our case might be a bit special because the goal is to run both in parallel and achieve consensus while often times B is going to replace A.
- In C we don't use malloc. Pretty much everything is pre-allocated and thus has known bounds. In Rust we see a lot of Vec or other dynamic structures whose bounds are not clear. In some cases these led to discovering DoS vulnerabilities. Note that this is not C, this is our mental model that translates to using C without mallocs.
Learning 1: always know your (memory) bounds.
- Rust `?` operator is very nice for Rust, very bad for someone who's trying to read the code, especially if they (i.e. me) have to match all error cases. It's very easy to miss some. Together with dyn err, it can easily make error propagation kind of random. We're spending a considerable amount of dev time and fuzzing resources not just to avoid issues with C, but to make sure we always return the same value/error in C as in Rust.
Learning 2: specify error behavior (e.g. expected errors, precedence of errors), not just the correct flow.
- Tests. This is my pet peeve, I apologize in advance. Many unit tests generate their input and then test a specific behavior. I work primarily in cryptography so let me make an example in this area: we want to test a signature verification. Bad test IMO: create a signature, then check that verify is successful. Good test IMO: there's a bunch of bytes (that we can create once by running the signature code, that's totally fine), check that the verify is successful. Think to what happens if you change the signature scheme. The first test is still passing, the second will highlight that there was a change and requires new bytes. I have countless examples of breaking changes in the Rust project that required major rewrites in C, that no one in the "Rust team" even thought they could cause any issue because unit tests are not highlighting any problem.
Learning 3: always have at least 1 test that's just a bunch of constant bytes in input.
These are all good things to keep in mind for me. I haven't had any experience with Rust yet, and only a few months with C.