|
> 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).