Go Developer Survey 2022 Q2 Results • Hacker News Board

Re: Go Developer Survey 2022 Q2 Results

#101

Post by marwatk » Thu, Sep 08, 2022, 6:50 PM UTC

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 golangci-lint to enforce it because not having context for an error has bitten us so many times)

Re: Go Developer Survey 2022 Q2 Results

#102

Post by avgcorrection » Thu, Sep 08, 2022, 6:50 PM UTC

randomdata wrote: post #87

hajile wrote: post #45

Almost 40% of respondents either use generics or want to use generics. That's a pretty quick uptake given the decade of loud, prominent voices shouting that go didn't need and shouldn't have generics.

Random internet comments don't mean anything. Nobody who mattered said that Go didn't need generics. In fact, Ian Lance Taylor, the lead behind getting generics in Go, has been working on adding generics to Go inside Google since before any of us outside of Google had even heard of Go. It was always explicitly on the table. It just took a long time, after many failed proposals, to find a solution that didn't come wit…

A lot of self-selected (not just any random programmer) Go programmers wanted generics according to the survey. So Go programmers who are motivated enough to find and answer such a survey don’t matter?

Actually scratch that, I was wrong. The opinions of regular programmers not mattering is after all one of the philosophies behind the invention of Go.

Re: Go Developer Survey 2022 Q2 Results

#103

Post by klodolph » Thu, Sep 08, 2022, 6:52 PM UTC

treis wrote: post #81

klodolph wrote: post #17

Earlier quoted context omitted.

