Comment by kcexn | Hacker News Reader

Comment by kcexn | Hacker News Reader

Parent Full thread

C is designed with a computing model in mind (the way memory works, the way arithmetic operations work, the way addressing works etc.). And its language idioms are designed to fall strictly in line with that computing model.

There's very little difference in C between a character string, an array of Bytes, or even a struct of appropriate size. Other than the types and other user friendly (relative to assembly) features that C adds. This is deliberate; yep, it makes working with text harder (and maybe slower) than is necessary, but C doesn't assume that text is something you ever need to represent in your programs by default. So if you need to work with a lot of text, you should find a library for it, or write a library for it.

C isn't designed to be fast (though it often is). It's not designed to be safe (though it also often is). It's designed to be extremely precise, like a hardware description, or a good maths paper.

Some people like that precision. More often, people need that level of precision (see Linus' comments about C over C++ in the Linux kernel).

> Linus' comments about C over C++ in the Linux kernel

For someone of his computing calibre, I found his take on C++ surprisingly... immature. He never truly justifies exactly why he feels C++ is bad in his rants[0][1]; furthermore, he resorts to rather poor logic, which boils down to essentially C++ is bad because the programmers using it are bad.

Perhaps when he did attempt to use it, C++ was equally as immature, and the tooling and compilers were sub-optimal, and there was no RAII, nor std::algorithm, nor any of the niceties available with C++11 (it got better still with C++20's concepts, ranges, std::format, modules, etc).

I daresay that C++ is equally as precise (honestly, I'm not quite sure how to parse this in context) and perhaps even fills in the gaps where the the programmer's intention and their code diverge.

[0]: https://lwn.net/Articles/249460/

[1]: https://developers.slashdot.org/story/21/04/17/009241/linus-...

For the record, I attempted Rust. While it looks nice, I am personally more partial to the by-default freedoms that C++ gives, together with judicious use of sanitisers. If not a systems language, then I default to .NET.

RAII was in C++ around 1985 or so.

> There's very little difference in C between a character string, an array of Bytes, or even a struct of appropriate size.

This is really bad!

> It's designed to be extremely precise, like a hardware description.

This is absolute nonsense. There's far too much undefined behavior in C for it to be described as precise with a straight face.

More generally, C's lack of memory safety has been directly responsible for innumerable vulnerabilities and trillions of dollars in costs to society. It is unacceptable and irresponsible to start a new project that's meant for public use in C in 2022.

linux,openbsd,systemd etc are all in c,c looks ok to me today.

All of them have had massive security vulnerabilities, and almost certainly (at least Linux and systemd) have many publicly undiscovered ones that are currently being exploited by state actors today.

Indeed security researchers appreciate they keeping food at their table, see CVE database.

Hardware description languages also have tons of undefined behaviour. Electronics, in general, has physical conditions it can be in that will not resolve to a finite value in a finite amount of time.

The C Standard library bakes in the use of 0-termination for strings. There's nothing about 0 terminated strings that is the way CPUs work.

C defines an abstract computing model. It's not that CPU's work with 0 terminated strings. It's that the compiler will always ensure that 0 terminated strings make sense on any arbitrary architecture.

If you're a hardware designer building a microcontroller for a gas heater, you can just target the 'C' model, and you can have a high degree of confidence that anything defined by C will work.

This isn't the case for say Python, since lots of behaviour is defined abstractly in terms of API's and program behaviour (what we want the programmer to worry about), not in terms of memory allocation, and register widths etc. That a hardware designer can design to.

An additional aspect of C that I really appreciate is that if something can be conceptually realized, it can be implemented in C. This is not the case with many other languages where you are often constrained by them - either accidentally or intentionally, for safety or other reasons. In most cases you will end up having to write a C shim to do the deed and make available libraries to the other language. C toys the rescue, again!

Can you explain what you mean with an example? Sorry I’m a bot tier swe since I mostly code in node and go

Been a while, but an example would be the ability to work with rawsockets. You can't use this in most higher-than-C languages as this was not, perhaps wisely, considered useful for most people and hence there is no mechanism provided.

D and its runtime are 100% implemented in D. D could implement the C Standard library as well, but there's no point to that, since it exists and is what it is.

Reply on news.ycombinator.com