Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C vs GO

crypto.stanford.edu

Post reply on HN
Print view View original

121–130 of 184 posts

Re: C vs GO

#121

Post by eswangren »

jamesgeck0 wrote: post #55
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…

> but could you write an "AAA" video game in it? Perhaps not, but an extremely large percentage of commercial indie games are written in managed languages.

Yes, but they tend to be relatively trivial (in terms of performance) in comparison to AAA titles.

Re: C vs GO

#122

Post by luriel »

comex wrote: post #98
luriel wrote: post #62

Earlier quoted context omitted.

The C and C++ code Google runs on their servers is always statically linked, and I would call that Serious Work. In the end, static linking is almost invariably superior to dynamic linking: simpler toolchain, simpler runtime, better reliability, better performance and better security, see: http://harmful.cat-v.org/software/dynamic-linking/ That said, I think you can do dynamic linking with gccgo, and when linking to…

> (Remember that the real impetus for adding them to Unix was X11 and its big and badly-factored libraries, which most of us aren't blessed with.) Really? Today we are very much blessed with quite a few large libraries - not just X but Qt on top of that and KDE on top of that. WebKit. ICU. These come out to dozens of megabytes. Static linking would add somewhat less by eliminating unused symbols, but you'd still end…

> Today we are very much blessed with quite a few large libraries

And with magnitude orders more RAM. And just because there are large libraries doesn't mean they are either necessary or desirable.

> not just X but Qt on top of that and KDE on top of that. WebKit. ICU. These come out to dozens of megabytes.

Interestingly most apps that depend on Qt, WebKit or ICU include their own copies of this libraries.

> Static linking would add somewhat less by eliminating unused symbols

Thanks for reminding me of another benefit of static linking which I forgot to mention.

> I count 4,000 odd binaries in my PATH

I'm a fan of many small tools working well together but I can't help but feel that when you have systems with 4,000 binaries in your PATH, something has gone terribly wrong.

Also, Go's current binaries are large not because they are statically linked but because there has been basically zero optimization of generated binary size. There is no reason why Go binaries couldn't be much smaller, other than so far it has not been a problem for anyone building systems in Go.

> Today's security environment requires frequent patches to library code.

Which is not helped by dynamic linking for reasons both of complexity (see http://harmful.cat-v.org/software/dynamic-linking/versioned-... ) and because most programs anyway use their own version of such 'shared' libs (update your system's ffmpeg and chrome will keep using its own copy). Dll-hell has security implications too.

In practice people end up doing things that either nullify the alleged benefits of dynamic linking, or simply using static linking (Google deploys statically linked binaries, sometimes multiple Gb in size to their servers).

Re: C vs GO

#123

Post by 0xABADC0DA »

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.

Somebody should write a Google Go to C transpiler. Mostly Google Go features are limitations or different styles in order to 'improve' C, so it should produce fairly readable C code. Then you could use any compiler, linking type, combine with any language, etc. You could probably even use LD_PRELOAD to replace coroutines with pthreads.

For instance Russ Cox did coroutines and channels in his C libtask in a few thousand lines of code. It's not pretty but it works. Include something like it behind an API as 'libgrt.o' with a few other features and the rest of the code transpiles cleanly.

...but say this existed. What would be the point of writing Google Go code? A more compiler-friendly syntax, less flexibility to make simple memory/pointer mistakes? Would that be enough or would you, with perfect C linkage, just end up writing most of the code in C and Lua? It certainly seem the effect of creating their own compiler (worse than gcc), an opaque "go" tool that does everything, project layout and hosting rules, complicated FFI, etc is to make a 'toolchain island' locking you into writing everything in Google Go, where you might not otherwise.

Re: C vs GO

#124

Post by cantankerous »

angelbob wrote: post #75
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.

He's picking a bunch of problems C is really good at and then roughly, fairly mechanically translating to Go. I don't think he's trolling, but I do think he's playing to C's strengths and Go's weaknesses, possibly by accident.

I agree. I don't see anything wrong what he did, but somebody should offer to submit counterpoints that better emphasize what Go is able to do.

Re: C vs GO

#125

Post by jbooth »

eswangren wrote: post #101
jbooth wrote: post #48

Earlier quoted context omitted.

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.

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.

Duh. "Done" and "easily done" are different things.

Structs with functions isn't the biggest deal, and namespaces can be simulated with a couple underscores. But I have a hard time with error handling if you don't have exceptions, any time I have a call stack more than 3-4 deep I find myself confused about how to treat certain errors. Then there's concurrency.

Re: C vs GO

#126

Post by cantankerous »

copx wrote: post #100
2mur wrote: post #65

Earlier quoted context omitted.

Do you have any resources / books for writing modern C like this or is it all experiential from the trenches?

>Do you have any resources / books for writing modern C like this No, sorry. >is it all experiential from the trenches? It's mostly about applying general principles of software construction like separation of concerns, encapsulation, robust interfaces, etc.

Maybe you could provide some of your favorite resources to those things, then?

Re: C vs GO

#127

Post by AncientPC »

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've gone ahead and reformatted his code using `indent -kr` and `gofmt`: https://gist.github.com/2932444

Re: C vs GO

#128

Post by swdunlop »

JackdawX wrote: post #118
ralph wrote: post #107

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

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

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.

Re: C vs GO

#129

Post by AncientPC »

JackdawX wrote: post #118
ralph wrote: post #107

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

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

The author's style is not idiomatic for C or Go. He uses shortcuts for compactness at the cost of readability.

Normally this alone is not an issue, but using non-idiomatic code is a weak argument when trying to describe language readability differences.

Re: C vs GO

#130

Post by it »

scott_s wrote: post #80
luriel wrote: post #79

Earlier quoted context omitted.

This is not really an issue with the language but with the implemetnation and most languages/libraries/OS-es are not suited for "hard real-time" either. How many people are writing "hard real-time" code? I suspect not many, and yes, for them probably Go is not the right tool at the moment, but also in great part because nobody has needed/wanted to use Go in such environments yet.

Requiring garbage collection is a language issue, not just an implementation issue. (Note that I do not think GC is a bad thing, but it matters a great deal in this context.) Making GC work in hard real-time system is a Hard Problem. I think you greatly underestimate how difficult it is, given your final sentence. Read the Metronome project I linked to. You are correct that not many people write hard real-time code;…

You can shut off the GC in Go:

  import "runtime"

  ...

  runtime.MemStats.EnableGC = false
https://groups.google.com/forum/?fromgroups#!topic/golang-nu...
Post reply on HN