Can you put your grinding axe away and stick entirely to facts and technical merits?
Note that Go ended up being a major language within Google for a wide range of systems (even replacing systems built previously by the Go developers, such as sawzall), so rather than saying "debatable loyalty to google", might it not be better to say that the developers worked to transform Google from the inside to be less dependent on C++ and Java?
That right there is evidence they don't have Google's best interests at heart.
Google Maps is fine. OSM is superior technically but Google Maps only wins because it has access to better data. It's not an example of great engineering, it's just okay.
Google Docs is pretty good. At least it was, the last time I used it was several years ago. I can't comment on the code, which is mainly what I'm commenting on in this thread: their engineering quality. Throw enough monkeys at a typewriter and maybe Google Docs comes out, but who knows what it looks like on the inside.
It sounds like you have some issues with the design itself, maybe some issues with the business practices. Those are issues with the spec, not the engineering. The engineering team delivers the spec, they do it smoothly, they do it at scale
Edit: you changed your comment out from under me and I fail to rouse the enthusiasm to reply to your new comment.
Gmail operates what is probably an industry-worst mail client. I have helped people using AOL Mail in 2020, and it is a superior experience. It performs better. FastMail is a paid service, and it's quality matches that: FastMail can run in circles around Gmail every single day.
Google Docs/Sheets is Office without all of the reasons businesses use Word. You can try to patch in some of it's holes with add-ons (I had some experience with a Mail Merge add-on for Gmail/Sheets, and it was fine, I guess, but a paid service from a third party) but with a lot of added jank. Collaborative editing was it's claim to fame, but you can do that just fine in Office 365, with a far more capable app suite.
Google Maps, Drew covered the point pretty well: Google just has the money for more data. It's prohibitively expensive to use that data yourself as a service, and others who have access to less data still manage a comparable and sometimes better product than Maps. Usually while better respecting your privacy.
Personally, I really like JAX and XLA. These are two really powerful systems that work together to implement high performance machine learning and theoretical physics/biology. JAX can basically take derivatives of python functions (useful for training) and XLA optimizes the underlying compute graph to execute quickly on different physical platforms.
Google doesn't get credit for Go, Bell Labs does.
Counter-anecdata: my most miserable years of my career were when dealing with bespoke build and API systems that weren't Bazel and gRPC.
Again, gRPC has its flaws (and I'm not a fan of HTTP2), but what are you comparing it to? For internal services REST is acceptable for extremely simple, stable and low volume APIs. For everything else it is an obvious disaster: terrible CPU/network/memory performance, you need to write more code than you would have to with gRPC and get zero type safety unless you add some json schema monstrosity on top of it at which point your performance will likely take a further nose dive. Also, good luck evolving the protocol – gRPC is carefully designed to support this. Far from doing a good job, "TFA" quotes some extremely clueless article on why protobuf sucks that was ripped to shreds when posted on HN previously.
The only compelling alternative to gRPC I am aware of is capnproto (which is derivative, but in some ways nicer), but it has far less eco system maturity and mindshare.
I would argue that while Cap'n Proto's serialization is derivative of Protobuf, the RPC protocol is wildly different from gRPC.
> but it has far less eco system maturity and mindshare.
That's certainly true.
(I'm the author of Cap'n Proto.)
2. protocol buffers
rest is vaporware
Ever had to maintain a Gerrit instance?
Bazel is the most complicated garbage I've ever had the displeasure of using. It takes tens of thousand of lines of support code just to add a new tool to your toolchain.
Google does not get credit for Go's design.
gRPC, k8s: see TFA
Yes. [1]
> It takes tens of thousand of lines of support code just to add a new tool to your toolchain.
No, I've added custom compilers and languages to Bazel, and it was not nearly 'tens of thousands of line'. Sure, it's complex, but such is life with inversion of control. It's difficult to get around this complexity if you want to follow the design goals of Bazel.
> gRPC, k8s: see TFA
The article says nothing about why gRPC or k8s are bad. It just uses very emotional language to handwave into the general direction of 'bloat' and 'too complex'.
[1] - https://cs.hackerspace.pl/hscloud/-/tree/devtools/gerrit
I'm serious. Say what you will about the high complexity of the web platform, or the rising dominance of Chromium. It's a seriously impressive piece of engineering. Have you ever watched the Chromium build process in action? It builds hundreds of static libraries, then statically links them all into one monster executable or DLL (depending on the platform). BTW, part of what enables static linking at this massive scale is the gn build system, which AFAIK is inspired by Blaze (the internal ancestor of Bazel). So IMO that's a major point in favor of that type of build system.
BTW, to answer your point about throwing tens of millions of dollars at a problem: some problems are just unavoidably that big, especially when you factor in things that are required for a piece of end-user-facing software to be usable by the whole world, such as internationalization, accessibility, and in general, complex but usable UIs.