
C vs GO - akg
http://crypto.stanford.edu/~blynn/c2go/index.html
======
copx
I like Go but it's not a replacement or even just competition for C. Garbage
collection alone ensures that.

C is for low-level code, where you usually want deterministic, real-time
behavior. Go cannot deliver that because of its GC.

You can certainly write web server software in Go (what Go was designed for),
but could you write an "AAA" video game in it? Or a mission critical embedded
system with real-time requirements?

Also, the author's portrayal of C is misleading. If you have 'naked' malloc()
calls all over your code you are doing something wrong. Much C code never
calls malloc() or follows the "no allocation after initialization" principle.

If you write C like Python you will run into problems. In C you do not wildly
allocate objects on the heap all across the program. E.g. in my current
program almost everything comes out of memory pools. E.g.

Object* object = ObjectNew();

..and if I forgot to release it I would know quickly because any "memory leak"
would cause the (pre-allocated, fixed size) memory pool to run out of free
slots. In C you should manage memory in a systematic fashion.

I think the C standard library should be seen as the very foundation of a
program, something you use to build the abstractions which solve the problem,
not something you use directly to solve the problem. People often warn about
the dangers of strcpy() (an the author uses it). I never use it except at the
lowest levels. At the high level robust C code looks more like this:

ObjectSetName(object, newName);

than this

strcpy(object->name, newName);

..the difference is that ObjectSetName() can internally guard against overflow
and that the concrete details of the object data structure remain hidden and
thus later code changes are easier. It is a very common C idiom to use
incomplete types and such functions to achieve a very high level of
encapsulation.

~~~
luriel
Your C code looks very unidiomatic to me, but I guess that is relatively a
matter of taste (still I don't understand why would somebody use C if they
don't like to write code in the 'classic' C style as seen in the original Unix
and Plan 9 source).

That aside, in Go you can also do fixed allocations and manage your own memory
pools to avoid the GC.

And I would also question how many C programs require real-time behaviour
(even the definition of 'real-time' has issues, most things people call 'real-
time' aren't).

~~~
nux6
E.g. any app with [record] button need to meet 'mostly' predicted system
latency, that's 'soft-real-time'. Any professional app with [play] and
[record] button needs a minimal warranted latency, that's 'hard-real-time'. Go
is unsuitable for both.

~~~
pjmlp
And yet there are sound manipulation tools developed in Java and .NET...

~~~
pcwalton
Well, to be fair, Java and .NET have generational, concurrent, incremental
garbage collectors.

------
fingerprinter
I guess I might be the only one to say this, but is this a joke? Some sort of
prank? Not a single Go program is more readable, and I would argue that they
are ALL less readable (and I like Go).

I honestly can't tell if he is trolling or if he is serious.

~~~
jbooth
I think Go's strengths over C really start to shine when you're writing
programs longer than 100 lines. Not having an exception mechanism, interfaces,
single namespace, no attaching methods to structs etc are fine in a small
program, but they make bigger programs harder to digest pretty quickly.

~~~
eswangren
Well, the operating system you used to write that comment was probably written
in C, so apparently it does in fact work in large projects. It has weaknesses
to be sure, but I don't think lack of OO (I.e., structs with functions) is one
of them.

~~~
dllthomas
Particularly given that you _can_ write OO code in C, and _can_ decorate
structs with functions, it's just messier.

~~~
StephenFalken
"Object oriented programming with ANSI-C":

<https://ritdml.rit.edu/handle/1850/8544>

------
simias
Damn. I can't comment on the Go listings, but could he make his C code any
_less_ readable?

What's the point of making the code so dense anyway? Without syntax
highlighting I gave up pretty quickly.

~~~
adobriyan
The point is to show that Go is superior to C (which obviously is true but not
for the reasons mentioned in the article).

Anything counts.

Go code is obviously formatted with gofmt. C code is obviously not formatted
with "indent -kr".

Liberal use of comma operator unseen in real world.

Look at example of yes(1) with error-handling.

Author doesn't use strdup(3).

But even if he did, it still doesn't make sense to call fprintf(3) once due to
allegedly hard error handling. Error handling is not common path, fprintf(3)
doesn't fail!

He concatenates all string into once which makes it O(n^2) because of many
many times strlen(3) is called (and kernel copied argv contents before that!).

I bet he did error checking wrong on C side (just checking return value should
not be enough). It'd be interesting to see same code on Go side.

Obligatory quote: "considering that bad code can be written in any language,
any language comparison performed using examples must be judged by the quality
of the examples in each language. it can't be all that hard to write a bad
example in language A and a good example in language B, and then proclaim
language B to be the winner -- this is how people compare languages all the
time, so either those who read them are bad programmers in any language (or
are not programmers at all) and don't know how to reject the bad examples, or
they already agree with the author of the comparison that language B is better
than language A. in either case, it's a waste of anything but marketing money.

