7 ms·

Straight from Rob Pike -- http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com/2012/06/less-is-exponentia

Straight from Rob Pike -- http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com/2012/06/less-is-exponentia... Python and Ruby programmers come to Go because they don't have to surrender much expressiveness, but gain performance and get to play with concurrency. C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way. The issue, then, is that Go's success would contradict their world view. And we should have realized that from the beginning. People who are excited about C++11's new features are not going to care about a language that has so much less. Even if, in the end, it offers so much more.

mturmon 14y ago
Nice link. The separate submission and thread is here: http://news.ycombinator.com/item?id=4158865 http://news.ycombinator.com/item?id=4158865
batista 14y ago
>The issue, then, is that Go's success would contradict their world view. I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.
- qznc 14y ago
  C++ is better for abstraction, as Go does not have generics yet, and C++ is better for performance. Go is faster to compile. Maybe Go is better for concurrent programming, but this is hard to measure.
  - tptacek 14y ago
    One look at the Go standard library contradicts this. Go is perfectly adequate for abstraction.
    - kragen 14y ago
      I think you may be talking past each other. C++ or D templates allow you to express (in a crude, verbose, error-prone way) some kinds of abstractions that are not expressible in Golang or ML. Not sure about C#. There are certainly lots of abstractions you can express in Golang.
  - draven 14y ago
    Go has interfaces, which can be used to write generic code. Go performance is not on par with optimized C++ but for me it's fast enough and the performance / dev_time ratio is higher.
    - qznc 14y ago
      http://golang.org/pkg/container/list/ http://golang.org/pkg/container/list/ Casting every list element to "interface{}" is not generic.
      - luriel 14y ago
        Use slices. Really, maybe we should remove container/* completely, so we don't have to answer this stuff over and over again.
        qznc 14y ago
        Slice still restricts you to an array data structure (a continuous block of memory). How would you implement a sorted set in Go? It should be generic and type safe and efficient, please. Compare with the C++ solution.
        draven 14y ago
        I think the problem with saying that Go can be used as a C++ replacement is that the statement is too vague. The problem space in which Go is a great tool and the one in which C++ is a great solution have a big overlap. But that does not mean that you will solve a given problem in this overlapping space the same way. Both languages have a different set of trade-offs. If you need a typesafe, generic sorted set with strict efficiency needs (or things like precise control over memory layout and such) then by all means go for C++, it's been designed for that kind of constraints.
        luriel 14y ago
        > If you need a typesafe, generic sorted set with strict efficiency needs When people ask for things like this, I can't help to think that what they want is not generic at all, they want something very specific to the problem they are solving, in those cases just writing custom data structures is the way to go in any language anyway. It is the way it has been done in C for decades too.
  - jussij 14y ago
    > Go does not have generics yet, From all accounts it will never ever get generics. > and C++ is better for performance. As Go is a GC based language I would expect it will always be slower than non GC languages like c/c++. But the big question is, is it really that much slower? And the fact that it is a GC language means it is a much simpler language than C++.
    - vardump 14y ago
      > As Go is a GC based language I would expect it will always be slower than non GC languages like c/c++. Actually C malloc, free, C++ new, etc. are really slow functions. Garbage collected languages can typically 'allocate' memory with little more than top of heap pointer increment. You can implement similar memory pools with C/C++, but it's hard to get right when large allocations are made, compacting is very hard, etc. It does work for limited applications, for example ones that have a lot of short-lived small objects. Multi-threaded garbage collected languages also don't need locking for freeing objects. With manual memory management you might need to lock the parent object before freeing the child to prevent some other thread from loading a pointer to the free'd child object. Locks are slow, even atomic primitives require slow inter-CPU communication. Garbage collection can avoid that completely. Performance win for gc can be hundreds of percents with 16+ CPUs.
    - heretohelp 14y ago
      >But the big question is, is it really that much slower? So, there's a pretty good shibboleth/knowledge smell you can use to detect whether somebody's done systems programming and knows what they're talking about or not. Whether they think relying completely on the heap is a "small" cost or not. Try writing some code in a real-time constrained environment where non-determinism is unacceptable. See how far malloc and Boehm gets you.
- raverbashing 14y ago
  I think there's a bit of truth in both And you can't use go outside of the "PC" (that is, embedded systems).
  - davidw 14y ago
    > And you can't use go outside of the "PC" (that is, embedded systems). Why not? It runs on Arm.
    - raverbashing 14y ago
      PPC, MIPS, SH? But the issue is twofold, you need a specialized GC for systems with memory limitations (and/or some realtime requirements)
      - davidw 14y ago
        I suppose it depends on just how "embedded" what you're dealing with is. Clearly, something like Go is bigger and slower than C, so there will be places where it's not useful. I could certainly see it being useful elsewhere though.
      - luriel 14y ago
        I think GCCGO should work for PPC and MIPS, not sure about SH, but is worth a try.
    - shin_lao 14y ago
      You need a deterministic memory management.
      - ori_b 14y ago
        For what? Android does fine without it, if you still consider that embedded. Java is used in a wide variety of embedded systems without trouble. Sure, there are some places that can't use Go. But there are also places that cant use dynamically allocated memory or recursion. Not all embedded systems are safety critical or need to be absolutely deterministic.
- jlouis 14y ago
  Actually, If you have invested the 15+ years it takes to become a decent C++ programmer, then you won't want to throw that out just because some new language comes by. Most of what happens in C++ is low level maintenance of data. There are certain programs where this is important, but for the largest chunk of programs, low level maintenance provides more buggy programs with considerably worse performance. And this is the real crux of the problem. For some C++ programmers they wont or simply can't give up the low level ability to mangle data. I have a hunch though that certain lacking constructs, generics come to mind, are used as excuses for not even wanting to take a decent look at the language. I have a feeling that sometimes it ends up being a religious tirade because "then I can't do my own containers". But you really shouldn't. Most dynamically typed languages do not really need a generic-primitive. Does that make them unsuitable for programming? Hardly. In Go you just have to work around the problem.
  - radiosnob 14y ago
    If you're a programmer/developer/hacker, you don't "throw out" what you already know. Wouldn't learning a new language expand your toolset? Not replace it. And I think most here agree that Go and C++ are solving different problem spaces. So knowing both would be a win.
  - stonemetal 14y ago
    If you have invested the 15+ years it takes to become a decent C++ programmer I have been programming in C++ for the past 14 years. Other than fast compile times, and a little less work to wire up interfaces, what exactly I am I supposed to be drooling over Go for? Between RAII and other modern C++ practices I don't really feel the need for a garbage collector. I already have a library that gives me Channel like functionality. I am sure if I really wanted green threads I could find an implementation that was similar to goroutines. Basically when I get excited about new programming languages it is about languages different enough from C++ that they actually have a shot at being better, Clojure, Scala, and Haskell come to mind. A language that doesn't affect the way you think about programming, is not worth knowing. Edit: I am fully aware that I may be blind. I do plan on exploring Go at some point, but exploring other more exotic languages take priority for me.
- tptacek 14y ago
  If you read this whole subthread, what you basically get is a confirmation of what Rob Pike wrote in his post: a series of objections revolving around things Go doesn't have that C++ does have. Pike's point is that these objections were in hindsight inevitable, because the whole idea behind Go is to simplify the language --- Go is even simpler than ANSI C. The Go team's idea was, look at languages like C++ and replace groups of individual features with orthogonal components that can be composed to similar effect. Pike is a little dismissive of C++, as am I, but ultimately he acknowledges the truth of the matter: if you're dead set on writing programs using template generics and inheritance hierarchies, you're going to stick with C++. And that's OK. We don't need to argue about it. I am very new to Go, have a background in C/C++, am Ruby today, and was Python from '02-'05. My take is that there are definitely still things I would write in C, and I would still write web frontend code in Ruby. But I see a place for Go (backend network code, network clients, things like that) and I personally see no place at all for C++ (but then, the C++ people might not see any place at all for C). Go doesn't have to be all things to all people.
  - batista 14y ago
    >I personally see no place at all for C++ Application programming in the scale of Photoshop, Word, etc. Video games. All kinds of multimedia apps and video/music editing apps. C is too low level for those kinds of things, and Go too high level. Plus it's not just the language, that's a mistake: it's the whole ecosystem that matters. E.g you're gonna find more experienced C++ programmers to make you the next, say, Call of Duty or Logic Pro 9, than you're gonna find Go programmers. And far more code and libs to leverage.
    - tptacek 14y ago
      It's true: C++ is probably going to own AAA games for a long time, and, for desktop applications, you're going to tend to use the "golden path" dev environment for each platform (ie, ObjC for Mac apps, C++/Managed C++ for $50 Windows desktop apps. Right now, I'm not sure I know of a desktop app environment where Go fits on the golden path. And, I'll restate: from the 1000-or-so lines of Go I've written so far, I'm pretty clear that I wouldn't want to use it for frontend web stuff (anything with serverside templates). But I'd probably use it before I would use Node.js for a backend web service, or maybe even for a single-page app.
- slurgfest 14y ago
  I disagree that the sweet spot of Go is in the same place as the sweet spot of Python. Go has put significantly less emphasis on transparently readable code. Viewed from C++, Go looks like Python, but viewed from Python Go looks like a less crazy Java. Fast compilation (merely being-interpreted) is surely a very cool feature which makes Go more appealing, but that is not the only productivity feature of Python.
tjoff 14y ago
I have such a hard time believing how anyone could have believed that C/C++ programmers would switch to a GC-only language just like that. I just can't see Go as an alternative to C or C++, and I'm quite surprised that anyone (especially someone such as Rob Pike) could. Sure there are situations where a program that typically would have been written in C/C++ could benefit from Go (so there is a place for it), but the reasons for choosing C/C++ are often the same that makes Go a really bad fit. My dreams of a C-like language where the dangerous parts have been removed (and in this context I don't consider having control of your memory dangerous) took a hit with the introduction of Go :(
- eckyptang 14y ago
  I think C/C++ programmers have had their reign long enough and have shown us through the amount of utterly horrible security issues that managing memory yourself is a bad idea. Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS. I controversially consider there to be no other use for C bsaed languages these days other than at the kernel level. It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do. Due to my engineering background, I would always sacrifice performance for less risk and more reliability. I've also spent 20 years writing C and C++ so I know how horrible it is.
  - tjoff 14y ago
    Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS. The anything-but-the-OS-niche? I thought we had plenty of languages for that. It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do. You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and don't do low-level work, why have you been using C/C++? Or if you have been doing low level or performance critical work, why wouldn't you want a safer alternative for that? When you have to tune and debug your application to please the garbage collector having to deal with your own memory seems like child's play. It is much easier and safer to verify that your own memory management won't bite you than it is to be sure that your garbage collector won't eat you. (surely that depends on the context etc. but making broad claims seems to be on topic...) Right tool for the right job. C/C++ has "monopoly" on a lot of use cases (way more than any other language) and considering its issues I truly believe that a "better C/C++" is needed, way more than those 20 JVM-based languages that popup every other month. Or Go.

mturmon 14y ago

Nice link. The separate submission and thread is here: http://news.ycombinator.com/item?id=4158865 http://news.ycombinator.com/item?id=4158865

batista 14y ago

>The issue, then, is that Go's success would contradict their world view. I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.

qznc 14y ago
C++ is better for abstraction, as Go does not have generics yet, and C++ is better for performance. Go is faster to compile. Maybe Go is better for concurrent programming, but this is hard to measure.
- tptacek 14y ago
  One look at the Go standard library contradicts this. Go is perfectly adequate for abstraction.
  - kragen 14y ago
    I think you may be talking past each other. C++ or D templates allow you to express (in a crude, verbose, error-prone way) some kinds of abstractions that are not expressible in Golang or ML. Not sure about C#. There are certainly lots of abstractions you can express in Golang.
- draven 14y ago
  Go has interfaces, which can be used to write generic code. Go performance is not on par with optimized C++ but for me it's fast enough and the performance / dev_time ratio is higher.
  - qznc 14y ago
    http://golang.org/pkg/container/list/ http://golang.org/pkg/container/list/ Casting every list element to "interface{}" is not generic.
    - luriel 14y ago
      Use slices. Really, maybe we should remove container/* completely, so we don't have to answer this stuff over and over again.
      - qznc 14y ago
        Slice still restricts you to an array data structure (a continuous block of memory). How would you implement a sorted set in Go? It should be generic and type safe and efficient, please. Compare with the C++ solution.
        draven 14y ago
        I think the problem with saying that Go can be used as a C++ replacement is that the statement is too vague. The problem space in which Go is a great tool and the one in which C++ is a great solution have a big overlap. But that does not mean that you will solve a given problem in this overlapping space the same way. Both languages have a different set of trade-offs. If you need a typesafe, generic sorted set with strict efficiency needs (or things like precise control over memory layout and such) then by all means go for C++, it's been designed for that kind of constraints.
        luriel 14y ago
        > If you need a typesafe, generic sorted set with strict efficiency needs When people ask for things like this, I can't help to think that what they want is not generic at all, they want something very specific to the problem they are solving, in those cases just writing custom data structures is the way to go in any language anyway. It is the way it has been done in C for decades too.
- jussij 14y ago
  > Go does not have generics yet, From all accounts it will never ever get generics. > and C++ is better for performance. As Go is a GC based language I would expect it will always be slower than non GC languages like c/c++. But the big question is, is it really that much slower? And the fact that it is a GC language means it is a much simpler language than C++.
  - vardump 14y ago
    > As Go is a GC based language I would expect it will always be slower than non GC languages like c/c++. Actually C malloc, free, C++ new, etc. are really slow functions. Garbage collected languages can typically 'allocate' memory with little more than top of heap pointer increment. You can implement similar memory pools with C/C++, but it's hard to get right when large allocations are made, compacting is very hard, etc. It does work for limited applications, for example ones that have a lot of short-lived small objects. Multi-threaded garbage collected languages also don't need locking for freeing objects. With manual memory management you might need to lock the parent object before freeing the child to prevent some other thread from loading a pointer to the free'd child object. Locks are slow, even atomic primitives require slow inter-CPU communication. Garbage collection can avoid that completely. Performance win for gc can be hundreds of percents with 16+ CPUs.
  - heretohelp 14y ago
    >But the big question is, is it really that much slower? So, there's a pretty good shibboleth/knowledge smell you can use to detect whether somebody's done systems programming and knows what they're talking about or not. Whether they think relying completely on the heap is a "small" cost or not. Try writing some code in a real-time constrained environment where non-determinism is unacceptable. See how far malloc and Boehm gets you.
raverbashing 14y ago
I think there's a bit of truth in both And you can't use go outside of the "PC" (that is, embedded systems).
- davidw 14y ago
  > And you can't use go outside of the "PC" (that is, embedded systems). Why not? It runs on Arm.
  - raverbashing 14y ago
    PPC, MIPS, SH? But the issue is twofold, you need a specialized GC for systems with memory limitations (and/or some realtime requirements)
    - davidw 14y ago
      I suppose it depends on just how "embedded" what you're dealing with is. Clearly, something like Go is bigger and slower than C, so there will be places where it's not useful. I could certainly see it being useful elsewhere though.
    - luriel 14y ago
      I think GCCGO should work for PPC and MIPS, not sure about SH, but is worth a try.
  - shin_lao 14y ago
    You need a deterministic memory management.
    - ori_b 14y ago
      For what? Android does fine without it, if you still consider that embedded. Java is used in a wide variety of embedded systems without trouble. Sure, there are some places that can't use Go. But there are also places that cant use dynamically allocated memory or recursion. Not all embedded systems are safety critical or need to be absolutely deterministic.
jlouis 14y ago
Actually, If you have invested the 15+ years it takes to become a decent C++ programmer, then you won't want to throw that out just because some new language comes by. Most of what happens in C++ is low level maintenance of data. There are certain programs where this is important, but for the largest chunk of programs, low level maintenance provides more buggy programs with considerably worse performance. And this is the real crux of the problem. For some C++ programmers they wont or simply can't give up the low level ability to mangle data. I have a hunch though that certain lacking constructs, generics come to mind, are used as excuses for not even wanting to take a decent look at the language. I have a feeling that sometimes it ends up being a religious tirade because "then I can't do my own containers". But you really shouldn't. Most dynamically typed languages do not really need a generic-primitive. Does that make them unsuitable for programming? Hardly. In Go you just have to work around the problem.
- radiosnob 14y ago
  If you're a programmer/developer/hacker, you don't "throw out" what you already know. Wouldn't learning a new language expand your toolset? Not replace it. And I think most here agree that Go and C++ are solving different problem spaces. So knowing both would be a win.
- stonemetal 14y ago
  If you have invested the 15+ years it takes to become a decent C++ programmer I have been programming in C++ for the past 14 years. Other than fast compile times, and a little less work to wire up interfaces, what exactly I am I supposed to be drooling over Go for? Between RAII and other modern C++ practices I don't really feel the need for a garbage collector. I already have a library that gives me Channel like functionality. I am sure if I really wanted green threads I could find an implementation that was similar to goroutines. Basically when I get excited about new programming languages it is about languages different enough from C++ that they actually have a shot at being better, Clojure, Scala, and Haskell come to mind. A language that doesn't affect the way you think about programming, is not worth knowing. Edit: I am fully aware that I may be blind. I do plan on exploring Go at some point, but exploring other more exotic languages take priority for me.
tptacek 14y ago
If you read this whole subthread, what you basically get is a confirmation of what Rob Pike wrote in his post: a series of objections revolving around things Go doesn't have that C++ does have. Pike's point is that these objections were in hindsight inevitable, because the whole idea behind Go is to simplify the language --- Go is even simpler than ANSI C. The Go team's idea was, look at languages like C++ and replace groups of individual features with orthogonal components that can be composed to similar effect. Pike is a little dismissive of C++, as am I, but ultimately he acknowledges the truth of the matter: if you're dead set on writing programs using template generics and inheritance hierarchies, you're going to stick with C++. And that's OK. We don't need to argue about it. I am very new to Go, have a background in C/C++, am Ruby today, and was Python from '02-'05. My take is that there are definitely still things I would write in C, and I would still write web frontend code in Ruby. But I see a place for Go (backend network code, network clients, things like that) and I personally see no place at all for C++ (but then, the C++ people might not see any place at all for C). Go doesn't have to be all things to all people.
- batista 14y ago
  >I personally see no place at all for C++ Application programming in the scale of Photoshop, Word, etc. Video games. All kinds of multimedia apps and video/music editing apps. C is too low level for those kinds of things, and Go too high level. Plus it's not just the language, that's a mistake: it's the whole ecosystem that matters. E.g you're gonna find more experienced C++ programmers to make you the next, say, Call of Duty or Logic Pro 9, than you're gonna find Go programmers. And far more code and libs to leverage.
  - tptacek 14y ago
    It's true: C++ is probably going to own AAA games for a long time, and, for desktop applications, you're going to tend to use the "golden path" dev environment for each platform (ie, ObjC for Mac apps, C++/Managed C++ for $50 Windows desktop apps. Right now, I'm not sure I know of a desktop app environment where Go fits on the golden path. And, I'll restate: from the 1000-or-so lines of Go I've written so far, I'm pretty clear that I wouldn't want to use it for frontend web stuff (anything with serverside templates). But I'd probably use it before I would use Node.js for a backend web service, or maybe even for a single-page app.
slurgfest 14y ago
I disagree that the sweet spot of Go is in the same place as the sweet spot of Python. Go has put significantly less emphasis on transparently readable code. Viewed from C++, Go looks like Python, but viewed from Python Go looks like a less crazy Java. Fast compilation (merely being-interpreted) is surely a very cool feature which makes Go more appealing, but that is not the only productivity feature of Python.

tjoff 14y ago

I have such a hard time believing how anyone could have believed that C/C++ programmers would switch to a GC-only language just like that. I just can't see Go as an alternative to C or C++, and I'm quite surprised that anyone (especially someone such as Rob Pike) could. Sure there are situations where a program that typically would have been written in C/C++ could benefit from Go (so there is a place for it), but the reasons for choosing C/C++ are often the same that makes Go a really bad fit. My dreams of a C-like language where the dangerous parts have been removed (and in this context I don't consider having control of your memory dangerous) took a hit with the introduction of Go :(

eckyptang 14y ago
I think C/C++ programmers have had their reign long enough and have shown us through the amount of utterly horrible security issues that managing memory yourself is a bad idea. Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS. I controversially consider there to be no other use for C bsaed languages these days other than at the kernel level. It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do. Due to my engineering background, I would always sacrifice performance for less risk and more reliability. I've also spent 20 years writing C and C++ so I know how horrible it is.
- tjoff 14y ago
  Go fits an important niche: stuff that doesn't have to play with the hardware directly, which is pretty much everything but the OS. The anything-but-the-OS-niche? I thought we had plenty of languages for that. It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do. You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and don't do low-level work, why have you been using C/C++? Or if you have been doing low level or performance critical work, why wouldn't you want a safer alternative for that? When you have to tune and debug your application to please the garbage collector having to deal with your own memory seems like child's play. It is much easier and safer to verify that your own memory management won't bite you than it is to be sure that your garbage collector won't eat you. (surely that depends on the context etc. but making broad claims seems to be on topic...) Right tool for the right job. C/C++ has "monopoly" on a lot of use cases (way more than any other language) and considering its issues I truly believe that a "better C/C++" is needed, way more than those 20 JVM-based languages that popup every other month. Or Go.