I think that was part of the point. Google made Go and then when OP wanted to use Go, their bosses said “use Java” (and took a month to do something that could be done in a few days)
I disagree with OP on this. Their boss in my opinion made the right call. I'd say for a few reasons:
1. Why did OP do this without talking through it first
2. Introducing a new language to a team is not some small decision, and IMO typically not a good idea
3. Why would it take a month in Java to do what takes a few days in Go
4. If it made this one task faster, the burden it will put on the team in the future can be bad in the long run
Perhaps the team would benefit a move to Go (I doubt that), but it should be something that is planned. Otherwise, they'll have "that" one thing that is written in a language that no one on the team really knows.
> Their boss in my opinion made the right call. I'd say for a few reasons:
Well you don't have enough context to say it was the right call.
> 1. Why did OP do this without talking through it first
I was tasked to prototype / MVP / "tracer dart" and prove that it was feasible. As proven, it took 2 days in Go. If it was done with Unix commands, the pieces can be jumbled together in a day. The point was having a self-contained "documentation via code" example of the exact business logic in such a program. The same can be achieved with a shell scripting language, but it wouldn't have been as readable. Go is about readibility, which is exactly the reason why it was invented Google, because Google prioritizes readibility. Java is readable if you know what idioms and style it's in, but it's also verbose, which is distracting. One, communicating with the source and sink. Two, get an initial picture of nuances in the Protobufs and data format. It happens to be that the Go prototype was 85-90% close to a final solution. In Java, after being able to actually bundle and consume the libraries had undocumented idiosyncrasies. Java is more powerful and thus more flexible, so a Hello World solution could might be in the wrong direction. You have options, no pun intended, on how you handle async.
> 2. Introducing a new language to a team is not some small decision, and IMO typically not a good idea
There was already half a dozen programming languages on the team's codebase, include a Go server which we inherited. So in effect, we should know Go anyways. As much as Google is Java shop, engineers are polyglot and not hired for a single language, in theory.
> 3. Why would it take a month in Java to do what takes a few days in Go
The language itself. Async code is verbose. Opinionated debates over variables should use the keyword final. Debating whether to use inheritance, delegation, function, or whatever composition / code-reuse pattern. It's been empirically shown Java programs are more verbose than other languages, both in tokens and in LoC. Complexity and entropy doesn't scale linearly, either. This is reflected in both client code and library code, which in the case of Google for many libraries is stale and misleading. One such library is authentication. For Java, Google has multiple competing libraries, or you can carve authentication features out of another feature library, but that is wrapped around and pegged to an older version. Something like JavaScript, there is 3 public sets of documentation on OAuth2 in JavaScript, and like 2.5 clients. With Go, there is a single canonical version, and so just figuring out what library you should use is a fraction of the troubles.
Then there is the ecosystem as a whole. You have options for logging library, and getting Gradle and the building system to pull in the dependencies, especially when you are on internal networks, is one thing. Aligning the Gradle build to be consistent with idiosyncrasies of the team's existing codebase is another. You can do inheritance with Gradle, and that's what was involved to be "consistent", because copy-and-pasting code is a no go.
> 4. If it made this one task faster, the burden it will put on the team in the future can be bad in the long run
That's a strawcut. What you are referring to is taking shortcuts, choosing a suboptimal solution because it saved time. Go was purpose built for middleware and microservices. It was the tool for the job, independent of how long it took to build the MVP. Beyond that, tess code is always better. If there was less code needed to build it, there is less code to maintain.
Google cares about code readability. This is exactly why Go was invented. Go is built readable language. Readability is what engenders low maintenance cost burden.
> Perhaps the team would benefit a move to Go (I doubt that)
No, it was not about a wholesale migration to Go. It was about using the right tool for the job, in one specific microservice, instead of having the Java and turning everything into a nail. Imagine if a company was a PHP shop and said everything had to be written in PHP. Frontends, backends, MapReduce jobs. This is the whole point about federating to microservices instead of monoliths. Or JavaScript, JavaScript everything. Hey, that's not bad, Coinbase was built solely on JavaScript. The argument might make sense if this was an esoteric language or a Lisp, but this is Go, which is, in theory, an official programming language at Google.
You do seem to be making assumptions and having expectations on how the team and how Google should operate. Regarding Java, I don't find the claims that Java isn't as good as Go compelling. For you, sure, but to make general claims is silly. There are many successful companies and productive developers using Java.
There are probably companies that are very productive in how you would want to pick and choose languages based on the problem. IMO, the language choice is not all that important, though I do think PHP, JavaScript, and similarly poorly designed languages are probably a hinderance (but again there are many successful companies using these like you said, so I think that's convincing that the language doesn't really matter all that much).
It could be part of the point but it does not sound like it.
It could say - Google is bad in that and that BUT it has Go.
Or it could say - Google designed Go and is interested in its adoption BUT its own managers don't think that Google developers want to learn Go.
But instead it says that Google documentation "does not teach you how to fish" and "you're not sure how to proceed" and at the same time Go somehow gets away with it - "At least with the Go libraries it's feasible to read the entire source code and flesh out things on the edge of documentation".
> It could say - Google is bad in that and that BUT it has Go. Or it could say - Google designed Go and is interested in its adoption BUT its own managers don't think that Google developers want to learn Go.
It's implied. In fact, Go is an "officially" supported language, meaning there is a dedicated team to maintain tooling around the Go ecosystem, sweep for security issues,
keep "runtimes" (in this case the compiler and binaries) up to date.
> But instead it says that Google documentation "does not teach you how to fish" and "you're not sure how to proceed" and at the same time Go somehow gets away with it - "At least with the Go libraries it's feasible to read the entire source code and flesh out things on the edge of documentation".
If documentation is going to be equally bad either ways ( that's something I've resigned with), then all else being equal the library implementation which is easier to read would be preferred.
That said, Go being idiomatic also means generated documentation is more standardized. Java has JavaDoc, but that's not enforced or culturally as consistent as Go.