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

Go Replaces Interface{} with 'Any'

github.com

Post reply on HN
Print view View original

171–180 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#171

Post by tptacek »

linkdd wrote: post #138
tptacek wrote: post #135

Earlier quoted context omitted.

A lot of people are going to write very un-idiomatic Go code with "Result" types built on simple generics that, 5 years from now, we'll all be kind of smirking at. Rust's Option and Result make sense because the language supports it (most importantly with match statements). They don't make sense here.

Fun observation of mine: most articles/tutorials I've read about "idiomatic go code" are presenting ideas that you never see in any production code. Seems to me that the ones who write about "idiomatic go code" aren't the ones who are shipping softwares/libraries.

This seems pretty glib. There's pretty obviously a phenomenon where people try (or used to try) to write code for other languages (less commonly Rust, more commonly Ruby) in Go, and that code is kind of notoriously uncooperative with the rest of the ecosystem and hard to maintain. You'll find it in Go web stack libraries, in particular, or with code for people who tried to fake generics with codegen.

Re: Go Replaces Interface{} with 'Any'

#172

Post by cozzyd »

socialdemocrat wrote: post #152
keithnz wrote: post #39

Earlier quoted context omitted.

Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with…

Get your point, but I kind of like it. It tells some really important info, and they are hardly alone. Python 3.x was breaking change. Until they they stayed in 2.x versioning a long time. And we will never see a Python 4.x

But many languages try really hard not to make breaking changes. With good reason...

Re: Go Replaces Interface{} with 'Any'

#173

Post by tptacek »

linkdd wrote: post #147
randomdata wrote: post #139

Earlier quoted context omitted.

Go exceptions do carry stack trace information. However, the topic is errors, not exceptions. Those are very different concepts. Of what use is stack trace information in debugging values that you have assigned error meaning to when not other types of values? If you had a function func add(a, b int) int { return a * b } there would be no expectation of carrying a stack trace to debug it. So what's different about fun…

Current state of the art: func read_file(filename string) (string, error) { return "", errors.New("oops") } func foo() error { a, err := read_file("a.txt") if err != nil { return errors.New(fmt.Sprintf("read a: %s", err)) } b, err := read_file("b.txt") if err != nil { return errors.New(fmt.Sprintf("read b: %s", err)) } // do stuff with a and b return nil } func main() { err := foo() if err != nil { fmt.Fprintln(os.St…

This is definitely not the current state of the art. Errors are values with types just like anything else in the language; dynamically populating calls to errors.New() is super weird (the point of errors.New is mostly to create global errors you can compare against), your errors nest without using %w, and there are a bunch of simple libraries that wrap typed stack traces in errors, just like there are a bunch of simple libraries in Rust that exist to make error types compatible with each other.

Re: Go Replaces Interface{} with 'Any'

#174

Post by tptacek »

linkdd wrote: post #169
randomdata wrote: post #161

Earlier quoted context omitted.

> It implies that the expected behavior is the "happy path" (everything went well) and any deviations (errors) is unexpected. Errors are the "happy path", though. Your network connection was lost for the data you were trying to transmit so you saved it to your hard drive instead means that everything went well! Throwing your hands up in the air and crashing your program because you had to make a decision is not somet…

> Throwing your hands up in the air and crashing your program because you had to make a decision is not something you would normally want to do And that's not something you do thanks to try/catch. You just handle the error where it's meaningful to handle it. The happy path of "make a request" is that there is no network error. The happy path of "make sure this request is sent" is that you handle the unexpected networ…

You don't. That's why Go errors are typed. You use `errors.Is` to check if any of the errors in a chain of wrapped errors is of a particular kind. It doesn't grovel through strings to answer that question.

It is very weird that this subthread starts with "current state of the art".

Re: Go Replaces Interface{} with 'Any'

#175

Post by xyzzy_plugh »

linkdd wrote: post #100
egeozcan wrote: post #97

Earlier quoted context omitted.

I don't see why that wouldn't be possible to implement now that the generics are here.

Which is exactly why I said: > I cannot wait for the Result monad. Generics make this possible, and will be a huge improvement to Go's error handling. I'm not saying it will solve everything, but it's a huge step nonetheless.

I think you will find that Go's error handling will not change as much as you suggest. The majority of developers are extremely cautious of generics and found the status quo to be the best balance between readability and conciseness.

Convenience is not a goal of the language, generally.

Re: Go Replaces Interface{} with 'Any'

#176

Post by benhoyt »

hbn wrote: post #62
kbd wrote: post #32

This is fantastic. It'll make Go feel much less weird. eg from the diff: []interface{}{1, 2.0, "hi"} -> []any{1, 2.0, "hi"} Now that Go is going to have generics, all we need is sugar syntax for early return on error -- like more modern languages such as Rust and Zig have -- and Go may finally be pleasant to program in!

It's definitely more streamlined, but my concern would be that newcomers might not understand that it's just an alias. Learning Go really reframed my concept of what an interface is, and I thought that using an empty interface to represent "any type" was kind of ingenious, and helps reinforce its ethos. An empty interface can represent any type because every type inherently implements an interface with no methods. An…

Counterpoint: I'm an experienced Go dev but still think of "interface{}" as a semi-special "any" type, just because it fits my brain better conceptually. "Any type" is simpler than "an interface with an empty method set, which is of course matched by any type". I think this is a win.

Re: Go Replaces Interface{} with 'Any'

#177

Post by gepoch »

rackjack wrote: post #27

I'd really like it if Github handled massive commits like this one better. The way they present it is not very pleasant to navigate.

Same.. This is just a mirror though, so at least you can browse it more sanely over on Gerrit.

https://go-review.googlesource.com/c/go/+/368254

Re: Go Replaces Interface{} with 'Any'

#178

Post by lmarcos »

karmanyaahm wrote: post #87
AtNightWeCode wrote: post #56

Like it! Now, can they continue to add more “useless” improvements like while-loops and so on.

https://go.dev/tour/flowcontrol/3 for sum < 1000 { sum += sum }

While using `for` for that particular snippet of code is understandable, you cannot say that

    while sum
reads better (like English).

Re: Go Replaces Interface{} with 'Any'

#179

Post by notthathardbro »

It's fun to imagine trying to wander into a Go community ~4 years ago and suggest that this might happen. I actually feel small and withdrawn just thinking about it.

Boy, I still remember when I go shit on by Real Go Devs who insisted there was never a need for more than one GOPATH or real dep management. And raged when I gave countless examples of how large Go projects (cough k8s) were doing all sorts of ... creative stuff... to accomodate The Google Way.

Re: Go Replaces Interface{} with 'Any'

#180

Post by geodel »

linkdd wrote: post #88
Thaxll wrote: post #63

Earlier quoted context omitted.

Well it's better than most language with exceptions. People makes it a big deal, in reality it's not.

An exception has a stacktrace. This single piece of information is crucial when you debug and makes handling errors in Golang embarrassing. I rest my case.

Yea, I am not really fan of 1000 line stack trace for an error in single line. I like Go's error handling better. Also it is clear you like error handling in Rust/Java etc which is fine. Exaggerating over how bad error handling in Go is hardly productive when a) many people do like it b) people can switch language when error handling primary concern over everything else.
Post reply on HN