FWIW, some of the advice in the book is pretty bad. The most unbelievable is to ignore memory leaks under 100Kb, but there are a lot of other examples.

The first half of the book covers Git, autotools, Makefiles, and random topics tangentially related to C. If you're unfamiliar with those, it's an okay introduction to them, but there's some dubious advice in those sections, too.

Thanks for sharing. Now I know not to waste time on the book. If I want to learn about Git, I'm not looking to learn it from a book about "Modern C".

I consider "use autotools" to be dubious advice anyway.

These days I won't even consider a language for serious work unless it has a reasonable set of built-in datastructures and algorithms. I'm just not interested in shopping around for a basic vector or hash or tree container or for a compatible set of elementary searching and sorting algorithms.

I know you can find implementations of all of these in C but this is the kind of thing that really needs to be built in to any modern language. C is fine for writing device drivers etc where you can't really assume anything about your environment but for anything else it seems too bike-sheddish.

> bike-sheddish

It seems this term has evolved beyond any recognition to me. In what way is choosing C over another language that may provide more built in "arguing over something trivial/tangential"?

... then use glib, apr or acf.

And hope that any client libraries and APIs I want to use made the same choices I did.

Code reuse at the level of strings and containers is essential for any kind of higher-level programming. C fails here.

I love C for its simple syntax and "charm" (can a programming language be charming?) While the book does look fascinating, I can't help but wonder if it would be easier to go with languages like "Go" which was supposedly designed with 21st century considerations in mind?

Yeah, I had the same thought. In fact, in the interview, the author actually picks up a copy of K&R C and looks through the index for "threading" and finds nothing, whereas Go was designed with concurrency in mind.

On the other hand, as the author said, C is over 40 years old. Many consider that a weakness, but he considers it a strength, given the large number of C libraries available, whereas you don't have the same number of libraries with native Go bindings. Ultimately, of course, it comes down to using the right tool for the job. That may be C, that may be Go, that may be a higher-level language like Python, Ruby, etc.

Just to be fair though, binding 90% of C libs out there to your Go project is fairly painless & straightforward -- if a tad tedious for bigger libs.

I've heard that doing that with Wayland's libraries is a royal pain because Wayland makes extensive use of function pointer based callbacks. So Go calling C calling Go. I'm not sure to what extent this sort of thing is common though, I haven't seen it often myself.

I've got it, and though I haven't read much yet, it's definitely got some good stuff.

I bought a copy after it was discussed here a while back. Overall it's a very good book and is worth purchasing IMHO. There are some notable holes and assumptions but it's probably the best attempt for a number of years.