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

291–300 of 327 posts

Re: Six years of Go

#291

Post by lobster_johnson »

pcwalton wrote: post #286
lobster_johnson wrote: post #283

Earlier quoted context omitted.

I think history has absolutely shown that exceptions are not the best solution; they don't scale, as you point out. And I agree with Go that errors are values, and should be passed around as such. Go basically tells us that errors are as really important — they should be in your face and handled by the caller. And then it goes ahead and makes it a second-class citizen that is really awfully laborious to work with. Wh…

> Go basically tells us that errors are as really important — they should be in your face and handled by the caller. And then it goes ahead and makes it a second-class citizen that is really awfully laborious to work with. Why not make error-handling a first-class construct? Not only that, it's very easy to just dump errors on the floor, which is why Golang needs tools like errcheck. For an easy example of this in pr…

Wow, people do this? I did have an error go unnoticed recently, but it was like this:

  v1, err := doStuff()
  if err != nil {
    return
  }
  var v2 MyStruct
  if value != nil {
    v2, err = doMoreStuff(
      some_param,
      different_param,
      one_more_params)
  }
  // ... use v1 and v2
  err = doYetMoreStuff()
I didn't catch the orphan err because I absent-mindedly focused on the parameter list to doMoreStuff() and just didn't see it.

But I find it frustrating that Go will, on the one hand, angrily refuse to compile a program where a variable is unused, but on the other it will happily accept a program where a value is never used. Isn't that potentially as bad? I'd rather have it complain and force me to assign to _ if I really wanted to discard it.

Re: Six years of Go

#292

Post by lobster_johnson »

grey-area wrote: post #252
lobster_johnson wrote: post #203

Earlier quoted context omitted.

What I don't understand is the people who say Go doesn't need generics. Go already has generics: channels, maps, make(), len(), range, etc. are all generic. Nobody can argue that generics in Go isn't extremely useful. After all, you couldn't have typed channels without generics. One has to be pretty obtuse to argue that the utility afforded by Go's internal generics wouldn't extend to the language as a whole; that so…

This is a good summary: https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX...

It's extremely incomplete. They enumerate some challenges, but don't investigate languages where generics is apparently a solved problem. Whole sections are blank, especially — and perhaps revealingly — the ones that are about less C-like languages such as Haskell and OCaml.

I wonder how the situation compares to Swift, Rust and Nim, three recent languages that have managed to implement generics without (as far as I know) a single complaint, and without descending into C++ madness.

Re: Six years of Go

#293

Post by existencebox »

tptacek wrote: post #281
matthewmacleod wrote: post #170

I have a bit of a love-hate relationship going on with Go. On one hand, it addresses many of the pain points I've experienced with other languages. It's easy to build and deploy, reasonably performant, and has a powerful and consistent standard library. On the other… developing in it feels like a total slog. It manages to be simultaneously far too anal and overly forgiving about syntax. Visibility definition using up…

It's like most languages: if you go in hoping to write in the style of your favorite previous language, the language is going to resist you. Python does the same thing to you if you want to write in functional style. Ruby also punishes you if you want custom data structures (it's the Rails community that coined the term "golden path", right?). If you've got loads of duplicated code due to lack of generics, you may no…

I don't disagree with your conclusion necessarily, especially given that I'm speaking from a position of ignorance with respect to Go, but I'm surprised by your statement about python and functional style. Coming from Ocaml, I found python to be one of the more accommodating languages in terms of maintaining the style I had built up in the former. (I do certainly acknowledge many examples for which this contradicts, immutability being a major point, but I can think of more situations where I was able to use similar design patterns than when I wasn't.) What in particular did you find lacking?

This all may be the ramblings of someone basing their opinions on "code I've written that has worked" and not on some higher standard of design patterns, so feel free to ignore if that's not productive :)

This ties into other thoughts I have rattling around about treating languages as specialty tools with well prescribed patterns, vs the trend to implement some subset of common lisp as the saying goes, but not well formulated enough to expound on them here. Broadly; I'm not sure which paradigm I prefer. (Having a big toolbox of specialty tools is nice, but if one tool can easily eat the functionality of another tool, I tend to side on considering that option.)

Re: Six years of Go

#294

Post by kasey_junk »

tptacek wrote: post #281
matthewmacleod wrote: post #170

I have a bit of a love-hate relationship going on with Go. On one hand, it addresses many of the pain points I've experienced with other languages. It's easy to build and deploy, reasonably performant, and has a powerful and consistent standard library. On the other… developing in it feels like a total slog. It manages to be simultaneously far too anal and overly forgiving about syntax. Visibility definition using up…

It's like most languages: if you go in hoping to write in the style of your favorite previous language, the language is going to resist you. Python does the same thing to you if you want to write in functional style. Ruby also punishes you if you want custom data structures (it's the Rails community that coined the term "golden path", right?). If you've got loads of duplicated code due to lack of generics, you may no…

Your code in Go almost certainly does use generics. Just not user defined ones. I don't particularly want to argue the generic point as I believe it is beat to death. But I could use a good concurrent map in Go in dozens if not hundreds of places.

I could use a lock free ring buffer in dozens of places. I could use promise/futures in dozens of places. I could use anything but the big honking lock that is channels in dozens of places.

I could use proper variance rules in the generics Go does provide in dozens of places. I could use monadic style errors and options in dozens of places.

