Not really. Unless the language gives you access to the computer (either directly, or by emitting machine code and scheduling for execution), you'll have hard time implementing it efficiently. Compare IronPython (python implemented in python) with the mainline Python (implemented in C).
Yes, there are meta-circular interpreters. But that's not the holy graal.
> I think C is a fine language, but it's missing some significant niceties. Like a decent native string class.
C++ is what happens when you sprinkle a few niceties here and there. The C++ Faq Lite [1] is longer than the whole C specs. The kitchen sink language can do everything, but porting it to a new environment is quite a task. Never mind the compilation time.
You can get an optimizing C compiler [2] in less characters than C++ Faq Lite has.
If you want modernized C with niceties, (Google's) Go probably comes close enough. No string class, thou, just string type.
--
Why not use Ruby to emit a bunch of bytes (ie, assembly), push it into a file, and set the executable bit? Ruby could be used to create GCC so you can write C. ie, a Ruby-based Ruby-to-assembly compiler. With that technique and therefore technically Ruby alone, you're still capable of recreating every language or application in existence, right down to being exact binary duplicates.
Sure it's pedantry. But the entire hypothetical deserted-forever-with-one-language situation is pedantic at its core.
That sounds like an argument for any language, though. As long as you can build the language of your choice in language X, you're fine being stuck with X because you're not really stuck.
If they had to write absolutely everything in more "pure" C, would their tune be the same? I think C is a fine language, but it's missing some significant niceties. Like a decent native string class.