
C to Go: Could Go replace C? - hanszeir
http://www-cs-students.stanford.edu/~blynn/c2go/
======
old-gregg
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.

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.

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.

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.

~~~
leon_
I know that shared libs are prominent and a better support for them would
probably help Go's popularity. (Though the idea behind shared libs is somewhat
flawed.)

But it rocks to deploy a Go app by just sending the binary to a dozen of
servers and never have to worry about any dependencies on shared libraries.

~~~
mattgreenrocks
Savvy Win32 devs used static linking whenever they could to minimize
deployment hassles way back when. :)

------
s_tec
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.

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 _that_ niche from C as well.

~~~
snprbob86
I'm not so sure there are applications which simply cannot tolerate garbage
collection. Unless, you have no reasonable way of preventing allocations.

Console games, for instance, are often largely garbage collected, despite
being hugely performance critical applications. The way this is generally
achieved is by allocating 100% of the console's memory upfront as object
pools. The game then utilizes domain specific collection mechanisms on those
pools.

Shawn Hargreaves has a good article on dealing with C#'s garbage collection in
XNA games: [http://blogs.msdn.com/b/shawnhar/archive/2007/07/02/twin-
pat...](http://blogs.msdn.com/b/shawnhar/archive/2007/07/02/twin-paths-to-
garbage-collector-nirvana.aspx)

The problem in .NET land is that some base class library methods allocate
internally, so you need to completely avoid them if you use "Path 1" (avoid
collections). You wind up having to do funky things like re-implementing core
methods and pre-allocating pools of strings to avoid concatenation.
Presumably, a language designed to be a systems language could avoid these
library problems.

I don't know much about Go, but if allocations are clearly demarcated and
easily avoidable when necessary, you could allocate 100% of memory up front.
You could treat virtual memory as an object pool of memory pages and perform
domain specific allocation on those.

Alternatively, a collector with a richer interface, such as generation
control, multiple heaps, etc. Would allow for "Path 2" (avoid latency) by
performing very small, simple collections.

~~~
JonnieCache
_> I'm not so sure there are applications which simply cannot tolerate garbage
collection._

Things that need to be really seriously realtime, such as aeroplane pilot
assistance AI, and medical equipment firmware, I think these cannot use stuff
like GC because there is no room for the slightest deviation in performance.

~~~
masklinn
> Things that need to be really seriously realtime

Real-time garbage collection (hard and soft) is not a work of fiction. Hell,
the first papers on real-time GCs were in the 70s.

> I think these cannot use stuff like GC because there is no room for the
> slightest deviation in performance.

IBM's Metronome (Bacon & al) is a hard real-time GC.

------
biotech
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.

~~~
buckwild
Google is likely capable of creating its own operating system (if you don't
already consider Chrome OS a legit operating system).

~~~
rbanffy
> Google is likely capable of creating its own operating system

I don't think they are capable of such mistake ;-)

There are plenty of free more-than-good-enough OSs to build upon. Unless
Google needs something more revolutionary than Plan-9, they don't need to
create another OS.

The only reason I would find sane to develop an entirely new OS would be to
use all these new shiny toys we got in specialized processors inside our
computers. It would be awesome to have a machine with lots (hundreds?) of
cores of varying capabilities that could be powered up or down according to
load, with processes being transparently migrated between binary-compatible
ones or between similar virtual machines hosted on diverse cores.

It's been a while since I have seen a cool new research OS.

~~~
buckwild
In a sense, I agree, but I guess I'm applying Apple business practices to
Google in my mind. If they create their own operating system, in their own
language, they have essentially gained a large amount of control. Given that
Google is the most popular search engine and many people want to use Google
products, it wouldn't be too hard to gain the majority foothold. Google is
even making a Chrome notebook!

~~~
rbanffy
I think it was more luck than anything else.

Apple was failing. It had an ancient and crufty OS and needed to find a new OS
outside the company because it failed to develop one internally at least
twice. They could go with BeOS, NeXT or MkLinux (I run MkLinux on one Mac in
my collection). NeXT came with Steve Jobs bundled for free.

At that time, Apple leveraged its bets making Java development a first-class
citizen. It was not clear whether Objective-C would gain any foothold because
it failed to get traction during its NeXT years.

------
Symmetry
I don't know that much about working on operating systms, but here's Linus
Torvalds on maybe using Go in the kernal:

"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.

But introducing a new language? It's hard. Give it a couple of decades, and
see where it is then."

[http://www.realworldtech.com/forums/index.cfm?action=detail&...](http://www.realworldtech.com/forums/index.cfm?action=detail&id=110624&threadid=110549&roomid=2)

~~~
TheBoff
From Linus, that's practically a shining endorsement.

~~~
Symmetry
Yeah. I should have mentioned that the quote was in _marked_ contrast to the
rants about the evils of C++ he had been delivering earlier in that thread.

------
mkelly
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.)

