15 ms·

C vs GO

202 points by akg 14y ago

FixThisPOS 14y ago
"As a rule, never start a new line with an opening brace; it belongs with the previous line." Wrong. That makes no sense.
simias 14y ago
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.
- adobriyan 14y ago
  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 fprintf(3) once due to allegedly hard error handling. Error handling is not common path, fprintf(3) doesn't fail! He concatenates all string into once which makes it O(n^2) because of many many times strlen(3) is called (and kernel copied argv contents before that!). I bet he did error checking wrong on C side (just checking return value should not be enough). It'd be interesting to see same code on Go side. Obligatory quote: "considering that bad code can be written in any language, any language comparison performed using examples must be judged by the quality of the examples in each language. it can't be all that hard to write a bad example in language A and a good example in language B, and then proclaim language B to be the winner -- this is how people compare languages all the time, so either those who read them are bad programmers in any language (or are not programmers at all) and don't know how to reject the bad examples, or they already agree with the author of the comparison that language B is better than language A. in either case, it's a waste of anything but marketing money. ... #\Erik"
  - akavel 14y ago
    > Go code is obviously formatted with gofmt. Is not, he also inlined some things, e.g. this: import ("flag";"fmt") would be expanded to multiline by gofmt, as well as this: if i>0 { fmt.Print(" ") } As to other things, I can't comment now, as I don't have time to read through all of the article at the moment.
  - cloudhead 14y ago
    Go is superior to C? Damn, I must have missed the memo!
  - shadowmint 14y ago
    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 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."
    - luriel 14y ago
      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 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 http://go-lang.cat-v.org/quotes
- anon_d 14y ago
  The C code looks very nice to me. What's the problem?
gouranga 14y ago
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.
- Devilboy 14y ago
  The big win for go over c is the goroutines - cheap and easy multithreading built right into the language.
  - gouranga 14y ago
    I agree entirely - they are great, but in all the Go I've written (which totals about 50kloc so far as a porting project), I haven't actually used them past anything I would have done with zmq in C.
    - luriel 14y ago
      Goroutines are great, but I'm not convinced they are the greatest advantage over C. Go cleans up and fixes pretty much every issue C had, and improves it in many non-obvious areas, from the syntax to the type system. And when porting an existing project I'm not surprised if goroutines would come up that often given that they probably don't have any equivalent in the original design.
  - jamwt 14y ago
    zeromq or coroutine libraries like libtask (by a go author!) have greatly reduced this advantage.
    - gouranga 14y ago
      libtask looks really cool. Thanks for posting. I suppose that begs the question: if you can built it in the language, should it really be a part of the implementation?
revelation 14y ago
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.
- Devilboy 14y ago
  Right now there's Go compilers for Windows, Mac and Linux. I'm sure others will follow soon.
  - dchest 14y ago
    + FreeBSD. Also, OpenBSD, NetBSD, and Plan 9 in the works.
    - luriel 14y ago
      OpenBSD and Plan 9 pretty much work already, even if the ports might not be as polished as FreeBSD. Also there is gccgo, which AFAIK also works on Solaris and probably elsewhere.
      - 4ad 14y ago
        Yes, it works on IRIX and RTEMS (an embedded OS), and the gc suite was also ported on Ethos. I'd also like to add that the gc compilers support ARM as well as x86 and amd64 and are very, very easy to port to new platforms.
  - vonmoltke 14y ago
    There is more to platforms than operating systems. I worked on an application that had to function on 8 different hardware architectures[0], though on all but one we ran Linux. We also had code that was bare metal (no OS) running on FPGAs and DSPs. Go is a long way from supporting that. This is not to say Go will not get there eventually, if the language gains popularity. Someone had to write or modify a compiler to target all those architectures for C, after all. This is just a reaction to what I see as assumptions tying operating systems to certain hardware architectures (in this and other discussions). Go can be used on a range of operating systems on two hardware architectures. Very good progress, but the language needs to get that second number up before we can seriously talk about it replacing C. [0] Only had to perform well on two, fortunately.
millerfung 14y ago
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.
- luriel 14y ago
  Go is relatively beginner friendly, is simpler and smaller than most languages around (even for example Python). Go code is concise but without dark magic (is easy to see what code does by just looking at it). And you can even read the whole language spec fairly easily.
  - kibwen 14y ago
    > smaller than most languages around I'm not certain that this is specific to Go, insamuch as it's a property of nearly all young languages. After 1.0, language complexity can only ever increase. Even Python has followed this trajectory, although Python should perhaps be commended for being willing to shed some of its complexity along the way (depending on how you view backwards-incompatible changes, some would say it should be denounced rather than commended).
