This is much more about your opinion, and your axe to grind against google, rather than an intelligent discussion about the merits of software.
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.
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.
Bazel is fucking awful. Most miserable years of my career is when I was tasked with maintaining a build system based on it. Same for gRPC, which TFA also does a good job of shutting down.
Blaze/Bazel has its flaws (including poor integration into the world outside google), but what are you comparing it against? Any general purpose build system I've seen that is not bazel based and not nix is a flaming pile of garbage: almost nothing else can even figure out a correct dependency tree, let alone which parts of it have changed and need recompilation. Bazel also uses a familiar, readable and yet concise subset of python for build description, whereas most other build systems use customer languages with syntaxes and semantics that are comically bad if you don't have to use them and tragically so if you do.
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.
Yes, sorry I was imprecise, it would have been better to have written "derivative of protobuf". To the extent the RPC part is derivative, it's probably mostly derivative of E?
I'm going to recommend at this point, you take a breather from your invective, cool off for a bit, and return when you have something valuable to contribute. You're going to have to do better when commenting on Hacker News: you're just attacking stuff because you don't like it, rather than making technical explanations.
> Bazel is fucking awful. Most miserable years of my career is when I was tasked with maintaining a build system based on it. Same for gRPC, which TFA also does a good job of shutting down.
Counter-anecdata: my most miserable years of my career were when dealing with bespoke build and API systems that weren't Bazel and gRPC.
I thought each of these were good until I tried something different. I think people moved from legacy things like Windows Live Mail, MapQuest, and Word 2000 to these services, and then never noticed the rest of the world got better outside of Google-land.
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.
Gmail sucks. They use it as a vehicle for anti-competitive "standards" and it's needlessly difficult to deliver mail to. Their new JavaScript-riddled frontends (which they seem to develop and then shrug off every couple of years) have awful performance and are terrible at doing what has ultimately a very simple task for 30 years.
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.
Engineering quality is about nothing other than meeting the spec- how well does google accomplish that?
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
Highly used? So what? Might does not make right. They're definitely not cost efficient. Google's standard play is throwing tens of millions of dollars at a problem, which is not good engineering, even if it works.
Edit: you changed your comment out from under me and I fail to rouse the enthusiasm to reply to your new comment.
Go was made by a small group of smart people with debatable loyalty to Google. Google just ran with it, and they haven't done a great job with it since.
I'm not sure what you mean by debatable loyalty. The creators of the language have all worked at the company for more than 10 years and support the product for internal users.
Can you put your grinding axe away and stick entirely to facts and technical merits?
Look, Go has way more to do with the experience of its creators than with their contact with the engineering culture of Google. The influences from Plan 9, Inferno, Limbo, and so on are all extremely apparent in Golang's design and were all born outside of Google. Very little of Google's spirit made it into Go.
I don't know how you got from "debatable loyalty to Google" to "the language was mostly inspired by Bell Labs tech, rather than Google", which is perfectly fine. But it doesn't explain your animosity and refusal to discuss based on technical merits, rather than just (what is clearly) axe-grinding.
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?
I retract "debatable loyalty to Google". I meant something more along the lines of "debatably attributable to Google's engineering", i.e. a statement directly in support of my main argument.
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.
> 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'.
I initially thought this was serious hyperbole and I still think it may overstate things a bit, but when I thought about it I actually had a really hard time coming up with counterexamples. Meanwhile it’s easy for Microsoft and Apple. Huh. Best I can do is products that were great at launch... like 12-15 years ago.