Maybe there's a point in there somewhere, but bad code samples distract from
it.

~~~
k_kisiel
Agreed. Besides crappy formatting, he also makes his programs do confusing
things. Why does the first example run in the infinite loop?

~~~
philwelch
Because that's what the "yes" utility does:

"By itself, the yes command outputs 'y' or whatever is specified as an
argument, followed by a newline repeatedly until stopped by the user or
otherwise killed; when piped into a command, it will continue until the pipe
breaks (i.e., the program completes its execution)."

<http://en.wikipedia.org/wiki/Yes_(Unix)>

------
jergosh
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.

~~~
leon_
I bet there are many static typed, compiled languages. But they never get any
traction because they are not "sexy" like the newest hyped dynamic language.
There are many devs who don't care for static typing - they just want to hack
their backend in a weekend and be done. Those devs seem to be the vocal ones
with blogs and social media power users behind them.

Look at Python. Python is over 20 years old. It has been here since before
Windows 95 but only got prominent (in the broad public) in the last few years
because some opinion leaders of the hip and young crowd found out you could
make cool web apps with it and hyped it into oblivion.

I bet if Go hadn't the names behind it it wouldn't get any more traction than
any other of the gazillions of programming languages that die silently. I
guess not many home brew languages get talking time at a Google conference.

Let's be just happy that Go seems to get a little popular - maybe it will be
enough for a break through. I'd love that.

~~~
dkarl
_Python is over 20 years old. It has been here since before Windows 95 but
only got prominent (in the broad public) in the last few years because some
opinion leaders of the hip and young crowd found out you could make cool web
apps with it and hyped it into oblivion._

Hmm, I thought it became popular for scientific applications and as an anti-
Perl for scripting before it became popular for web apps? I first got into
Python because I needed a scripting language. People said, "If you don't like
the design philosophy of Perl, then you might like Python, which made the
opposite choices." The centerpiece of Python advocacy back in the day was this
article by Eric Raymond: <http://www.linuxjournal.com/article/3882>

I know that's the article that convinced me to try Python. Everything he
praised about Python screamed "opposite of Perl!" and after experiencing my
mind rejecting Perl like a body rejecting a transplanted organ, I was
desperate for an alternative that would make me as productive at scripting as
the Perl gurus. (Yes, I'm still jealous of the one-liners.)

So there is certainly room for a language to grow and become popular without
having a first-class web framework. (These days any popular language will
sprout a few web frameworks, but they don't have to become popular for the
language to succeed.)

~~~
Splines
Also IMO the ActiveState did alot to make perl & Python popular. Only in the
last 10 years or so did ActivePython become really useful. In the last 90's it
seemed (in my mind, at least) to play second fiddle to ActivePerl.

------
jff
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.

~~~
Maro
I'm wondering why you didn't use a scripting language like Python?

~~~
jff
1\. We wanted to try out Go

2\. We wanted something that would give us a single, staticly-linked binary
that we could easily push out to the nodes. Does Python allow that?

3\. Go's goroutines and channels fit beautifully with what we were trying to
do.

------
smosher
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.

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.

~~~
supersillyus
I want a simple language that compiles to native code, has easy concurrency
support, is garbage collected, allows me to distinguish between values and
references, and has a compiler/standard library that is useable for real
tasks. What other language betters fill that?

~~~
smosher
That depends. I don't have a good answer because I don't personally think Go
qualifies. Rhetorically: _is that really all you want out of it? Does Go
really do it well enough in your opinion?_

The thing about compiling to native code is interesting. Why is that
important? And are you excluding VM languages which nevertheless produce
system binaries in that?

------
CoffeeDregs
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.

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.

The best part of the post is that (until later) I didn't know that the "ooh-
wow" bits on [http://www-cs-
students.stanford.edu/~blynn/c2go/ch04.html#_f...](http://www-cs-
students.stanford.edu/~blynn/c2go/ch04.html#_full_translation) 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.

------
cageface
How can a language with garbage collection _replace_ C?

~~~
latch
Like you, I obviously don't grok Go. Is the goal to build a modern general
purpose language? Or is it to build a better C?

I'm not sure how it can succeed at either when when it borrows a so much from
C (a language which is at least a couple generations dated when it comes to
general purpose languages) while adding garbage collection.

~~~
kinghajj
The purpose of Go isn't to replace C at what C does best, like being wicked
fast and having very direct access to the hardware. It's meant to replace
programs that Google used to write in C++, like web servers, data aggregators,
etc. Go was designed by Googlers for Googlers, and that's very obvious from
both the design and standard libraries.

------
jergosh
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.

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).

------
andhow
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".

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.

------
silon
-1 to Automatic semicolon insertion (seriously).

