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

51–60 of 184 posts

Re: C vs GO

#51

Post by scott_s »

shadowmint wrote: post #49
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.

Also, who cares what his style is?

Me, because I found it unpleasant to read. Working on such code is beside the point.

Re: C vs GO

#52

Post by shadowmint »

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…

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

Re: C vs GO

#53

Post by rwj »

revelation wrote: post #5

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.

Go is not a replacement for C. As many people have said, Go is not suitable for most purposes where C would currently be the best choice.

Go is a replacement for Python, Ruby, etc. Garbage collection, duck typing, an excellent library. Go is a language with the same level of abstraction of many other "scripting" languages, but is unique because it uses static typing and is compiled.

Re: C vs GO

#54

Post by batista »

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.

I fail to see how Go is "unsuitable" for even the pro use case.

Go could do a recording type application with minimal guaranteed latency just fine, and the GC won't stop it doing so.

Re: C vs GO

#55

Post by jamesgeck0 »

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.

Re: C vs GO

#56

Post by pjmlp »

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.

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

Re: C vs GO

#57

Post by jkn »

shadowmint wrote: post #42
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...

According to my limited experience (small tools such as a process monitor linking to libproc) it is astonishingly easy and convenient to call C code from Go: no need to write bindings, as Cgo allows to access C symbols directly from Go. I would be interested in what are the difficulties when dealing with larger projects.

For illustration, here's how I call the openproc() function from libproc:

    import (
	/*
	 #cgo LDFLAGS: -lproc
	 #include 

	 PROCTAB* my_openproc(int flags) { return openproc(flags); }
	 */
	"C"
    )

    func parse_procs() {
        proc := C.my_openproc(C.PROC_FILLUSR | C.PROC_FILLCOM | C.PROC_FILLSTAT)
        ...
    }
This illustrates one issue I found with Cgo: calling functions with variable number of arguments is not supported. I had to define a new C function "my_openproc" with a fixed number of arguments, which you can see in the metadata of the import statement. It also includes the compiler and Cgo directives that make editing a Makefile unnecessary. The code for the whole tool is contained in one Go file.

Re: C vs GO

#58

Post by thraxil »

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.

My understanding is that the static linking is a temporary measure to keep things simple and let them focus on getting the language stable. Dynamic linking will come later.

Re: C vs GO

#59

Post by regularfry »

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.

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.

Re: C vs GO

#60

Post by luriel »

regularfry wrote: post #59
jamesgeck0 wrote: post #55

Earlier quoted context omitted.

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

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 reply on HN