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

Six years of Go

blog.golang.org

Post reply on HN
Print view View original

211–220 of 327 posts

Re: Six years of Go

#211

Post by nickbauman »

vox_mollis wrote: post #206
nickbauman wrote: post #100

Earlier quoted context omitted.

Go's concurrency is limited to the CSP-style and favors share nothing problems. Languages like Clojure can do CSP just fine, but also have powerful language-level support for heterogeneous concurrency problems that are easy to use and easy to understand.

This isn't remotely true. CSP via goroutines and channels is idiomatic Go, but it's not the only option. Go offers mutexes and other concurrency primitives which, along with goroutines as lightweight thread analogues, allow what you're looking for.

.. mutexes limit you to the locking paradigm. You know there's more/better out there, right? If you want an actor / agent model you still must do this with mutexes channels and goroutines, resulting in some pretty fugly code, more so than normal go code.

Re: Six years of Go

#212

Post by kornish »

spotman wrote: post #197
bkeroack wrote: post #192

Earlier quoted context omitted.

You either "get" Go or you don't. Which shouldn't be surprising given that it is a very opinionated language. A diagnostic indicator is whether you gravitate towards things like Martini or Gin, which aren't idiomatic Go and seem designed to ease the pain of using Go for those who don't actually care for it much.

Curious your opinion on what you would advise if not Martini or Gin? I love martini (and lately gin) and definitely love and use go every day. What about these frameworks is not idiomatic go? Is there another framework that is? Or you suggest just rolling your own using net/http by itself? Cheers

Here's a great blog post by the author of Martini about why, after he had gained experience in Go, he came to realize that Martini isn't very idiomatic: https://codegangsta.io/blog/2014/05/19/my-thoughts-on-martin...

tl;dr - Martini doesn't have a strict, type-safe API. Overuse of reflection leads to a small performance loss but a much larger, much more important cognitive tax.

Re: Six years of Go

#213

Post by sanderjd »

tptacek wrote: post #83
codygman wrote: post #63

I wish the gdb support were better or that delve were more stable. I also had some weirdnesses using cgo on osx. Then I went into #go-nuts on freenode, and I got told I was wrong and there was no problem. Back in 2009 #go-nuts seemed to be a much different place. I write Go at work, and I admire many of the same things in Go I admire about Python. I still wish generics were part of the language and will say their exc…

I've been yelled at on #go-nuts too; I ran into what turned out to be an authentic limitation of Go's I/O scheduling, and was instead chided for _'ing out error results in my minimized example code.

It's really a shame when a community's most visible public channel devolves into "you're doing it wrong"-itude. When I first started looking at Go in 2010 or so, coming from the rails community, I thought it was wonderful how friendly and helpful #go-nuts was. Unfortunately, it seems like an inevitable result of the regulars in a room seeing a deluge of similar questions and increasingly losing their patience. Eventually, everything starts to look like an instance of some annoying newbie pattern with a pat answer, and you have to fight to convince people that there is something novel and non-pat going on.

Re: Six years of Go

#214

Post by bdamm »

drumdance wrote: post #135
coldtea wrote: post #102

Earlier quoted context omitted.

> It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. (...) The reason for the move were few: 1) Ambivalence on Java roadmap So, because there was some "ambivalence for the Java roadmap", a language with multiple implementations, a huge community (including open source), and so entrenched in the industry that will be there in 2100 too, you switched to a 3-4 yea…

Ha. I built my first company on Java back in 1996. It was a terrible decision. Very buggy, lots of BS from Sun & Oracle that was really more about Ellison and McNealy envying Bill Gates. Netscape made a similarly bad decision when they tried to create a pure Java version of the browser. I'm sure Java is 10x better now, but I'm not convinced it will be here in 2100.

It will be, because there is now more Java running business processes than there is Cobol, and Cobol is surprisingly still with us.

Profitable code dies hard.

Re: Six years of Go

#215

Post by lobster_johnson »

plexicle wrote: post #207
lobster_johnson wrote: post #193

Earlier quoted context omitted.

I'm in the same boat. Go's simplicity is initially refreshing, then a huge pain once you find yourself writing the same thing over and over again. A good example is errors being values — which is a great idea. But then you realize every single function needs to be littered 1-10 cases of if err != nil { return nil, err } It's an extremely common pattern. It's tiring to write, over and over. Tiring to refactor, too: If…