...

#\Erik"

~~~
shadowmint
This has been discussed before, so many times.

In fact, in pretty much every thread go turns up in. _sigh_ I'm just going to
link to my favourite review now, again (pertinent, and mentioned here only
because the author of the original shared a favourite with me):
<http://www.math.bas.bg/bantchev/misc/on-go.html>

Quote: "But I know I am not going to love Go. True beauty evades this
language. Go may be practical, but is also eclectic, and has taken some
unconvincing or downright ugly design choices. It definitely lacks that subtle
but unmistakable touch of elegance that makes a language great."

~~~
luriel
I'm not sure how to take that review given that his two main complaints seem
to be:

1) That Go has i++ and not ++i. Don't even know what to say to someone who
thinks this a major issue, really.

2) That the declaration syntax is 'unattractive' and different from other
languages. Yes, the syntax looks a bit strange at first if you are used to C,
but it is unquestionably cleaner and better, specially in more complex
declarations. This is even covered in the FAQ:
<http://golang.org/doc/go_faq.html#declarations_backwards>

His other complaints seem to be about the name of the language and how much
some of the Go documentation acknowledges the influences of certain languages,
which as he himself says, is just politics and not really relevant to the
language itself.

At the same time there seems to be plenty of people who actually have used Go
and love it, including the designers of other languages:

<http://go-lang.cat-v.org/quotes>

------
ralph
I gave up reading this very early on. The striving for compactness of the
source, in both C and Go, makes it misleading to read. Take

    
    
        if (argc < 2) puts("y"); else {
          for(int i = 1; i < argc; i++) {
            if (i > 1) putchar(' ');
            printf("%s", argv[i]);
          }
          putchar('\n');
        }
    

A casual skim sees the _if_ followed by an indented block, but that isn't the
then-path but the else-path. Now yes, I can read it carefully and follow it,
just as if I was debugging someone else's poorly formatted code, but in doing
so my attention is being distracted from the main point of the article and
frankly I have a huge pile of other things to read that are potentially more
rewarding.

~~~
JackdawX
Your post adds nothing useful to the discussion. There is no point arguing
about indenting style in a 7 line program, it's needless pedantry! This is
almost exactly the same thing as grammar nazi-ism, and seems to have a
similarly negative impact coding related websites.

I think we need to coin a new term - indent-nazi, style-nazi, or something
similar - for the purpose of dismissing this kind of post and keeping people
on topic.

~~~
swdunlop
Actually, "indent-nazism" is a big thing in the Go community. The Gofmt
utility, which takes an AST of your code and normalizes it to a common style.
Nobody agrees that the style is perfect, a lot of people have religious
preferences when it comes to brace placement. But Gofmt ensures that all these
people can find a consistent format when it comes time to diff.

GoSublime and go.vim both integrate gofmt into the editor; you start to miss
it when refactoring, because you can just shrug and say "gofmt will clean it
up when I save" when you move a block to a different function or indent level.

I agree with the grandparent -- seeing non-gofmt code is jarring and
deliberately distracting. It's like someone writing an entire Python program
with nothing but lambdas.

~~~
drivebyacct2
It's not just diffs, you learn to scan code. The same way that you can't use
i++ inline, having consistent indentation and treatment of syntax allows for
quicker at-a-glance human parsing.

------
gouranga
Interesting comparisons.

However (not slating Go, which I think is excellent), I genuinely think Go is
going to go the same way as plan9 eventually. Unfortunately, its predecessor
(C) is good enough, much as UNIX was good enough compared to plan9.

~~~
nux6
The devil is in details. Go is great for hi-level or simple stuff like that,
but is not really usable for system programming. If things are a bit more
complicated, the go runtime stays in the way. For those problems, after a
while, the bare metal support was removed from the language completely...

~~~
pjmlp
Ever heard of Oberon, Modula-2 and Modula-3?

These languages also had OS fully implemented on them, just with tiny bits of
Assembly to do the very low level stuff, similar to what C would require
anyway.

The only advantage of C is that its runtime is so small, that in practice the
OS is the C's runtime.

~~~
mkup
It's not the only advantage. Another, more important advantage of C and C++
over Go is a lack of stop-the-world garbage collection (and predictable memory
usage under high load).

~~~
rwmj
You can predict the time that malloc(3) and free(3) take to run? You know they
are backed by very complex data structures that need to manipulated and
iterated over?

The point you mention is only valid when using entirely static memory, which
is a very rare case in real C code (only really used in a few small embedded
codebases).

~~~
pjmlp
> You can predict the time that malloc(3) and free(3) take to run?

Thanks for pointing this out.

This is often a misunderstanding from manual memory management fans. In many
cases malloc()/free() also behave non-deterministic.

This is the main reason why for special types of applications, you need to
have malloc()/free() implementations specially targeted to the use case at
hand.