Now, I agree that I generally don't need to write my own generic code very often, but if the blessed generic writers on the go lang compiler team don't write these things for me, I don't have a fall back option in Go (other than code gen, which people are starting to fall back on). It just seems unsustainable to me.

Re: Six years of Go

#295

Post by tptacek »

kasey_junk wrote: post #294
tptacek wrote: post #281

Earlier quoted context omitted.

It's like most languages: if you go in hoping to write in the style of your favorite previous language, the language is going to resist you. Python does the same thing to you if you want to write in functional style. Ruby also punishes you if you want custom data structures (it's the Rails community that coined the term "golden path", right?). If you've got loads of duplicated code due to lack of generics, you may no…

Your code in Go almost certainly does use generics. Just not user defined ones. I don't particularly want to argue the generic point as I believe it is beat to death. But I could use a good concurrent map in Go in dozens if not hundreds of places. I could use a lock free ring buffer in dozens of places. I could use promise/futures in dozens of places. I could use anything but the big honking lock that is channels in…

That's a fair point: the fact that Go seems to have a few hardcoded generics is one of the uglier bits of the language.

I don't think Go is a great language, as I'm fond of saying, I just think it's a very useful tool.

Re: Six years of Go

#296

Post by kasey_junk »

tptacek wrote: post #295
kasey_junk wrote: post #294

Earlier quoted context omitted.

Your code in Go almost certainly does use generics. Just not user defined ones. I don't particularly want to argue the generic point as I believe it is beat to death. But I could use a good concurrent map in Go in dozens if not hundreds of places. I could use a lock free ring buffer in dozens of places. I could use promise/futures in dozens of places. I could use anything but the big honking lock that is channels in…

That's a fair point: the fact that Go seems to have a few hardcoded generics is one of the uglier bits of the language. I don't think Go is a great language , as I'm fond of saying, I just think it's a very useful tool.

Been doing Go dev for over a year now, in a place where I can make the language decisions, so I clearly agree.

But it being a good tool should not be a deterrent from it becoming a better tool.

[edit] Edited to sound lest strident.

Re: Six years of Go

#297

Post by spopejoy »

bsuh wrote: post #271
rylee wrote: post #200

Earlier quoted context omitted.

`#go-nuts` is a very angry place.

I tried to go there to ask some questions while picking up the language, and what I got was RTFM, where manual includes the language specification, Effective Go book, and A Tour of Go. Apparently you're unfit to ask a question unless you know everything about the language already. Killed my excitement for learning the language.

What languages have nice IRCs? I ask b/c I was very pleasantly surprised by the extremely civil and noob-helpful #haskell.

Are there other nice ones out there? Good to know...

Re: Six years of Go

#298

Post by rdtsc »

lobster_johnson wrote: post #283
tptacek wrote: post #280

Earlier quoted context omitted.

I felt very much the same way about Go's error handling; that, coupled with straight-line synchronous-style socket programming, made me feel like I was writing the same dumb C code I did when I was a teenager in the mid-90s. I've come to believe that slicker error handling is a bit of a false economy, at least compared to other "informal" languages like Java, Ruby, and Python (all bets are off if you want to compare…

I think history has absolutely shown that exceptions are not the best solution; they don't scale, as you point out. And I agree with Go that errors are values, and should be passed around as such. Go basically tells us that errors are as really important — they should be in your face and handled by the caller. And then it goes ahead and makes it a second-class citizen that is really awfully laborious to work with. Wh…

> I think history has absolutely shown that exceptions are not the best solution;

Good point but exceptions or explicit handling (even with sum-type like in Rust) are not the only ways. There is also the crash-and restart way, Go has some with panic, Rust, Erlang is probably king here, can do it with OS processes as well. That of course, has to be handled well by the runtime, so either no shared memory so corruption doesn't spread arbitrarily throughout the application or provable compile time checking (like Rust).

Re: Six years of Go

#299

Post by fixermark »

jstoiko wrote: post #249
fixermark wrote: post #199

I recently implemented a RESTful resource mapper in go, which just accepts some basic parameters and an exemplar of a storable structure and wires up all the HTTP endpoints necessary to give users CRUD access to the resource. I'm honestly very happy with how straightforward it was, even lacking generics---I solved the problem of no generics by basing the resource creation and management on JSON and a "Storable" inter…

Would you care to share some code example?

Happy to; I'll share the whole thing.

http://pastebin.com/qBh6NRXc

It's not cleaned up for easy reading (hell, I haven't even run `go fmt` on it ;) ). But it has unit tests and seems to work. ;)

One thing worth noting is that it relies on the Storables to also be tagged with necessary JSON. It occurs to me that I could also have used tags instead of the key() function in the interface to specify which field in the Storable should be the resource name; key() is a bit more flexible in that the function could calculate the name using any method though.

Re: Six years of Go

#300

Post by rdtsc »

fixermark wrote: post #196
placeybordeaux wrote: post #150

Earlier quoted context omitted.

Yeah I have been bitten by the _'ing errors thing in the go community.

Given other aspects of Go's design, I'm actually a little surprised that Go makes it as easy to drop errors on the floor as it does. It feels like the language's strict checking of unneeded or missing imports and its lack of checking for capture of return values are philosophically at odds.

If compiler did it, how else would they get to chide people in people on bad style ;-)

But yes, good point. I think a better type system should handle it and make it harder to drop errors on the floor. But that kind of asks for Rust's like sum-type which is too close to generics for their comfort.

Post reply on HN