Will Go eventually replace C++ as Google hoped when Go came out?
https://www.quora.com/Will-Go-eventually-replace-C++-as-Google-hoped-when-Go-came-out
Go will probably not replace C++ entirely. However, I've never heard that was the goal of Go.
There are some systems already rewritten in Go. More will follow, but Go is not a silver bullet for all systems in place at Google.
There are some systems already rewritten in Go. More will follow, but Go is not a silver bullet for all systems in place at Google.
The Go programming language was conceived in late 2007 as an answer to some of the problems we were seeing developing software infrastructure at Google. The computing landscape today is almost unrelated to the environment in which the languages being used, mostly C++, Java, and Python, had been created. The problems introduced by multicore processors, networked systems, massive computation clusters, and the web programming model were being worked around rather than addressed head-on. Moreover, the scale has changed: today's server programs comprise tens of millions of lines of code, are worked on by hundreds or even thousands of programmers, and are updated literally every day. To make matters worse, build times, even on large compilation clusters, have stretched to many minutes, even hours.Go at Google: Language Design in the Service of Software Engineering
Go was designed and developed to make working in this environment more productive. Besides its better-known aspects such as built-in concurrency and garbage collection, Go's design considerations include rigorous dependency management, the adaptability of software architecture as systems grow, and robustness across the boundaries between components.
Go has been around for approximately 8 years now, and it's been publicly available for over 5 years.
During that time, it doesn't seem to have even made a dent in C++'s market share. Rather the contrary, C++ has (if anything) grown, especially in the last few years (roughly speaking, since C++11).
If you view Go primarily (or exclusively) as a competitor to C++, it doesn't fare very well as a rule. In other words, for the kinds of projects where C++ would be a reasonable possibility to start with, Go doesn't offer a great alternative as a rule.
The biggest deficiency is obviously speed. For example:
Go vs C++ g++ | Computer Language Benchmarks Game
On these, Go came out ahead on only one benchmark (which has a footnote saying it's comparing a single-threaded implementation to a multi-threaded implementation). It came out 2 to 5 times slower on about half the benchmarks.
If you were considering C or C++ in the first place, chances are pretty good that this sort of speed deficiency would be unacceptable.
In my opinion, Go is really much better viewed primarily as a competitor to something like Python or Ruby. Compared to Ruby or Python:
Go vs Python 3 | Computer Language Benchmarks Game
Computer Language Benchmarks Game
You can expect to write somewhere around the same amount of code, that's somewhere around the same level of complexity, and still get a pretty serious speed improvement in many cases.
On a more theoretical level, I don't know of any reason Go *couldn't* produce code that was much more competitive with C or C++. When it first came out, I (for one) found it interesting, and more or less assumed that its speed deficiency was purely temporary. Five years later, regardless of how much I might like to believe it can be competitive, I have to admit it's not currently, and as years go by without any major speed improvements, it seems less and less likely that it ever will be.
During that time, it doesn't seem to have even made a dent in C++'s market share. Rather the contrary, C++ has (if anything) grown, especially in the last few years (roughly speaking, since C++11).
If you view Go primarily (or exclusively) as a competitor to C++, it doesn't fare very well as a rule. In other words, for the kinds of projects where C++ would be a reasonable possibility to start with, Go doesn't offer a great alternative as a rule.
The biggest deficiency is obviously speed. For example:
Go vs C++ g++ | Computer Language Benchmarks Game
On these, Go came out ahead on only one benchmark (which has a footnote saying it's comparing a single-threaded implementation to a multi-threaded implementation). It came out 2 to 5 times slower on about half the benchmarks.
If you were considering C or C++ in the first place, chances are pretty good that this sort of speed deficiency would be unacceptable.
In my opinion, Go is really much better viewed primarily as a competitor to something like Python or Ruby. Compared to Ruby or Python:
Go vs Python 3 | Computer Language Benchmarks Game
Computer Language Benchmarks Game
You can expect to write somewhere around the same amount of code, that's somewhere around the same level of complexity, and still get a pretty serious speed improvement in many cases.
On a more theoretical level, I don't know of any reason Go *couldn't* produce code that was much more competitive with C or C++. When it first came out, I (for one) found it interesting, and more or less assumed that its speed deficiency was purely temporary. Five years later, regardless of how much I might like to believe it can be competitive, I have to admit it's not currently, and as years go by without any major speed improvements, it seems less and less likely that it ever will be.
- The Go team is a tiny, tiny part of Google, and Go is a bottoms-up project originally designed by Google programmers who felt it would be useful, not a top-down directive from Google upper management. Especially back when Go came out, I don't think Google as a whole had any hopes or feelings about Go one way or another.
- Even the Go team never intended Go to replace C++. The goal was to provide an alternative that could be used in places where C++ was formerly the only reasonable choice. Go and C++ are different languages and have different advantages.
- In practice, while Go has had some success as an alternative to C++, it has had more success as an alternative to Python and Ruby and similar languages. It certainly has not and will not replaced those languages, but it is a useful alternative for some uses.
A Googler acquaintence of mine commented that Go was created essentially as a more scalable version of Python, one fit for larger systems.
But to address how much Go will replace C++ we need look at the things that Go does not do.
According to wiki:
Frequent criticisms [of Go] assert that :
These are all things that C++ can do and the resulting power and expressiveness is a reason that differentiates C++ from Go.
But to address how much Go will replace C++ we need look at the things that Go does not do.
According to wiki:
Frequent criticisms [of Go] assert that :
- lack of compile-time generics leads to repetition or excessive dynamic code
- lack of language extensibility (through, for instance, operator overloading) makes certain tasks more verbose
- the type system's lack of const or Hindley-Milner typing inhibits safety and/or expressiveness
- garbage collection pauses limit Go's domain of applicability (and that of Java, C#, etc.) compared to languages like C++ or Rust
These are all things that C++ can do and the resulting power and expressiveness is a reason that differentiates C++ from Go.
Who ever said that Go was supposed to replace C++? That's crazy. There are some higher level tasks that are much easier to program in Go while maintaining the
speed of C++, but the lower level, high performance stuff will always be C++.
Not even close! I think it is unlikely that Go will ever be more than a curiosity used mostly at Google. Even with its warts and all, C++ remains the standard
system implementation language, and Go can't touch it, except maybe for the specific case of simple networking client/servers.
C++14 (the current C++ language) is a mature, complete, consistent language with no design holes, while Go has none of these attributes. It will be a tall order to find a language able replace C++, and the contender will have to be extraordinarily good... and Go just isn't.
C++14 (the current C++ language) is a mature, complete, consistent language with no design holes, while Go has none of these attributes. It will be a tall order to find a language able replace C++, and the contender will have to be extraordinarily good... and Go just isn't.
I think it will for the kinds of things Google used C++ for. However Go only covers a subset of what C++ as suited for. E.g. for Game Engines or We rendering engines
I think Rust is more likely to replace C++. But that will be along drawn out process as it will take long time for new tools to be developed, compilers to be optimized enough etc.
And of course there is a lot of established C++ code which isn't likely to be rewritten. But in say 6-7 years I doubt many projects will start by being written in C++.
And of course there is a lot of established C++ code which isn't likely to be rewritten. But in say 6-7 years I doubt many projects will start by being written in C++.
Mandeep Gill,
Views
I don't think go can replace c or c++ as c or c++ have large community, good documents, tutorials and university likes to teach c, c++ or java first.
Second thing c++ programs have better performance.
Third and last thing if GoLang need to grow then google need to make own OS like Microsoft Windows and Mac OS or Linux to use Full GoLang and it's not possible with current Generation and Coming Generation because most of teachers will teach what they know best, and If New OS By Google then there will be less Games because most of PC Users play games and all develop using c or c++ that makes user attachment to c or c++ language for sure.
Brian Connors
Views
I would compare how Google has handled Go to how Apple has handled Swift.
Apple just shoved Swift right into the deep end. It targeted a tangible platform -- iOS -- right out of the gate, and provided extra features (particularly playgrounds) to sweeten the deal for users on the fence about it. They've been hinting at promoting Swift as a language for computer education, or at least that's the impression I get from their offering of scholarships to WWDC'15 to student developers working in Swift.
By contrast, Go doesn't even rank on the TIOBE index. Its pedigree is impeccable -- Ken Thompson and Rob Pike were two of its designers -- but although Go gets the job done and is actively supported, it's a very marginal language that seems to be mostly used internally at Google. They've never made much of an effort to integrate it into the Android or Chrome ecosystems, which would have given it a huge boost just the way Swift got from iOS devs; most Android development is still done in Java and run on Dalvik or ART. If there was a real market rivalry (which there really isn't -- I don't think Go even registers on most mobile devs' radar), the impending open sourcing of Swift 2 would likely be perceived as a death blow.
Basically, I think Google fumbled the handoff with Go. Everything about it screams missed opportunity and I suspect that unless some future company finds a killer app for it the way Apple did with Objective-C and iOS, you won't hear much about it unless you actually work at Google.
Apple just shoved Swift right into the deep end. It targeted a tangible platform -- iOS -- right out of the gate, and provided extra features (particularly playgrounds) to sweeten the deal for users on the fence about it. They've been hinting at promoting Swift as a language for computer education, or at least that's the impression I get from their offering of scholarships to WWDC'15 to student developers working in Swift.
By contrast, Go doesn't even rank on the TIOBE index. Its pedigree is impeccable -- Ken Thompson and Rob Pike were two of its designers -- but although Go gets the job done and is actively supported, it's a very marginal language that seems to be mostly used internally at Google. They've never made much of an effort to integrate it into the Android or Chrome ecosystems, which would have given it a huge boost just the way Swift got from iOS devs; most Android development is still done in Java and run on Dalvik or ART. If there was a real market rivalry (which there really isn't -- I don't think Go even registers on most mobile devs' radar), the impending open sourcing of Swift 2 would likely be perceived as a death blow.
Basically, I think Google fumbled the handoff with Go. Everything about it screams missed opportunity and I suspect that unless some future company finds a killer app for it the way Apple did with Objective-C and iOS, you won't hear much about it unless you actually work at Google.
