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

121–130 of 186 posts

Re: Go Developer Survey 2022 Q2 Results

#121

Post by bheadmaster »

5d8767c68926 wrote: post #38
kbd wrote: post #24

Surprised to see language satisfaction so high. Error handling is very painful, and Go's own tools don't work together (eg. go mod tidy doesn't work properly with `go.work` since being released in 1.18). So many things in the language feel bad for no reason. At least they finally added generics!

>Surprised to see language satisfaction so high. Who else do you think responds to these surveys? I have a long list of grievances against Go, so I don't use it, and am not qualified to participate in a survey.

To be honest, many other languages have a lot of users that are quite unsatisfied with it, despite using it regularly (Java comes to mind). The fact that most of the people who use Go are happy with it isn't that insignificant.

Re: Go Developer Survey 2022 Q2 Results

#122

Post by nerdwaller »

bilinguliar wrote: post #80
nerdwaller wrote: post #23

Earlier quoted context omitted.

What kinds of inconsistencies are on your mind?

I never use new(). It gives a way to allocate, that I would prefer to avoid in favor of declaring zero-value explicitly. Maybe I am missing the point of new().

I don't particularly find that inconsistent, though it's usage may not be super common (depending on the type of work you do in go). If you ever need to do atomic operations, it's rather helpful. Though they have been adding new features in go 1.19+ that help there (Int32[1] type, for example). As an aside, for those using atomics - Uber's wrapper library[2] is pretty pleasant to use.

[1] - https://pkg.go.dev/sync/atomic#Int32 [2] - https://pkg.go.dev/go.uber.org/atomic

Re: Go Developer Survey 2022 Q2 Results

#123

Post by bheadmaster »

BobbyJo wrote: post #107
bheadmaster wrote: post #72

Earlier quoted context omitted.

> Python’s venv dance only really comes into play if you need a third-party dependency that you haven’t installed globally. True. Though installing third-party dependencies globally is considered bad practice, since it can easily break system packages. > The Go dance is always necessary, which makes it slightly more annoying for short scripts or tests. Well, if you just want to compile/run a single file (or a couple…

I can't tell you how many time global dependencies in python have cause me headaches. Do a small project then do another small project 6 months later and the formers dependencies conflict with the latter's.

The whole concept of "only one major version of library can be installed at a time" is completely broken and is the direct cause of diamond import issues. Go designers have correctly recognized that two major versions of a library are actually two different libraries, only under the same name and the same team.

The "v2/ subdirectory" practice of versioning Go packages is one of the things I love the most about Go. Combined with the "packages are directories" philosophy, it makes it easy to use as many major versions of the library as you want, without any complications whatsoever.

Re: Go Developer Survey 2022 Q2 Results

#124

Post by seer-zig »

bheadmaster wrote: post #64
stouset wrote: post #59

Earlier quoted context omitted.

Not really. Go thinks this is fine (on mobile, forgive me if I get this wrong). foo, err := foo() if err != nil { return nil, err } bar, err := bar(foo) return bar, nil The problem occurs because go only cares if a variable is used once per definition. Not once per assignment.

You are right, I have missed that, as I have written under the sibling comment. Though I'd like to ask - does that scenario really happen in practice? It is idiomatic to handle every error right after the function call that returns the error. To me, the lack of "if err != nil {" under the "bar(foo)" call really stings my eyes. I know, compile time checking is different from "it doesn't happen in practice". It's a tra…

> does that scenario really happen in practice

It does happen, I've seen it several times, and even other insidious examples that linters did not catch. When you're dealing with a code base that is constantly changes, things like that end up happening.

Re: Go Developer Survey 2022 Q2 Results

#125

Post by geodel »

cletus wrote: post #66

I was glad to see Go get generics. Not because it was super-important but rather so we didn't have to hear about it anymore. I think exceptions are a false economy so I have no real issue with Go's error handling. It could be cleaner. Rust's match expressions are better. Multiple returns are a bit awkward. Something like a result or error union type would be better and could fit in with the type system. Standard erro…

Maven configuration is a cottage industry in itself. I have not seen developers who know maven from first principles. Despite taking many courses, books, tutorials etc I just dare not touch pom.xml beyond adding/deleting/updating dependencies.

Even then every couple of months maven and IDE combination will run into obscure build issues that will not resolve until all the local maven repos are nuked from desktop.

Re: Go Developer Survey 2022 Q2 Results

#126

Post by convolvatron »

icholy wrote: post #114
cletus wrote: post #66

I was glad to see Go get generics. Not because it was super-important but rather so we didn't have to hear about it anymore. I think exceptions are a false economy so I have no real issue with Go's error handling. It could be cleaner. Rust's match expressions are better. Multiple returns are a bit awkward. Something like a result or error union type would be better and could fit in with the type system. Standard erro…

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

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 intermediary in the middle of my development process

Re: Go Developer Survey 2022 Q2 Results

#127

Post by geodel »

melony wrote: post #75
hbogert wrote: post #69

Earlier quoted context omitted.

I find the op's perspective weird as well, though I have colleagues which reason like this at well when I point to those blogs/talks of 2014-2016 during reviews -- "that can't be the way to do it 8 years later right?"

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.

Re: Go Developer Survey 2022 Q2 Results

#128

Post by Gibbon1 »

marwatk wrote: post #101
aniforprez wrote: post #5

I'm genuinely hoping that after generics, the focus will be on error handling from the survey results Go devs in a lot of communities love to put their heads in the sand going "error handling is perfectly fine". But it's not fine. Not even close. And I'm very happy there's a lot of demand for some solution in this space. It's just plain too verbose without any of the actual benefits of that verbosity. You don't have…

The bigger issue is that returning the error without wrapping provides zero context and after a crash you're stuck trying to figure out which of a hundred calls to Write was responsible for "write error" or some other equally ambiguous message that's nearly impossible to track down. So you have to resort to a poor man's stack trace: if err != nil { return fmt.Errorf("my thing: %w", err) } (We use wrapcheck via golang…

Things I tend to do in my firmware for errors.

Record the error line number where the error happened. Use __builtin_return_address(0) to fink on the caller.

Idle thoughts. Despite it's provenience BASIC's on error goto has merit. The problem with try/catch is creating scoped blocks of code that's annoying.

   try
   {
     // scoped stuff
   }
   catch
   {
   }
vs

   on_error_goto label;

   // stuff

   label:
Also a thought is having a separate error_return keyword. And the ability to mark functions with 'no error'

Re: Go Developer Survey 2022 Q2 Results

#129

Post by cletus »

icholy wrote: post #114
cletus wrote: post #66

I was glad to see Go get generics. Not because it was super-important but rather so we didn't have to hear about it anymore. I think exceptions are a false economy so I have no real issue with Go's error handling. It could be cleaner. Rust's match expressions are better. Multiple returns are a bit awkward. Something like a result or error union type would be better and could fit in with the type system. Standard erro…

> 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 security practices or even just whims (eg making the repo private; IIRC this has happened in the node.js ecosystem);

3. These aren't versioned. You may want to stick to a particular version. A new version may break your code. You should be able to be explicit about that. Now you can "go get" particular versions but how do you specify that such that someone can just check out your code and build it?

4. Managing your own dependency repo (eg in an enterprise environment) is more limited.

Re: Go Developer Survey 2022 Q2 Results

#130

Post by erik_seaberg »

randomdata wrote: post #52
aniforprez wrote: post #5

I'm genuinely hoping that after generics, the focus will be on error handling from the survey results Go devs in a lot of communities love to put their heads in the sand going "error handling is perfectly fine". But it's not fine. Not even close. And I'm very happy there's a lot of demand for some solution in this space. It's just plain too verbose without any of the actual benefits of that verbosity. You don't have…

Go doesn't have errors, only values. Value handling could be improved, I'm sure, but anything that focuses on values that humans attach error meaning to is fundamentally flawed and will leave broken half-solutions. Each problem people say Go has with error handling is actually a more general problem with value handling and/or interfaces and the right solution would solve for those problems across the board. The probl…

There are always going to be cases where the happy path call tree should be abandoned because no useful value meeting requirements is going to be possible. What’s needed is to persuade Go devs to use panics instead of obscuring every function reinventing them by hand.
Post reply on HN