7 ms·

"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

by krosaen 13y ago

"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." This, "they can't handle how awesome it is" is kind of a fun rationale and strikes me as plausible, but it would be more interesting to me to hear from some of the stellar c++ programmers at google as to why they aren't interested in switching. C++ was the first language I really invested in mastering during and after college - it was like, "all I need to do is read these 5 books about how to avoid the pitfalls and use all the powerful tools, and it's amazing!" What really changed my mind was trying other languages (first python) and seeing how immediately productive I could be without so much as skimming through the "dive into python" website. So specifically, I'd be interested in hearing something from an expert C++ programmer who has really given go a try and decided it's not their cup of tea.

fein 13y ago
> C++ was the first language I really invested in mastering during and after college This is partially why you picked up Python so easily. It's one thing to approach a language like Python as your first, but if you took the dive and learned c/c++ prior, everything else is going to be much easier to grok.
- krosaen 13y ago
  Yeah good point, impossible to forget what it's like not to know something. I also haven't done systems programming in a long time - so it would really be more fair to have someone comment who is considering a language under higher performance constraints. That said, I can report on what I prefer right now, knowing what I already know (having spent 4 years programming java professionally as well) - and I truly prefer a more functional approach that comes a lot more easily in languages that support closures and first class functions. It also strikes me that many of the best practices in java / c++ are basically moving towards more functional programming (prefer composition to inheritance, make objects immutable by default, interfaces over classes when possible, dependency injection / referential transparency and parameterizing methods by interfaces e.g functions).
