Phil Eaton’s book club is starting The Art of Multiprocessor Programming, 2nd Edition , which is a very well regarded textbook, and pretty recently updated (2021). I’ve even heard of a couple of authors.
I’ve done a lot of concurrent programming, and have always felt like I’ve still got plenty to learn, so I was excited for the topic. So far, what I’ve learned is that I would never recommend this book, despite any merits.
Probably only two people read my arena allocation article last week (even my employer, who begged me to write, did not post), but one person did seem to read it (and to the other: hi, mom!). Okay, maybe a few other people skimmed it, but stopped when they realized it was just an arena allocator as a precursor to a garbage collector.
I know one person read it fully, because this person let me know I was full… of garbage. And not because I had stopped before the actual garbage, collection.🥁 No, apparently, the complaint came due to an article last week people actually did read:
See Look Ma, h4x0rs! for an introduction to this series.
There’s absolutely no reason for memory management in C to be as hard as it is. In fact, there’s almost never a good reason for memory management to be hard, and is one of my issues with Rust– why should I work even harder on memory management than I would in C?
* Of the grey-beard law-abiding kind
I care a lot about ease of use for programming. To me, it’s an important consideration for both languages and APIs. Languages should aim to make it possible for anyone with good ideas and some determination to accomplish them. That’s why I was early to advocate for Python for most programming problems (the least-bad option), and am surprisingly okay with “Vibe Coding”.