This is no different from the GC runtimes, which are coded specifically for
real time applications, like avionics, for example.

~~~
ori_b
It's very different in one significant regard: it's very easy to write your
own acceptably performant and deterministic malloc and free, compared to the
effort it takes to write a GC that would fit in to those constraints.

------
delinka
My complaint about Go centers around its mechanics of code reuse: static
linking for all Go code; making anything Really Useful requires using other
libraries, which includes those written in C, which require use of a tool to
help you write your wrapper ...

If we could get dynamic linking and something less cumbersome for interfacing
with existing libs, I could use Go for Serious Work.

~~~
shadowmint
I dont see why this got downvoted. It's the biggest issue I have with go as
well.

It's a royal pain writing go that talks to C code, compared to say, lua or
python, and there just _isnt_ a way to make other languages pickup go
libraries and run the symbols from them afaik...

~~~
luriel
> It's a royal pain writing go that talks to C code, compared to say, lua or
> python

This is plain wrong, you can pretty much call C code directly, while in Python
and the like you _really_ have to write a wrapper.

Of course in Go you will write a wrapper anyway to give the library a more Go-
like API, but I don't see how this could be any worse than in any other
language.

> there just _isnt_ a way to make other languages pickup go libraries and run
> the symbols from them afaik...

To get non-Go code to call Go code is trickier (also Go really wants to run
your main()), but can be done, and there are even libraries to write Python
extensions in Go, see:

<http://gopy.qur.me/extensions/>

~~~
xyproto
Also, there's assembly. <http://stackoverflow.com/a/6535590/131264>

------
Graphon
People suggesting that Go is a potential replacement for Python, Lua or Ruby
are missing the point. IMO, Go isn't designed to compete with those existing
languages for existing opportunities.

The key opportunity in the future is smart devices everywhere. Embedded,
connected intellgence, everywhere. Everything is a communication device. Today
your phone and your car; tomorrow: Your shoes, your office, the grocery store,
your refrigerator. Think of xbox Kinect-type sensors embedded into everything.

Writing solid C code for all those systems will be too hard. We also
definitely do not want an serendipitously-designed language (Javascript). Yes,
that leaves Python Ruby and so on, which brings us full circle. Go will
compete with those languages but not in the domains that are evident today.
Not in web browser, and not in a new! improved! web server. It seems to me
that Go is a forward-looking design, aimed to meet the challenges of the
everything-connected world of tomorrow.

To make tomorrow happen, we need a better C. Go is that.

~~~
heretohelp
Go is highly inappropriate in embedded environments so your pipedream betrays
a naivete to systems programming.

~~~
xyproto

      * You can turn off the GC.
      * You can compile with gccgo.
      * You can call assembly code from Go.
    

What is the major hindrance from using Go in embedded environments?

------
revelation
I can't do system programming using Go on a platform for which there is no
compiler. There is probably a reasonable C compiler for every platform in
existence out there.

~~~
Devilboy
Right now there's Go compilers for Windows, Mac and Linux. I'm sure others
will follow soon.

~~~
dchest
\+ FreeBSD.

Also, OpenBSD, NetBSD, and Plan 9 in the works.

~~~
luriel
OpenBSD and Plan 9 pretty much work already, even if the ports might not be as
polished as FreeBSD.

Also there is gccgo, which AFAIK also works on Solaris and probably elsewhere.

~~~
4ad
Yes, it works on IRIX and RTEMS (an embedded OS), and the gc suite was also
ported on Ethos.

I'd also like to add that the gc compilers support ARM as well as x86 and
amd64 and are very, very easy to port to new platforms.

------
kristianp
Mods, the title should be "C to Go", Go is not spelled with all-caps.

------
iamgopal
err..sarcasm ?

------
papsosouid
Go is the best worst language I've used. Most of what I do fits pretty much
right in the sweet spot for go, network services and web development. Stuff I
would have previously used C and (insert scripting language here) for
respectively. Go fits into both of those areas really nicely, and I prefer it
over C and scripting language X for these tasks.

But the problem is, I've already tried haskell, which also fits that same
area, and is semantically a vastly better language. I just wish go had been
more willing to push the envelope and at least try to be somewhat modern and
useful instead of being "C with modules, but slow". On the other hand, haskell
is a terrible language syntactically, and from a development environment
perspective. Go is near enough to perfect in those regards. Having a fast
compiler, a simple, working build system, a sane and easily enforced code
format all make a huge practical difference. I wish I could use go, as it is
much nicer than haskell from a usability perspective. But the language is just
too primitive.

~~~
eeperson
Might I suggest Scala[1]? It is a modern languages with mature build tools and
development environment. It also has a lot of nice tools surrounding network
services and web development[2].

[1] <http://www.scala-lang.org/> [2] <http://typesafe.com/stack>

