4 ms·

Seems weird that from what I hear about the intense interview process that Google programmers go through that they'd feel a need to dumb down the language of ch

by bwanab 10y ago

Seems weird that from what I hear about the intense interview process that Google programmers go through that they'd feel a need to dumb down the language of choice.

deleted 10y ago
[deleted]
Filligree 10y ago
I have yet to meet anyone inside Google who actually likes the language. At best they call it a decent replacement for C or C++, which is damning with faint praise. Lots of people are neutral, of course.
- oddthink 10y ago
  I like it. My brain's already pretty full with trying to get a ML pipeline optimized and launchable, and if I need to write something to read a CSV file, make some RPC calls to a service for each row, and dump the results to a file, go just works. Sure, I could use something like Haskell, but then I'd have to worry about whether I'm accumulating a giant stack of thunks that'll blow up. go just works, and less of it will bit-rot than the comparable python script, thanks to at least some types. This is why the SREs seem to be fans, e.g. https://talks.golang.org/2013/go-sreops.slide#1 https://talks.golang.org/2013/go-sreops.slide#1
  - danieldk 10y ago
    trying to get a ML pipeline optimized I wrote some machine learning tools in Go and the experience is quite bad. The lack of operator overloading and parametric polymorphism make most ML code ugly. It also does not help that Go's compiler backend does not optimize very strongly and calling out to C comes with a relatively large overhead. Sure, I could use something like Haskell, but then I'd have to worry about whether I'm accumulating a giant stack of thunks that'll blow up. There are many languages between Go and Haskell that are productive and provide a sufficiently strong type system.
    - oddthink 10y ago
      Yeah, the ML parts aren't in Go. I'm working in TensorFlow, so it's C++ scripted by Python. But there's a lot of incidental stuff that needs to be done, most of which I don't want to spend cycles on thinking hard about, and Go does a good job there, in that narrow niche where I want something that runs on one machine but find python too slow. At a previous gig, I had done a lot of F#, and I think that's close to my personal sweet spot, but I'd have to use it frequently to keep it in my head. Go is small enough that I can load it into cache when I need it.
      - danieldk 10y ago
        But there's a lot of incidental stuff that needs to be done, most of which I don't want to spend cycles on thinking hard about, and Go does a good job there, in that narrow niche where I want something that runs on one machine but find python too slow. Definitely! I have continued to use Go for small utility every now and then as well. The standard library is extremely well-suited for that kind of work. (Now using Rust more in that role as well, but mostly to get continued practice ;).)
  - solidsnack9000 10y ago
    I think in areas where there's a lot of math, the absence of generic collections might prove to be a frustration relative to C++ or Java (both allowed languages at Google).
psiclops 10y ago
The idea is that it makes software engineering across an organization much simpler if your language is minimal and eschews magic or complex constructs
SamWhited 10y ago
No matter how smart you are (or think you are), or how much state you can store in your head at once, if you remove some of the mental overhead of a language, then you have more time to think about other things. It's not about people needing to "dumb down" anything, it's about having a bit less mental overhead, meaning you can get a bit more done a bit easier.
- danieldk 10y ago
  No matter how smart you are (or think you are), or how much state you can store in your head at once, if you remove some of the mental overhead of a language, then you have more time to think about other things. So you use a language that makes specifying ownership (and immutability hard)? I always feel Go adds a lot of mental overhead. E.g., if you have a method that returns, say, a float32 slice. 1. If I return a slice of an array/slice that is a struct member, the caller could modify elements in the slice, breaking struct invariants. 2. Returning a copy of the slice is safe, but adds a lot of overhead. What you'd actually want is to return an immutable slice, but Go does not provide any facilities to do so (apart from wrapping a slice, but the lack of generics and operator overloading makes this tedious). I guess a lot of Go code will just assume that returned pointers/slices/maps will not be used in a way that breaks invariants. But you usually end up reading the source code of 3rd party packages to see what is safe, whereas in other languages you could just read the method signature. tl;dr: I think ownership and preserving invariants usually give the most mental overhead and Go does zero in that department.
  - fauigerzigerk 10y ago
    I agree that mutability constraints are a major weakness of Go. Interestingly, they did make string immutable and added []byte as a mutable alternative. It's unfortunate that string and []byte are so similar and yet it's impossible to treat a []byte as a string without copying (with the exception of looping over runes). This leads to massive code duplication and/or lack of functionality (byteconv where are you??). Just look at the strings, strconv and bytes packages. This whole area of the language is messy. The funny thing about Go is that it makes up for its long list of weaknesses with essentially one single strength. You can actually read other people's code without much introduction to the concepts used in that codebase, because the number of possible meanings of any particular expression is much smaller than in other languages. There is so much talk about Go being for dumb, second rate, corporate developers, because that's what Pike essentially said at one point (perhaps without thinking first). But in fact, it's not the developers who are dumb. It's the process by which large corporations employ and dispose of developers. They are thrown into some project and expected to "hit the ground running". There's no time for explanation. So what they do is read code to acquaint themselves with the codebase and hopefully become productive before they move on to the next job. And that is the one task where Go really shines. Reading arbitrary pieces of code. Of course powerful abstraction features eventually make reading code easier as well, but only after having learned the abstractions created for that particular problem and codebase and only if those abstractions are very carefully crafted. Powerful language features help writers of code long before they help readers. And that, I believe, is essentially the dirty secret that Go exploits. We all want to be brilliant writers of code when in fact we are often readers poking helplessly at half understood code to make something happen. We even forget our own abstractions once we haven't looked at them for a couple of months or even weeks. The problem with Go is that it not only acknowledges this state of affairs, it also enshrines it.

