4 ms·

Right, but Go itself, which builds on those ideas was built within Google. I have no objection to attributing ideas, but you seem to want to attribute some gene

Right, but Go itself, which builds on those ideas was built within Google. I have no objection to attributing ideas, but you seem to want to attribute some general “quality of engineering” attributes to “not Google”. The people doing things you like are just as much Googlers as all the people doing things you don’t like, and they all have an influence on the company and vice versa. In many cases, it’s even the same people. So the distinctions you are trying to draw are silly. Just let the criticisms stand on their own.

ddevault 6y ago
The distinction is meaningful. The language designers of Go are a small group of people with a history of innovation outside of Google who had established the context in which Go was made prior to joining Google. Just because Google signed the check, they should get credit? Go would have happened no matter who hired the team. Google's engineering ethos has a negative effect on the products of developer labor, and it shows in their stewardship of Golang as well as all of their other products. I know you work at Google and have been busy in this thread trying to cognitive dissonance your way around this problem, but the fact is that Google sucks at engineering and I have argued to support this point.
- akerl_ 6y ago
  Yes; Google hiring people with a history of innovation and giving them the support (financial and otherwise) to undertake a project does make the project part of Google’s engineering portfolio. I’m not sure how this could be in dispute. It’s not like Golang was something that Google backed on Kickstarter: they gave resources and pay to the people whom they intentionally hired because they wanted engineers with their skillset. If employees hired as engineers, who work on engineering projects, don’t count as part of your company’s “engineering ethos” just because they were already engineers before you hired them, I’m not sure we have a shared agreement on what “engineering ethos” means. Are only fresh college graduates permitted to count as part of your “ethos”? How many years of experience can an engineer attain before their accomplishments at work are no longer part of their employer’s ethos?
  - ddevault 6y ago
    I must be really awful at explaining my point or there's an awful lot of willful ignorance in this thread. Either way, something awful is going on. Read carefully: the engineering culture of Google - it's practices, policies, principles, insiprations, and so on - did not make Go. The prior experiences of the Go authors, and a handful of specific and obvious influences, both of which are objectively not of Google, made Go. Google's engineering ethos does not get credit for Go, though maybe an argument can be made that their wallet gets credit. Personally, I don't agree with that, but it's beside the point.
    - akerl_ 6y ago
      The part that I don’t understand is: why does Google not get credit, in your opinion, for having built an engineering org from qualified people? Google hired the engineers who made Go. A company’s engineering ethos is the combined ethos of its engineers. The Golang developers are engineers who Google hired. To attempt to draw a metaphor: if I operated an auto repair shop, and I wanted my shop’s “ethos” to be “we do high-quality repairs on cars”, one of the primary ways to do that would be to hire smart, already-experienced mechanics. And it would seem strange to me if people wrote blog posts saying that the work of those mechanics didn’t count towards my “ethos” because they were already good at their jobs; that’s why I hired them! As a tangential comment, phrases like “Read carefully” seem extraneous, as does the accusation of “an awful lot of willful ignorance”. They just serve as jabs at the other commenters here.
      - ddevault 6y ago
        Go was principally made by 3 people, whose resumes basically justified being allowed to work at their discretion (this last bit is conjecture, but I would be surprised to be proven wrong). If Ken Thompson has a manager at Google that has any influence whatsoever on Ken's work, then Google's culture is more broken than I thought. The rest of Google is over 100,000 engineers who have managers, team leads, and much more rigid policies and workflows than I imagine the Go designers were ever subjected to during the development of Go. This is the engineering ethos to which I refer, not the system to which the Go designers where subject. So: Google gave a chair and a desk to a few talented people who applied experience and influences from entirely outside of Google to designing a programming language. In my book, Google doesn't get credit for that, and their engineering culture definitely doesn't get credit for that - it was barely involved, if at all.
- tptacek 6y ago
  I know you work at Google and have been busy in this thread trying to cognitive dissonance your way around this problem This kind of writing is not allowed on HN. Make your argument on its merits, not with innuendo.
