Honestly, if you use one of the available GCs out there (like Boehm's), and give up on static typing, and heavily rely on function pointers, you can write C similar to how you'd write something like Haskell. Yes, it won't go as fast as it the most idiomatic C, and you can't really make an operating system if you have a GC, but really, how often do most of us actually write code that can't use a GC these days? Even with a GC, it'll still probably perform better than 90% of languages.
I'm not a fan of adding GC to C. I've hard my fair share of stress caused by GC issues. It's great 99% of the time but when you run into performance issues caused by the GC it becomes a very very leaky abstraction.
I'm ok with it not being 70's-era C to be honest; I even with the extra stuff, I find the language to be fairly simple to pick up compared to C++.
I haven't had any problem with performance with the Boehm GC personally, though for what I've used C for is not-real-time video processing stuff. I found I typically got better throughput using Boehm than I did when I was manually managing my memory, but for what I was using it for, a small pause wasn't really a problem as long as the throughput wasn't really affected.
If you are doing that, you might as well use Go and get green threads and little or no undefined behaviour in a modern actively developed language for free. Go is practically C without the undefined behaviours.
If you have a GC and no static typing, is it better than other functional languages (many of which have benefits of both GC and static typing)? Not a rhetorical question, I have never used a GC with C.
For what I was doing, which was video processing stuff, I'm not sure that it was faster than if I had written it in Haskell. For this job, I was required to use C or C++, and so I never attempted to port it to Haskell or OCaml or something. I'm more of a wannabe-academic and certainly not a systems programmer, so I did what I could.
If I were to guess, the C version would have a bit better performance in a single-threaded context due to the fact that I would occasionally use tricks to avoid reallocations/frees, and the Boehm GC is opt-in, so when I was reasonably certain I could handle the memory correctly, I would do it myself, minimizing how much was actually being done by the GC.
I do feel that a static functional language like Haskell might perform well (maybe even better-on-the-average-case?) in a multi-threading context, since I personally find dealing with locks in C (and C++) to be very difficult to do correctly, so utilization of some of the cool tricks in Haskell to avoid manual locking might benefit. I was too much of a coward to use threads and locks much at that job, so I haven't had much of a chance to test it.
