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

Go 1.27 Interactive Tour

victoriametrics.com

Post reply on HN
Print view View original

41–50 of 219 posts

Re: Go 1.27 Interactive Tour

#41

Post by nitrix »

jerf wrote: post #16
drivebyhooting wrote: post #11

Can generics be used to improve error handling and eliminate the if err pattern?

No. I kind of want to leave it there. But that will probably be looked on disfavorably. I've seen at least a dozen attempts. It's not like it's hard to write it out. There's maybe a couple of variants but they're all just a handful of lines. The problem is, once you have an Option in hand, you end up trading: val, err := whatever(...) if err != nil { // handle error } // use val for val := whatever(...) if err, isErr…

Error handling is as important as the happy path of an application. It’s not something you sweep under the rug.

The err != nil quickly turns into metrics, logs, fallback strategies, retry mechanisms, flight recording, rate limiting, updating caches, so on.

Anyone who’s trying to shorten this hasn’t maintained any actual real software.

Re: Go 1.27 Interactive Tour

#44

Post by stingraycharles »

fooster wrote: post #10
stingraycharles wrote: post #4

Am I the only one who’s absolutely shocked that Go finally is embracing generics? Does anyone have a bit of an inside view into what changed in the perspectives of the language maintainers? I’m not buying the “it took us 20 years to understand how to do it correctly” argument, as this is something you explicitly take into consideration when designing the language or not. And it was specifically not a part of language…

It’s also not true that because it wasn’t part of the initial design that it was harder to retrofit. I just don’t understand all this go bashing that happens on this site especially when so much is badly informed speculation. I guess it’s easier to tear something down.

my post was never intended as Go bashing, I use Go a lot and appreciate its simplicity.

am I tearing something down in my comment?

Re: Go 1.27 Interactive Tour

#45

Post by foldr »

EdiX wrote: post #35
nothrows wrote: post #22

generics were a slippery slope. give it a decade and Go will be indistinguishable from c++

Generics themselves maybe not. Generic methods probably yes. What people want generic methods for is to do deeply nested call chains that were never typical of Go. And if you have deeply nested calls you'll need some way to deal with errors in deeply nested calls, and then a short function syntax to pass to behavior inside those deeply nested calls. Give it a few years and everyone will be writing the same functional…

The generic methods that have been added are essentially just syntax sugar. You can now use method syntax in cases where you could equivalently define a function. They’re not the fundamental extension to the type system that some people have been asking for (and probably will never get, because there’d be no reasonable way to implement it).

Re: Go 1.27 Interactive Tour

#47

Post by mappu »

gigatexal wrote: post #40
mappu wrote: post #13

Automatically draining http response bodies is a risky silent behaviour change. I think it will be an improvement for most applications, but it's very subtle if you were relying on the old behaviour

Can you go more into this? I don’t quite follow

Go's http.Client will keepalive a TCP/TLS connection to save you handshake latency on second requests. But it can only do this if you completely finish reading the last request.

Now in 1.27:

> http.Response.Body drains itself on Close. For HTTP/1, closing the body now reads and discards any unread content (up to a conservative limit) so the connection can be reused. For most programs this is a transparent win [...]

Great, so i no longer have to io.Copy(io.Discard, resp.Body) in the err case, one less thing to worry about; but

> if you were leaning on an early Close to abort a large download, set Transport.DisableKeepAlives to opt out.

That's a subtle behaviour change. Any previous Go program which used Close in this way - say for an infinite event stream - now hangs, soaking up bandwidth.

In the past, the Go team have searched the entire Github corpus for misuse before making changes like this. I don't have a reference but I assume an appropriate level of consideration went into this decision.

EDIT: ""up to a conservative limit"" so this is not so bad after all.

Re: Go 1.27 Interactive Tour

#48

Post by kune »

mappu wrote: post #13

Automatically draining http response bodies is a risky silent behaviour change. I think it will be an improvement for most applications, but it's very subtle if you were relying on the old behaviour

The Go team is addressing that in the release notes: https://go.dev/doc/go1.27 They think it will only affect use cases where a high number of idle connections were allowed to linger, for instance by setting MaxIdleConns in Transport to 0. They recommend to disable keep alives in that case.

Re: Go 1.27 Interactive Tour

#49

Post by foldr »

stingraycharles wrote: post #44
fooster wrote: post #10

Earlier quoted context omitted.

It’s also not true that because it wasn’t part of the initial design that it was harder to retrofit. I just don’t understand all this go bashing that happens on this site especially when so much is badly informed speculation. I guess it’s easier to tear something down.

my post was never intended as Go bashing, I use Go a lot and appreciate its simplicity. am I tearing something down in my comment?

HN threads on Go are boring because they always get derailed by someone grousing about the fact that it took a long time to add generics. The history of this has been gone over a thousand times already and it’s really quite undramatic. The Go team couldn’t figure out a good design for generics for a long time. Eventually, they got some help from Phil Wadler and other type system experts and figured it out. The end. Anyone who feels that the Go team should have done it faster owes us at the very least their own design together with a soundness proof for a plausible fragment of Go. Conspicuously, no-one provided such a thing before the Go team did.

The details of Go generics, their advantages and disadvantages compared to other languages, etc., are absolutely interesting to discuss. But there is nothing hiding behind the “official” story.

Re: Go 1.27 Interactive Tour

#50

Post by adrianmsmith »

baalimago wrote: post #42

This: "(b Box[T]) Map[U any](f func(T) U) Box[U]" is the type of cognitive weight I was happy that Go avoided.

I never understood the convention of using single letter names for generic parameters. I guess this started in C++ and every language has copied that convention.

I think that code would be a lot easier to read if the types were called IN and OUT or In and Out or TIn and TOut or something like that.

Post reply on HN