~~~
smosher
Yup. I stopped following Go when that happened. Not intentionally but adding
yet more things (invisible ones, no less) that I need to be wary of is not
what I consider convenience in a syntax. Other more awkward languages became
less inconvenient to use and I just stopped using Go.

I probably would have kept at it a bit longer if the dev team was more
accepting of feedback presented in good faith. I'm not really surprised --
it's often hard to tell the difference between fruitless bikeshedding and _oh
guys FYI you might consider this a problem, I do._

I am biased towards semis though, when I first saw OCaml's ';;' I was pleased.

~~~
silon
I mostly stopped too. I still read the mailing list occasionally, but haven't
bothered to download any snapshots.

------
wazoox

        As a rule, never start a new line with an opening brace; 
        it belongs with the previous line.
    

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.

~~~
joelthelion
I'm pretty sure you'd get used to it very fast. I think it's a good idea to
enforce one style from the start: it kills all stupid arguments in the egg,
and lets people focus on the important stuff.

------
bigblankenship
Really? Systems programming with a garbage collected language? I'm sure the
kernel developers will love that.

~~~
ryannielsen
Why not have a systems language with garbage collection?

From <http://research.microsoft.com/pubs/52716/tr-2005-135.pdf>:

    
    
      3.4	Garbage Collection
      Garbage collection is an essential component of most safe languages,
      as it prevents memory deallocation errors that can subvert safety
      guarantees. In Singularity, the kernel and processes object spaces
      are garbage collected.
    

I appreciate that Microsoft Research is saying "why not?" rather than "why?".
Singularity is a fascinating OS and I hope it, or some derivative or something
like it from someone else, eventually reaches the mainstream market.

~~~
chalst
BitC, a project started by Jonathan Shapiro of Coyotos project fame and
briefly associated with Microsoft's Midori project, is a systems programming
language that supports garbage collection but also allows the programming of
critical sections of code in which garbage collection is not permitted to take
place.

<http://www.bitc-lang.org/docs/bitc/bitc-origins.html>

------
sigzero
I don't see a lot of buzz for Go or at least not nearly enough to make me even
ponder "Could Go replace C?".

------
SRG
Related: simple Unix tools written in Haskell. Most of them become just one-
liners. Everything is linked to a single executable.

<http://www.haskell.org/haskellwiki/Simple_unix_tools>

------
evilduck
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.

~~~
chrisjsmith
It's all about trade-offs. GC does eat more memory but with the proliferation
of reasonably sized chunks of RAM on ARM embedded systems for example, it's of
little concern. Not only that, you reduce the time to market and likelyhood of
your code falling over due to pointer and memory problems. That is probably
preferred (in my experience) when your product is in situ and has no form of
upgrade possible other than shipping an engineer out to do it.

~~~
evilduck
The cheapest ARM chips are still total overkill for most retail embedded
electronic devices and many times more expensive per unit.

The cheapest ATTiny AVR chip is $0.60/ea bulk. The cheapest ARM chip like an
AT91 is about $4.00/ea bulk. Ship a few million units and suddenly the cost
difference between developing in C and Go is pittance.

------
sliverstorm
I'm no CS guru, but just reading the Go code makes me long for the C examples.
Thankfully they are not far up the page. Aaahhh...

------
trezor
Serious question. Does Go really have anything unique going for it, apart from
the fact that it comes from Google?

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.

~~~
chrisjsmith
It's as easy and as expressive as python, nearly as fast as C and less
complicated than both. That's good enough in my book.

~~~
bfung
_nearly as fast as C_

not quite; using comparisons from the The Computer Language Benchmarks Game
[[http://shootout.alioth.debian.org/u32/which-programming-
lang...](http://shootout.alioth.debian.org/u32/which-programming-languages-
are-
fastest.php?gpp=on&gcc=on&java=on&ghc=on&csharp=on&go=on&racket=on&python3=on&yarv=on&calc=chart)],
Go is currently (in general) slower than C++ gnu g++, C gnu gcc, Java 6
-server, Haskell GHC, C# mono, just to name a few. Sure, it's not a definitive
view, but it's better than code not run and compared.

~~~
uriel
Go's compilers are still very young and do almost no optimizations.

Also, the 32bit compilers are specially bad as they are not really used by
most of the Go developers, the 64bit compilers do much better as you can see
here:

[http://shootout.alioth.debian.org/u64/which-programming-
lang...](http://shootout.alioth.debian.org/u64/which-programming-languages-
are-fastest.php)

~~~
limmeau
There is also gccgo, which uses (and profits from) the gcc backend.

------
raz0r
Really? Replace C? Really? <http://golang.org/src/>

------
rookie
eww, single character variable and function names make me ill

------
wcsun
Go is designed more like a language for the web. it has a special niche in
server programming with ease in memory management and concurrency.

