The Development of the C Language (1993)

It will depend on your goal. Do they produce the same output?

Or just comparable results?

Edit: oh, look at the chances - the ("the [only]" - 2nd to 1st) neighbouring submission is "How small is the smallest .NET Hello World binary". Suggests non overlappable outputs.

Not the commenter you're replying to, but I suspect what they mean is that the C memory model is byte-addressable not bit-addressable. You can't point/refer to a specific bit in memory, instead you have to first read the byte and then select an individual bit using bitwise operations, much like most modern processors.

I'd say that's more of an annoyance than a feature. The reason vendors use C is because it is there, comes with compilers, ides, tools, operating systems, etc. that will all work out of the box as soon as they get the compiler going on a new hardware platform. Just a critical mass of stuff that they need that conveniently is right there. And when you need to add just a few tiny things, you are going to stick with what's right in front of you instead of rebuilding all of that from scratch.

Rust is not "functional ways", though, and Go is certainly not devoid of annoyances (subjectively).

Really wish people would stop having language wars and realize that languages are tools for a job. C is like a flathead screwdriver, C++ is like a philips, Rust like a torx and Go like a hex. You can probably use a flatheat or even a philips for the torx or hex screws but you probably shouldn't, because they're not the right tool for the job.

I love Rust. I use Rust often. I choose it over C or C++ these days for a number of reasons. But I'm not going to write some throwaway little one-off scripts in Rust. I'd probably choose Python if I need to crunch some data, or Node (javascript) to do some quick I/O related tasks.

I'll use a makefile when windows compatibility and graph evaluation speed aren't important, and a shell script when compatibility and graphs aren't important at all.

And so on. The sooner people begin to realize this, collectively, we can stop having these silly "X language is better than Y" discussions.

C has its place. It's simple (quirky, but simple), doesn't take on a philosophy, and has a very, very wide set of compatible toolchains. That is the reality. Perhaps C-like's will take off and replace it (e.g. Drew Devault's Hare[0]) to get us away from most of the quirks, but that probably isn't happening any time soon.

In the same way that "putting ChatGPT in front of a computer-enabled machine gun is irresponsible", so is using unsafe languages in cases where you absolutely cannot afford a security risk without some sort of safeguards, verifiers, etc. and just good ol' fashioned "good engineering". And even in "safe" languages this is often hard to achieve, so it often comes down to the engineers anyway - not the language.

I feel like we have beaten the "C sucks" horse to death so many times that we could extract oil from it at this point. What is the goal with such discussions in 2023?

[0] https://harelang.org

I don't write C as much as i used to but i still write a lot of it, including new code. The reasons are:

1. C is relatively simple. Sure, not as simple as it could be (e.g. compared to something like Oberon-07) but in the grand scheme of language things, it is far on the simpler side of the spectrum. I can write a C parser relatively easy if i want to for example (and at some point years ago i did that to transpile a C project to C# to run under Sony's PSM platform that was based on Mono and allowed only C#).

2. Undefined behavior is annoying as it can break previously working code with newer versions of the same compiler (though language lawyers playing word games like the code already being broken are way more annoying - the code did the thing i wanted previously so as far as i am concerned it was not broken), but this is something that aside from "obvious" things (accessing invalid memory) i can probably count in my fingers the times i encountered in practice (i write "probably" because right now i can't remember any case, but i've being writing C for more than 20 years). Valgrind and Ubsan help with these so they are not much of a practical concern.

3. I find CPP macros to actually be very useful and a feature that a) i'd actually like expanded instead of being stuck in the 80s (let me store some state or have a loop, FFS) and b) were available on languages too (Free Pascal is a language i also use and does have some C-like macro support, which is more than what you'd find in other languages but still not to the same extent as C). D's mixins essentially being ubermacros are a thing that i liked with that language but sadly their stance on breaking things is something that kept me away from it.

4. A C compiler is available on pretty much everything that can compute things - or at least on pretty much everything i might think on targeting with C anyway (and chances are there are multiple C compilers instead of just one). If not, i can probably write a compiler myself - it'd be rather simple and not that great but i'd be more likely to finish it than a compiler for some other language.

4b. Very related, so it gets a "4b" instead of 5 :-P, but there are a bunch of IDEs and editors that "understand" C. I like IDEs, i like syntax completion, i like semantic highlighting, i like being able to easily rename an identifier, etc and C being easy to parse (see #2) means it has a lot of those. Let me correct that, i don't "like" IDEs, i love IDEs.

5. Most modern computers might not technically be like how C presents them to be, but they're close enough where any differences only matter if you're trying to perform microoptimizations to your microoptimizations - at which point you'd most likely be using a combination of compiler-specific heuristics and assembly code anyway.

6. In most systems where that'd be a concern, the C ABI is pretty much stable or at least there is a stable C ABI, allowing any code written in C to be usable by other languages as well as shared libraries to be able to expose an ABI that will remain backwards compatible and usable by other languages. Of course other languages can do that but they pretty much always do it through a C-fication of their APIs.

7. C compilers - even those that perform a dangerous (see #2) number of optimizations - tend to be very fast. I hate waiting the computer to finish doing things so i tend to prefer languages with fast compilers.

8. While i don't (always) need to maintain 30+ year old code, i do have existing C code that (seemingly, see #2) works and i don't see a reason to waste time rewriting that code in some other language. Even if it'd be broken chances are it'll be faster to fix it than rewrite it.

9. I am comfortable with C. For me being comfortable with a language important because it lets me focus on the thing i'm trying to use the language for instead of the language itself.

There might be other stuff i forgot, but the above should give you an idea why i personally write C. Though note that i don't see as any sort of perfect language, there are a lot of things i'd like it to do better - including the type system you mentioned as well as the compile-time code evaluation i wrote above, be it via CPP or by some other means - but it is good enough.