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

Go Developer Survey 2022 Q2 Results

go.dev

Post reply on HN
Print view View original

171–180 of 186 posts

Re: Go Developer Survey 2022 Q2 Results

#171

Post by dannymi »

metaltyphoon wrote: post #132
klodolph wrote: post #103

Earlier quoted context omitted.

I don't think any option should panic on error. I've had to deal with programs that panic on error and the way I dealt with it was by forking the project and removing every call to panic(). It's even worse with libraries. The other problem is that it's super common to want to wrap the error somehow when returning it. Often you want to wrap the error differently depending on where the error came from in the function,…

Unless you put the function name somewhere in the error, there is no way to know where something happened. "Some thing didn't write properly? Cool! Where and which line?"

If it's an internal (unexpected) error, panic. You get a backtrace and everything--which helps because it was an unexpected internal error, so you probably messed up. You'd like to know where that is.

But if it's an actual user-visible error code then that means you expected for this error to happen eventually and you designed for it. Why then do you need a backtrace? You program is doing what it's supposed to.

I mean sure while developing it's nice to be able to just replace the error code emission by panic (which I do sometimes)--but in regular operation? It doesn't help the user at all.

Re: Go Developer Survey 2022 Q2 Results

#172

Post by todotask »

kitkat_new wrote: post #138
bilinguliar wrote: post #19

I am delighted with the error handling in Go. Overall I would prefer to Go with the current features and not add more, maybe even deleting some inconsistencies in Go v2.

I find that interesting, and like the Rust way of error handling much more. Go error handling blows the code up a lot and makes the code less comprehensible. res1, err1 = canFail() if err1 != nil { return err1 } res2, err2 = canFail() if err2 != nil { return err2 } return res1 + res2, nil becomes res1 = canFail()? res2 = canFail()? return Ok(res1 + res2) guess what is more readable

Exactly that Go code is simple, comprehensible and readable.

Your 2nd code is concise to me.

Re: Go Developer Survey 2022 Q2 Results

#173

Post by JustSomeNobody »

kitkat_new wrote: post #138
bilinguliar wrote: post #19

I am delighted with the error handling in Go. Overall I would prefer to Go with the current features and not add more, maybe even deleting some inconsistencies in Go v2.

I find that interesting, and like the Rust way of error handling much more. Go error handling blows the code up a lot and makes the code less comprehensible. res1, err1 = canFail() if err1 != nil { return err1 } res2, err2 = canFail() if err2 != nil { return err2 } return res1 + res2, nil becomes res1 = canFail()? res2 = canFail()? return Ok(res1 + res2) guess what is more readable

Both.

Seriously. I'm not going to be reading Go code and all the sudden forget what error handling looks like.

Re: Go Developer Survey 2022 Q2 Results

#174

Post by randomdata »

throw_m239339 wrote: post #164
randomdata wrote: post #139

Earlier quoted context omitted.

> these were a bunch of well known gatekeepers in the main go mailing list Celebrity status doesn't make someone's comments any less random. > Let's not try to rewrite history. No need to rewrite anything. It was written right on golang.org for most, if not all, of Go's public life. Though obviously no longer relevant these days. The various generics proposals (eight of them, if I recall correctly) were also publishe…

> The various generics proposals (eight of them, if I recall correctly) were also published publicly. And? It doesn't make go generics "always explicitly on the table", Pike didn't want them and it's profusely documented in his blog. So please don't invent facts now.

You can clearly see in the original Go announcement, hosted by Pike, that generics were presented as "not yet". Not "never". Let's not invent facts. It was indicated from public day one that it would get them eventually, even by Pike himself.

As we all know, Pike is a bit of a troll, so nobody is surprised that his random musings said that they'll never come. But it also was never his project to decide. He was involved to some degree, and you can recognize his influence, but it's really Ken Thompson's baby. Griesemer was the only founding member young enough to not want to retire after the initial work was done, so it soon became his to oversee. Not to mention that ultimately the project is owned by Google, who is capable of squashing Pike like a bug if he wasn't acting in the interest of the company's assets.

Officially, generics were always on the table and would come once a suitable implementation was found. And, guess what? A suitable implementation, after a lot of flawed tries, was found and generics came. Imagine that.

Had the open source community wanted generics more perhaps they would have jumped in and helped Taylor where he was struggling to speed up the process, but such is life. Ultimately people don't care, are lazy, and like to make others do the work for them, all while complaining about it the whole way. Google eventually found a domain expert willing to be hired to close the gaps Taylor was struggling with and the rest is history.

Re: Go Developer Survey 2022 Q2 Results

#175

Post by assbuttbuttass »

beltsazar wrote: post #65

I wonder if what I heard from some people is true, that at Google Go isn't used as widely as people think.

Google employee here, for my role I work almost exclusively in Go.

A lot of legacy code is C++ or Java, but almost all of the new software being developed uses Go.

Re: Go Developer Survey 2022 Q2 Results

#176

Post by melony »

geodel wrote: post #127
melony wrote: post #75

Earlier quoted context omitted.

