Looking at the book's TOC it looks like there's a bunch of interesting ideas in there, I'm tempted to pick it up.
Looking at the book's TOC it looks like there's a bunch of interesting ideas in there, I'm tempted to pick it up.
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.
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.
Code reuse at the level of strings and containers is essential for any kind of higher-level programming. C fails here.
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"?
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.