"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.
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).
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.
Java is deliberately simplistic because it prioritizes code maintainability (even by mediocre programmers), but I thought that was the same philosophy as go (e.g. limited type system). And I don't know what you're talking about wrt security.
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.
I'm not sure I would call Java simplistic.. It seems incredibly bloated to me especially in comparison to Go and other languages.
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!
I would call Java simplistic, but for a funny reason: with other languages, you can do things the straightforward way using basic constructs, or you can do things the expert way using a variety of more complex (sometimes user-defined) constructs. With Java, you have to do things the simple way. Sure, you have to define a class with a main method in it instead of just being able to print "Hello World", but there's one less way to do that in Java than in scripting languages.
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.
You're probably thinking of security issues with the browser plugin? They're... unfortunate, but don't affect the language as it's actually used. Don't write java applets, and as a user, don't install the browser plugin.
Indeed. Java in a sandbox in the browser is pretty much a failure. But there is no Go browser sandbox at all, so I'd hardly say Go is better off here. I guess you look better when you don't make the attempt at all.
Your comment really scared me when you talk about not liking strict or structured code. I maintain a lot of legacy code and one of the things that bother me the most about the C/C++ code I work on is the complete lack of organization. Because there's no strong conventions built into the language on how to organize things, people just sort of do it willy nilly. Wanting to do a serious refactor is a nightmare of grep and other crap. Java's packaging at least encourages some level of code organization and grouping of similar functionality. Could you organize things well in your C/C++ code? Of course. But it seems to not happen. That's not to say that all the Java code I've maintained has been well organized, but it's leaps and bounds better than the C/C++ stuff.
I'm not trying to suggest that /all/ code shouldn't be structured; it's all dependent on what you are writing. I have contributed to a decent sized C++ ftpd program (https://github.com/jawr/ebftpd) and it is well structured in my opinion. Go can be well structured too, it just seems to approach it in a different way. As I said before, it's horses for courses.
* 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.
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.
The build system we have now is significantly better than what was available at the time he mentioned (September 2007). IIRC back then the local machine was a significant bottleneck in dispatching work, storing intermediate build products, and running tests. If you weren't around then, send me a mail from your work address and I'll tell you about when we had to walk uphill both ways in the snow.
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.
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.
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)
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.
> "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.
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#.
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.
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 ).
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.
The fact that Unity uses C# as one of it's scripting engines doesn't mean that C# is taking over the game world (I'll assume that's where the C# reference is from - since Unity is incredibly popular for iOS devs). The vast majority of games are still C++, often scripted in Lua, Python, Javascript and C#.
I wouldn't describe Unity's relationship with C# as 'scripting'.
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...
> "C# is taking over the game world. Most iOS games are, for instance, written in C# these days."
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.
Most iOS games aren't C# now a days. Unity likes to trot out the 70% number for mobile games but it's mostly bs. That isn't counting games that are actually published that based on there registered numbers, a lot of of never actually make it into the store. I'm willing to bet the most of iOS games are still Obj-C
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.
Memory management is extremely important for high-performance code. And C/C++ allow you complete control over it, but obviously with extra work needed to do this. But when you need the speed, it's so worth it, it's not funny.
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.
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.
> 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.
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).
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.
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.