H3g3m0n 13y ago
I'm not an expert but in the gamedev domain, control over memory is fairly vital. It seems like it would be for lots of the other stuff C++ is used with too. In C++ I can allocate all my memory upfront in a pool since I know the exact size of my level, the number of objects and so on. Then use custom allocators/static for just about everything. When I make an object at runtime I can just snag preallocated space from the pool. With the ability to cast the pool's primitive data types to pointers I can even save on any need to index the blocks since I can use the unused memory to point to the next block of unused memory (although it's probably a minor optimization). Go drops that control totally in favour of it's inbuilt garbage collector which the Go devs think they can just get right. That seems unlikely (the current implementation is apparently quite bad stop-the-world implementation). Another issue that strikes me is library building. Afaik Go doesn't produce object that can be linked against by non-go stuff. C does this, it has a ABI. This means I can write one library in C/C++ (and apparently Rust) and then have wrappers for just about every other programming language in existence. (Although C++ can make this painful with things like exceptions http://250bpm.com/blog:4 http://250bpm.com/blog:4 ). It might be that Go's interfaces make it really useful for making Go libraries in, but some libraries need to be language agnostic as much as possible. Many of the things Go initially solved over C++ are being chipped away too. I love reflection, it would be very useful for games, serialization and so on. C++ doesn't have it but there is a standards working group looking at it now, so we could see it in either C++14 in a year, or C++17 (probably with implementations before then). C++11 got threads and so on and there is a working group doing transactional memory, more threading stuff, networking and so on. So we could see something like Gorutines and Channels but still have access to low level things like raw memory barriers. C++ tooling is set to explode with what the clang people are up to. Go seems great, but it does seem focused in the 'business' kind of domain. Maybe future versions could address some of the issues like the GC (either fixing it so it does meet the performance requirements, or allowing custom memory options, C# has the unsafe keyword for example). EDIT: I note that Go might provide a package "unsafe" that could allow for some things like a custom GC but apparently would be hard to implement.
- sambeau 13y ago
  >in the gamedev domain, control over memory is fairly vital. C# is taking over the game world. Most iOS games are, for instance, written in C# these days. I have worked for a company who wrote a state-of-the-art 3D PC gaming engine in C#. Being garbage collected doesn't remove the ability to manage memory. It just removes the need to call Malloc directly.
smosher 13y ago
I don't think it takes a C++ expert to point out that the more plausible explanation is simply that Rob Pike is a narcissist. This is the same guy who said you don't need to know what I know (re: endianness) because you will never write a compiler. Consummate narcissism.
- ionforce 13y ago
  Isn't that elitism? Narcissism: I am the most beautiful of all. Elitism: I am more beautiful than you.
  - seertaak 13y ago
    Isn't that pedantry? ;)
- alecbenzer 13y ago
  Someone I know at google said he was once talking to Rob Pike about go and asking questions about some of the design decisions. After answering a few questions, Pike looked at him and said "Do you know who I am?". (supposedly)
  - WalterBright 13y ago
    I once questioned the design decisions for a particular project of the guy who made them, and his response was "who the do you think you are?"
  - swah 13y ago
    "Say my name".
- bjz_ 13y ago
  No need for personal attacks.
  - smosher 13y ago
    You're right, and my point wasn't to attack his character but to explain the nonsense coming out of his mouth. There is a clear and simple explanation, consistent with his history, that is (perhaps unfortunately) not flattering. However, he has a history of being insulting towards people who want to use different paradigms. So if you're going to bring that line up with anyone, bring it up with Rob Pike himself.
danieldk 13y ago
So specifically, I'd be interested in hearing something from an expert C++ programmer I don't know what qualifies as an expert, but as someone who is using C++ and Java (and did look at Go): - If I want a garbage collected language that is reasonably fast and safe, I prefer Java over Go, since there are many high-quality libraries available, there are good IDEs, it's easy to instrument the JVM (heck, I can even debug a remote application running in Tomcat in my IDE), and has a good central repository and package manger (JVM). Go is hardly more expressive than Java, so if I am looking for a replacement, it will probably be Kotlin or Scala. - There are applications where I want manual memory management, auto-vectorization, real generics (templates), etc. Go has none of these features. In other words: Go does not offer me any advantages over Java or C++. At the same time, moving from Java to Go would require me to sacrifice a lot of well-developed and reliable tools and libraries. I know that someone is going to mention Goroutines and channels. There are great concurrency options for Java as well, e.g. Akka, which implements actors, futures, a scheduler, remoting, and clustering. In comparison Go's concurrency offering is quite pale. Sure, you could implement something like Akka on top of Go, but it currently does not exist (except for a binding against Erlang's C node functionality).
- jawr 13y ago
  The problem that I find with Java is that it forces you to write code in a certain way; OO programming seems to have become the de facto way of dealing with large problems, especially in enterprise and sometimes I think far too much time is given to design patterns (that do work in a /lot/ of cases) and how they can be shoe horned into the program you are making. Java does have some amazing features, libraries, etc. It also has a lot of security flaws (afaik). Also, IDE's really do not interest me in the slightest. Writing in Go isn't as strict or structured as Java which I really enjoy. I used to write a lot of C++ and although I was never a pro, I did really used to enjoy programming in it. Go is certainly a breath of fresh air to develop in in comparison and I find that I can write more concisely and if anything performance seems to improve as I am not making trivial mistakes that "powerful" languages like C++ allow me to repeatedly make. KISS. As always, it's horses for courses.
  - lmm 13y ago
ansible 13y ago
I am an adequate C programmer, and with some care, I can turn out code that seems to be reliable. I am not an C++ expert, but at one time I did want to obtain mastery over it as well. I ran into problems. There was some recent discussion about the "Edward C++ Hands" article. [1] And that discussion summarizes neatly the issues I have with C++. Yes, I get that it is a powerful multi-paradigm language. Yes, I get that it will take time to master. But should this language (or any language; I'm looking at you Javascript) have so many hotly-debated dark corners and pitfalls? It is an enormous undertaking to just figure out what the best practices are. And it is then a further enormous undertaking to get the rest of your team on-board. [1] https://news.ycombinator.com/item?id=6414162 https://news.ycombinator.com/item?id=6414162
pmelendez 13y ago
> "I'd be interested in hearing something from an expert C++ programmer who has really given go a try and decided it's not their cup of tea." I am not a C++ expert but I have programmed a fairly amount of C++ code so I will give you my two cents. I use C++ because a blend of three things: * Performance, * Abstraction and * Portability. If I would care just in a subset of that tuple I probably will code in something else. For instance, if for some project performance is not an issue, I will probably use a higher level language like Python or Scheme. If I am feeling that Abstraction is not as important as performance and portability I will use C. When I care about the three of them I feel there are not too many options.
- lmm 13y ago
  It seems likely that a compiled functional language like OCaml or Haskell would do better overall - maybe a slight sacrifice in performance, but much more abstraction available, and greater portability since more of the library is standardized.
  - CmonDev 13y ago
    Not to mention benefits of being strongly-typed.
- mattnewport 13y ago
  I agree, in the games industry we use C++ for a few reasons: * Performance * Portability * Direct API access (D3D, OpenGL, console specific APIs) * Large legacy codebases * Control over memory management Go doesn't really address all these areas adequately at the moment from what I've seen. For me personally, for those problem domains where the above are not a concern I find other languages more compelling than Go - Haskell, F#, even C#.
scottlamb 13y ago
I program in C++ at Google. I won't make claims about "stellar". Here are a few Google-specific reasons Go hasn't replaced C++ for me: * The long C++ build times he was complaining about are mostly gone due to distributed builds. http://google-engtools.blogspot.com/2011/09/build-in-cloud-distributing-build-steps.html http://google-engtools.blogspot.com/2011/09/build-in-cloud-d... Throwing resources at the problem isn't ideal, but it does work. * Google has a lot of C++ library code, including client libraries for things like Bigtable. Go's Google-specific libraries are a work in progress. * For serving systems, I care more about machine efficiency and latency for than about development time. I'm still skeptical of those properties in Go. Obviously the compiler (and my comfort with it) will improve over time. So will the garbage collector, to a point. It will always operate on one large heap like Java's. People say Java's GC works fine, but they spend a lot of time tuning it and then quote pause times that don't thrill me. I've seen a lot of problems caused by bad tuning parameters, like (for example) Java heap sizes that exceed the size of the container it's running in. And relatively hard-to-diagnose and slow-to-recover GC death spirals because the defaults suck: Java just bogs down in situations where a C++ binary would dump a heap sample, crash, and get restarted. So I'd be more comfortable with a system like Rust's: many smaller heaps, language enforcement of ownership rules when transferring between its equivalent of goroutines. Now for internal tools, where speed of development is more important, I wish I could magically switch everything over to Go instantly. Some of that stuff is in Python. Python's fragile in an always-refactored large codebase without 100% unit test coverage. The library situation is worse than Go's (few Python-specific libraries, and I hate SWIG). And while performance is less important for internal tools, Python's horrible single-threaded performance and GIL are a real pain. And finally, using Go for internal tools might eventually give me the comfort I need to start using it for more serving systems.
- dekhn 13y ago
  Regarding the post and your reply: Rob's post was posted after the "distributed builds" blog post and it specifically says he was using distributed builds. I'm a Google C++/Python programmer who has (mostly) switched to Go for new development. Rob's statements about C++/go compilation performance are still relatively correct. The client libraries are sufficient for many, but not all projects. I think what most people don't appreciate is how cleverly the Go team at Google established a reasonable migration path for internal developers. Some systems have migrated far more quickly. hopefully, we'll see some papers describing the migration at some point.
deleted 13y ago
[deleted]
kjackson2012 13y ago
I've been programming in C/C++ for 15+ years and I enjoy it. Personally I think the C++11 extensions are not useful and could bloat/kill the language. It feels like they are trying to make it a scripting language, which isn't why people use C++. However, I recently started using Python and I absolutely love it. Using python, I can usually whip up a proof of concept within minutes because things just work. I wrote a OCR program using a mix of OpenCV and Tesseract in Python, and I was able to get a proof of concept up in about an hour. Of course, the performance isn't nearly what I want it to be (on the order of seconds, which is too slow for my application), but the fact I could get something working so quickly is why I love Python so much.

by krosaen 13y ago

fein 13y ago

> C++ was the first language I really invested in mastering during and after college This is partially why you picked up Python so easily. It's one thing to approach a language like Python as your first, but if you took the dive and learned c/c++ prior, everything else is going to be much easier to grok.

krosaen 13y ago
Yeah good point, impossible to forget what it's like not to know something. I also haven't done systems programming in a long time - so it would really be more fair to have someone comment who is considering a language under higher performance constraints. That said, I can report on what I prefer right now, knowing what I already know (having spent 4 years programming java professionally as well) - and I truly prefer a more functional approach that comes a lot more easily in languages that support closures and first class functions. It also strikes me that many of the best practices in java / c++ are basically moving towards more functional programming (prefer composition to inheritance, make objects immutable by default, interfaces over classes when possible, dependency injection / referential transparency and parameterizing methods by interfaces e.g functions).

H3g3m0n 13y ago

I'm not an expert but in the gamedev domain, control over memory is fairly vital. It seems like it would be for lots of the other stuff C++ is used with too. In C++ I can allocate all my memory upfront in a pool since I know the exact size of my level, the number of objects and so on. Then use custom allocators/static for just about everything. When I make an object at runtime I can just snag preallocated space from the pool. With the ability to cast the pool's primitive data types to pointers I can even save on any need to index the blocks since I can use the unused memory to point to the next block of unused memory (although it's probably a minor optimization). Go drops that control totally in favour of it's inbuilt garbage collector which the Go devs think they can just get right. That seems unlikely (the current implementation is apparently quite bad stop-the-world implementation). Another issue that strikes me is library building. Afaik Go doesn't produce object that can be linked against by non-go stuff. C does this, it has a ABI. This means I can write one library in C/C++ (and apparently Rust) and then have wrappers for just about every other programming language in existence. (Although C++ can make this painful with things like exceptions http://250bpm.com/blog:4 http://250bpm.com/blog:4 ). It might be that Go's interfaces make it really useful for making Go libraries in, but some libraries need to be language agnostic as much as possible. Many of the things Go initially solved over C++ are being chipped away too. I love reflection, it would be very useful for games, serialization and so on. C++ doesn't have it but there is a standards working group looking at it now, so we could see it in either C++14 in a year, or C++17 (probably with implementations before then). C++11 got threads and so on and there is a working group doing transactional memory, more threading stuff, networking and so on. So we could see something like Gorutines and Channels but still have access to low level things like raw memory barriers. C++ tooling is set to explode with what the clang people are up to. Go seems great, but it does seem focused in the 'business' kind of domain. Maybe future versions could address some of the issues like the GC (either fixing it so it does meet the performance requirements, or allowing custom memory options, C# has the unsafe keyword for example). EDIT: I note that Go might provide a package "unsafe" that could allow for some things like a custom GC but apparently would be hard to implement.

sambeau 13y ago
>in the gamedev domain, control over memory is fairly vital. C# is taking over the game world. Most iOS games are, for instance, written in C# these days. I have worked for a company who wrote a state-of-the-art 3D PC gaming engine in C#. Being garbage collected doesn't remove the ability to manage memory. It just removes the need to call Malloc directly.

smosher 13y ago

I don't think it takes a C++ expert to point out that the more plausible explanation is simply that Rob Pike is a narcissist. This is the same guy who said you don't need to know what I know (re: endianness) because you will never write a compiler. Consummate narcissism.

ionforce 13y ago
Isn't that elitism? Narcissism: I am the most beautiful of all. Elitism: I am more beautiful than you.
- seertaak 13y ago
  Isn't that pedantry? ;)
alecbenzer 13y ago
Someone I know at google said he was once talking to Rob Pike about go and asking questions about some of the design decisions. After answering a few questions, Pike looked at him and said "Do you know who I am?". (supposedly)
- WalterBright 13y ago
  I once questioned the design decisions for a particular project of the guy who made them, and his response was "who the do you think you are?"
- swah 13y ago
  "Say my name".
bjz_ 13y ago
No need for personal attacks.
- smosher 13y ago
  You're right, and my point wasn't to attack his character but to explain the nonsense coming out of his mouth. There is a clear and simple explanation, consistent with his history, that is (perhaps unfortunately) not flattering. However, he has a history of being insulting towards people who want to use different paradigms. So if you're going to bring that line up with anyone, bring it up with Rob Pike himself.

danieldk 13y ago

So specifically, I'd be interested in hearing something from an expert C++ programmer I don't know what qualifies as an expert, but as someone who is using C++ and Java (and did look at Go): - If I want a garbage collected language that is reasonably fast and safe, I prefer Java over Go, since there are many high-quality libraries available, there are good IDEs, it's easy to instrument the JVM (heck, I can even debug a remote application running in Tomcat in my IDE), and has a good central repository and package manger (JVM). Go is hardly more expressive than Java, so if I am looking for a replacement, it will probably be Kotlin or Scala. - There are applications where I want manual memory management, auto-vectorization, real generics (templates), etc. Go has none of these features. In other words: Go does not offer me any advantages over Java or C++. At the same time, moving from Java to Go would require me to sacrifice a lot of well-developed and reliable tools and libraries. I know that someone is going to mention Goroutines and channels. There are great concurrency options for Java as well, e.g. Akka, which implements actors, futures, a scheduler, remoting, and clustering. In comparison Go's concurrency offering is quite pale. Sure, you could implement something like Akka on top of Go, but it currently does not exist (except for a binding against Erlang's C node functionality).

jawr 13y ago
The problem that I find with Java is that it forces you to write code in a certain way; OO programming seems to have become the de facto way of dealing with large problems, especially in enterprise and sometimes I think far too much time is given to design patterns (that do work in a /lot/ of cases) and how they can be shoe horned into the program you are making. Java does have some amazing features, libraries, etc. It also has a lot of security flaws (afaik). Also, IDE's really do not interest me in the slightest. Writing in Go isn't as strict or structured as Java which I really enjoy. I used to write a lot of C++ and although I was never a pro, I did really used to enjoy programming in it. Go is certainly a breath of fresh air to develop in in comparison and I find that I can write more concisely and if anything performance seems to improve as I am not making trivial mistakes that "powerful" languages like C++ allow me to repeatedly make. KISS. As always, it's horses for courses.
- lmm 13y ago

ansible 13y ago

I am an adequate C programmer, and with some care, I can turn out code that seems to be reliable. I am not an C++ expert, but at one time I did want to obtain mastery over it as well. I ran into problems. There was some recent discussion about the "Edward C++ Hands" article. [1] And that discussion summarizes neatly the issues I have with C++. Yes, I get that it is a powerful multi-paradigm language. Yes, I get that it will take time to master. But should this language (or any language; I'm looking at you Javascript) have so many hotly-debated dark corners and pitfalls? It is an enormous undertaking to just figure out what the best practices are. And it is then a further enormous undertaking to get the rest of your team on-board. [1] https://news.ycombinator.com/item?id=6414162 https://news.ycombinator.com/item?id=6414162

pmelendez 13y ago

> "I'd be interested in hearing something from an expert C++ programmer who has really given go a try and decided it's not their cup of tea." I am not a C++ expert but I have programmed a fairly amount of C++ code so I will give you my two cents. I use C++ because a blend of three things: * Performance, * Abstraction and * Portability. If I would care just in a subset of that tuple I probably will code in something else. For instance, if for some project performance is not an issue, I will probably use a higher level language like Python or Scheme. If I am feeling that Abstraction is not as important as performance and portability I will use C. When I care about the three of them I feel there are not too many options.

lmm 13y ago
It seems likely that a compiled functional language like OCaml or Haskell would do better overall - maybe a slight sacrifice in performance, but much more abstraction available, and greater portability since more of the library is standardized.
- CmonDev 13y ago
  Not to mention benefits of being strongly-typed.
mattnewport 13y ago
I agree, in the games industry we use C++ for a few reasons: * Performance * Portability * Direct API access (D3D, OpenGL, console specific APIs) * Large legacy codebases * Control over memory management Go doesn't really address all these areas adequately at the moment from what I've seen. For me personally, for those problem domains where the above are not a concern I find other languages more compelling than Go - Haskell, F#, even C#.

scottlamb 13y ago

I program in C++ at Google. I won't make claims about "stellar". Here are a few Google-specific reasons Go hasn't replaced C++ for me: * The long C++ build times he was complaining about are mostly gone due to distributed builds. http://google-engtools.blogspot.com/2011/09/build-in-cloud-distributing-build-steps.html http://google-engtools.blogspot.com/2011/09/build-in-cloud-d... Throwing resources at the problem isn't ideal, but it does work. * Google has a lot of C++ library code, including client libraries for things like Bigtable. Go's Google-specific libraries are a work in progress. * For serving systems, I care more about machine efficiency and latency for than about development time. I'm still skeptical of those properties in Go. Obviously the compiler (and my comfort with it) will improve over time. So will the garbage collector, to a point. It will always operate on one large heap like Java's. People say Java's GC works fine, but they spend a lot of time tuning it and then quote pause times that don't thrill me. I've seen a lot of problems caused by bad tuning parameters, like (for example) Java heap sizes that exceed the size of the container it's running in. And relatively hard-to-diagnose and slow-to-recover GC death spirals because the defaults suck: Java just bogs down in situations where a C++ binary would dump a heap sample, crash, and get restarted. So I'd be more comfortable with a system like Rust's: many smaller heaps, language enforcement of ownership rules when transferring between its equivalent of goroutines. Now for internal tools, where speed of development is more important, I wish I could magically switch everything over to Go instantly. Some of that stuff is in Python. Python's fragile in an always-refactored large codebase without 100% unit test coverage. The library situation is worse than Go's (few Python-specific libraries, and I hate SWIG). And while performance is less important for internal tools, Python's horrible single-threaded performance and GIL are a real pain. And finally, using Go for internal tools might eventually give me the comfort I need to start using it for more serving systems.

dekhn 13y ago
Regarding the post and your reply: Rob's post was posted after the "distributed builds" blog post and it specifically says he was using distributed builds. I'm a Google C++/Python programmer who has (mostly) switched to Go for new development. Rob's statements about C++/go compilation performance are still relatively correct. The client libraries are sufficient for many, but not all projects. I think what most people don't appreciate is how cleverly the Go team at Google established a reasonable migration path for internal developers. Some systems have migrated far more quickly. hopefully, we'll see some papers describing the migration at some point.

deleted 13y ago

[deleted]

kjackson2012 13y ago

I've been programming in C/C++ for 15+ years and I enjoy it. Personally I think the C++11 extensions are not useful and could bloat/kill the language. It feels like they are trying to make it a scripting language, which isn't why people use C++. However, I recently started using Python and I absolutely love it. Using python, I can usually whip up a proof of concept within minutes because things just work. I wrote a OCR program using a mix of OpenCV and Tesseract in Python, and I was able to get a proof of concept up in about an hour. Of course, the performance isn't nearly what I want it to be (on the order of seconds, which is too slow for my application), but the fact I could get something working so quickly is why I love Python so much.