<story><title>Less is exponentially more (2012)</title><url>http://commandcenter.blogspot.de/2012/06/less-is-exponentially-more.html</url><text>I was asked a few weeks ago, &amp;quot;What was the biggest surprise you encountered rolling out Go?&amp;quot; I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.</text></story><parent_chain><item><author>krosaen</author><text>&amp;quot;C++ programmers don&amp;#x27;t come to Go because they have fought hard to gain exquisite control of their programming domain, and don&amp;#x27;t want to surrender any of it. To them, software isn&amp;#x27;t just about getting the job done, it&amp;#x27;s about doing it a certain way.&lt;p&gt;The issue, then, is that Go&amp;#x27;s success would contradict their world view.&amp;quot;&lt;p&gt;This, &amp;quot;they can&amp;#x27;t handle how awesome it is&amp;quot; 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&amp;#x27;t interested in switching.&lt;p&gt;C++ was the first language I really invested in mastering during and after college - it was like, &amp;quot;all I need to do is read these 5 books about how to avoid the pitfalls and use all the powerful tools, and it&amp;#x27;s amazing!&amp;quot; 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 &amp;quot;dive into python&amp;quot; website. So specifically, I&amp;#x27;d be interested in hearing something from an expert C++ programmer who has really given go a try and decided it&amp;#x27;s not their cup of tea.</text></item></parent_chain><comment><author>scottlamb</author><text>I program in C++ at Google. I won&amp;#x27;t make claims about &amp;quot;stellar&amp;quot;. Here are a few Google-specific reasons Go hasn&amp;#x27;t replaced C++ for me:&lt;p&gt;* The long C++ build times he was complaining about are mostly gone due to distributed builds. &lt;a href=&quot;http://google-engtools.blogspot.com/2011/09/build-in-cloud-distributing-build-steps.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;google-engtools.blogspot.com&amp;#x2F;2011&amp;#x2F;09&amp;#x2F;build-in-cloud-d...&lt;/a&gt; Throwing resources at the problem isn&amp;#x27;t ideal, but it does work.&lt;p&gt;* Google has a lot of C++ library code, including client libraries for things like Bigtable. Go&amp;#x27;s Google-specific libraries are a work in progress.&lt;p&gt;* For serving systems, I care more about machine efficiency and latency for than about development time. I&amp;#x27;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&amp;#x27;s. People say Java&amp;#x27;s GC works fine, but they spend a lot of time tuning it and then quote pause times that don&amp;#x27;t thrill me. I&amp;#x27;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&amp;#x27;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&amp;#x27;d be more comfortable with a system like Rust&amp;#x27;s: many smaller heaps, language enforcement of ownership rules when transferring between its equivalent of goroutines.&lt;p&gt;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&amp;#x27;s fragile in an always-refactored large codebase without 100% unit test coverage. The library situation is worse than Go&amp;#x27;s (few Python-specific libraries, and I hate SWIG). And while performance is less important for internal tools, Python&amp;#x27;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.</text></comment>
<story><title>Less is exponentially more (2012)</title><url>http://commandcenter.blogspot.de/2012/06/less-is-exponentially-more.html</url><text>I was asked a few weeks ago, &amp;quot;What was the biggest surprise you encountered rolling out Go?&amp;quot; I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.</text></story><parent_chain><item><author>krosaen</author><text>&amp;quot;C++ programmers don&amp;#x27;t come to Go because they have fought hard to gain exquisite control of their programming domain, and don&amp;#x27;t want to surrender any of it. To them, software isn&amp;#x27;t just about getting the job done, it&amp;#x27;s about doing it a certain way.&lt;p&gt;The issue, then, is that Go&amp;#x27;s success would contradict their world view.&amp;quot;&lt;p&gt;This, &amp;quot;they can&amp;#x27;t handle how awesome it is&amp;quot; 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&amp;#x27;t interested in switching.&lt;p&gt;C++ was the first language I really invested in mastering during and after college - it was like, &amp;quot;all I need to do is read these 5 books about how to avoid the pitfalls and use all the powerful tools, and it&amp;#x27;s amazing!&amp;quot; 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 &amp;quot;dive into python&amp;quot; website. So specifically, I&amp;#x27;d be interested in hearing something from an expert C++ programmer who has really given go a try and decided it&amp;#x27;s not their cup of tea.</text></item></parent_chain><comment><author>H3g3m0n</author><text>I&amp;#x27;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&amp;#x2F;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&amp;#x27;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&amp;#x27;s probably a minor optimization).&lt;p&gt;Go drops that control totally in favour of it&amp;#x27;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).&lt;p&gt;Another issue that strikes me is library building. Afaik Go doesn&amp;#x27;t produce object that can be linked against by non-go stuff. C does this, it has a ABI.&lt;p&gt;This means I can write one library in C&amp;#x2F;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 &lt;a href=&quot;http://250bpm.com/blog:4&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;250bpm.com&amp;#x2F;blog:4&lt;/a&gt; ).&lt;p&gt;It might be that Go&amp;#x27;s interfaces make it really useful for making Go libraries in, but some libraries need to be language agnostic as much as possible.&lt;p&gt;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&amp;#x27;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.&lt;p&gt;Go seems great, but it does seem focused in the &amp;#x27;business&amp;#x27; 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).&lt;p&gt;EDIT: I note that Go might provide a package &amp;quot;unsafe&amp;quot; that could allow for some things like a custom GC but apparently would be hard to implement.</text></comment>