- EliRivers 14y ago
  "any new language today should be all beginner friendly" I disagree. I think any new language should be designed to best meet the kind of problem it's being created to deal with. Making it "beginner friendly" (whatever that means - I bet there are lots of different interpretations) is a nice extra, but should not come at the expense of solving the problems.
  - millerfung 14y ago
    Yes I agree that new language should be developed because of the ever rapidly changing digital world to enhance everyones experience in digital products. I am sure it is going to get more complicated, however, being a beginner friendly language should still be taken into account. In fact, only the one who is more beginner friendly will survive in the long run because in the future there might be a mismatch of demand and supply of coders. Living in this moment of our planet is exciting because of the experience we have having digital products around us everyday, and there are/will be lots of teenagers who wants to get involve as well. In my opinion, coders are like "workers" in manufacturing companies in the future.
tubbo 14y ago
I mean, the only other living inventor of C is working on Go...
- anacrolix 14y ago
  We really need to hear from him.
copx 14y ago
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 requirements? Also, the author's portrayal of C is misleading. If you have 'naked' malloc() calls all over your code you are doing something wrong. Much C code never calls malloc() or follows the "no allocation after initialization" principle. If you write C like Python you will run into problems. In C you do not wildly allocate objects on the heap all across the program. E.g. in my current program almost everything comes out of memory pools. E.g. Object* object = ObjectNew(); ..and if I forgot to release it I would know quickly because any "memory leak" would cause the (pre-allocated, fixed size) memory pool to run out of free slots. In C you should manage memory in a systematic fashion. I think the C standard library should be seen as the very foundation of a program, something you use to build the abstractions which solve the problem, not something you use directly to solve the problem. People often warn about the dangers of strcpy() (an the author uses it). I never use it except at the lowest levels. At the high level robust C code looks more like this: ObjectSetName(object, newName); than this strcpy(object->name, newName); ..the difference is that ObjectSetName() can internally guard against overflow and that the concrete details of the object data structure remain hidden and thus later code changes are easier. It is a very common C idiom to use incomplete types and such functions to achieve a very high level of encapsulation.
- luriel 14y ago
  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 behaviour (even the definition of 'real-time' has issues, most things people call 'real-time' aren't).
  - nux6 14y ago
fingerprinter 14y ago
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.
- donnyg107 14y ago
  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.
- jbooth 14y ago
  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.
  - Locke1689 14y ago
    Calling Go's panic/recover system a proper exception mechanism is quite a stretch.
    - sirclueless 14y ago
      I think he is referring more to go's "defer" functionality and out-of-band error return values more than panic/recover.
      - Locke1689 14y ago
        All of these things are just really poor exception mechanisms, in my opinion. It really looks like no one with an up-to-date PLT background was consulted in the design. I agree 100% with Andreas Rossberg (who now, somewhat ironically, works at Google): It is ironic that their motivation is to tame and restrict the use of exceptions, and then they replace them by something even richer and much less structured. I fail to see any pros of this proposal. It seems mostly equivalent to exceptions, i.e., you can easily express raise/try/finally as syntactic sugar, and likely the other way round. But it is (1) much more ad-hoc -- you cannot give a simple reduction semantics for this, (2) much less orthogonal -- tying `defer' in with function definitions, (3) dependent on mutation -- for recovering and returning alternative results, and implicitly in the semantics of `defer'. One consequence is the loss of beta-convertibility, which means that you as a programmer cannot take an arbitrary piece of code and turn it into a function anymore, or vice versa, eliminate a function by inlining its body. Such abstractions/refactorings are impossible in general under this proposal, or at least require transforming the relevant code in potentially non-trivial ways.
delinka 14y ago
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.
- shadowmint 14y ago
  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...
  - jkn 14y ago
    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 <proc/readproc.h> 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.
  - luriel 14y ago
    > It's a royal pain writing go that talks to C code, compared to say, lua or python This is plain wrong, you can pretty much call C code directly, while in Python and the like you really have to write a wrapper. Of course in Go you will write a wrapper anyway to give the library a more Go-like API, but I don't see how this could be any worse than in any other language. > there just _isnt_ a way to make other languages pickup go libraries and run the symbols from them afaik... To get non-Go code to call Go code is trickier (also Go really wants to run your main()), but can be done, and there are even libraries to write Python extensions in Go, see: http://gopy.qur.me/extensions/ http://gopy.qur.me/extensions/
deleted 14y ago
[deleted]
papsosouid 14y ago
Go is the best worst language I've used. Most of what I do fits pretty much right in the sweet spot for go, network services and web development. Stuff I would have previously used C and (insert scripting language here) for respectively. Go fits into both of those areas really nicely, and I prefer it over C and scripting language X for these tasks. But the problem is, I've already tried haskell, which also fits that same area, and is semantically a vastly better language. I just wish go had been more willing to push the envelope and at least try to be somewhat modern and useful instead of being "C with modules, but slow". On the other hand, haskell is a terrible language syntactically, and from a development environment perspective. Go is near enough to perfect in those regards. Having a fast compiler, a simple, working build system, a sane and easily enforced code format all make a huge practical difference. I wish I could use go, as it is much nicer than haskell from a usability perspective. But the language is just too primitive.
- drivebyacct2 14y ago
  What have you written in Go that you'd wished you'd written in Haskell?
  - papsosouid 14y ago
    Everything, and the same in reverse. That's the problem. Using haskell, I wish I was using go because the downsides of haskell bother me. But when I am using go, I wish I was using haskell because the downsides of go bother me.
    - drivebyacct2 14y ago
      Ah the quest for the perfect mix of everything. I sympathize but I've generally found that there are some things that are better solved in Haskell and others in Go and have found a generally pleasant balance.
      - papsosouid 14y ago
        I see. For me I haven't found anything like that, where task X would be better in go and task Y would be better in haskell. Everything I've done was always better in haskell. It was just an annoying pain in the ass the whole time because of super slow compile times, or running out of RAM compiling, or package conflicts from cabal hating me, or .cabal files requiring spaces instead of tabs, or haskell code I want to modify being some giant mess of arbitrarily aligned with a million spaces craziness that makes cool things like "diff" useless. It just feels like rather than "haskell needs to stop being so crazy", the "go needs to gain modern features" approach is more likely to actually be possible.
drivebyacct2 14y ago
I've been using Go exclusively in my personal projects for the last 8 months now, am in love with the simplicitly and fun of writing it (and goroutines), but this is a horrid way of introducing the language. To anyone who doesn't appreciate the Go syntax style, this is an instant turn off. There is a reason there is an idiomatic style used by... every single Go project I've ever seen. Further, these examples are so trivial that one doesn't see an advantage over C and so this comment thread is like every other. Those who've written "Hello World" dismiss it as neither C nor Haskell and most others seem to be generally happy with it.
Graphon 14y ago
People suggesting that Go is a potential replacement for Python, Lua or Ruby are missing the point. IMO, Go isn't designed to compete with those existing languages for existing opportunities. The key opportunity in the future is smart devices everywhere. Embedded, connected intellgence, everywhere. Everything is a communication device. Today your phone and your car; tomorrow: Your shoes, your office, the grocery store, your refrigerator. Think of xbox Kinect-type sensors embedded into everything. Writing solid C code for all those systems will be too hard. We also definitely do not want an serendipitously-designed language (Javascript). Yes, that leaves Python Ruby and so on, which brings us full circle. Go will compete with those languages but not in the domains that are evident today. Not in web browser, and not in a new! improved! web server. It seems to me that Go is a forward-looking design, aimed to meet the challenges of the everything-connected world of tomorrow. To make tomorrow happen, we need a better C. Go is that.
- heretohelp 14y ago
  Go is highly inappropriate in embedded environments so your pipedream betrays a naivete to systems programming.
  - xyproto 14y ago
    * You can turn off the GC. * You can compile with gccgo. * You can call assembly code from Go. What is the major hindrance from using Go in embedded environments?
  - Graphon 14y ago
    Today's embedded is not tomorrow's embedded. In 10 years your sunglasses will have more compute power and memory than today's smartphone .
ralph 14y ago
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 < 2) puts("y"); else { for(int i = 1; i < argc; i++) { if (i > 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, but in doing so my attention is being distracted from the main point of the article and frankly I have a huge pile of other things to read that are potentially more rewarding.
- luriel 14y ago
  Yes, his code style is bizarre at best, both for C and Go. This is particularly jarring in Go when gofmt exists and is used almost universally (I think this is the first time I see non-gofmt'd code in quite a while).
- JackdawX 14y ago
  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 people on topic.
  - swdunlop 14y ago
    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.
iamgopal 14y ago
err..sarcasm ?
kristianp 14y ago
Mods, the title should be "C to Go", Go is not spelled with all-caps.

202 points by akg 14y ago

"As a rule, never start a new line with an opening brace; it belongs with the previous line." Wrong. That makes no sense.

simias 14y ago

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.

adobriyan 14y ago
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 fprintf(3) once due to allegedly hard error handling. Error handling is not common path, fprintf(3) doesn't fail! He concatenates all string into once which makes it O(n^2) because of many many times strlen(3) is called (and kernel copied argv contents before that!). I bet he did error checking wrong on C side (just checking return value should not be enough). It'd be interesting to see same code on Go side. Obligatory quote: "considering that bad code can be written in any language, any language comparison performed using examples must be judged by the quality of the examples in each language. it can't be all that hard to write a bad example in language A and a good example in language B, and then proclaim language B to be the winner -- this is how people compare languages all the time, so either those who read them are bad programmers in any language (or are not programmers at all) and don't know how to reject the bad examples, or they already agree with the author of the comparison that language B is better than language A. in either case, it's a waste of anything but marketing money. ... #\Erik"
- akavel 14y ago
  > Go code is obviously formatted with gofmt. Is not, he also inlined some things, e.g. this: import ("flag";"fmt") would be expanded to multiline by gofmt, as well as this: if i>0 { fmt.Print(" ") } As to other things, I can't comment now, as I don't have time to read through all of the article at the moment.
- cloudhead 14y ago
  Go is superior to C? Damn, I must have missed the memo!
- shadowmint 14y ago
  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 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."
  - luriel 14y ago
    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 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 http://go-lang.cat-v.org/quotes
anon_d 14y ago
The C code looks very nice to me. What's the problem?

gouranga 14y ago

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.

Devilboy 14y ago
The big win for go over c is the goroutines - cheap and easy multithreading built right into the language.
- gouranga 14y ago
  I agree entirely - they are great, but in all the Go I've written (which totals about 50kloc so far as a porting project), I haven't actually used them past anything I would have done with zmq in C.
  - luriel 14y ago
    Goroutines are great, but I'm not convinced they are the greatest advantage over C. Go cleans up and fixes pretty much every issue C had, and improves it in many non-obvious areas, from the syntax to the type system. And when porting an existing project I'm not surprised if goroutines would come up that often given that they probably don't have any equivalent in the original design.
- jamwt 14y ago
  zeromq or coroutine libraries like libtask (by a go author!) have greatly reduced this advantage.
  - gouranga 14y ago
    libtask looks really cool. Thanks for posting. I suppose that begs the question: if you can built it in the language, should it really be a part of the implementation?

revelation 14y ago

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.

Devilboy 14y ago
Right now there's Go compilers for Windows, Mac and Linux. I'm sure others will follow soon.
- dchest 14y ago
  + FreeBSD. Also, OpenBSD, NetBSD, and Plan 9 in the works.
  - luriel 14y ago
    OpenBSD and Plan 9 pretty much work already, even if the ports might not be as polished as FreeBSD. Also there is gccgo, which AFAIK also works on Solaris and probably elsewhere.
    - 4ad 14y ago
      Yes, it works on IRIX and RTEMS (an embedded OS), and the gc suite was also ported on Ethos. I'd also like to add that the gc compilers support ARM as well as x86 and amd64 and are very, very easy to port to new platforms.
- vonmoltke 14y ago
  There is more to platforms than operating systems. I worked on an application that had to function on 8 different hardware architectures[0], though on all but one we ran Linux. We also had code that was bare metal (no OS) running on FPGAs and DSPs. Go is a long way from supporting that. This is not to say Go will not get there eventually, if the language gains popularity. Someone had to write or modify a compiler to target all those architectures for C, after all. This is just a reaction to what I see as assumptions tying operating systems to certain hardware architectures (in this and other discussions). Go can be used on a range of operating systems on two hardware architectures. Very good progress, but the language needs to get that second number up before we can seriously talk about it replacing C. [0] Only had to perform well on two, fortunately.

millerfung 14y ago

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.

luriel 14y ago
Go is relatively beginner friendly, is simpler and smaller than most languages around (even for example Python). Go code is concise but without dark magic (is easy to see what code does by just looking at it). And you can even read the whole language spec fairly easily.
- kibwen 14y ago
  > smaller than most languages around I'm not certain that this is specific to Go, insamuch as it's a property of nearly all young languages. After 1.0, language complexity can only ever increase. Even Python has followed this trajectory, although Python should perhaps be commended for being willing to shed some of its complexity along the way (depending on how you view backwards-incompatible changes, some would say it should be denounced rather than commended).
EliRivers 14y ago
"any new language today should be all beginner friendly" I disagree. I think any new language should be designed to best meet the kind of problem it's being created to deal with. Making it "beginner friendly" (whatever that means - I bet there are lots of different interpretations) is a nice extra, but should not come at the expense of solving the problems.
- millerfung 14y ago
  Yes I agree that new language should be developed because of the ever rapidly changing digital world to enhance everyones experience in digital products. I am sure it is going to get more complicated, however, being a beginner friendly language should still be taken into account. In fact, only the one who is more beginner friendly will survive in the long run because in the future there might be a mismatch of demand and supply of coders. Living in this moment of our planet is exciting because of the experience we have having digital products around us everyday, and there are/will be lots of teenagers who wants to get involve as well. In my opinion, coders are like "workers" in manufacturing companies in the future.

tubbo 14y ago

I mean, the only other living inventor of C is working on Go...

anacrolix 14y ago
We really need to hear from him.

copx 14y ago

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 requirements? Also, the author's portrayal of C is misleading. If you have 'naked' malloc() calls all over your code you are doing something wrong. Much C code never calls malloc() or follows the "no allocation after initialization" principle. If you write C like Python you will run into problems. In C you do not wildly allocate objects on the heap all across the program. E.g. in my current program almost everything comes out of memory pools. E.g. Object* object = ObjectNew(); ..and if I forgot to release it I would know quickly because any "memory leak" would cause the (pre-allocated, fixed size) memory pool to run out of free slots. In C you should manage memory in a systematic fashion. I think the C standard library should be seen as the very foundation of a program, something you use to build the abstractions which solve the problem, not something you use directly to solve the problem. People often warn about the dangers of strcpy() (an the author uses it). I never use it except at the lowest levels. At the high level robust C code looks more like this: ObjectSetName(object, newName); than this strcpy(object->name, newName); ..the difference is that ObjectSetName() can internally guard against overflow and that the concrete details of the object data structure remain hidden and thus later code changes are easier. It is a very common C idiom to use incomplete types and such functions to achieve a very high level of encapsulation.

luriel 14y ago
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 behaviour (even the definition of 'real-time' has issues, most things people call 'real-time' aren't).
- nux6 14y ago

fingerprinter 14y ago

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.

donnyg107 14y ago
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.
jbooth 14y ago
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.
- Locke1689 14y ago
  Calling Go's panic/recover system a proper exception mechanism is quite a stretch.
  - sirclueless 14y ago
    I think he is referring more to go's "defer" functionality and out-of-band error return values more than panic/recover.
    - Locke1689 14y ago
      All of these things are just really poor exception mechanisms, in my opinion. It really looks like no one with an up-to-date PLT background was consulted in the design. I agree 100% with Andreas Rossberg (who now, somewhat ironically, works at Google): It is ironic that their motivation is to tame and restrict the use of exceptions, and then they replace them by something even richer and much less structured. I fail to see any pros of this proposal. It seems mostly equivalent to exceptions, i.e., you can easily express raise/try/finally as syntactic sugar, and likely the other way round. But it is (1) much more ad-hoc -- you cannot give a simple reduction semantics for this, (2) much less orthogonal -- tying `defer' in with function definitions, (3) dependent on mutation -- for recovering and returning alternative results, and implicitly in the semantics of `defer'. One consequence is the loss of beta-convertibility, which means that you as a programmer cannot take an arbitrary piece of code and turn it into a function anymore, or vice versa, eliminate a function by inlining its body. Such abstractions/refactorings are impossible in general under this proposal, or at least require transforming the relevant code in potentially non-trivial ways.

delinka 14y ago

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.

shadowmint 14y ago
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...
- jkn 14y ago
  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 <proc/readproc.h> 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.
- luriel 14y ago
  > It's a royal pain writing go that talks to C code, compared to say, lua or python This is plain wrong, you can pretty much call C code directly, while in Python and the like you really have to write a wrapper. Of course in Go you will write a wrapper anyway to give the library a more Go-like API, but I don't see how this could be any worse than in any other language. > there just _isnt_ a way to make other languages pickup go libraries and run the symbols from them afaik... To get non-Go code to call Go code is trickier (also Go really wants to run your main()), but can be done, and there are even libraries to write Python extensions in Go, see: http://gopy.qur.me/extensions/ http://gopy.qur.me/extensions/

deleted 14y ago

[deleted]

papsosouid 14y ago

Go is the best worst language I've used. Most of what I do fits pretty much right in the sweet spot for go, network services and web development. Stuff I would have previously used C and (insert scripting language here) for respectively. Go fits into both of those areas really nicely, and I prefer it over C and scripting language X for these tasks. But the problem is, I've already tried haskell, which also fits that same area, and is semantically a vastly better language. I just wish go had been more willing to push the envelope and at least try to be somewhat modern and useful instead of being "C with modules, but slow". On the other hand, haskell is a terrible language syntactically, and from a development environment perspective. Go is near enough to perfect in those regards. Having a fast compiler, a simple, working build system, a sane and easily enforced code format all make a huge practical difference. I wish I could use go, as it is much nicer than haskell from a usability perspective. But the language is just too primitive.

drivebyacct2 14y ago
What have you written in Go that you'd wished you'd written in Haskell?
- papsosouid 14y ago
  Everything, and the same in reverse. That's the problem. Using haskell, I wish I was using go because the downsides of haskell bother me. But when I am using go, I wish I was using haskell because the downsides of go bother me.
  - drivebyacct2 14y ago
    Ah the quest for the perfect mix of everything. I sympathize but I've generally found that there are some things that are better solved in Haskell and others in Go and have found a generally pleasant balance.
    - papsosouid 14y ago
      I see. For me I haven't found anything like that, where task X would be better in go and task Y would be better in haskell. Everything I've done was always better in haskell. It was just an annoying pain in the ass the whole time because of super slow compile times, or running out of RAM compiling, or package conflicts from cabal hating me, or .cabal files requiring spaces instead of tabs, or haskell code I want to modify being some giant mess of arbitrarily aligned with a million spaces craziness that makes cool things like "diff" useless. It just feels like rather than "haskell needs to stop being so crazy", the "go needs to gain modern features" approach is more likely to actually be possible.

drivebyacct2 14y ago

I've been using Go exclusively in my personal projects for the last 8 months now, am in love with the simplicitly and fun of writing it (and goroutines), but this is a horrid way of introducing the language. To anyone who doesn't appreciate the Go syntax style, this is an instant turn off. There is a reason there is an idiomatic style used by... every single Go project I've ever seen. Further, these examples are so trivial that one doesn't see an advantage over C and so this comment thread is like every other. Those who've written "Hello World" dismiss it as neither C nor Haskell and most others seem to be generally happy with it.

Graphon 14y ago

People suggesting that Go is a potential replacement for Python, Lua or Ruby are missing the point. IMO, Go isn't designed to compete with those existing languages for existing opportunities. The key opportunity in the future is smart devices everywhere. Embedded, connected intellgence, everywhere. Everything is a communication device. Today your phone and your car; tomorrow: Your shoes, your office, the grocery store, your refrigerator. Think of xbox Kinect-type sensors embedded into everything. Writing solid C code for all those systems will be too hard. We also definitely do not want an serendipitously-designed language (Javascript). Yes, that leaves Python Ruby and so on, which brings us full circle. Go will compete with those languages but not in the domains that are evident today. Not in web browser, and not in a new! improved! web server. It seems to me that Go is a forward-looking design, aimed to meet the challenges of the everything-connected world of tomorrow. To make tomorrow happen, we need a better C. Go is that.

heretohelp 14y ago
Go is highly inappropriate in embedded environments so your pipedream betrays a naivete to systems programming.
- xyproto 14y ago
  * You can turn off the GC. * You can compile with gccgo. * You can call assembly code from Go. What is the major hindrance from using Go in embedded environments?
- Graphon 14y ago
  Today's embedded is not tomorrow's embedded. In 10 years your sunglasses will have more compute power and memory than today's smartphone .

ralph 14y ago

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 < 2) puts("y"); else { for(int i = 1; i < argc; i++) { if (i > 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, but in doing so my attention is being distracted from the main point of the article and frankly I have a huge pile of other things to read that are potentially more rewarding.

luriel 14y ago
Yes, his code style is bizarre at best, both for C and Go. This is particularly jarring in Go when gofmt exists and is used almost universally (I think this is the first time I see non-gofmt'd code in quite a while).
JackdawX 14y ago
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 people on topic.
- swdunlop 14y ago
  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.

iamgopal 14y ago

err..sarcasm ?

kristianp 14y ago

Mods, the title should be "C to Go", Go is not spelled with all-caps.