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

51–60 of 219 posts

Re: Go 1.27 Interactive Tour

#51

Post by ad_hockey »

drivebyhooting wrote: post #11

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

As of June last year[1] the Go team have pretty much drawn a line under this issue, with a very small amount of wiggle room to possibly reopen it at some point:

"For the foreseeable future, the Go team will stop pursuing syntactic language changes for error handling. We will also close all open and incoming proposals that concern themselves primarily with the syntax of error handling, without further investigation.”

Personally I'm OK with this, I didn't see any of the (many) proposals as a definite improvement. They all had trade-offs.

[1] https://go.dev/blog/error-syntax

Re: Go 1.27 Interactive Tour

#52

Post by MartinodF »

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

Say you have some code that does a request to an HTTP/1 dependency, and if it get an error response, just closes the connection without reading the response body.

Go 1.26 in practice never re-used that connection, it always established a new one because you can't reuse a connection which has a pending response ready to be read.

Go 1.27 will now consume the body for you, causing your application to re-use connections much more aggressively, bringing in potential edge cases (e.g. dependency is broken, connection is now permanently unusable, your app no longer recovers automatically).

To be clear, I'm very glad for the change and I had equivalent code in our in-house framework to do just that, but yeah it does change the behavior in a way that it could expose undetected issues.

Re: Go 1.27 Interactive Tour

#53

Post by adrianmsmith »

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.

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.

Re: Go 1.27 Interactive Tour

#55

Post by neilprosser »

my-next-account wrote: post #46

>The quieter but bigger change I really wish they didn't use such stupid LLM-isms.

I do wonder whether, as a group of people being regularly exposed to text written by LLMs, we'll gradually end up writing and talking like that in our normal language. At that point perhaps text written by LLM and human will be indistinguishable. I already find myself using terms like 'footgun' in jest more than I ever did before!

"The creatures outside looked from pig to man, and from man to pig, and from pig to man again; but already it was impossible to say which was which." ― George Orwell, Animal Farm

Re: Go 1.27 Interactive Tour

#56

Post by adrianmsmith »

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…

> What people want generic methods for is to do deeply nested call chains

I don't see that as the only use of generic methods.

The example in the article is a "Map" method that transforms e.g. a List[A] to a List[B], by taking a function that takes an A and returns a B. To be able to transform a list like that is a useful operation.

It was possible to do the same with a global function like MapList but the syntax is nicer if you use methods. You don't need the type in the name (function MapList vs method Map) and it is an operation on the List after all so list.Map(..) is nicer than MapList(list, ..).

Re: Go 1.27 Interactive Tour

#57

Post by jiehong »

adrianmsmith wrote: post #50
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.

We all know letters are expensive ^^

Re: Go 1.27 Interactive Tour

#58

Post by phplovesong »

adrianmsmith wrote: post #50
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.

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.

Re: Go 1.27 Interactive Tour

#59

Post by fweimer »

> interfaces still can’t declare type-parameterized methods

What would an implementation look like? Wouldn't it be quite different from the existing one because it has to rely heavily on indirection because (limited) monomorphimization is not possible?

Re: Go 1.27 Interactive Tour

#60

Post by spockz »

adrianmsmith wrote: post #50
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.

Completely agree and I personally name generic type parameters as I would name types and parameters. It helps a lot.
Post reply on HN