Whole OSes were written in Lisp, too, as well as other GC'd programming languages (Smalltalk, Mesa, perhaps a few others), and they ran on rather underpowered hardware by modern standards as well.
I get your point, but having to check for allocation failure is a substantial source of bugs in non-trivial programming without GC, and having to manually allocate RAM makes string handling, for example, orders of magnitude less safe than it is in a language with GC.
Let me be clear: could a C programmer understand and effectively use Genera OS without significant, paradigm-altering changes in mindset about programming? Probably not. So, I don't include LISP in a C-replacement discussion given they're in two, different ballparks. And LISP is universally hated by almost all programmers outside its own fans and those Clojure is attracting. That's despite the fact that I promote its advantages elsewhere where they might get take-up. ;)
Now, back to imperative languages with some familiarity to C programmers. For allocation failure, some languages provide exceptions to handle such things but I usually recommend allocating what you need at the beginning and being sure you'll know your max for later. Do the checks plus reserve early so you worry less from then. Shouldn't be a problem. It's work to keep in mind but straight-forward.
Far as string-handling, there's safe libraries and approaches to it. We just use them with whatever performance or syntax hit we get if our language doesn't do it inherently safe. The issues with it are why I recommend prefix strings for clean-slate stuff over null-terminated. If you can get away with it. Having separate types for the two can highlight interface errors.
I get your point, but having to check for allocation failure is a substantial source of bugs in non-trivial programming without GC, and having to manually allocate RAM makes string handling, for example, orders of magnitude less safe than it is in a language with GC.