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

181–186 of 186 posts

Re: Go Developer Survey 2022 Q2 Results

#181

Post by nirui »

iainmerrick wrote: post #180
nirui wrote: post #168

Earlier quoted context omitted.

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 resul…

> would you still be returning a separate error result, just not using it

It's a part of the examples for the statement "you don't always have to return an error", so... you don't return a separate error, you just abort at that point. Sorry I should have described it more clearly :)

Re: Go Developer Survey 2022 Q2 Results

#182

Post by jen20 »

bilinguliar wrote: post #86
closeparen wrote: post #31

Earlier quoted context omitted.

Do you write primarily HTTP / RPC services? I've found Go's error handling very tedious when "return an error to the caller" is almost always the answer, but for background stuff, daemons, etc. it's nice.

I have misread your comment. So, your experience with handling errors that must be returned to the caller is tedious. Hmm, I do not feel it is tedious. I will likely bubble it up the stack, report it and return a relevant code. I appreciate that this is almost linear, without mental complexity of exception, where you occupy another part of your brain with accounting for exception handling.

> report it and return a relevant code.

This would be more convincing if the signature of func main in go even permitted an exit code. Instead one must use os.Exit which does not run defers, or have main consist primarily of a call to os.Exit(realMain()).

Re: Go Developer Survey 2022 Q2 Results

#183

Post by jen20 »

arccy wrote: post #140
convolvatron wrote: post #126

Earlier quoted context omitted.

seems to me like a worldview problem. are remote resources really persistent and associated with long lived commercial organizations like github? or are they more like urls that come and go. it would suck to have to deal with another location service, although one could imagine using something like DNS were it sufficiently secure. but on the other hand, I'm personally kind of offended that there is a rent-seeking int…

you can run a http(s) server allowing you to disentangle names from hosting

Not many do, however. A reasonable approach would be to disentangle the import name from the download location.

Re: Go Developer Survey 2022 Q2 Results

#184

Post by jen20 »

klodolph wrote: post #103
treis wrote: post #81

Earlier quoted context omitted.

I'd like stuff like myFunc() works as today myFunc()^ returns the err if there is one myFunc()! panics if there is an err

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,…

Aborting is almost always the correct answer in order that you get a core dump that may be debugged post-mortem. Blindly continuing when in an invalid state is a horrible idea.

Re: Go Developer Survey 2022 Q2 Results

#185

Post by rochak »

awb wrote: post #151
rochak wrote: post #77

Earlier quoted context omitted.

The reason why you are not getting any requests for Go is because you are not asked to find people for backend.

No, I am. Companies just seem to want their web app backend built on a JS stack, and ask for Node devs. Maybe Go is more systems/ops heavy, of which I’m not recruiting actively for.

Hmm. Don't know why but it could be due to popularity of Node in general. Going with something that is popular is often the best way to ensure you'll always have candidates to hire.

Re: Go Developer Survey 2022 Q2 Results

#186

Post by lenkite »

klodolph wrote: post #178
metaltyphoon wrote: post #132

Earlier quoted context omitted.

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 erro…

Java stack-traces are extraordinarily informative - they give line number, class, method and even offset inside relative lambda when an exception occurs. Few languages do better and Go is not one of them.
Post reply on HN