To replace C, one must create a language which, first and foremost, can target shared libraries, because that's how most of systems software operates on virtually all current day's operating systems.<p>This is by far the #1 requirement: extensions to all VMs and scripting languages are shared libraries. Plugins for various servers are shared libraries, heck pretty much everything which is not a web app is a shared library, either on windows or linux.<p>In my life as a C++ developer (about 7 years) I have never, even once, worked on an executable. All my code, at all companies where I worked, always ran inside of either a DLL or a so-file loaded by some hosting process.<p>In fact, I believe that so-files must have been the default compilation target for both Go and D. So millions of Ruby/Perl/Python/Java/<anything goes> programmers could have used those languages for performance-critical or OS-dependent code in their programs, after all that's what "systems languages" are for.
I remember a time when people asked, "What will replace the floppy drive?" Everyone expected the replacement to look and feel like a floppy drive, but with more speed and capacity. In the end, the "floppy killer" never materialized. Several unrelated technologies ended up taking over floppy's uses one-by-one. CD-ROM's took over software distribution, USB thumb drives took over file transfer between computers, and the network took over everything else.<p>The same thing will probably happen to C. Modern languages like Python or have arguably "replaced C" in several use-cases already. Go will probably claim a few more. On the other hand, Go is completely unsuitable for applications that cannot tolerate garbage collection, such as embedded firmware. Some other language will have to come along and claim <i>that</i> niche from C as well.
C is probably the most firmly entrenched programming language that ever existed, and it's not going away in the near future. One big factor here is the fact that all major operating systems are written in (and have core libraries to support) C. I think in order to "replace C", you'd have to develop an OS in the other language, and that OS would have to gain widespread adoption.
I don't know that much about working on operating systms, but here's Linus Torvalds on maybe using Go in the kernal:<p>"Hey, I think Go picked a few good and important things to
look at, but I think they called it "experimental" for a
reason. I think it looks like they made a lot of reasonable
choices.<p>But introducing a new language? It's hard. Give it a couple
of decades, and see where it is then."<p><a href="http://www.realworldtech.com/forums/index.cfm?action=detail&id=110624&threadid=110549&roomid=2" rel="nofollow">http://www.realworldtech.com/forums/index.cfm?action=detail&...</a>
Is this person intentionally trying to make the C harder to read? What's with all the missing newlines? I didn't get past the first few examples, because the C was so unnecessarily difficult to read, I assumed the Go was in similarly bad style. (I don't know Go.)<p>Maybe there's a point in there somewhere, but bad code samples distract from it.
This is just a facet of a bigger issue: how come when you want a dynamically typed, scripting language you have plenty of choice but when you want an alternative to C/C++ (i. e. general purpose, compiled to actual machine code -- no VM, no GC), there is hardly anything (Fortran anyone?) If you add 'object-oriented,' you're pretty much left with C++ and, um, OCaml? Even when you want a functional programming language (still semi-esoteric in my book), you have more to choose from.
We used Go to re-write our cluster management system. In 2,000 lines, we have master and slave daemons that launch programs, exchange files, and forward output from running programs; "launcher" functionality in the same codebase allows users to start jobs and check the status of the system. Switching to Go made everything significantly easier.
I see too many other languages defeating Go at its strengths. The only one that survives is its fast compilation, but others are not so slow to make that a deciding factor.<p>If you happen to like/need its particular combination of strengths it may be a good choice, but I think much better can be done. It's a good experiment, but I think they're taking it too seriously in some regards and not seriously enough in others. I just don't see it lasting.
This seems like a case of premature optimization. C rocks at what it does. The billion other languages are pointing out and improving upon the stuff C does badly, but they don't replace C (a language I've nearly forgotten, but respect). I RTFA (and its subpages) and didn't see anything mindblowing.<p>The payoff of C->Go comes if you have 1M LOC of C. 900k LOC of Go is much better. For most of us, just-getting-it-to-run is awesome and that's why Ruby, Python, Lisp and Clojure dominate.<p>The best part of the post is that (until later) I didn't know that the "ooh-wow" bits on <a href="http://www-cs-students.stanford.edu/~blynn/c2go/ch04.html#_full_translation" rel="nofollow">http://www-cs-students.stanford.edu/~blynn/c2go/ch04.html#_f...</a> were Go and were longer than their C equivalents. Sure, the C bits look scary to a noob; they look perfectly sane to a journeyman.
There is a lot to be gained by designing a language that is easier to use than C++ while being at least as fast and that's what Google is probably betting on. GC saves a lot of programmer's time and they don't care about tiny embedded systems not being able handle it. Examples of D and other alternatives only show you need a company behind a language to make anyone use it.<p>On the other hand, C can't be improved much without compromising the 'as much speed as possible but handle with care' philosophy (like introducing GC while sacrificing a bit of speed).
If the title was "Could Go be used instead of C for a great many applications?" then the author would stand a chance at making a point. However, asking whether Go can "replace" C shows a deep misunderstanding of why people still use C: to do the type of stuff that a safe, typed and garbage collected language won't let you. Need to poke hardware? Need to use efficient memory layouts for your data structures that confound non-dependent type systems? Need exact control over generated code to achieve competitive performance? (And, apparently for Go's case) need to handle OOM conditions? (The "some systems don't even have malloc() return NULL on OOM" argument was particularly weak.) True, these things can be handled by C/C++ and called by Go through a FFI, but then C hasn't really been "replaced".<p>Really, the title should be "Can simple C programs be written in Go in about the same number of lines?" because that's all that was demonstrated.
<p><pre><code> As a rule, never start a new line with an opening brace;
it belongs with the previous line.
</code></pre>
I'm always using the "one true brace style", so that wouldn't be a problem for me personally; however I feel the pain for people using BSD style. Using a consistent indentation and brace style across all languages you're working with, be it C, Java, Javascript, Perl, PHP is a must, and that Go idiosyncrasy seems really wrong to me; this kind of detail may hamper Go acceptance quite a lot.
Related: simple Unix tools written in Haskell. Most of them become just one-liners. Everything is linked to a single executable.<p><a href="http://www.haskell.org/haskellwiki/Simple_unix_tools" rel="nofollow">http://www.haskell.org/haskellwiki/Simple_unix_tools</a>
I'm surprised nobody has pointed out another major reason Go will not replace C: embedded programming. GC eats valuable kilobytes on hardware that often doesn't have any to spare.
Serious question. Does Go really have anything unique going for it, apart from the fact that it comes from Google?<p>I have yet to see a convincing argument why I should choose Google's little (and relatively immature) language over anything else and I'm very close to assuming this thing is pure hype and has nothing actual newsworthy. Ofcourse, as always I'd love to be proved wrong.