A personal anecdote that took place sometime between 1999 and 2003.
It's C++ that is more like a chainsaw: a noisy, smelly, clattering but effective tool, dangerous without modern protective gear, and an equally poor choice for tightening screws.
One of the things that I like about the chef's knife is that if you hold it correctly (http://www.seriouseats.com/2010/05/knife-skills-how-to-hold-...) the deep blade gives you both control and increased safety. People often think the bigger the knife the more dangerous, but often the opposite is true.
Chainsaws on the other hand scare me despite their utility, possibly because my grandfather (a very experienced chainsaw user) had a horrendous scar across his neck and face from being stitched back together after an unexpected kickback.
C is going to look horrible if you've only ever used python. That's because you don't understand at all about real computers and how to program them.
But no, trust me there are C programmers who use malloc and friends without knowing about the heap and stack. For those programmers it's just how you "get memory" in C. It's just part of the language for them (as opposed to part of the operating system).
Some people say Golang is that language, but the tooling is actually not that great and then theres the garbage collector...
Edit: forgot to add "sound type system", to me C feels like a hybrid between a properly strongly typed language and something scripty.
Make, while I quite liked it in its day, has some real limitations. cmake, while better on some fronts, doesn't actually solve the right set of problems (or, it solves the set of problems as they were perceived ~15 years ago).
I wish there were a strict subset of C (compliant with standards, but that prohibits the trickiest bits during build), with a good package/build system, a huge/modern library of high level functionality. I always enjoyed poking at C, but I just can't spend enough time coding in C to ever be really good at it. I can go years between working on C code, so I forget all the gotchas by the time I look at it again. It's not forgiving of casual users the way Ruby, Perl, Python, Go, and even (some) Java can be.
Then again, I guess Go is kinda that language for some classes of problem (not the very lowest level systems stuff, but I rarely do any of that kind of coding, anyway; I haven't touched a kernel module in a decade).
In most cases I don't even need a full build system. I do most of my hacking in Python and I often create small "throwaway libraries" to create a nicer structure of my project. In Python you can do this by just creating a sub-directory and a __init__.py file. This takes 45 seconds and then you can easily "import lib_xyz" in your project. And if you need this library in another project you can just copy/paste the. (I know, this is not an ideal solution but when I am hacking on some stuff it is a good way to do things because it takes no effort and brainpower to do it)
It's not so much tools like debuggers or linters, but more about the build system and the compilation process. There is just do much crust and dangling bits and pieces of the last few decades that the whole process is the complete opposite of streamlined and user friendly.
I do most of my programming in Python and for most projects it is enough to create a program.py file, import some stuff and then do 'python program.py'. If your Python program is not overly complex and only uses one of the common libraries then there is almost no visible build system which gets in your way.
If i haven't used Python in half a year it takes about 30 seconds to start programming again, but god forbid I haven't looked at make or cmake for half a year...