3 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. ..
by epi8 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.
...
The issue, then, is that Go's success would contradict their world view."
No it won't! I'm excited about Go. What I've read about it makes it look like a language I would love to work in, some day. However, I don't think the problems I'm solving now are the problems Go is good at solving. The programs I'm writing run on one machine with restricted memory, and they need to be highly, highly performant. The execution time is measured in tens of milliseconds, and during that time we do a lot mathematics and processing. SIMD is our close, beloved friend. In that context, I don't think Go is an appropriate language, due to its garbage collector, its lack of precise control over where objects go in memory, and the overhead of method calls. But if I ever write code similar to that written by Google, C++ would be a terrible choice.
I was all on board with what he was saying until that last little jab. I'm not migrating to Go because I have problems that Go doesn't set out to solve, but I'm not threatened by Go, because it's just another tool. Having more high-quality, carefully-designed tools is never a bad thing, and I can't imagine ever being threatened by a new tool's success.
Honestly, this smacks of more divisive bullshit. Pythonistas vs Rubyists, VIM vs Emacs, and now, Go vs C++. Blurgh.
- MrBuddyCasino 13y agoSo if your point is a technical one, whats the main issue for you - that you can't emit hand-tuned SIMD code (I have no idea if thats possible) or that you can't do realtime because of garbage collection? I acknowledge that the go compiler has some catching up to do to become as fast as c++.
- epi8 13y agoBoth of those are problems for me. The garbage collection is probably the larger one, though, since I'm sure one could add explicit, hand-tuned SIMD into any language (auto-vectorization, while useful in many contexts, just doesn't cut it here). The main thing is that the garbage collector is a problem in time-constrained and memory-constrained environments. I can't afford to wait to clean up my large data set until the GC decides to, and I can't afford to wait the 100ms that the GC may take. Or, more accurately, I might be able to, but I just don't know, and that lack of certainty means that a GC language is not an option for me. But that's not to say that Go suxxors! Different solutions to different problems. I'm just saying why I won't be using Go to work on the project I'm on now.
- bmohlenhoff 13y agoThis. The nondeterminism induced by an uncontrollable garbage collector is unacceptable given hard realtime requirements.
- stelonix 13y agoI can't speak for him, but the issues that make Go not interesting at all to me (and I believe, to a lot of other C++ coders) are automatic GC, lack of generics and lack of template metaprogramming. The thing with Go is that it is (was?) marketed as a system's programming language. Go might work as a replacement for Java, but Java is not for system programming. Whoever decided to say Go was capable of it either has no idea what systems programming means or was being deceitful. Go can not replace C++; these languages don't solve the same problems.
- drucken 13y ago^^well expressed stelonix. This topic/article should have been re-titled, "Rob Pike on Why Go continues to be incorrectly marketed to systems programmers". Go is not a systems programming language, since it gives barely a passing nod to control. Thus, it does not fall in the same core domains of C++ or C.
- Pxtl 13y agoI always say, all of these "replacements for C++" don't feel like C++, they feel like statically-typed Python. Which is great, if you want statically-typed Python. There's a lot of fantastic uses for statically-typed Python. But they're not C++. As soon as you tie the whole language to a garbage-collector and leave out any real mechanism for metaprogramming or even simple generics, you've lost me. Pure text-based lexical macros like templates are a weapon of last-resort for language design... but it's not an optional one. Dynamic-typed languages cheat by offering a simple "exec" statement/function. Static languages have a religious objection to offering a first-party preprocessor, because they have the hubris to believe they can solve every possible problem ever within their language. Nobody is that good at programming language design. Not Pike, not Gosling, not Ritchie, not anybody. The difference is that Ritchie's team knew that, and didn't try and pretend that every single thing could be easily and performantly expressed in their language, and made the hackish ugly macro system to solve the edge cases... and it worked.
- stelonix 13y agoI think Rust stands a chance as a C/C++ replacement: manual low-level memory management, templates, a powerful macro system and type-safeness.