13 ms·

Two types of C programmers

111 points by susam 4y ago

jstanley 4y ago
The post is kind of confusing regarding which sort is the "first sort", because they are presented in one order in the provocative thesis, and in the other order in the following paragraphs. But: > My perception of the second sort of C programmer is that if they've moved to any more recent mainstream language, it's probably Rust. If in this context the "second sort" is the type who likes C on its own merits (rather than because they don't have any other choice), I think Zig is a much better option than Rust.
- pyrolistical 4y ago
  I am the first sort. I mostly like the ideas from C but don’t like the actual implementation. Which is why I’ve moved on to Zig. The author asserting the second sort would have moved on to Rust makes sense. They are ones who are trying to get away from C ideas
- rbatiati 4y ago
  I've always thought of myself as the second type of C programmer... I only used C if no other option was available (yeah, it was indeed fear!). After I started programming in Zig, I realized I really appreciated all of C's simplicity and (lack of) features, but now in "Zig fearless mode", it makes me feel like I always belonged to the first group.
antiquark 4y ago
[flagged]
- eckesicle 4y ago
  … and those who mistake it for trinary.
  - jwandborg 4y ago
    10 in binary _is_ 2 in decimal. I think you've made an off-by-one error in your critique.
    - version_five 4y ago
      But it's (decimal) 3 in ternary, I think that's the point (you get a 3rd group of people if you're mistaken about the base)
      - jwandborg 4y ago
        Could be that I missed the joke.
    - jwandborg 4y ago
      In fact, 10 in any base represents the base number.
      - jzwinck 4y ago
        Good point, but not in base 1.
        lioeters 4y ago
        > In the unary system, the number 0 (zero) is represented by the empty string, that is, the absence of a symbol. Numbers 1, 2, 3, 4, 5, 6, ... are represented in unary as 1, 11, 111, 1111, 11111, 111111, ... https://en.wikipedia.org/wiki/Unary_numeral_system https://en.wikipedia.org/wiki/Unary_numeral_system
  - SAI_Peregrinus 4y ago
    And those who know that "10" can be any number if you change the base.
sparkie 4y ago
I'd consider myself the former: I use C because it's the only viable option for what I'm doing - but most of the time it's nothing to do with C itself, but the various extensions and builtins of GCC. It's the inline asm, the control of registers, placement of code and data, control of inlining, etc, which are missing from all of the C "replacements". The replacements assume you are building a user application on top of an existing unix-like OS or VM, but they're missing the parts necessary to write the OS or VM itself. They don't provide simple ways to use hardware-specific features. Obviously there is C++ which can leverage most of this too, but C++ traps you into an ABI which is difficult to use from any language which is not C++.
- galaxyLogic 4y ago
  Good points. I like C, I think simplicity and hardware alignment make it very useful. Simplicity wins in the end.
  - cat_plus_plus 4y ago
    C is not aligned with modern hardware and optimizing compilers are severely hampered by things like undeclared pointer aliasing.
    - fsckboy 4y ago
      so then, add a declarator or two to solve the problem, don't just throw the baby out with the bathwater. The population of C programmers who understand how C works is the population of people who can understand how hardware works. The reverse has never been true, hardware designers have never understood software, and academic software experts have spent too much time babysitting college freshman who can't code and spend all their time dreaming about languages that freshmen could learn well enough to TA the course. But that's probably not a language good enough for systems programmers to adopt.
      - pjmlp 4y ago
        It is called restrict and usually a fun problem to debug if one causes UB by actually having two restrict pointers doing aliasing.
anderspitman 4y ago
I also mostly use other languages these days, but there's still something about C that always feels like coming home to me. Maybe it's because it's what I used during my apprenticeship which is where the magic of programming finally clicked for me (after a failed attempt taking a programming class). Maybe it's just the simplicity and lack of rules to learn.
- efficax 4y ago
  the simplicity of c is an illusion the moment you start using pointers and define macros. nothing is harder to understand than a big C program, imo
  - matheusmoreira 4y ago
    I don't see how simplicity is lost through use of pointers. Dynamic language variable references are essentially pointers and they couldn't be simpler.
    - zokier 4y ago
      Pointer provenance.
- ordu 4y ago
  > Maybe it's just the simplicity and lack of rules to learn. This is how I feel about assembler. No rules, you on your own. And it is impossible to imagine simpler language. Though I do not write asm lately.
samsquire 4y ago
I used C for my own just in time compiler because I wanted to learn C. I still don't "know" C or what's a customary way of doing things because I only started with C code by Martin Jacob that executes machine code in a memory buffer ( https://gist.github.com/martinjacobd/3ee56f3c7b7ce621034ec3ecbc8e13f1/fe7e78b89e1581ff15c4d2797662516f281a33bd https://gist.github.com/martinjacobd/3ee56f3c7b7ce621034ec3e... ) and some Perl Compatible Regular Expression library example C file. I want to know C enough that I can create good APIs in it and transpile to C effectively because I want to take advantage of LLVM and gcc optimising backends.
tonyedgecombe 4y ago
It's interesting that C has managed to remain relatively stable whilst everything else has ballooned in size. I spend most of my time writing C# and it has become quite large. I wouldn't want to pick it up from scratch now.
- zabzonk 4y ago
  actually, C has ballooned in size and complexity. it has come a long way from the first edition of k&r.
- rileymat2 4y ago
  At the same time, people have expectations for ability now. A beginner might want to make a web request, good luck doing anything beyond mimicry with C from code samples if they get that far. With python, they could pull it off quickly.
- pjmlp 4y ago
  C23 versus K&R C, and then there are all those compiler specific extensions.
version_five 4y ago
To be a bit pedantic, those options aren't mutually exclusive. An appealing property of C is that it's easy to target almost any device (often making it the best or only option). So it's possible to like C because you like (and need) something you can compile in lots of different places.
vivegi 4y ago
I learnt C in college but C++ was emerging as the language of choice circa 1995 when I got into my first job. This was before C++ was standardized and we had to make do with whatever MSVC 1.5 would do. It did not even support templates back then and even the highly polarizing STL did not exist yet -- in a cross platform way; The STL source itself was available from 1994, and if I recall right, the C++ compiler on Sun/Solaris supported templates etc., We were then a Sun/Solaris + Dell/WinNT shop then and had software running on both and therefore settled on the lowest common denominator of features supported by compilers on both platforms. Heady days. Given that environment, I was comfortable switching between C and C++.
- pjmlp 4y ago
  Borland did templates since 1993, Borland C++ 2.0 and Turbo C++ had early support for them, and BIDS 2.0 changed from pre-processor macros into the templates experimental design. MSVC was always behind until Borland management messed up.
  - vivegi 4y ago
    Yes, that’s right. In fact, in college we used Borland compilers. But my first job had standardized on MSVC. So, that determined what I used on the job. Loved Turbo Pascal and Turbo C++ IDEs in those days. Simple and fast!
pjmlp 4y ago
Some people like to workship whatever the UNIX founders have done, yet they miss that for Plan 9 and Inferno, they also decided to go with automatic memory management languages. While Alef failed, Limbo's design with GC was considered a revisit from what was missing from Alef. They also miss that lint was considered a must have tool for safer C code, introduced in 1979, and that Dennis actually proposed fat pointers to ISO, which weren't accepted. https://en.wikipedia.org/wiki/Alef_(programming_language) https://en.wikipedia.org/wiki/Alef_(programming_language) http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ http://doc.cat-v.org/inferno/4th_edition/limbo_language/ http://doc.cat-v.org/inferno/4th_edition/limbo_language/ https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/vararray.pdf https://www.bell-labs.com/usr/dmr/www/vararray.pdf
- jesse__ 4y ago
  > yet they miss that for Plan 9 and Inferno, they also decided to go with automatic memory management languages And which of these three operating systems won?
  - rwmj 4y ago
    Operating systems don't "win" because they make the best technical choices ... or even because they are best for their users.
    - lelanthran 4y ago
      Maybe, but when all the winning OSes share a common characteristic then you cannot simply dismiss that characteristic as irrelevant to winning without some evidence that it is not relevant.
      - int_19h 4y ago
        The winning characteristic in this case is "it was already there, and it was good enough". This is a recurring theme in the industry.
fargle 4y ago
I appreciate the sentiment, but: - there doesn't have to be "two kinds". Trivially you can fit both "types" at once, I certainly feel that way. And if there are 100 programmers, there'd be about 237 other reasons to use a language. False dichotomy. - a better categorization might be "there are two kinds of C programmers: those who eventually start using rust and those that don't." which is at least of course absolutely true. - I dislike the idea that a programmer is bound to a language. He's a "C" programmer, She's a LISP person, etc. A good software engineer should use about 5-10 different languages appropriate for the purpose at hand.
- eqvinox 4y ago
  > I dislike the idea that a programmer is bound to a language. He's a "C" programmer, […] Nothing in the article suggests that being a "C programmer" is that kind of a binding label. It's you reading that into it ;). (Though certainly influenced by the fact that that is a widespread interpretation.) FWIW, I consider myself a C programmer, and in both camps presented in that article. But I'm also a Python programmer, and I don't think either of those two languages "owns" me.
- psyklic 4y ago
  I disagree that enjoying C automatically means you will like Rust. If you are obsessed with safety, Rust will be a nice solution. But Rust is a much more complex language than C, which will turn many C programmers away.
  - unionpivo 4y ago
    But its not really. Sure it seems so when you start. K&R and away you go, that programming is a lot easier than writing rust sure. But unless you are writing for just yourself, no current C software get developed that way. You need to understand C standard, that is quite complex and you need to understand it in detail because of undefined behavior (and of course how your compiler interprets it and sometimes fight with compiler to emit right code). Then you needed to know all the gotchas in the standard library, and how you properly use them. Then you need to know how to do basic arithmetic without having undefined behavior (that's where a lot of memory leaks happen). Or maybe the software you are working on has created their own implementation of most of those functions, so you need to figure how to use those. Even to just print out a debug statement can sometimes be nontrivial. And of course you need a way to compile the damn thing, just figuring out what sane options you need to use to get decent warnings and what they mean takes a while. And when you figure all of that out, you still need to keep track of most of the stuff that borrow checker does, but this time by hand using comments and conventions (that you also need to learn for each project.) (I left out whole build setup, but its usually harder than Rust one too. ) I believe that programmer who has only programmed java or maybe C# before (or python, js...) will get up too up to speed faster on Rust than on C on most real-world projects C is deceptively simpler.
klyrs 4y ago
I'm old enough to be in both camps. After years of toodling around in a variety of BASIC languages, I took a class on C. For the first time, I went from a vague text-to-result association to a clear picture of machine and its inner workings*. I then learned C++ and Java which were both hot garbage at the time, and a variety of scripting languages. The scripting langues are great for high productivity and mediocre performance. Shell languages are great for interacting with the operating system. Query languages are great for interacting with big data. But for years, C was the unparalleled language for getting the best performance out of CPU-intensive algorithms. I've still never found a language that erases these boundaries -- while I'm a "C programmer" I'm multilingual by necessity. Today? C's performance is matched by C++, and more tedious to write. Zig is there on performance, but for my purposes, the language gets in the way. Rust also gets in the way, and can end up forcing reference-counting which tanks performance. I do like how Go mostly gets out of the way, but again, I cannot abide unnecessary reference counting. * and, yes, the abstraction is a lie, but it's an incredibly useful and high-performance abstraction
- throwawaymaths 4y ago
  > Zig is there on performance, but for my purposes, the language gets in the way I guess zig for me is indeed a slightly more complicated language than c, and it's way more verbose, but what I appreciate about it is that straightforward code looks good and code that is on shakier ground looks hairier which is basically a "this code is sus, plz review the fuck out of it" sign. In the end though, what gets in the way for me with C is everything else to ship a "real c program", especially when you want/need someone else's code. Lexical macros, header/code separation, flat namespace, errno, architecture dependent definitions for int, char, etc, having to think about object (file) units, make, automake, config... At that point the cognitive burden is enough that a small added complexity in the language is worth it
- int_19h 4y ago
  Go uses a tracing garbage collector. Although I suppose that's even worse from this perspective. If you don't mind me asking, how does Zig get in the way? My own gut feel is that it's the only real "better C" out of the present crop of alternatives.
photochemsyn 4y ago
With C, programmers of different types (there are certainly more than two) can be combined into one operational unit by a clever manager. Sometimes differently typed programmers will implicitly agree to adopt a uniform approach before working together on a project. Sometimes the programmers won't do this by themselves and so a manager is needed to explicitly guide them to adopt the appropriate type. However, some types stubbornly resist conversion, and so are tricky to work with. Pointy-headed programmers tend to be surprisingly flexible, and the ones who stare off into the void are often the most useful when you need them to function effectively. Overall, managers who can understand and utilize this hierarchy of programmer types in their organization may find themselves getting promoted regularly. Of course, many people can't stand these corporate structures and prefer the simple farmer's life, raising ducks instead. Quack!
williamcotton 4y ago
C with libdispatch and clang blocks is the most fun I’ve had programming in quite some time! Here’s a web framework (complete with ORM) modeled on ExpressJS written in C: https://github.com/williamcotton/express-c https://github.com/williamcotton/express-c The finished product is < 90Mb Docker image that idles at like 2Mb of memory. There’s also a lot of examples of the (basically required) support tooling like Valgrind, AdSan, etc. Check it out!
- winrid 4y ago
  It looks cool. The DB library is appreciated. However, you would get about the same idle memory and docker size with Go's Fibers framework :)
  - williamcotton 4y ago
    Lol, yeah, the libdispatch runtime is probably about as big as the Go runtime! I think this has a slight advantage in that it uses a memory arena for a per-request bump allocator so it should keep overall memory usage lower. The slowest part of all this has to do with Block_copy and the places where I’m very much treating blocks/closures in an OOP type manner. This could be fixed by writing a different function that did basically the same thing as Block_copy but for all the “methods” on an “object” in a single pass. But who has time for that? :D Here’s more about those performance issues and some example code that show how slow the approach is: https://github.com/williamcotton/express-c/tree/master/research/blocks https://github.com/williamcotton/express-c/tree/master/resea...
  - preseinger 4y ago
    go-fiber is a weird, non-idiomatic, and non-serious project, fine for a proof of concept, but definitely not something anyone should be using in prod but your point is sound, any reasonable go http server will have the same level of memory usage at idle
    - winrid 4y ago
      Wow, really? The project has 25k github stars and 300 contributors. They are on v2.44. Why is it not serious? What makes any software "serious" to you?
up2isomorphism 4y ago
“My perception of the second sort of C programmer is that if they've moved to any more recent mainstream language, it's probably Rust.” If you are the first type, you likely get the second type’s taste wrong. Rust is very very different from C both in terms of syntax and philosophy.
- pornel 4y ago
  Rust is from a different language family, but I think it still fits a taste of "low-level control, not OOP, not C++". I know many people see "complex with angle brackets" and equate Rust more with C++, but I disagree and think it's still closer to C — I can convert C libraries 1:1 to Rust, but C++ libraries hit an impedance mismatch and are really hard to rustify.
  - pjmlp 4y ago
    The use of macros and compiler plugins is pretty much closer to C++.
  - scoutt 4y ago
    > "low-level control, not OOP, not C++". Things have a drop-scope. There are hidden initializations. Boxing is required for many things including dynamic dispatch in error handling. The tendency to use FP-like one-liners. All that mixed with funny syntax that hurts C developers eyes. A lot of "no-go" in C land (at least for me), that makes really hard to learn and to move definitely into Rust (again, at least for me)
- Gibbon1 4y ago
  I feel like another division is there are programmers who love mathy languages and syntax and those that hate mathy languages and syntax. The former looks down on the latter with contempt. And the latter thinks the former is annoying.
eqvinox 4y ago
Tense is very important with this article. People who chose C. Whatever these reasons were that made someone chose C, that choice may have been made 20 years ago, and the choice may pan out very different if made now. But now you have 20 years of C experience…
- gavinhoward 4y ago
  I was not there in those days (somewhat young). I have still chosen C, and I chose it before I had experience with it. I just like the low-level nature.
pm215 4y ago
Personally, the primary reason I'm a C programmer because the main project I work on is a million lines of code, and it's C... As with COBOL, legacy code will mean there's still demand for C programmers for a fair while yet.
_darkmatterdev_ 4y ago
I consider myself the latter who just hasn’t had the time to look into Rust or Zig extensively. But also, I work in safety critical application and it would be hard to shift the organization over to Rust for a lot of reasons, both technological and political.
cracrecry 4y ago
Why I love C? In a word, simplicity. A language designed by a single person. I also did program a lot in CLisp, a language designed by committee, with more than 100 different flow control directives(and people often create their own). I loved and love Lisp as a concept and tool, but hated CLisp complex design so badly. I programmed in Arc for a while because of that. I have created my own C compiler and interpreter. Something impossible to do for a single person in C++(C++ is way more complicated). I also love manual memory handling in C because it lets me create my own automatic local systems much more efficient than someone else's "one size fits all" aproach. I have also programmed mac apps in Objective C and Swift, C++, java, javascript, Perl. I program today mainly in four languages: C/C++, Python, Rust and Clojure. With C it is so easy to create python modules. It is trivial to interoperate from C++ with C. Clojure is a Lisp that is simple, clean design, and you could interoperate with java objects. Rust has some advantages over C, but also disadvantages(it is too bloated).
- WalterBright 4y ago
  > impossible to do for a single person in C++(C++ is way more complicated) I wrote a fully compliant C++98 compiler (Digital Mars C++).
- shrimp_emoji 4y ago
  >I have created my own C compiler and interpreter. It's relatively simple because everything is UB/UsB/IDB. ;)
- WalterBright 4y ago
  > In a word, simplicity. For fun, go to /usr/include and try to understand the system .h files.
  - gavinhoward 4y ago
    This is why I've kinda built my own libc on the bare minimum that the system gives me. The POSIX and Windows API's are garbage; C the language is great.
the__alchemist 4y ago
Implicit in the article is that there are only a handful of languages capable of certain use cases. Eg, embedded, bare-metal, programming operating systems, performance-sensitive code etc. So, your options are limited (C, C++, Rust, Zig, ADA, maybe a few more?), which would drive option 2.
deleted 4y ago
[deleted]
phendrenad2 4y ago
I think there are way more types, or subtypes. The first category can be broken down into "people who like C because it's simple" and "people who use C because they need to do manual memory management" (and that can be broken down into "has not tried Rust" and "has tried Rust and didn't like it"). The second category can be broken down into "people who wrote a program in the 1980s in C and are now stuck with it" and "people who learned C in the 1980s and haven't tried to learn a new language" and "people who learned C in the 1980s-1990s and think that Python and Ruby would be too slow for their purposes (no longer true)".
jasoneckert 4y ago
Many people I know (myself included) started in the second category in the 1980s and 1990s (C = God's programming language) and then moved to the first category once attractive alternatives (e.g., Go) that met our use cases became widely used.
mmphosis 4y ago
I am definitely the former. I didn't like C too much in 1986 but there wasn't really anything else except writing in Assembler! Having programmed in Pascal, it wasn't too much of a leap to transition to C. The C compilers at the time were buggy. 37 years later, I still write C programs. I won't touch C++.
hgs3 4y ago
> I no longer want to have to think about memory management and related issues. In some cases efficient memory management _is_ the problem to be solved. I'm not just talking about esoteric or embedded systems here. If you're developing for modern GPU's with a modern API, like Vulkan, you must manage GPU memory yourself. With direct memory access you can do many "unsafe" things, like memory aliasing, to improve performance. "Safe" languages, like Rust, will not help you here.
gavinhoward 4y ago
I'm the former kind: I choose C because I like it above all else. [1] That said, like the author, I'm trying to find an alternative. Well, more like I'm building my alternative because I hate Go. And Rust. And anything else. I don't know why C fits my brain, but it does. I think it's because my brain is low-level; I like messing with assembler when I get the chance to optimize. [1]: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-in-memory-safety/ https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
- tacitusarc 4y ago
  How do you feel about zig?
  - gavinhoward 4y ago
    I hate it.
    - throwawaymaths 4y ago
      Care to explain why?
      - gavinhoward 4y ago
        Several things, but I'll name two. comptime just doesn't fit my brain well. Async Zig gives me a headache. [1] [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-colors/ https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
        throwawaymaths 4y ago
        Got it. Thank you for your perspective. I can appreciate that comptime is tricky. Indeed, async zig is hard and annoying (but you're wrong about the function coloring... Here is someone's project where they call an async function alternately from a sync or async context with zero lines of code: https://youtu.be/lDfjdGva3NE?t=1999 https://youtu.be/lDfjdGva3NE?t=1999 Yielding is async and threaded is sync)
shmerl 4y ago
What about those who are stuck with it because of the huge legacy code base? They wouldn't choose it deliberately for anything new, but there isn't much they can easily do about it in the above case. People who chose C as the best option at the time might not be even around the project anymore.
haberman 4y ago
I am a C programmer. For me the language is a means to an end. I prefer to work on problems where both performance and code size is paramount. The kinds of problems where it makes economic sense to spend months or years of engineer time designing and implementing a solution that will compile to a 50kB binary. I think primarily about the kind of machine code I want to generate, and pick a language that best approximates that ideal output code while still allowing the source code to be as clear as possible. From these constraints I keep coming back to C. Zig is the most appealing contender in terms of next-gen languages. If I could get safety without giving up anything, of course I would take it. But I am increasingly convinced that this is not generally possible.
- softirq 4y ago
  How do you feel about Rust?
  - haberman 4y ago
    I was really positive on Rust for at least five years. But several experiences have led me to reconsider this position, most notably the difficulty using arena allocation: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html https://blog.reverberate.org/2021/12/19/arenas-and-rust.html This is one of the things that endears me to Zig: passing an explicit allocator around is a very common idiom in the language.
    - int_19h 4y ago
      I'm curious what you think about Ada; from what I remember, its memory management facilities have this basically as a first-class thing directly in the language.
Scubabear68 4y ago
I used C in the late 80s and 90s because it was the only viable option for many use cases. In the late 90s I got heavily involved in Java, and C usage dropped. Had some spikes of C++ work (which I despised), and then working in many different languages with no real work on C or C++ in at least 18 years or so. What always killed me the most in C was the absolutely anemic standard library. OS’ had more libraries, but still very low level stuff.
cat_plus_plus 4y ago
I don't get enjoying every second line being "if (r == -1) goto cleanup" and then a cleanup block freeing every pointer which is not null. True, you can define macros to automate that, but then you just end up with clunkier version of C++ destructors. The rest depends on what you are doing, no need for heavy OOP for simple tasks and on the other hand automatic memory management is great when reliability is more important than hardware access or real time performance. But at least no reason to avoid automated facilities that replace well known red tape.
hwc 4y ago
Also, wants to use C ABI in other software.
- xvilka 4y ago
  You can easily expose it from Rust as well.
kps 4y ago
C programmers are implicitly converted to the required type. Implicit conversions are one thing I don't like about C, or at least the way it ended up as int grew (maybe it would have been better if ANSI had picked unsigned-preserving, but maybe that's just grass-is-greener thinking). I also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs.” I do like the directness and explicitness. Good C can be very nice.
- cpncrunch 4y ago
  I used to think implicit type conversions were bad in C, until I started programming in javascript.
  - kps 4y ago
    `5 - "2"` is 3, and `5 + "2"` is "52". Makes perfect sense! It could be worse, though; you could be doing Norwegian YAML.
- tialaramex 4y ago
  > I also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs.” You can have a language where all the behaviour is defined but in my experience most programmers who whine about this in C are just as unhappy because what they actually wanted was DWIM. In a language with defined behaviour their program is wrong, which is their fault, whereas in C they can claim "obviously" it's the compiler's fault. I like it when it's my fault, I just learned something, and early in my education I assumed everybody was the same but I rapidly learned that most people prefer to be told they're correct regardless, and a language which says "Nope, 4 - 5 is a negative value and this variable in unsigned, too bad" makes those people unhappy, whereas when 4 - 5 = mysterious program behaviour they can blame the compiler engineers instead.
  - kragen 4y ago
    4u - 5u is not undefined behavior in c; unsigned arithmetic overflow is defined to wrap around, in both directions assigning -1 to an unsigned variable has never been undefined behavior either, but implementation-defined behavior (see §6.2.1.2p3 in iso c90 or §6.3.1.3 in c99 and c11); decent compilers like gcc define it to do the obviously correct thing (see https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.h...), not produce mysterious program behavior. in the new c++20 standard it's no longer even implementation-defined, but fully define behavior in the standard, but in standard c it's still implementation-defined as a programmer who whines about the kind of ub exploitation at issue here, and who (as established above) has a much clearer idea than you do of what behavior is and is not defined, specifically what i am whining about is that it's harder to debug my code if doing things like dereferencing a null pointer doesn't reliably crash it, but instead triggers the silent removal of apparently unrelated logic from my program, or subtle semantics changes in it, in the name of optimization also it sucks to have existing security-sensitive code acquire new security holes, and i don't really care if that's a learning opportunity for the guy who wrote it 20 years ago this didn't happen 20 or 30 years ago, and in those 20 or 30 years the impact of introducing fresh security holes into existing well-tested c code has greatly increased, while the usefulness of c compiler optimizations has greatly decreased
patrakov 4y ago
There is (or maybe was a few decades ago) a third type. A person who was taught C programming in the school/university, because back then it was the norm to teach it and nothing else, and who does not have enough motivation or abilities to learn anything else on their own, even if C is clearly the wrong tool for what they are doing.
skywhopper 4y ago
Not sure what’s provocative about “people use language X because either they like it or they have to use it”. The same could be said about every tool.
worthless443 4y ago
> They feel strongly drawn to C's virtues, often explicitly in contrast to other languages Can someone point me to which set of virtues you are talking about here? Simplicity? Value semantics and imperatives, little abstractions over what the computer OS is actually doing? Manual control over almost everything being done? Are such "virtues" safe and dignifying under an universal context of computer programming? Isn't it a bit dangerous to let such Virtues take over in modern programming dealing with heavy abstraction layers because of the yield in complexity of modern hardware?
xorvoid 4y ago
I switch between both depending on my mood and the particular application. For me: Rust killed C++ but not C I have an on-again off-again love affair with C. And in its domain it’s still unmatched: low-level close to hardware where you directly need to deal with concepts that are normal abstracted away: alignment, custom layouts, type punning, pointer tagging, different types of memory, cache coherency, DMA, kernel bypass, etc etc Sure you can do it in rust unsafe but it’s (intentionally) a world of pain. But, when you start needing bigger abstractions or you work with a team larger than say 5, C falls on its face super fast. But it Feels Oh So Nice otherwise. Here’s to me hoping Rust unsafe becomes more usable and can be a proper C successor someday. But.. I’m happy to be rid of C++ :-) (I’ve been meaning to write a blog post on this for some time)
- xorvoid 4y ago
  One more thing: codegen Getting good codegen out of Rust is 5 times harder than C. And sometimes it’s not really possible.

111 points by susam 4y ago

The post is kind of confusing regarding which sort is the "first sort", because they are presented in one order in the provocative thesis, and in the other order in the following paragraphs. But: > My perception of the second sort of C programmer is that if they've moved to any more recent mainstream language, it's probably Rust. If in this context the "second sort" is the type who likes C on its own merits (rather than because they don't have any other choice), I think Zig is a much better option than Rust.

pyrolistical 4y ago
I am the first sort. I mostly like the ideas from C but don’t like the actual implementation. Which is why I’ve moved on to Zig. The author asserting the second sort would have moved on to Rust makes sense. They are ones who are trying to get away from C ideas
rbatiati 4y ago
I've always thought of myself as the second type of C programmer... I only used C if no other option was available (yeah, it was indeed fear!). After I started programming in Zig, I realized I really appreciated all of C's simplicity and (lack of) features, but now in "Zig fearless mode", it makes me feel like I always belonged to the first group.

antiquark 4y ago

[flagged]

eckesicle 4y ago
… and those who mistake it for trinary.
- jwandborg 4y ago
  10 in binary _is_ 2 in decimal. I think you've made an off-by-one error in your critique.
  - version_five 4y ago
    But it's (decimal) 3 in ternary, I think that's the point (you get a 3rd group of people if you're mistaken about the base)
    - jwandborg 4y ago
      Could be that I missed the joke.
  - jwandborg 4y ago
    In fact, 10 in any base represents the base number.
    - jzwinck 4y ago
      Good point, but not in base 1.
      - lioeters 4y ago
        > In the unary system, the number 0 (zero) is represented by the empty string, that is, the absence of a symbol. Numbers 1, 2, 3, 4, 5, 6, ... are represented in unary as 1, 11, 111, 1111, 11111, 111111, ... https://en.wikipedia.org/wiki/Unary_numeral_system https://en.wikipedia.org/wiki/Unary_numeral_system
- SAI_Peregrinus 4y ago
  And those who know that "10" can be any number if you change the base.

sparkie 4y ago

I'd consider myself the former: I use C because it's the only viable option for what I'm doing - but most of the time it's nothing to do with C itself, but the various extensions and builtins of GCC. It's the inline asm, the control of registers, placement of code and data, control of inlining, etc, which are missing from all of the C "replacements". The replacements assume you are building a user application on top of an existing unix-like OS or VM, but they're missing the parts necessary to write the OS or VM itself. They don't provide simple ways to use hardware-specific features. Obviously there is C++ which can leverage most of this too, but C++ traps you into an ABI which is difficult to use from any language which is not C++.

galaxyLogic 4y ago
Good points. I like C, I think simplicity and hardware alignment make it very useful. Simplicity wins in the end.
- cat_plus_plus 4y ago
  C is not aligned with modern hardware and optimizing compilers are severely hampered by things like undeclared pointer aliasing.
  - fsckboy 4y ago
    so then, add a declarator or two to solve the problem, don't just throw the baby out with the bathwater. The population of C programmers who understand how C works is the population of people who can understand how hardware works. The reverse has never been true, hardware designers have never understood software, and academic software experts have spent too much time babysitting college freshman who can't code and spend all their time dreaming about languages that freshmen could learn well enough to TA the course. But that's probably not a language good enough for systems programmers to adopt.
    - pjmlp 4y ago
      It is called restrict and usually a fun problem to debug if one causes UB by actually having two restrict pointers doing aliasing.

anderspitman 4y ago

I also mostly use other languages these days, but there's still something about C that always feels like coming home to me. Maybe it's because it's what I used during my apprenticeship which is where the magic of programming finally clicked for me (after a failed attempt taking a programming class). Maybe it's just the simplicity and lack of rules to learn.

efficax 4y ago
the simplicity of c is an illusion the moment you start using pointers and define macros. nothing is harder to understand than a big C program, imo
- matheusmoreira 4y ago
  I don't see how simplicity is lost through use of pointers. Dynamic language variable references are essentially pointers and they couldn't be simpler.
  - zokier 4y ago
    Pointer provenance.
ordu 4y ago
> Maybe it's just the simplicity and lack of rules to learn. This is how I feel about assembler. No rules, you on your own. And it is impossible to imagine simpler language. Though I do not write asm lately.

samsquire 4y ago

I used C for my own just in time compiler because I wanted to learn C. I still don't "know" C or what's a customary way of doing things because I only started with C code by Martin Jacob that executes machine code in a memory buffer ( https://gist.github.com/martinjacobd/3ee56f3c7b7ce621034ec3ecbc8e13f1/fe7e78b89e1581ff15c4d2797662516f281a33bd https://gist.github.com/martinjacobd/3ee56f3c7b7ce621034ec3e... ) and some Perl Compatible Regular Expression library example C file. I want to know C enough that I can create good APIs in it and transpile to C effectively because I want to take advantage of LLVM and gcc optimising backends.

tonyedgecombe 4y ago

It's interesting that C has managed to remain relatively stable whilst everything else has ballooned in size. I spend most of my time writing C# and it has become quite large. I wouldn't want to pick it up from scratch now.

zabzonk 4y ago
actually, C has ballooned in size and complexity. it has come a long way from the first edition of k&r.
rileymat2 4y ago
At the same time, people have expectations for ability now. A beginner might want to make a web request, good luck doing anything beyond mimicry with C from code samples if they get that far. With python, they could pull it off quickly.
pjmlp 4y ago
C23 versus K&R C, and then there are all those compiler specific extensions.

version_five 4y ago

To be a bit pedantic, those options aren't mutually exclusive. An appealing property of C is that it's easy to target almost any device (often making it the best or only option). So it's possible to like C because you like (and need) something you can compile in lots of different places.

vivegi 4y ago

I learnt C in college but C++ was emerging as the language of choice circa 1995 when I got into my first job. This was before C++ was standardized and we had to make do with whatever MSVC 1.5 would do. It did not even support templates back then and even the highly polarizing STL did not exist yet -- in a cross platform way; The STL source itself was available from 1994, and if I recall right, the C++ compiler on Sun/Solaris supported templates etc., We were then a Sun/Solaris + Dell/WinNT shop then and had software running on both and therefore settled on the lowest common denominator of features supported by compilers on both platforms. Heady days. Given that environment, I was comfortable switching between C and C++.

pjmlp 4y ago
Borland did templates since 1993, Borland C++ 2.0 and Turbo C++ had early support for them, and BIDS 2.0 changed from pre-processor macros into the templates experimental design. MSVC was always behind until Borland management messed up.
- vivegi 4y ago
  Yes, that’s right. In fact, in college we used Borland compilers. But my first job had standardized on MSVC. So, that determined what I used on the job. Loved Turbo Pascal and Turbo C++ IDEs in those days. Simple and fast!

pjmlp 4y ago

Some people like to workship whatever the UNIX founders have done, yet they miss that for Plan 9 and Inferno, they also decided to go with automatic memory management languages. While Alef failed, Limbo's design with GC was considered a revisit from what was missing from Alef. They also miss that lint was considered a must have tool for safer C code, introduced in 1979, and that Dennis actually proposed fat pointers to ISO, which weren't accepted. https://en.wikipedia.org/wiki/Alef_(programming_language) https://en.wikipedia.org/wiki/Alef_(programming_language) http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ http://doc.cat-v.org/inferno/4th_edition/limbo_language/ http://doc.cat-v.org/inferno/4th_edition/limbo_language/ https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/vararray.pdf https://www.bell-labs.com/usr/dmr/www/vararray.pdf

jesse__ 4y ago
> yet they miss that for Plan 9 and Inferno, they also decided to go with automatic memory management languages And which of these three operating systems won?
- rwmj 4y ago
  Operating systems don't "win" because they make the best technical choices ... or even because they are best for their users.
  - lelanthran 4y ago
    Maybe, but when all the winning OSes share a common characteristic then you cannot simply dismiss that characteristic as irrelevant to winning without some evidence that it is not relevant.
    - int_19h 4y ago
      The winning characteristic in this case is "it was already there, and it was good enough". This is a recurring theme in the industry.

fargle 4y ago

I appreciate the sentiment, but: - there doesn't have to be "two kinds". Trivially you can fit both "types" at once, I certainly feel that way. And if there are 100 programmers, there'd be about 237 other reasons to use a language. False dichotomy. - a better categorization might be "there are two kinds of C programmers: those who eventually start using rust and those that don't." which is at least of course absolutely true. - I dislike the idea that a programmer is bound to a language. He's a "C" programmer, She's a LISP person, etc. A good software engineer should use about 5-10 different languages appropriate for the purpose at hand.

eqvinox 4y ago
> I dislike the idea that a programmer is bound to a language. He's a "C" programmer, […] Nothing in the article suggests that being a "C programmer" is that kind of a binding label. It's you reading that into it ;). (Though certainly influenced by the fact that that is a widespread interpretation.) FWIW, I consider myself a C programmer, and in both camps presented in that article. But I'm also a Python programmer, and I don't think either of those two languages "owns" me.
psyklic 4y ago
I disagree that enjoying C automatically means you will like Rust. If you are obsessed with safety, Rust will be a nice solution. But Rust is a much more complex language than C, which will turn many C programmers away.
- unionpivo 4y ago
  But its not really. Sure it seems so when you start. K&R and away you go, that programming is a lot easier than writing rust sure. But unless you are writing for just yourself, no current C software get developed that way. You need to understand C standard, that is quite complex and you need to understand it in detail because of undefined behavior (and of course how your compiler interprets it and sometimes fight with compiler to emit right code). Then you needed to know all the gotchas in the standard library, and how you properly use them. Then you need to know how to do basic arithmetic without having undefined behavior (that's where a lot of memory leaks happen). Or maybe the software you are working on has created their own implementation of most of those functions, so you need to figure how to use those. Even to just print out a debug statement can sometimes be nontrivial. And of course you need a way to compile the damn thing, just figuring out what sane options you need to use to get decent warnings and what they mean takes a while. And when you figure all of that out, you still need to keep track of most of the stuff that borrow checker does, but this time by hand using comments and conventions (that you also need to learn for each project.) (I left out whole build setup, but its usually harder than Rust one too. ) I believe that programmer who has only programmed java or maybe C# before (or python, js...) will get up too up to speed faster on Rust than on C on most real-world projects C is deceptively simpler.

klyrs 4y ago

I'm old enough to be in both camps. After years of toodling around in a variety of BASIC languages, I took a class on C. For the first time, I went from a vague text-to-result association to a clear picture of machine and its inner workings*. I then learned C++ and Java which were both hot garbage at the time, and a variety of scripting languages. The scripting langues are great for high productivity and mediocre performance. Shell languages are great for interacting with the operating system. Query languages are great for interacting with big data. But for years, C was the unparalleled language for getting the best performance out of CPU-intensive algorithms. I've still never found a language that erases these boundaries -- while I'm a "C programmer" I'm multilingual by necessity. Today? C's performance is matched by C++, and more tedious to write. Zig is there on performance, but for my purposes, the language gets in the way. Rust also gets in the way, and can end up forcing reference-counting which tanks performance. I do like how Go mostly gets out of the way, but again, I cannot abide unnecessary reference counting. * and, yes, the abstraction is a lie, but it's an incredibly useful and high-performance abstraction

throwawaymaths 4y ago
> Zig is there on performance, but for my purposes, the language gets in the way I guess zig for me is indeed a slightly more complicated language than c, and it's way more verbose, but what I appreciate about it is that straightforward code looks good and code that is on shakier ground looks hairier which is basically a "this code is sus, plz review the fuck out of it" sign. In the end though, what gets in the way for me with C is everything else to ship a "real c program", especially when you want/need someone else's code. Lexical macros, header/code separation, flat namespace, errno, architecture dependent definitions for int, char, etc, having to think about object (file) units, make, automake, config... At that point the cognitive burden is enough that a small added complexity in the language is worth it
int_19h 4y ago
Go uses a tracing garbage collector. Although I suppose that's even worse from this perspective. If you don't mind me asking, how does Zig get in the way? My own gut feel is that it's the only real "better C" out of the present crop of alternatives.

photochemsyn 4y ago

With C, programmers of different types (there are certainly more than two) can be combined into one operational unit by a clever manager. Sometimes differently typed programmers will implicitly agree to adopt a uniform approach before working together on a project. Sometimes the programmers won't do this by themselves and so a manager is needed to explicitly guide them to adopt the appropriate type. However, some types stubbornly resist conversion, and so are tricky to work with. Pointy-headed programmers tend to be surprisingly flexible, and the ones who stare off into the void are often the most useful when you need them to function effectively. Overall, managers who can understand and utilize this hierarchy of programmer types in their organization may find themselves getting promoted regularly. Of course, many people can't stand these corporate structures and prefer the simple farmer's life, raising ducks instead. Quack!

williamcotton 4y ago

C with libdispatch and clang blocks is the most fun I’ve had programming in quite some time! Here’s a web framework (complete with ORM) modeled on ExpressJS written in C: https://github.com/williamcotton/express-c https://github.com/williamcotton/express-c The finished product is < 90Mb Docker image that idles at like 2Mb of memory. There’s also a lot of examples of the (basically required) support tooling like Valgrind, AdSan, etc. Check it out!

winrid 4y ago
It looks cool. The DB library is appreciated. However, you would get about the same idle memory and docker size with Go's Fibers framework :)
- williamcotton 4y ago
  Lol, yeah, the libdispatch runtime is probably about as big as the Go runtime! I think this has a slight advantage in that it uses a memory arena for a per-request bump allocator so it should keep overall memory usage lower. The slowest part of all this has to do with Block_copy and the places where I’m very much treating blocks/closures in an OOP type manner. This could be fixed by writing a different function that did basically the same thing as Block_copy but for all the “methods” on an “object” in a single pass. But who has time for that? :D Here’s more about those performance issues and some example code that show how slow the approach is: https://github.com/williamcotton/express-c/tree/master/research/blocks https://github.com/williamcotton/express-c/tree/master/resea...
- preseinger 4y ago
  go-fiber is a weird, non-idiomatic, and non-serious project, fine for a proof of concept, but definitely not something anyone should be using in prod but your point is sound, any reasonable go http server will have the same level of memory usage at idle
  - winrid 4y ago
    Wow, really? The project has 25k github stars and 300 contributors. They are on v2.44. Why is it not serious? What makes any software "serious" to you?

up2isomorphism 4y ago

“My perception of the second sort of C programmer is that if they've moved to any more recent mainstream language, it's probably Rust.” If you are the first type, you likely get the second type’s taste wrong. Rust is very very different from C both in terms of syntax and philosophy.

pornel 4y ago
Rust is from a different language family, but I think it still fits a taste of "low-level control, not OOP, not C++". I know many people see "complex with angle brackets" and equate Rust more with C++, but I disagree and think it's still closer to C — I can convert C libraries 1:1 to Rust, but C++ libraries hit an impedance mismatch and are really hard to rustify.
- pjmlp 4y ago
  The use of macros and compiler plugins is pretty much closer to C++.
- scoutt 4y ago
  > "low-level control, not OOP, not C++". Things have a drop-scope. There are hidden initializations. Boxing is required for many things including dynamic dispatch in error handling. The tendency to use FP-like one-liners. All that mixed with funny syntax that hurts C developers eyes. A lot of "no-go" in C land (at least for me), that makes really hard to learn and to move definitely into Rust (again, at least for me)
Gibbon1 4y ago
I feel like another division is there are programmers who love mathy languages and syntax and those that hate mathy languages and syntax. The former looks down on the latter with contempt. And the latter thinks the former is annoying.

eqvinox 4y ago

Tense is very important with this article. People who chose C. Whatever these reasons were that made someone chose C, that choice may have been made 20 years ago, and the choice may pan out very different if made now. But now you have 20 years of C experience…

gavinhoward 4y ago
I was not there in those days (somewhat young). I have still chosen C, and I chose it before I had experience with it. I just like the low-level nature.

pm215 4y ago

Personally, the primary reason I'm a C programmer because the main project I work on is a million lines of code, and it's C... As with COBOL, legacy code will mean there's still demand for C programmers for a fair while yet.

_darkmatterdev_ 4y ago

I consider myself the latter who just hasn’t had the time to look into Rust or Zig extensively. But also, I work in safety critical application and it would be hard to shift the organization over to Rust for a lot of reasons, both technological and political.

cracrecry 4y ago

Why I love C? In a word, simplicity. A language designed by a single person. I also did program a lot in CLisp, a language designed by committee, with more than 100 different flow control directives(and people often create their own). I loved and love Lisp as a concept and tool, but hated CLisp complex design so badly. I programmed in Arc for a while because of that. I have created my own C compiler and interpreter. Something impossible to do for a single person in C++(C++ is way more complicated). I also love manual memory handling in C because it lets me create my own automatic local systems much more efficient than someone else's "one size fits all" aproach. I have also programmed mac apps in Objective C and Swift, C++, java, javascript, Perl. I program today mainly in four languages: C/C++, Python, Rust and Clojure. With C it is so easy to create python modules. It is trivial to interoperate from C++ with C. Clojure is a Lisp that is simple, clean design, and you could interoperate with java objects. Rust has some advantages over C, but also disadvantages(it is too bloated).

WalterBright 4y ago
> impossible to do for a single person in C++(C++ is way more complicated) I wrote a fully compliant C++98 compiler (Digital Mars C++).
shrimp_emoji 4y ago
>I have created my own C compiler and interpreter. It's relatively simple because everything is UB/UsB/IDB. ;)
WalterBright 4y ago
> In a word, simplicity. For fun, go to /usr/include and try to understand the system .h files.
- gavinhoward 4y ago
  This is why I've kinda built my own libc on the bare minimum that the system gives me. The POSIX and Windows API's are garbage; C the language is great.

the__alchemist 4y ago

Implicit in the article is that there are only a handful of languages capable of certain use cases. Eg, embedded, bare-metal, programming operating systems, performance-sensitive code etc. So, your options are limited (C, C++, Rust, Zig, ADA, maybe a few more?), which would drive option 2.

deleted 4y ago

[deleted]

phendrenad2 4y ago

I think there are way more types, or subtypes. The first category can be broken down into "people who like C because it's simple" and "people who use C because they need to do manual memory management" (and that can be broken down into "has not tried Rust" and "has tried Rust and didn't like it"). The second category can be broken down into "people who wrote a program in the 1980s in C and are now stuck with it" and "people who learned C in the 1980s and haven't tried to learn a new language" and "people who learned C in the 1980s-1990s and think that Python and Ruby would be too slow for their purposes (no longer true)".

jasoneckert 4y ago

Many people I know (myself included) started in the second category in the 1980s and 1990s (C = God's programming language) and then moved to the first category once attractive alternatives (e.g., Go) that met our use cases became widely used.

mmphosis 4y ago

I am definitely the former. I didn't like C too much in 1986 but there wasn't really anything else except writing in Assembler! Having programmed in Pascal, it wasn't too much of a leap to transition to C. The C compilers at the time were buggy. 37 years later, I still write C programs. I won't touch C++.

hgs3 4y ago

> I no longer want to have to think about memory management and related issues. In some cases efficient memory management _is_ the problem to be solved. I'm not just talking about esoteric or embedded systems here. If you're developing for modern GPU's with a modern API, like Vulkan, you must manage GPU memory yourself. With direct memory access you can do many "unsafe" things, like memory aliasing, to improve performance. "Safe" languages, like Rust, will not help you here.

gavinhoward 4y ago

I'm the former kind: I choose C because I like it above all else. [1] That said, like the author, I'm trying to find an alternative. Well, more like I'm building my alternative because I hate Go. And Rust. And anything else. I don't know why C fits my brain, but it does. I think it's because my brain is low-level; I like messing with assembler when I get the chance to optimize. [1]: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-in-memory-safety/ https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...

tacitusarc 4y ago
How do you feel about zig?
- gavinhoward 4y ago
  I hate it.
  - throwawaymaths 4y ago
    Care to explain why?
    - gavinhoward 4y ago
      Several things, but I'll name two. comptime just doesn't fit my brain well. Async Zig gives me a headache. [1] [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-colors/ https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
      - throwawaymaths 4y ago
        Got it. Thank you for your perspective. I can appreciate that comptime is tricky. Indeed, async zig is hard and annoying (but you're wrong about the function coloring... Here is someone's project where they call an async function alternately from a sync or async context with zero lines of code: https://youtu.be/lDfjdGva3NE?t=1999 https://youtu.be/lDfjdGva3NE?t=1999 Yielding is async and threaded is sync)

shmerl 4y ago

What about those who are stuck with it because of the huge legacy code base? They wouldn't choose it deliberately for anything new, but there isn't much they can easily do about it in the above case. People who chose C as the best option at the time might not be even around the project anymore.

haberman 4y ago

I am a C programmer. For me the language is a means to an end. I prefer to work on problems where both performance and code size is paramount. The kinds of problems where it makes economic sense to spend months or years of engineer time designing and implementing a solution that will compile to a 50kB binary. I think primarily about the kind of machine code I want to generate, and pick a language that best approximates that ideal output code while still allowing the source code to be as clear as possible. From these constraints I keep coming back to C. Zig is the most appealing contender in terms of next-gen languages. If I could get safety without giving up anything, of course I would take it. But I am increasingly convinced that this is not generally possible.

softirq 4y ago
How do you feel about Rust?
- haberman 4y ago
  I was really positive on Rust for at least five years. But several experiences have led me to reconsider this position, most notably the difficulty using arena allocation: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html https://blog.reverberate.org/2021/12/19/arenas-and-rust.html This is one of the things that endears me to Zig: passing an explicit allocator around is a very common idiom in the language.
  - int_19h 4y ago
    I'm curious what you think about Ada; from what I remember, its memory management facilities have this basically as a first-class thing directly in the language.

Scubabear68 4y ago

I used C in the late 80s and 90s because it was the only viable option for many use cases. In the late 90s I got heavily involved in Java, and C usage dropped. Had some spikes of C++ work (which I despised), and then working in many different languages with no real work on C or C++ in at least 18 years or so. What always killed me the most in C was the absolutely anemic standard library. OS’ had more libraries, but still very low level stuff.

cat_plus_plus 4y ago

I don't get enjoying every second line being "if (r == -1) goto cleanup" and then a cleanup block freeing every pointer which is not null. True, you can define macros to automate that, but then you just end up with clunkier version of C++ destructors. The rest depends on what you are doing, no need for heavy OOP for simple tasks and on the other hand automatic memory management is great when reliability is more important than hardware access or real time performance. But at least no reason to avoid automated facilities that replace well known red tape.

hwc 4y ago

Also, wants to use C ABI in other software.

xvilka 4y ago
You can easily expose it from Rust as well.

kps 4y ago

C programmers are implicitly converted to the required type. Implicit conversions are one thing I don't like about C, or at least the way it ended up as int grew (maybe it would have been better if ANSI had picked unsigned-preserving, but maybe that's just grass-is-greener thinking). I also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs.” I do like the directness and explicitness. Good C can be very nice.

cpncrunch 4y ago
I used to think implicit type conversions were bad in C, until I started programming in javascript.
- kps 4y ago
  `5 - "2"` is 3, and `5 + "2"` is "52". Makes perfect sense! It could be worse, though; you could be doing Norwegian YAML.
tialaramex 4y ago
> I also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs.” You can have a language where all the behaviour is defined but in my experience most programmers who whine about this in C are just as unhappy because what they actually wanted was DWIM. In a language with defined behaviour their program is wrong, which is their fault, whereas in C they can claim "obviously" it's the compiler's fault. I like it when it's my fault, I just learned something, and early in my education I assumed everybody was the same but I rapidly learned that most people prefer to be told they're correct regardless, and a language which says "Nope, 4 - 5 is a negative value and this variable in unsigned, too bad" makes those people unhappy, whereas when 4 - 5 = mysterious program behaviour they can blame the compiler engineers instead.
- kragen 4y ago
  4u - 5u is not undefined behavior in c; unsigned arithmetic overflow is defined to wrap around, in both directions assigning -1 to an unsigned variable has never been undefined behavior either, but implementation-defined behavior (see §6.2.1.2p3 in iso c90 or §6.3.1.3 in c99 and c11); decent compilers like gcc define it to do the obviously correct thing (see https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.h...), not produce mysterious program behavior. in the new c++20 standard it's no longer even implementation-defined, but fully define behavior in the standard, but in standard c it's still implementation-defined as a programmer who whines about the kind of ub exploitation at issue here, and who (as established above) has a much clearer idea than you do of what behavior is and is not defined, specifically what i am whining about is that it's harder to debug my code if doing things like dereferencing a null pointer doesn't reliably crash it, but instead triggers the silent removal of apparently unrelated logic from my program, or subtle semantics changes in it, in the name of optimization also it sucks to have existing security-sensitive code acquire new security holes, and i don't really care if that's a learning opportunity for the guy who wrote it 20 years ago this didn't happen 20 or 30 years ago, and in those 20 or 30 years the impact of introducing fresh security holes into existing well-tested c code has greatly increased, while the usefulness of c compiler optimizations has greatly decreased

patrakov 4y ago

There is (or maybe was a few decades ago) a third type. A person who was taught C programming in the school/university, because back then it was the norm to teach it and nothing else, and who does not have enough motivation or abilities to learn anything else on their own, even if C is clearly the wrong tool for what they are doing.

skywhopper 4y ago

Not sure what’s provocative about “people use language X because either they like it or they have to use it”. The same could be said about every tool.

worthless443 4y ago

> They feel strongly drawn to C's virtues, often explicitly in contrast to other languages Can someone point me to which set of virtues you are talking about here? Simplicity? Value semantics and imperatives, little abstractions over what the computer OS is actually doing? Manual control over almost everything being done? Are such "virtues" safe and dignifying under an universal context of computer programming? Isn't it a bit dangerous to let such Virtues take over in modern programming dealing with heavy abstraction layers because of the yield in complexity of modern hardware?

xorvoid 4y ago

I switch between both depending on my mood and the particular application. For me: Rust killed C++ but not C I have an on-again off-again love affair with C. And in its domain it’s still unmatched: low-level close to hardware where you directly need to deal with concepts that are normal abstracted away: alignment, custom layouts, type punning, pointer tagging, different types of memory, cache coherency, DMA, kernel bypass, etc etc Sure you can do it in rust unsafe but it’s (intentionally) a world of pain. But, when you start needing bigger abstractions or you work with a team larger than say 5, C falls on its face super fast. But it Feels Oh So Nice otherwise. Here’s to me hoping Rust unsafe becomes more usable and can be a proper C successor someday. But.. I’m happy to be rid of C++ :-) (I’ve been meaning to write a blog post on this for some time)

xorvoid 4y ago
One more thing: codegen Getting good codegen out of Rust is 5 times harder than C. And sometimes it’s not really possible.