I would love to see some in-depth discussion about this. Even in 2022, I don't think it's clear what we want error handling to look like. You can ask for correctness guarantees from the compiler, but it's easy to ask, it's harder to design a system that actually works. > The lack of exhaustive switch case statements makes this worse because the compiler doesn't care if you're handling all the expected error types (or…

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, like this:

  d, err := os.ReadFile(fname)
  if err != nil {
    return err // unwrapped
  }
  x, err := parseX(d)
  if err != nil {
    return fmt.Errorf("%s: %w", fname)
  }

I know that not all Go developers write good error handling code. However, I don't want to make it easier to write bad error handling code if you're not making it correspondingly easier to write good error handling code.

Re: Go Developer Survey 2022 Q2 Results

#104

Post by avgcorrection » Thu, Sep 08, 2022, 6:52 PM UTC

LukeShu wrote: post #62

hajile wrote: post #45

Almost 40% of respondents either use generics or want to use generics. That's a pretty quick uptake given the decade of loud, prominent voices shouting that go didn't need and shouldn't have generics.

> loud, prominent voices shouting that go didn't need and shouldn't have generics The party line has always[1] been that generics would be nice to have, but "We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it." The prominent voices had been saying "the need is overstated", not "there is no need"; but I understand[2] why so many hear it wrong. [1]: La…

> Proportionate to the complexity

If many people like it and find it useful then their armchair calculation of the complexity tradeoff might have been totally wrong.

Re: Go Developer Survey 2022 Q2 Results

#105

Post by AtNightWeCode » Thu, Sep 08, 2022, 6:53 PM UTC

Some thoughts.

There is no best practice on how to structure a Go code base.

go.dev is still ugly. It is ok in comparison to the old Win95-styled design.

That awful closure fib example on go.dev is still a good reason to ignore Go. I would guess most of all devs don't understand it when they read it the first time.

Fuzzing in general is an anti-pattern but can be useful.

Re: Go Developer Survey 2022 Q2 Results

#106

Post by bilinguliar » Thu, Sep 08, 2022, 6:54 PM UTC

marwatk wrote: post #99

bilinguliar wrote: post #91

Earlier quoted context omitted.

Indeed, this may be the use case. I am curious how often you may need a pointer to an int.

In things like rest APIs you need them quite a bit to distinguish between a value being the zero value and not present at all. Most libraries I've seen have an IntPointer or similar function exposed globally.

This is true. In the case of REST, it is your “encoding/json” who will allocate for int pointer. So I do not see why new() is needed.

Re: Go Developer Survey 2022 Q2 Results

#107

Post by BobbyJo » Thu, Sep 08, 2022, 6:57 PM UTC

bheadmaster wrote: post #72

just-ok wrote: post #70

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. The Go dance is always necessary, which makes it slightly more annoying for short scripts or tests. I usually resort to the Go playground for them.

> 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.

Re: Go Developer Survey 2022 Q2 Results

#108

Post by stouset » Thu, Sep 08, 2022, 6:58 PM UTC

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…

You're looking at a minimal test case, not an example of it happening in real production code. Of course it's obvious in the minimal test case, that's the point.

I've personally written something akin to the following, which triggered no errors (at the time, maybe this is fixed):

    foo, err := foo()
    if err != nil { 
        nil, err
    }

    return foo, nil

The worst part is because all of the error-handling is copypasta boilerplate, your eyes don't look at it. So subtle bugs get through and make it to production. I've seen this one too:

    foo, err := foo()
    if err != nil { 
        return foo, nil
    }

    return foo, nil

Also note that now we've gone from "Doesn't [go] provide compile time check for errors?" to "Well I guess it doesn't check that errors are used, but that would never happen to me."

Re: Go Developer Survey 2022 Q2 Results

#109

Post by throw_m239339 » Thu, Sep 08, 2022, 6:58 PM UTC

randomdata wrote: post #87

hajile wrote: post #45

Almost 40% of respondents either use generics or want to use generics. That's a pretty quick uptake given the decade of loud, prominent voices shouting that go didn't need and shouldn't have generics.

Random internet comments don't mean anything. Nobody who mattered said that Go didn't need generics. In fact, Ian Lance Taylor, the lead behind getting generics in Go, has been working on adding generics to Go inside Google since before any of us outside of Google had even heard of Go. It was always explicitly on the table. It just took a long time, after many failed proposals, to find a solution that didn't come wit…

> Random internet comments don't mean anything.

These weren't random internet comments, these were a bunch of well known gatekeepers in the main go mailing list trying to gaslight everybody else and threatening to quit Go if Go ever added generics. Obviously that didn't work and now these people have lost any form of power they thought they have. But these are very public people I won't name here.

> Nobody who mattered said that Go didn't need generics.

Well I guess these people clearly don't matter now, since they are still on the mailing list despite their threats...

> It was always explicitly on the table.

No it wasn't, Rob Pike himself was clearly not interested in adding generics and the effort truly began when Pike left the Go team. Let's not try to rewrite history.

Re: Go Developer Survey 2022 Q2 Results

#110

Post by masklinn » Thu, Sep 08, 2022, 7:00 PM UTC

cesarb wrote: post #36

aniforprez wrote: post #22

Earlier quoted context omitted.

1) Yes I didn't want to make the tired comparisons to Rust but Rust does have the excellent syntactic sugar for returning errors. Of course, something like this is hampered by the lack of sum types and the ambiguous zero values in Go which makes it more difficult for the compiler to know what to return but I hope we eventually get there or we find another way to do this 2) I'm not a fan of leaving error checking to l…

> > Syntactic sugar for if err != nil { return err }; similar to ? in Rust > Yes I didn't want to make the tired comparisons to Rust but Rust does have the excellent syntactic sugar for returning errors. Many people seem to forget that Rust didn't start (even in its 1.0 release) with the ? operator. It started with the try!() macro, which expanded to something not unlike Go's "if err != nil { return err }". The ? ope…

> If Rust was able to create the ? operator based on developer experience with its try!() macro, I don't see why Go won't be able to create its own error propagation operator based on developer experience with its "if err != nil { return err }" idioms.

Because Go does not have declarative macros. So while Rust got something like 25 versions out of try! before considering that it’s worth an operator (but it could well have gone with an other pattern if one had arisen) that’s not really an option for go.