Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New case studies about Google’s use of Go

opensource.googleblog.com

Post reply on HN
Print view View original

221–230 of 269 posts

Re: New case studies about Google’s use of Go

#221

Post by _y5hn »

eweise wrote: post #177
piazz wrote: post #84

I played around with Go a while ago, and while I appreciated the approach to concurrency, I was really put off by both the boilerplate + how primitive the type system felt. Not having map and filter due to lack of generics meant writing for loops all over the place just to filter and modify arrays. Appending elements to slices felt clumsy. The type system didn't feel expressive, and I often found myself having to res…

I get the feeling that Go programmers came from some other imperative language and got burned by some OO features. I feel kind of bad for them. I hope they never discover modern functional features or they will realize how much of their life was wasted writing pointless boilerplate.

What you feel about what you don't understand, isn't really important to anyone else though.

Go provides less is more as a feature, but would be invisible unless the dev cared about seeking simplicity and performance.

Re: New case studies about Google’s use of Go

#222

Post by _y5hn »

athrun wrote: post #198
ahelwer wrote: post #182

Earlier quoted context omitted.

Many people find the "pozzy vibes only" philosophy much more annoying than relentless cynicism, which can at least be refuted by just ignoring it & building stuff.

I don't know about that. I find relentless cynicism/negativity to be much more difficult to ignore than positive comments. I tend to think this is how we are wired as humans.

I find both positivity and negativity annoying, bleh! ;)

Joke aside, how about we all complain about your favourite language in every post? It over time becomes irrelevant to those who grok the language.

Re: New case studies about Google’s use of Go

#223

Post by philosopher1234 »

cmrdporcupine wrote: post #137
mabbo wrote: post #75

While I do trust Rob Pike to not let personal biases sway his writing, I do have to wonder if the case studies weren't selecting because they were positive. So I'm curious: does anyone have a case study where using Go was a disaster? Every language has things it's good at, and things it's bad at. Where does Go not do well?

Let me just say that I've been at Google for almost 9 years, and have recently started looking for work elsewhere and it seems that Go is far more popular outside of Google than inside it. Which disappoints me because my experiences with the language internally have biased me such that I have no desire to go use it elsewhere. I've said this before, but I think it's a bit dishonest to sell this as a "Google language."…

This comment doesn’t tell me anything about why you don’t like go, just that you don’t like it.

Re: New case studies about Google’s use of Go

#224

Post by andykx »

erik_seaberg wrote: post #201
solidasparagus wrote: post #185

Earlier quoted context omitted.

I've never found it much more painful to write: for i, c in range col { if c.isReady && convertToX(c).color == "BLUE": return True } (which is not to say I don't miss the map/filter syntax - although I don't miss the bugs related to lazy execution in stuff like LINQ or Spark)

That’s actually pretty good. Most people would use three more lines to create a temporary and break after setting it, and three to nine more depending on how many steps require idiomatic Go error handling.

Would most people actually do that? That example seems like pretty idiomatic Go. I imagine junior developers would write that.

Re: New case studies about Google’s use of Go

#225

Post by kovac »

_y5hn wrote: post #221
eweise wrote: post #177

Earlier quoted context omitted.

I get the feeling that Go programmers came from some other imperative language and got burned by some OO features. I feel kind of bad for them. I hope they never discover modern functional features or they will realize how much of their life was wasted writing pointless boilerplate.

What you feel about what you don't understand, isn't really important to anyone else though. Go provides less is more as a feature, but would be invisible unless the dev cared about seeking simplicity and performance.

Go is not simple (conceptually) by any strecth of imagination. Golang has pointers bolted on as if they are a real thing. Like, what's the point of exposing pointers without the pointer arithmetic when modern languages have come up with simpler ways to think about accessing memory? So, as a Go developer are you supposed to understand pointers or not? Similarly with Go routines, people boast about them as if they are a silver bullet for concurrent programming. But then, you also have and need to use sync primitives like mutexes sometimes. So, you still need to understand accessing shared mutable state and it's challenges well to use Go which is the actually complex part of concurrent programming. So, I don't know what people mean when they say Golang is simpler. I find it an ugly, weird and a hyped up language. The languages I consider simple are C and Python. C is simple because it's a small language and Python because it truly abstracts away the low level details. Golang is an opinionated (an quite an unimpressive) language with pros and cons like any other language. Currently, with more cons than pros, IMHO.

Re: New case studies about Google’s use of Go

#226

Post by pansa2 »

pansa2 wrote: post #206
solidasparagus wrote: post #118

Earlier quoted context omitted.

