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

71–80 of 184 posts

Re: C vs GO

#71

Post by wsc981 »

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

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

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

I'd say "C programming: A modern approach" (K.N. King) should be a good candidate? Personally I like the book.

Re: C vs GO

#72

Post by look_lookatme »

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

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

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

I'm interested in this too.

Re: C vs GO

#73

Post by scott_s »

batista wrote: post #54
nux6 wrote: post #39

Earlier quoted context omitted.

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.

While I agree that Go is suitable for his examples, it's not suitable for hard real-time. As far as I know, its GC does not have bounded latencies. There are GCs that do have bounded latencies (see the Metronome project for Java's GC: http://researcher.ibm.com/researcher/view_project.php?id=174) which then allow them to be used for hard real-time systems.

Re: C vs GO

#74

Post by jaybill »

millerfung wrote: post #15

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.

What kind of "beginner"? If you mean someone who has never programmed before, Go is much simpler to learn than C and makes a lot more sense.

If you mean someone that is a programmer and hasn't used go before, I can tell you I went from "never having seen Go before" to "reasonably proficient" inside of two months. Further, my Go code is easier to read and maintain than anything I've done in other languages. (I came largely from Java, so maybe that's not saying much.)

I think that for beginners of either kind, the documentation and community support are just as important as the language itself. I mean, look at something like JavaScript, which is picked up by "beginners" all the time and is, frankly, obtuse as hell. Go has great docs and a really friendly and helpful community.

Re: C vs GO

#75

Post by angelbob »

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.

Re: C vs GO

#76

Post by icebraining »

luriel wrote: post #33
nux6 wrote: post #11

Earlier quoted context omitted.

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

> For those problems, after a while, the bare metal support was removed from the language completely... Not really true, you have direct control over the memory layout of your data structures, and if you want to do really tricky stuff there is also the unsafe package.

I think nux6 means running Go programs without an OS, directly "on the metal". There was a proof of concept early on, but it was abandoned.

Re: C vs GO

#77

Post by dillon »

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 is definitely serious.

I do think that all semicolons really shouldn't be used. The only time I ever use semicolons is for error checking in Go.

Re: C vs GO

#78

Post by luriel »

shadowmint wrote: post #52
adobriyan wrote: post #12

Earlier quoted context omitted.

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

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

Re: C vs GO

#79

Post by luriel »

scott_s wrote: post #73
batista wrote: post #54

Earlier quoted context omitted.

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.

While I agree that Go is suitable for his examples, it's not suitable for hard real-time. As far as I know, its GC does not have bounded latencies. There are GCs that do have bounded latencies (see the Metronome project for Java's GC: http://researcher.ibm.com/researcher/view_project.php?id=174 ) which then allow them to be used for hard real-time systems.

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.

Re: C vs GO

#80

Post by scott_s »

luriel wrote: post #79
scott_s wrote: post #73

Earlier quoted context omitted.

While I agree that Go is suitable for his examples, it's not suitable for hard real-time. As far as I know, its GC does not have bounded latencies. There are GCs that do have bounded latencies (see the Metronome project for Java's GC: http://researcher.ibm.com/researcher/view_project.php?id=174 ) which then allow them to be used for hard real-time systems.

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; it's generally found in such things as software controlling planes, power grids or power plants.

Post reply on HN