~~~
papsosouid
You certainly can suggest it, I already tried it though. ;)

Scala ends up more like the worst aspects of haskell and go combined, rather
than the best aspects of both.

~~~
soc88
Details, please.

~~~
papsosouid
Pretty much what I described above. The bad parts of haskell (compile time,
memory usage while compiling, bad syntax, terrible dependency/package/module
management) are all present in scala, and it is semantically an inferior
language to haskell. Scala is certainly a whole lot closer to haskell than go
is, and I certainly don't blame anyone involved in the creation of scala for
its limitations, the JVM limits how good they can get. But at the end of the
day, using scala would solve none of the problems I have with haskell, and
leave me with a less powerful language.

~~~
eeperson
Out of curiosity, what make the Go dependency management so good? I'm not
terribly familiar with this aspect of Go. Based on a what I've read, it
doesn't seem dramatically different than what you would do for Scala (except
it is packaged with the language rather than an external tool like SBT). Is
there something I am missing?

~~~
papsosouid
SBT just fails to work correctly on a semi-regular basis. Quite a few scala
people ended up resorting to maven instead, which says a lot.

~~~
eeperson
That has not been my experience at all. SBT has always worked correctly for
me.

When was the last time you used Scala and/or SBT? I know a lot of the tools in
the Scala ecosystem were unstable prior to Scala 2.8. However, now they have
become pretty good. Even the, previously notoriously bad, Eclipse plugin has
become good.

~~~
papsosouid
~6 months ago. I'd certainly say the eclipse plugin has improved a lot, it's
better than the intellij one now. It is still quite a ways away from good
though.

------
drivebyacct2
I've been using Go exclusively in my personal projects for the last 8 months
now, am in love with the simplicitly and fun of writing it (and goroutines),
but this is a horrid way of introducing the language. To anyone who doesn't
appreciate the Go syntax style, this is an instant turn off. There is a reason
there is an idiomatic style used by... every single Go project I've ever seen.

Further, these examples are so trivial that one doesn't see an advantage over
C and so this comment thread is like every other. Those who've written "Hello
World" dismiss it as neither C nor Haskell and most others seem to be
generally happy with it.

------
tubbo
I mean, the only other living inventor of C is working on Go...

------
millerfung
In my opinion, any new language today should be all beginner friendly, there
are large pool of people who are interested and it means a great future of our
world.

~~~
EliRivers
"any new language today should be all beginner friendly"

I disagree. I think any new language should be designed to best meet the kind
of problem it's being created to deal with. Making it "beginner friendly"
(whatever that means - I bet there are lots of different interpretations) is a
nice extra, but should not come at the expense of solving the problems.

~~~
millerfung
Yes I agree that new language should be developed because of the ever rapidly
changing digital world to enhance everyones experience in digital products. I
am sure it is going to get more complicated, however, being a beginner
friendly language should still be taken into account. In fact, only the one
who is more beginner friendly will survive in the long run because in the
future there might be a mismatch of demand and supply of coders. Living in
this moment of our planet is exciting because of the experience we have having
digital products around us everyday, and there are/will be lots of teenagers
who wants to get involve as well. In my opinion, coders are like "workers" in
manufacturing companies in the future.

~~~
EliRivers
"In fact, only the one who is more beginner friendly will survive in the long
run"

That makes no sense to me. In any industry with a sizeable number of workers,
there is a huge range of tools, from the entry level easy-to-use up to the
fantastically intricate and arcane. Tools that are not "beginner friendly" are
that way for a reason.

As an example, assembly code is never going away; for the obvious reason that
if nobody understands it, nobody can write compilers, and also because there
are cases where knowing assembly is useful and helps to make better code,
whether it's taking apart the code to really, truly get every last clock-cycle
of power out of the thing, or to take apart code in the search for arcane bugs
and wonderfully subtle interactions causing unexpected behaviour. Assembly is
old, and will never go away, and is (for most meanings of the phrase) not
beginner-friendly.

The only advantage to a language being "beginner friendly" is that beginners
can learn it fast. What you then get are inexperienced programmers who know
just enough to be dangerous (this is not an attack on them; it's the case in
any industry with a low barrier to entry, and a stepping stone to being
better). One expert, experienced programmer with knowledge of a "beginner
unfriendly" language is worth literally dozens of first-day coders wielding
their hand-holding, garbage-collecting, counting-begins-at-one modern version
of BASIC. That is never going to change, and every first-day coder wants to
become that expert.

Even if somehow all the non-"beginner friendly" languages died, the very next
day someone who'd been coding in this "beginner friendly" language for a
decade would finally get sick of it and start designing a language she can
truly express herself in without having all the hand-holding that holds her
back.

~~~
millerfung
That's a very good argument, I will accept this :) hopefully, at the end,
there is a language that is easy to understand at first and therefore people
could easily pick it up, like English?

