Does Google actually consider Go to be a success? I get the impression that it failed in what it set out to be: a successor to C/C++. Or put differently, Rust has eaten Go‘s lunch.
Go was never intended to be a C/C++ successor, it was intended to solve a class of problems that Pike and gang experienced in the software they worked on. Which is to say network servers. What you are probably remembering is that they assumed from their unique Google lens that it was C++ developers who had those same problems and would see it as an alternative to C++ when faced with those problems, but it turned out that in the "real" world people were writing network servers in Python and Ruby, not C++.
Which isn't surprising to the rest of us. If you remember the days before Go, every second thread on HN was about how "company X", including the company now known as X, saw their Ruby network servers completely falling down under load, forcing a rewrite in whatever the language du-jour was that day. But Googlers tend to live in a completely different bubble with respect to the way software is written.
Well, a lot of servers are Google are (or were) written in Java not C++. As a GCd language, arguably Go competed with Java internally moreso than C++. One of Go's flagship projects (Kubernetes) started out being written in Java for example.
If I remember the legend correctly, the idea for Go was initially conceived while waiting for a C++ program to compile. Not sure about any of the other stuff, but they definitely got the compile times right...
A goal of Go was to put working on complex distributed systems within the reach of the junior people Google had access to in the quantity they were hiring. To whit, the kind of people who would have been able to work on a big Python system with 3 months ramp up or on a big C++ system with a year of ramp up.
It is pretty clear that with respect to that goal, Go is a success. It has attracted Python programmers who need type safety and performance. Someone with no Go experience could land a useful new feature in a big Go program in 3 months.
Introducing a junior person to a large Rust system would still take a year, because it is so much more difficult than Go. Which means to me that if Rust had been aiming at this same adoption goal (it wasn't) it would not have succeeded where Go did.
"When we have rewritten from Go into Rust, we found that it takes the same size of team and same time to build it."
Important part here being: rewrite. I would expect a rewrite to take less time, not the same time, than writing from scratch. Yet a Rust rewrite took as long as Go from-scratch project.
So to me, this implies the opposite, that Rust takes longer to write.
Time to build a new system and time to onboard a new team member without professional experience in a given language are 2 very difficult things.
Go is much more optimised for quick onboarding, fast feedback, more “code look” consistency across projects then rust.
Now a team that knows both rust and go well might have the same proditivity in rust and go (maybe even more in rust), but with lots of changes in personell, specifically in quick growing departments, go can make a huge difference.
This is obviously just an anecdote, but i’ve seen more companies or departments running mostly a go backend stack, having job postings saying “no go experience required”, than the equivalent other companies (or departments ) focused on any other lang.
> Introducing a junior person to a large Rust system would still take a year, because it is so much more difficult than Go.
Do you really think large Golang codebases are so easy to survey? I could see the argument wrt. C++, but Rust actually has a great featureset for programming "in the large". Take a look at the k8s codebase for an example of a large project that's written in Golang - doesn't seem all that easy to get started with.
This is an interesting question, but I doubt you will get a satisfactory answer here and probably anywhere. There is probably not even a uniform opinion about this within Google.
What I am more curious about is how much actual use Go has within companies and especially Google. What is the percentage of Go within their monorepo? How much of Google search is powered by Go?
I guess it depends on how you define success, but given there's a lot of people writing a lot of go code inside and outside of google over the last 15 years it seems likely it's doing a decent job at solving problems for those people. I'd call that a success.
