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

61–70 of 219 posts

Re: Go 1.27 Interactive Tour

#61

Post by spockz »

mappu wrote: post #47
gigatexal wrote: post #40

Earlier quoted context omitted.

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 [...] G…

Is “a conservative limit” a high limit or a low limit? If it is high such that many responses will still be drained it would keep reading those infinite streams for a long time. If it is low it might still not drain all normal sized messages.

Anyway, this is why it pays off to read release notes closely and have a decent test suite.

Re: Go 1.27 Interactive Tour

#63

Post by twsted »

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 really understand your feeling, I escaped from C++ years ago when I was overwhelmed by meta programming (initially i loved it).

But anyway I find this in Go much more bearable.

Re: Go 1.27 Interactive Tour

#64

Post by spockz »

adrianmsmith wrote: post #53
drivebyhooting wrote: post #24

Earlier quoted context omitted.

I think my opinion will be even more maligned: I like Java-style checked exceptions. It forces awareness of the error and a clean way to propagate it.

People advocate for Go's error handling because it forces you to deal with errors. But in the cases I do want to catch a specific error, the signature only tells me that a function returns an error, not which type. So I do feel that returning (int, error) is strictly worse than Java's checked exceptions if you care about errors.

This is elegantly solved with sum types. (And arguably needs sub typing.)

If instead of just returning (int, error) the function would return (int, parseError | outOfBoundsError) you would know that the parser function can fail on reading a number at all and on the number being to big/small to fit the type and handle then accordingly.

Saliently, Java in a sense has supported sum types in the throws declaration and the subsequent catch statements forever. Unfortunately it has not landed in other places where you can use types so you cannot use it for returning errors. Scala 3 supports this but has tiny adoption it seems.

Re: Go 1.27 Interactive Tour

#67

Post by kitd »

adrianmsmith wrote: post #53
drivebyhooting wrote: post #24

Earlier quoted context omitted.

I think my opinion will be even more maligned: I like Java-style checked exceptions. It forces awareness of the error and a clean way to propagate it.

People advocate for Go's error handling because it forces you to deal with errors. But in the cases I do want to catch a specific error, the signature only tells me that a function returns an error, not which type. So I do feel that returning (int, error) is strictly worse than Java's checked exceptions if you care about errors.

That's helped by errors.Unwrap() and errors.Is(), though you do need to build and structure your errors appropriately.

Re: Go 1.27 Interactive Tour

#68

Post by mook »

drivebyhooting wrote: post #24
jerf wrote: post #16

Earlier quoted context omitted.

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…

I think my opinion will be even more maligned: I like Java-style checked exceptions. It forces awareness of the error and a clean way to propagate it.

I agree; in practice, probably only the public error types, though. If it can return fmt.Errorf("…%w…") I probably only need the type of the wrapped error, not whatever type the implementation uses.

Re: Go 1.27 Interactive Tour

#69

Post by fauigerzigerk »

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.

It's hard to avoid, because (naming aside) the cognitive load is caused by higher order functions, which are hard avoid without causing massive code duplication.

I understand the desire to keep things concrete and avoid high level abstractions, but it's a decision not to automate stuff that can easily be automated. It runs counter to the basic instincts and purpose of our field/industry. That's why it never sticks.

Re: Go 1.27 Interactive Tour

#70

Post by asQuirreL »

phplovesong wrote: post #58
adrianmsmith wrote: post #50

Earlier quoted context omitted.

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.

Im pretty sure it came from the MLs, where you usually have a/b/c instrad of the T,U etc combo. I dont find it confusing, as its pretty clear that it only an placeholder. In generics the name usually does not matter or is REALLY hard to name so that it makes sense. More specifically in Go where you have interfaces, concrete types and generics.

Fairly sure it would predate even that, and go all the way to lambda calculus, and predicate logic before that, and that's where my knowledge stops and somebody else can tell us where the current conventions around variables in logic and mathematics come from.
Post reply on HN