C vs GO • Hacker News Board

Re: C vs GO

#41

Post by [deleted] » Thu, Jun 14, 2012, 1:17 PM UTC

luriel wrote: post #29

copx wrote: post #27

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

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…

[deleted]

Re: C vs GO

#42

Post by shadowmint » Thu, Jun 14, 2012, 1:20 PM UTC

delinka wrote: post #37

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.

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

Re: C vs GO

#43

Post by copx » Thu, Jun 14, 2012, 1:21 PM UTC

luriel wrote: post #29

copx wrote: post #27

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

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…

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

Because we learned a lot about writing more robust and maintainable software since the 1970s. Also the original Unix source code was one thing more than anything: small. Really, really small. Mostly because it did not do much compared to a modern OS.

Things like encapsulation, separation of concerns, etc. only become important once the code grows to a certain size. Unfortunately some people think you need at least C++ for that, despite the fact that for example "private" member variables are way less private than incomplete C types. C is old, but that does not mean it is incompatible with modern software development approaches. Or that you have to write code as if your compiler only parsed the first few letters of an identifier. I think C's bad reputation in some circles can be explained by people only ever seeing 1970s style code.

Re: C vs GO

#44

Post by cloudhead » Thu, Jun 14, 2012, 1:21 PM UTC

adobriyan wrote: post #12

simias wrote: post #3

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.

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…

Go is superior to C? Damn, I must have missed the memo!

Re: C vs GO

#45

Post by gouranga » Thu, Jun 14, 2012, 1:23 PM UTC

copx wrote: post #36

rwmj wrote: post #26

Earlier quoted context omitted.

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

>You can predict the time that malloc(3) and free(3) take to run? The correct answer would be: depends on the concrete implementation. There are implementations with real-time guarantees. However, assuming standard desktop OS malloc()/free() the answer is: No. These functions can execute very quickly.. or very slowly, depending on their current internal state. But you can control when they get called, which can be an…

You speak sense. I tend to use apr pools all the time in critical sections.

Re: C vs GO

#46

Post by fingerprinter » Thu, Jun 14, 2012, 1:23 PM UTC

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.

Re: C vs GO

#47

Post by donnyg107 » Thu, Jun 14, 2012, 1:51 PM UTC

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 disagree. After only a brief runthrough of Go, the different types of statements are very recognizable line by line. The sytax includes less obvious breaks and parens, but I think that makes the code a lot more readable because it eliminates the nastier paren nesting you often see in C. I think the first example in chapter 2 gives clear indication of the benefits of eliminating the features of C which are more compact but less readable.

Re: C vs GO

#48

Post by jbooth » Thu, Jun 14, 2012, 1:52 PM UTC

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.

Re: C vs GO

#49

Post by shadowmint » Thu, Jun 14, 2012, 1:56 PM UTC

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.

Judging by the similarity to his much large section on C (http://crypto.stanford.edu/~blynn/c/) I'd say serious.

Also, who cares what his style is?

If _you_ ever have to work on the code, run gofmt on it; if that's how he likes his go, good for him.

Re: C vs GO

#50

Post by thdn » Thu, Jun 14, 2012, 1:57 PM UTC

gouranga wrote: post #4

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.

Even the pet looks similar hehehe :P