TS and Golang aren't comparable. I use both and I've never had a case where I needed to decide between the two. Golang is a high performance, modern language without the low-level or legacy headaches of comparably performant languages. Golang was written for an era where network communication and concurrency are commonly necessities and those use cases feel very natural. Typescript is JS (a conversation ending advant…

> Golang is like Python [...] Fast to implement, easy to read I disagree. Python is often described as "executable pseudocode" - for example, to delete the `i`th element from a list `a` you use `del a[i]`. In Go, it's much more convoluted: `a = append(a[:i], a[i+1:]...)`. Plus, without generics, you can't even easily hide that inside a function! There's a whole page of these "tricks" that are necessary to perform bas…

> `a = append(a[:i], a[i+1:]...)`

Not only is this ugly and unintuitive (“what function do I call to delete an element?”; “append”), according to the linked page it can also cause a memory leak?!

Re: New case studies about Google’s use of Go

#227

Post by nedsma »

tigershark wrote: post #166
nedsma wrote: post #94

Go is super productive. My day-to-day responsibilities include development in .NET and Go. A full day working in Go is like a having a pleasant day off. On the other hand, .NET is so cumbersome, complex and verbose (I've been using it since its inception), that I'd rather abandon it for good if possible.

.NET is not a language. Are you using C#, VB.NET or F#?

You're absolutely right. In majority of cases, when people say .NET, they mean .NET & C#. VB.NET or F# are pretty much always explicitly mentioned as they're not the default choice for .NET development.

Re: New case studies about Google’s use of Go

#228

Post by erik_seaberg »

andykx wrote: post #224
erik_seaberg wrote: post #201

Earlier quoted context omitted.

That’s actually pretty good. Most people would use three more lines to create a temporary and break after setting it, and three to nine more depending on how many steps require idiomatic Go error handling.

Would most people actually do that? That example seems like pretty idiomatic Go. I imagine junior developers would write that.

I would typically expect

  anyBlue := false
  for _, c in range col {
          ready, err := c.IsReady()
          if err != nil {
                  return nil, fmt.Errorf("isReady failed: %v", err)
          }
          if !ready {
                  continue
          }
          x, err := ConvertToX(c)
          if err != nil {
                  return nil, fmt.Errorf("convertToX failed: %v", err)
          }
          color, err := x.GetColor()
          if err != nil {
                  return nil, fmt.Errorf("getColor failed: %v", err)
          }
          if color == BLUE {
                  anyBlue = true
                  break
          }
  }
which badly obscures what’s going on but demands no cleverness at all (except that some might forget the “break” and still get the right answer).

Re: New case studies about Google’s use of Go

#229

Post by pasabagi »

pansa2 wrote: post #226
pansa2 wrote: post #206

Earlier quoted context omitted.

> Golang is like Python [...] Fast to implement, easy to read I disagree. Python is often described as "executable pseudocode" - for example, to delete the `i`th element from a list `a` you use `del a[i]`. In Go, it's much more convoluted: `a = append(a[:i], a[i+1:]...)`. Plus, without generics, you can't even easily hide that inside a function! There's a whole page of these "tricks" that are necessary to perform bas…

> `a = append(a[:i], a[i+1:]...)` Not only is this ugly and unintuitive (“what function do I call to delete an element?”; “append”), according to the linked page it can also cause a memory leak?!

On the other hand, it's very clear about what's actually happening when you delete an element of an array.

I'm not a C guy, but I figure doing this in C would involve several lines of mmemove, with loads of error checking[1]. So the Go version is about as ergonomic as you can get without obscuring what's going on.

[1] - I guess you'd do something like: memmove(a+i+1, a+i, sizeof(element) * (a->len - i)) with a whole load of checks to make sure everything's in order. I think C has the advantage of being utterly explicit about what is actually happening, but I think a higher level thing like append() is kind of nice when you don't want to think hard about, say, inserting an element in the middle of an array.

Re: New case studies about Google’s use of Go

#230

Post by pkolaczk »

mjevans wrote: post #103
piazz wrote: post #84

I played around with Go a while ago, and while I appreciated the approach to concurrency, I was really put off by both the boilerplate + how primitive the type system felt. Not having map and filter due to lack of generics meant writing for loops all over the place just to filter and modify arrays. Appending elements to slices felt clumsy. The type system didn't feel expressive, and I often found myself having to res…

The use of an Interface type in Go is a good sign that either the data or the logic flow isn't optimized for static analysis and optimizations. The most common case I happen to have run across is the result of parsing data or configuration files; situations where there might be structure, but all of it is optional. PS: Your "algebraic data types / sum types" sounds very much like interface composition, a ReaderWriter…

Interface composition is product of types, not sum.
Post reply on HN