Edit: also, not sure why you were downvoted, since your question at least deserves a reasonable answer.
Drive-by downvoting is what doesn't contribute anything in this case.
Perhaps if someone actually makes a detailed post on that subject then the post can be undownvoted. But at the moment there is no contribution, and the drive-by downvoting sorts it to the bottom, which is a good thing.
I'll do it.
@aosmith: It's interesting, because Go's creators explicitly aimed it at the "systems" niche, which is what C was created to do, but C programmers don't seem to have picked up the baton the way Pike/etc hoped.
I think it comes down to a handful of things, in no particular order. YMMV, of course.
(1) Control. C gives you minute control over memory, Go of course does not. That's very satisfying and useful to many C programmers. Also, it's often helpful to have a good idea what your code is mapping to in terms of assembly instructions.
(2) Speed. Go still isn't anywhere near as fast as C in many, many cases.
(3) Portability. Lots of C programmers need (or get satisfaction from) the ability to compile C on a zillion platforms. Go supports only a few.
(4) Garbage collection. (Sorta a revisiting of point #1). Many C programmers don't want GC in their code. Now, while I wouldn't mind if my copy of 'less' used GC, some programmers would. I know I don't want GC freezing my game. So this is an issue, not one that will ever go away.
(5) Libraries. Go's made strides but can't touch C's library selection. Of course, you can use C libs from Go, but that has its own complications, and if the author already prefers C, why pick Go?
(6) Newness. In the context of systems languages, Go is still very new. Nobody's built an entire userspace out of it, ya know? Not that that's necessary, but certainly when the Unix programmer sits down and selects C, s/he knows anything can be built with it. It's long since passed into respectability. Go's on its way, but isn't there yet.
I'm sure there are a few other things. Don't think there's a way to run a runtime-less Go. As Damien mentioned, C has a bevy of tools, Go's selection is much more limited. I'm sure others can think of some more.
Other than C and C++, Go is one of the best languages for controlling memory. Not freeing, of course, but making it very clear where there are allocations, where there are copies, exactly how much memory is being used by any particular data structure.
Portability - you can run binaries created by gccgo in many many places beyond amd64/x86/arm. No, certainly not as many as C... but probably as many as anyone would ever want to support. So unless you're targeting a specific embedded application, then Go is probably fine.
GC is getting a big push in Go and in 6 months they're going to make hard real time guarantees about the GC... i.e., no more than 10ms pause every 50ms, and the GC will be hybrid stop-the-world/concurrent, so some memory may be collected while other code continues to run.
Otherwise, yes, you're right, there are (of course) some limitations to using Go over C.
However, there are some huge benefits to using Go over C as well... such as memory safety. There will never be a buffer overflow in your code. Also, concurrent code will be a thousand times more readable and easier to reason about.
That's not to say that C isn't the right choice sometimes... I just think the places where C is the best choice are becoming more and more rare, and not just due to Go, but Rust as well.
Better than language like Pascal, Ada...?
I think you're taking downvotes far too seriously. I might even call caring about karma a reddit attitude ;) And as far as illumination, I think you have it backwards. Posts that actually have illuminating answers should be brought to the top, so that many people can learn from them. Posts that only have a chance of getting such an answer should lie further down. There's probably also a positive correlation between people likely to form a detailed illuminating response and people that read further down the page on a particular subject.