You are missing the point, documentation is either evergreen, or it is not. If you don't clearly state whether your documentation is current, then it leads to a lot of confusion.

I'd like to other blogs which of announcement of being current. There are deprecated notice I have seen, else things are considered current by default.

The other languages don't use their blogs as official language best practice guides.

Re: Go Developer Survey 2022 Q2 Results

#177

Post by icholy »

cletus wrote: post #129
icholy wrote: post #114

Earlier quoted context omitted.

> Putting domain names in import statements is a massive mistake. Why do you say that? I appreciate the lack of indirection.

Several reasons: 1. Finding dependencies with tooling now requires parsing code. Luckily Go's syntax is relatively simple and doesn't have conditional includes like C++ does but it'd be better if you could simply inspect a depedency configuration; 2. You're directly importing potentially untrusted code that will often be of the form "github.io/someuser/reponame" so you now have a depedency on some random user's secur…

The go.mod is the dependency configuration file you're describing.

Re: Go Developer Survey 2022 Q2 Results

#178

Post by klodolph »

metaltyphoon wrote: post #132
klodolph wrote: post #103

Earlier quoted context omitted.

I don't think any option should panic on error. I've had to deal with programs that panic on error and the way I dealt with it was by forking the project and removing every call to panic(). It's even worse with libraries. The other problem is that it's super common to want to wrap the error somehow when returning it. Often you want to wrap the error differently depending on where the error came from in the function,…

Unless you put the function name somewhere in the error, there is no way to know where something happened. "Some thing didn't write properly? Cool! Where and which line?"

> "Some thing didn't write properly? Cool! Where and which line?"

My eyes glaze over when I'm trying to read stack traces in Java or Python, and then it turns out I can't figure out what's wrong because the stack trace doesn't include the path of the file that failed to parse.

What we care about is stuff like:

- Program tried to parse file X,

- Failed because file X doesn't exist, or because file contains syntax errors, or something

- Some context giving us the reason why program tried to read file X, which is usually at a fairly high level (something like "could not load config").

Putting the function name in the error-handling code is something that you SOMETIMES do, but only when it adds important context. If you do it all the time you end up with something completely unreadable, like a stack trace. There are various libraries you can use that give you stack traces for errors in Go, if that's what you want.

If I get an error that X is not a valid JSON file--often, that's all I need to know, because I can open X and see the syntax error and fix it. Knowing the name of the function that detected the syntax error is unhelpful, usually, and we have logging + debuggers to help with those cases.

Re: Go Developer Survey 2022 Q2 Results

#179

Post by kitkat_new »

silisili wrote: post #160
kitkat_new wrote: post #138

Earlier quoted context omitted.

I find that interesting, and like the Rust way of error handling much more. Go error handling blows the code up a lot and makes the code less comprehensible. res1, err1 = canFail() if err1 != nil { return err1 } res2, err2 = canFail() if err2 != nil { return err2 } return res1 + res2, nil becomes res1 = canFail()? res2 = canFail()? return Ok(res1 + res2) guess what is more readable

Less lines does not mean more readable. Anyone who has ever programmed will know exactly what Go is doing here(perhaps with exception to nil). Moreso if this were compilable code and every return returned two items as it needs to. You have to know Rust to understand what the Rust code is doing. Even then, it's not as obvious what's happening under the covers.

> You have to know Rust to understand what the Rust code is doing.

don't see this as a problem

> Even then, it's not as obvious what's happening under the covers.

actually, it is, since it is clearly defined

Re: Go Developer Survey 2022 Q2 Results

#180

Post by iainmerrick »

nirui wrote: post #168
kitkat_new wrote: post #138

Earlier quoted context omitted.

I find that interesting, and like the Rust way of error handling much more. Go error handling blows the code up a lot and makes the code less comprehensible. res1, err1 = canFail() if err1 != nil { return err1 } res2, err2 = canFail() if err2 != nil { return err2 } return res1 + res2, nil becomes res1 = canFail()? res2 = canFail()? return Ok(res1 + res2) guess what is more readable

I like how currently Go handles errors. It's not just about res1, err1Error = canFail() it's also about res1, successful1Bool = canFail() and many other ways that communicates an abort event. Current Go syntax handles every case in a consistent way, while the Rust-like syntax could only apply to error type specifically. But you don't always have to return an error if something failed (say Hashmap lookup, strings.Inde…

But you don't always have to return an error if something failed (say Hashmap lookup, strings.Index, or even just `if res1.IsValid()` without `err1` all together), right?

No, a real error type is strictly better than a success/failure bool, I think. For something like a hashmap lookup, “false” becomes “NotFound” (say) which is a lot clearer. And you don’t need the “true” at all -- in that case you just have the result of the lookup.

In your “res1.IsValid” example, would you still be returning a separate error result, just not using it? If so, that seems a little dangerous -- how can the compiler verify that you’re correctly handling errors? If instead there’s no explicit error return, it seems like you’re not really using the language’s built-in error handling, and it could work equally well in either Go or Rust.

Post reply on HN