stefan_ 6y ago
It's about complexity, about design and process. I don't think anyone can seriously deny that Google, it's engineering process and resources have a vast impact on what a documentation or package server comes out looking. If all you have been building for the past 20 years are web services and you are surrounded by Kubernetes-but-the-internal-version and Postgres-but-the-internet-scale-version, is it any surprise that what comes out at the other end is invariably a centralized web service running on a bunch of Google proprietary infrastructure? And is it really that difficult to see how that is very different from the principles in Go, the language? Git is very much the same thing. There is no doubt that in a world without Git, version control inside Google looks a lot more like Team Server than it does decentralized Merkle tree.
ocdtrekkie 6y ago
FWIW, Drew's position on Go is hardly even unique. Someone who is quite fond of Go was telling me last week about how I should consider learning it despite it being from Google, because it is not very Google-like of a project. And that wasn't the first time I'd heard it either. (Myself, I am usually just trying to build stuff people wrote in Go, and I usually end up fighting the tooling for a while and getting mystified by the error messages and having no idea where to look to solve them.)
- arp242 6y ago
  I avoided Go for years because it was from Google until I quite accidentally landed a Go job several years ago, and I haven't looked back. Amusingly, I am now using Go to build a competitor for Google Analytics. Heh. It was an important lesson in a way, as it taught me that Google – or indeed, any organisation comprised of thousands of people – is not a single monolithic entity. Also, feel free to drop me a line if you've got problems with a specific error, and I can perhaps point you in the right direction.
  - ocdtrekkie 6y ago
    I did get the thing last week to build! :) My Go-recommending friend seemed to think the script I was using was pulling in Go 1.11 where modules were not as well supported as they are now? But I got around it. It was just that the error message I got really gave me nothing useful to search for. Literally was a "permission denied" error... while "go build"ing stuff with effective superuser. It wasn't really pointing me at what it didn't have permission to do or how I would go about getting it.
    - arp242 6y ago
      "Permission denied" usually happens when it tries to build stuff in "GOROOT", that is, the standard library installed in /usr/lib/go or some such. This normally shouldn't happen, so there's probably something wrong with your installation or setup. Hard to be 100% sure though, that's just the usual cause in my experience. I think Debian ships with Go 1.11 in current stable (and by extension, Ubuntu too, I assume?). The entire GOPATH to modules switch is messy, ugly, broke a lot of stuff, and is confusing for newcomers, even though modules is clearly better. I think we're finally nearing the end of it though. You probably want to just use Go 1.14 (the latest version) if you can. The language itself is very stable (just not the surrounding tooling).

ddevault 6y ago

The distinction is meaningful. The language designers of Go are a small group of people with a history of innovation outside of Google who had established the context in which Go was made prior to joining Google. Just because Google signed the check, they should get credit? Go would have happened no matter who hired the team. Google's engineering ethos has a negative effect on the products of developer labor, and it shows in their stewardship of Golang as well as all of their other products. I know you work at Google and have been busy in this thread trying to cognitive dissonance your way around this problem, but the fact is that Google sucks at engineering and I have argued to support this point.

