21–30 of 118 posts
The primary benefit to C is that it is simple. And that is IMO the reason why it has such sticking power. The entire language & toolchain is understandable at a fairly core level without too much effort. Please don’t start a C flame war either HN. I know I’m nerd sniping you all on this one
The primary benefit to C is that it is simple. And that is IMO the reason why it has such sticking power. The entire language & toolchain is understandable at a fairly core level without too much effort. Please don’t start a C flame war either HN. I know I’m nerd sniping you all on this one
C _looks_ simple, deceivingly so. As soon as you need to deal with a large project in a corporate environment on a code base aged in double digit years you don't think it's simple anymore. C is incredibly complex, unmanageably so.
Earlier quoted context omitted.
The use-case for Rust is not the same as C. In general, C is a better option if you find you are escaping to macro defined Assembly or other memory ops (glib back-ported data structures for C highly recommended). Rust likes to keep unsafe operations organized, but is a persistent pain if a problem scope requires many "unsafe" operations. I'd wager Rust will end up like Boost... really cool.. but too chaotic to trust…
I don't get the 10 months part. is it some reference?
https://en.wikipedia.org/wiki/Second-system_effect
i.e. the attempt to "improve" ultimately adds additional complexity, and defeats its stated purpose due to conflicting use-cases.
The primary benefit to C is that it is simple. And that is IMO the reason why it has such sticking power. The entire language & toolchain is understandable at a fairly core level without too much effort. Please don’t start a C flame war either HN. I know I’m nerd sniping you all on this one
I would argue it's very easy to think one understands it. However I would wager most people who say they understand C don't really know many of the undefined behaviour cases and their implications.
(But, I also totally concede that a language is inseparable from its std lib in reality)
This entire article seems to amount to "I am used to C, thus I don't see the problem with C." which is a fine position to have, but it's a perspective unique to the writer and others like him. It doesn't apply to people learning new languages that aren't C. Also several statements about how C must be used because somehow it's closer to the real world/hardware than other languages. Which is easily shown to be false gi…
Earlier quoted context omitted.
Your comment seems to assume C++ is a better, safer language than C. I know a number of people who would sharply question that assumption. I for one really hate destructors. They mean you can never tell what `delete` does. I remember a nasty double-free bug I had because of that.
First off, new/delete are only used for objects that are allocated on the heap. Even then, modern C++ has RAII wrappers such as std::unique-ptr. You should only need new/delete in rare cases.
The primary benefit to C is that it is simple. And that is IMO the reason why it has such sticking power. The entire language & toolchain is understandable at a fairly core level without too much effort. Please don’t start a C flame war either HN. I know I’m nerd sniping you all on this one
Write a multithreaded program guaranteed to have no data races in C and tell me that C is simple. C _looks_ simple, deceivingly so. As soon as you need to deal with a large project in a corporate environment on a code base aged in double digit years you don't think it's simple anymore. C is incredibly complex, unmanageably so.
But, I’m not arguing with you. I honestly think that any corporate codebase after double digit years (and seven figure LoC) turns into a completely unmanageable mess. If it isn’t, it’s because of the team culture and pure rigor. Not the language
This entire article seems to amount to "I am used to C, thus I don't see the problem with C." which is a fine position to have, but it's a perspective unique to the writer and others like him. It doesn't apply to people learning new languages that aren't C. Also several statements about how C must be used because somehow it's closer to the real world/hardware than other languages. Which is easily shown to be false gi…
[flagged]
Not sure what you mean by “rant”, he makes some good points.
Earlier quoted context omitted.
I would argue it's very easy to think one understands it. However I would wager most people who say they understand C don't really know many of the undefined behaviour cases and their implications.
I would bet that the vast majority of undefined behavior encountered is when interacting with the standard library though. Which isn’t really the languages fault (But, I also totally concede that a language is inseparable from its std lib in reality)
Earlier quoted context omitted.
How would malloc/free be better in that situation?
I don't know, but when I use C, I like to statically allocate everything if at all possible, I don't free() anything, I let the OS clean everything up at exit(). A lot of the small Unix utilities don't necessarily need dynamic memory allocation IMO