5 ms·

Your statements are overly hostile and hyperbolic. There's been plenty of great software out of Google and lots of good ideas taken for granted. I'll give you f

by Xorlev 6y ago

Your statements are overly hostile and hyperbolic. There's been plenty of great software out of Google and lots of good ideas taken for granted. I'll give you folks trying to build things the Google way without Google tools or scale is more often than not the wrong thing to do, but that doesn't invalidate the good.

ddevault 6y ago
Name a single piece of good software from Google.
- mwcampbell 6y ago
  Chromium. 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.
- jiqiren 6y ago
  The Go Language.
  - ddevault 6y ago
    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.
    - dekhn 6y ago
      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?
      - ddevault 6y ago
        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.
        dekhn 6y ago
        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?
        ddevault 6y ago
        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.
      - twic 6y ago
        > support the product for internal users That right there is evidence they don't have Google's best interests at heart.
- jonfw 6y ago
  Gmail, google maps, and google docs are all excellent
  - Nextgrid 6y ago
    They are working very hard at ruining the UIs of these products though.
  - ddevault 6y ago
    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.
    - jonfw 6y ago
      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
      - ddevault 6y ago
        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.
- dekhn 6y ago
  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.
- CameronNemo 6y ago
  dm-verity
- pantaloony 6y ago
  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.
- zaphar 6y ago
  Bazel, gRpc, Guava, Go, Dart, I could go on but you technically only asked for one.
  - ddevault 6y ago
    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. Google doesn't get credit for Go, Bell Labs does.
    - patrec 6y ago
      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.
      - kentonv 6y ago
        > The only compelling alternative to gRPC I am aware of is capnproto (which is derivative, but in some ways nicer) 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.)
- zelly 6y ago
  1. search 2. protocol buffers rest is vaporware
- q3k 6y ago
  Off the top of my head: Gerrit, Bazel, Go, gRPC, Kubernetes.
  - ddevault 6y ago
    I've addressed most of these already. 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
    - q3k 6y ago
      > Ever had to maintain a Gerrit instance? 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 https://cs.hackerspace.pl/hscloud/-/tree/devtools/gerrit
goldfishlover 6y ago
They match my experience with most Google software at least, maybe worded in an extreme way but hey that's forums for ya

by Xorlev 6y ago

ddevault 6y ago

Name a single piece of good software from Google.

mwcampbell 6y ago
Chromium. 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.
jiqiren 6y ago
The Go Language.
- ddevault 6y ago
  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.
  - dekhn 6y ago
    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?
    - ddevault 6y ago
      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.
      - dekhn 6y ago
        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?
        ddevault 6y ago
        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.
    - twic 6y ago
      > support the product for internal users That right there is evidence they don't have Google's best interests at heart.
jonfw 6y ago
Gmail, google maps, and google docs are all excellent
- Nextgrid 6y ago
  They are working very hard at ruining the UIs of these products though.
- ddevault 6y ago
  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.
  - jonfw 6y ago
    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
    - ddevault 6y ago
      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.
dekhn 6y ago
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.
CameronNemo 6y ago
dm-verity
pantaloony 6y ago
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.
zaphar 6y ago
Bazel, gRpc, Guava, Go, Dart, I could go on but you technically only asked for one.
- ddevault 6y ago
  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. Google doesn't get credit for Go, Bell Labs does.
  - patrec 6y ago
    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.
    - kentonv 6y ago
      > The only compelling alternative to gRPC I am aware of is capnproto (which is derivative, but in some ways nicer) 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.)
zelly 6y ago
1. search 2. protocol buffers rest is vaporware
q3k 6y ago
Off the top of my head: Gerrit, Bazel, Go, gRPC, Kubernetes.
- ddevault 6y ago
  I've addressed most of these already. 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
  - q3k 6y ago
    > Ever had to maintain a Gerrit instance? 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 https://cs.hackerspace.pl/hscloud/-/tree/devtools/gerrit

goldfishlover 6y ago

They match my experience with most Google software at least, maybe worded in an extreme way but hey that's forums for ya