I'm not an expert in Go, but can't you inline a statement before the conditional? value, err := bar(); err { // there was an error } I like how that looks, personally. Obviously YMMV.

Actually, that wasn't really the point of my paste. But since you ask: Nearly. You can do this:

  if value, err := bar(); err != nil {
    return err
  }
Note that this syntax declares "value" in the "if" scope. You can only access it inside the "then" block or in an "else" block:

  if value, err := bar(); err != nil {
    return err
  } else {
    log.Print(value)  // this compiles
  }
  log.Print(value)  // does not compile
So if you need it later, you have to do:

  var value MyType
  var err error
  if value, err = bar(); err != nil {
    return err
  }
Note that you cannot do this:

  var value MyType
  if value, err := bar(); err != nil {
    return err
  }
This would, again, declare a new "value" that shadows the outer "value" inside the "if" scope. (Go would fail to compile it since it doesn't allow unused variables.)

Re: Six years of Go

#216

Post by pvg »

tptacek wrote: post #141
aws_ls wrote: post #117

Earlier quoted context omitted.

Lets just put it this way, I bought onto the basic proposition which was offered, after having read Rob Pike's original blog introducing it, and having watched lots of Go team videos. Some points which also went into decision making: 1) I am not a functional language programmer. No disrespect, just stating fact, after having noticed a Lisp programmer having questioned my choice regarding "boredom". So languages like…

If everyone thought this way, our realistic professional choices of languages would be C, C++, and Perl. The exact same things you're saying about Go were things people said about Java --- a language, by the way, with much more harrowing ownership issues than Go, which is an open-source project top-to-bottom.

What do you feel are the much more harrowing ownership issues? If you google 'goroutine leaking' you get a pile of convoluted stuff. I don't mean to language-war, if anything I find 'stuff proponents and detractors said about Java in its early days' eerily similar (and likely as overwrought) to the same said about Go now.

Re: Six years of Go

#217

Post by AnimalMuppet »

kasey_junk wrote: post #17
kris-s wrote: post #12

I picked up the new Go book (gopl.io) and have had a lot of fun going through it. The prevailing feeling of Go is "getting things done". I also write a little Go program every day as practice. If you want a sample of some Go. https://github.com/kris-s/daily-go

> The prevailing feeling of Go is "getting things done". This is a common refrain amongst go proponents and I find it quite distasteful. It either implies those of us who prefer other languages aren't "getting things done" or those who feel productive in Go aren't smart/hard-working/educated/etc enough to "get things done" in other languages. I don't think either is true. I think a more accurate way to look at Go is…

> This is a common refrain amongst go proponents and I find it quite distasteful. It either implies those of us who prefer other languages aren't "getting things done" or those who feel productive in Go aren't smart/hard-working/educated/etc enough to "get things done" in other languages. I don't think either is true.

It could just be the feeling that Go gets out of your way more than other languages do. (For example, people complain about how much ceremony is involved in writing Java. Go could easily feel like "getting things done" in contrast.)

Re: Six years of Go

#218

Post by lobster_johnson »

vruiz wrote: post #210
lobster_johnson wrote: post #193

Earlier quoted context omitted.

I'm in the same boat. Go's simplicity is initially refreshing, then a huge pain once you find yourself writing the same thing over and over again. A good example is errors being values — which is a great idea. But then you realize every single function needs to be littered 1-10 cases of if err != nil { return nil, err } It's an extremely common pattern. It's tiring to write, over and over. Tiring to refactor, too: If…

> If you have "func bar() (MyStruct, error)", you cannot do "foo(bar())". You must always assign the result to an intermediate variable. You could embed the error in the MyStruct struct instead, but that goes against Go's grain. Chaining does work, but obviously the function needs the same signature as the return values, which limits things since most APIs don't accept errors as input. But within your code you can st…

I swear I tried that once, and that it didn't work. Thanks for educating me.

Still, having to let every function take an error parameter isn't really an option, generally.

Re: Six years of Go

#219

Post by csn »

kornish wrote: post #209
plexicle wrote: post #207

Earlier quoted context omitted.

I'm not an expert in Go, but can't you inline a statement before the conditional? value, err := bar(); err { // there was an error } I like how that looks, personally. Obviously YMMV.

It does look better, but `value` will only be accessible inside the block. That's a no-go if you want to perform actions with `value` below.

That is iff you use the shorthand declaration-assign: https://play.golang.org/p/6uGmPZIu4S

Re: Six years of Go

#220

Post by lobster_johnson »

penetrarthur wrote: post #105
jinst8gmi wrote: post #59

I find it curious that virtually any negative or critical comments about Go get downvoted.

Because you don't insult someone when it's his birthday!

On the other hand, honouring people by roasting [1] them is also tradition. Maybe if the criticisms were funnier.

[1] https://en.wikipedia.org/wiki/Roast_(comedy)

Post reply on HN