by bwanab 10y ago

Seems weird that from what I hear about the intense interview process that Google programmers go through that they'd feel a need to dumb down the language of choice.

deleted 10y ago

[deleted]

Filligree 10y ago

I have yet to meet anyone inside Google who actually likes the language. At best they call it a decent replacement for C or C++, which is damning with faint praise. Lots of people are neutral, of course.

oddthink 10y ago
I like it. My brain's already pretty full with trying to get a ML pipeline optimized and launchable, and if I need to write something to read a CSV file, make some RPC calls to a service for each row, and dump the results to a file, go just works. Sure, I could use something like Haskell, but then I'd have to worry about whether I'm accumulating a giant stack of thunks that'll blow up. go just works, and less of it will bit-rot than the comparable python script, thanks to at least some types. This is why the SREs seem to be fans, e.g. https://talks.golang.org/2013/go-sreops.slide#1 https://talks.golang.org/2013/go-sreops.slide#1
- danieldk 10y ago
  trying to get a ML pipeline optimized I wrote some machine learning tools in Go and the experience is quite bad. The lack of operator overloading and parametric polymorphism make most ML code ugly. It also does not help that Go's compiler backend does not optimize very strongly and calling out to C comes with a relatively large overhead. Sure, I could use something like Haskell, but then I'd have to worry about whether I'm accumulating a giant stack of thunks that'll blow up. There are many languages between Go and Haskell that are productive and provide a sufficiently strong type system.
  - oddthink 10y ago
    Yeah, the ML parts aren't in Go. I'm working in TensorFlow, so it's C++ scripted by Python. But there's a lot of incidental stuff that needs to be done, most of which I don't want to spend cycles on thinking hard about, and Go does a good job there, in that narrow niche where I want something that runs on one machine but find python too slow. At a previous gig, I had done a lot of F#, and I think that's close to my personal sweet spot, but I'd have to use it frequently to keep it in my head. Go is small enough that I can load it into cache when I need it.
    - danieldk 10y ago
      But there's a lot of incidental stuff that needs to be done, most of which I don't want to spend cycles on thinking hard about, and Go does a good job there, in that narrow niche where I want something that runs on one machine but find python too slow. Definitely! I have continued to use Go for small utility every now and then as well. The standard library is extremely well-suited for that kind of work. (Now using Rust more in that role as well, but mostly to get continued practice ;).)
- solidsnack9000 10y ago
  I think in areas where there's a lot of math, the absence of generic collections might prove to be a frustration relative to C++ or Java (both allowed languages at Google).

psiclops 10y ago

The idea is that it makes software engineering across an organization much simpler if your language is minimal and eschews magic or complex constructs

SamWhited 10y ago

No matter how smart you are (or think you are), or how much state you can store in your head at once, if you remove some of the mental overhead of a language, then you have more time to think about other things. It's not about people needing to "dumb down" anything, it's about having a bit less mental overhead, meaning you can get a bit more done a bit easier.

danieldk 10y ago
No matter how smart you are (or think you are), or how much state you can store in your head at once, if you remove some of the mental overhead of a language, then you have more time to think about other things. So you use a language that makes specifying ownership (and immutability hard)? I always feel Go adds a lot of mental overhead. E.g., if you have a method that returns, say, a float32 slice. 1. If I return a slice of an array/slice that is a struct member, the caller could modify elements in the slice, breaking struct invariants. 2. Returning a copy of the slice is safe, but adds a lot of overhead. What you'd actually want is to return an immutable slice, but Go does not provide any facilities to do so (apart from wrapping a slice, but the lack of generics and operator overloading makes this tedious). I guess a lot of Go code will just assume that returned pointers/slices/maps will not be used in a way that breaks invariants. But you usually end up reading the source code of 3rd party packages to see what is safe, whereas in other languages you could just read the method signature. tl;dr: I think ownership and preserving invariants usually give the most mental overhead and Go does zero in that department.
- fauigerzigerk 10y ago
  I agree that mutability constraints are a major weakness of Go. Interestingly, they did make string immutable and added []byte as a mutable alternative. It's unfortunate that string and []byte are so similar and yet it's impossible to treat a []byte as a string without copying (with the exception of looping over runes). This leads to massive code duplication and/or lack of functionality (byteconv where are you??). Just look at the strings, strconv and bytes packages. This whole area of the language is messy. The funny thing about Go is that it makes up for its long list of weaknesses with essentially one single strength. You can actually read other people's code without much introduction to the concepts used in that codebase, because the number of possible meanings of any particular expression is much smaller than in other languages. There is so much talk about Go being for dumb, second rate, corporate developers, because that's what Pike essentially said at one point (perhaps without thinking first). But in fact, it's not the developers who are dumb. It's the process by which large corporations employ and dispose of developers. They are thrown into some project and expected to "hit the ground running". There's no time for explanation. So what they do is read code to acquaint themselves with the codebase and hopefully become productive before they move on to the next job. And that is the one task where Go really shines. Reading arbitrary pieces of code. Of course powerful abstraction features eventually make reading code easier as well, but only after having learned the abstractions created for that particular problem and codebase and only if those abstractions are very carefully crafted. Powerful language features help writers of code long before they help readers. And that, I believe, is essentially the dirty secret that Go exploits. We all want to be brilliant writers of code when in fact we are often readers poking helplessly at half understood code to make something happen. We even forget our own abstractions once we haven't looked at them for a couple of months or even weeks. The problem with Go is that it not only acknowledges this state of affairs, it also enshrines it.