* 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-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.
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.
Now, build times are not a major loss of productivity for me. In fairness, I don't work on the same system he was working on, and presumably not the same as you either.
I started a year after that time.
My perspective is similar. I do a bit of Java, C++ and Python, and recently wrote a ~1K LOC backend in Go. I figured I'd share it in case someone finds it interesting.
For low-level infrastructure projects that don't have very complicated business logic (e.g. caching systems, gateways between different RPC systems, etc.) but which run in many machines and must handle many requests per second, I'm sticking with C++. It's sometimes painful to troubleshoot race conditions around resource destruction issues, given that I use lots of async calls and threads, but still ... I don't think I'd feel comfortable investing significant efforts building this kind of systems in Go or even Java. That said, I'm trying to gradually migrate away from callbacks spaghetti and data sharing between threads towards ... specialized threads and message passing, a model far more similar to Go's. But I prefer C++ over Go and Java because it feels more predictable and, barring bugs, seems to have a lower operational cost. I don't want to imagine things like Bigtable or Google's other storage systems written in anything other than C++.
For higher-level backends with more business logic but which still must handle many requests per second, I lean towards Java. I feel that Java brings a few headaches for the production engineers that for some reason happen less in C++, such as having to tune the GC for performance and latency. Systems in C++ feel significantly more predictable, from my production perspective. But I'm willing to lose that predictability and switch to Java for the gains for the development team. I'm not sure I would be ready to switch to Go: I perceive the state of internal libraries on Go as trailing significantly behind those in Java. I guess this may change (or my perception may even be already dated).
Finally, for internal servers with little load, I'd already pick Go over Python. I come from a strong Scheme background and originally really liked Python, a very nice subset of Scheme. However, I'm coming to find projects in Python relatively hard to maintain. :-/ I feel that when Python projects hit a certain size (when a program reaches something like ~20 non-trivial classes, with some inheritance or interfaces, something like that), it becomes hard for new comers to extend it successfully. It may be just me, but I find that the lack of a canonical way to do things like interfaces means everyone has their own adhoc way to do this and ... things just get messy, or at least more messy, faster, than they do in the other 3 Google languages. It could also be the lack of type checks at compile time, I'm not sure. But I digress, all I meant to say is that I think Go may actually make things a lot better than Python in this regard, so I'm starting to use it in this area.
You'd know more about Java's strengths than I would. I haven't really touched it since we parted teams. I just remember production pain...
I'm sure the Go library situation will improve, and we can nudge that along as we write internal tools. I'll definitely start my next one in Go. I might even translate my last one to Go sometime.
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).
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.
Have you tried a modern, expressive, strongly typed functional language like Scala or Haskell? I can well believe that go would be an improvement over Java, but Java's not exactly state of the art these days.
With regards to security issues, I was under the impression that since oracle took it over, Java has had prevalent issues that have just been ignored by Oracle. Quick search seems to agree..
I have played with Haskell and really enjoyed the language. Although imperative languages are my bread and butter it certainly gave me a different approach to programming, primarily stepping away from an OO design and love of recursion!
Haskell is a lovely language and everyone should dabble in it for a while, for that very reason: because it makes you look at programming differently.
Nor was it when it was created. It was born outdated (just like go!).
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 ).
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.
>in the gamedev domain, control over memory is fairly vital.
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.
I realise that there are no doubt a number of custom C++ engines out there with embedded scripting languages but push for multi-platform mobile games has caused an huge shift towards Unity.
Maybe I'm moving in the wrong circled here — but anecdotally all the people I know making iOS & Android games are developing in Unity.
And I don't doubt that alot of devs use Unity, it's most likely the most popular game engine. But it's still a C++ project, despite the languages used to script game events...
When the engine underneath is done in C# as well I will take that argument. So far, it would be the same that saying that most console games are done in UnrealScript.
I know many iOS game developers and none of them use Objective-C any more.
(in fact I only ever knew one)
How does it compare to Cry Engine, Unreal Engine, Frostbite, ...?
Because these are the state of the art gaming engines these days.
It was C# from the ground up. Scripting was provided via other .Net languages (Python in the case of the UI team).
[1] http://en.wikipedia.org/wiki/Command_%26_Conquer_(2013_video...
Well, for shitty games maybe it is true, shovelware aplenty on iOS anyway.
But for the part of the market that actually has a profit (not just revenue) C# is not that dominant.
In terms of profit, the most profitable games probably still rely on C++.
Also most engines (including Unity) are made in C or C++, they sorta abstract the memory management for the game author, but they still do a lot of manual fiddling themselves, XNA for example (that allow you to write C# games directly to the hardware without a C++ engine) is notorious for bigger games having memory issues.
Also 2D "retina" games use so much absurd amounts of memory, that they are almost impossible to do purely in high-level languages, you need some C or C++ somewhere to handle them, at least texture loading, otherwise you end with loading times so big that people want to suicide.
Loading times have been an issue since game consoles moved away from cartridges.
Which game's engine was in C#? Project MyWorld?
On top of this, things like bit-packing and tagged-pointer type things can allow you to save memory, allowing you to fit more stuff into cachelines more efficiently, giving even more speedups.
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.
Narcissism: I am the most beautiful of all.
Elitism: I am more beautiful than you.
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.
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.
* 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#.
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.
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.
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).
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.
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.