C vs GO

Post by eswangren » Thu, Jun 14, 2012, 5:59 PM UTC

jbooth wrote: post #48

fingerprinter wrote: post #46

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.

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.

Post by stcredzero » Thu, Jun 14, 2012, 6:09 PM UTC

luriel wrote: post #60

regularfry wrote: post #59

Earlier quoted context omitted.

My chief worry over Go at the moment isn't that is has GC (for the most part), but that the GC it does have is relatively dumb.

The GC in Go 1 is a bit smarter than it used to be, and it is going to be even smarter in Go 1.1, this things take time, and the current GC works quite well for most people. Also Go gives you control over memory layout, which allows you to avoid some GC issues that are much more difficult in languages like Java.

Post by jff » Thu, Jun 14, 2012, 6:12 PM UTC

nux6 wrote: post #39

luriel wrote: post #29

Earlier quoted context omitted.

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 behav…

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.

Post by ralph » Thu, Jun 14, 2012, 6:15 PM UTC

    if (argc  1) putchar(' ');
        printf("%s", argv[i]);
      }
      putchar('\n');
    }

Post by samnardoni » Thu, Jun 14, 2012, 6:23 PM UTC

pcwalton wrote: post #63

luriel wrote: post #29

Earlier quoted context omitted.

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 behav…

Go is a fine language, but I do have a nitpick here: you do not "avoid the GC" by using memory pools. The GC must still trace through the pool when it does run. The more correct thing to say is that you can reduce allocations with memory pools, which make the GC run less often and make it do less work. Furthermore, memory pools compromise safety: if you free a pointer to an object in your memory pool and you accident…