There might be good arguments for avoiding "C/C++" but this article makes none of them. If the author is going to be playing the "modern C++ isn't anything like

There might be good arguments for avoiding "C/C++" but this article makes none of them. If the author is going to be playing the "modern C++ isn't anything like when it started out" card then they damn sure shouldn't be talking about K&R declaration style either. Using FFI in Rust/Go whatever is not at all the same thing as a compiler directly accepting much of the same code without distinction. Arguments about constructors/destructors and overloading and lambdas and move semantics would be at least slightly more compelling, but all are absent. It's not clear the author even knows C++ very well. Net result is that some people will keep using "C/C++" solely to poke fun at the ultra-pedantic and needlessly aggrieved.