akerl_ 6y ago
Yes; Google hiring people with a history of innovation and giving them the support (financial and otherwise) to undertake a project does make the project part of Google’s engineering portfolio. I’m not sure how this could be in dispute. It’s not like Golang was something that Google backed on Kickstarter: they gave resources and pay to the people whom they intentionally hired because they wanted engineers with their skillset. If employees hired as engineers, who work on engineering projects, don’t count as part of your company’s “engineering ethos” just because they were already engineers before you hired them, I’m not sure we have a shared agreement on what “engineering ethos” means. Are only fresh college graduates permitted to count as part of your “ethos”? How many years of experience can an engineer attain before their accomplishments at work are no longer part of their employer’s ethos?
- ddevault 6y ago
  I must be really awful at explaining my point or there's an awful lot of willful ignorance in this thread. Either way, something awful is going on. Read carefully: the engineering culture of Google - it's practices, policies, principles, insiprations, and so on - did not make Go. The prior experiences of the Go authors, and a handful of specific and obvious influences, both of which are objectively not of Google, made Go. Google's engineering ethos does not get credit for Go, though maybe an argument can be made that their wallet gets credit. Personally, I don't agree with that, but it's beside the point.
  - akerl_ 6y ago
    The part that I don’t understand is: why does Google not get credit, in your opinion, for having built an engineering org from qualified people? Google hired the engineers who made Go. A company’s engineering ethos is the combined ethos of its engineers. The Golang developers are engineers who Google hired. To attempt to draw a metaphor: if I operated an auto repair shop, and I wanted my shop’s “ethos” to be “we do high-quality repairs on cars”, one of the primary ways to do that would be to hire smart, already-experienced mechanics. And it would seem strange to me if people wrote blog posts saying that the work of those mechanics didn’t count towards my “ethos” because they were already good at their jobs; that’s why I hired them! As a tangential comment, phrases like “Read carefully” seem extraneous, as does the accusation of “an awful lot of willful ignorance”. They just serve as jabs at the other commenters here.
    - ddevault 6y ago
      Go was principally made by 3 people, whose resumes basically justified being allowed to work at their discretion (this last bit is conjecture, but I would be surprised to be proven wrong). If Ken Thompson has a manager at Google that has any influence whatsoever on Ken's work, then Google's culture is more broken than I thought. The rest of Google is over 100,000 engineers who have managers, team leads, and much more rigid policies and workflows than I imagine the Go designers were ever subjected to during the development of Go. This is the engineering ethos to which I refer, not the system to which the Go designers where subject. So: Google gave a chair and a desk to a few talented people who applied experience and influences from entirely outside of Google to designing a programming language. In my book, Google doesn't get credit for that, and their engineering culture definitely doesn't get credit for that - it was barely involved, if at all.
tptacek 6y ago
I know you work at Google and have been busy in this thread trying to cognitive dissonance your way around this problem This kind of writing is not allowed on HN. Make your argument on its merits, not with innuendo.

stefan_ 6y ago

It's about complexity, about design and process. I don't think anyone can seriously deny that Google, it's engineering process and resources have a vast impact on what a documentation or package server comes out looking. If all you have been building for the past 20 years are web services and you are surrounded by Kubernetes-but-the-internal-version and Postgres-but-the-internet-scale-version, is it any surprise that what comes out at the other end is invariably a centralized web service running on a bunch of Google proprietary infrastructure? And is it really that difficult to see how that is very different from the principles in Go, the language? Git is very much the same thing. There is no doubt that in a world without Git, version control inside Google looks a lot more like Team Server than it does decentralized Merkle tree.

ocdtrekkie 6y ago

FWIW, Drew's position on Go is hardly even unique. Someone who is quite fond of Go was telling me last week about how I should consider learning it despite it being from Google, because it is not very Google-like of a project. And that wasn't the first time I'd heard it either. (Myself, I am usually just trying to build stuff people wrote in Go, and I usually end up fighting the tooling for a while and getting mystified by the error messages and having no idea where to look to solve them.)

arp242 6y ago
I avoided Go for years because it was from Google until I quite accidentally landed a Go job several years ago, and I haven't looked back. Amusingly, I am now using Go to build a competitor for Google Analytics. Heh. It was an important lesson in a way, as it taught me that Google – or indeed, any organisation comprised of thousands of people – is not a single monolithic entity. Also, feel free to drop me a line if you've got problems with a specific error, and I can perhaps point you in the right direction.
- ocdtrekkie 6y ago
  I did get the thing last week to build! :) My Go-recommending friend seemed to think the script I was using was pulling in Go 1.11 where modules were not as well supported as they are now? But I got around it. It was just that the error message I got really gave me nothing useful to search for. Literally was a "permission denied" error... while "go build"ing stuff with effective superuser. It wasn't really pointing me at what it didn't have permission to do or how I would go about getting it.
  - arp242 6y ago
    "Permission denied" usually happens when it tries to build stuff in "GOROOT", that is, the standard library installed in /usr/lib/go or some such. This normally shouldn't happen, so there's probably something wrong with your installation or setup. Hard to be 100% sure though, that's just the usual cause in my experience. I think Debian ships with Go 1.11 in current stable (and by extension, Ubuntu too, I assume?). The entire GOPATH to modules switch is messy, ugly, broke a lot of stuff, and is confusing for newcomers, even though modules is clearly better. I think we're finally nearing the end of it though. You probably want to just use Go 1.14 (the latest version) if you can. The language itself is very stable (just not the surrounding tooling).