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

51–60 of 186 posts

Re: Go Developer Survey 2022 Q2 Results

#51

Post by throwaway893031 »

I begrudgingly use Go.

Go really fucked us by not having sum types or exhaustive type-safe switches or pattern matching. It doesn't even have optionals, or type-safe nillables. The error handling is the least of my concerns.

Moving on, I'd like to see an ML-like language (with hindly milner) that has M:N threading, with pre-emptive multitasking, and safe concurrency with borrow checker like Rust, with both structural and nominal typing.

Something of a mix of Rust, Go, Erlang, and OCaml.

Not sure about error handling, maybe just use exceptions (ala swift), polymorphic variants (ala ocaml), or error unions (ala zig).

Most importantly in the next language iterations, we need to stop with the async/await nonsense, and let the runtime and/or compile handle that.

Re: Go Developer Survey 2022 Q2 Results

#52

Post by randomdata »

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 problems are real, but not related to errors specifically.

Re: Go Developer Survey 2022 Q2 Results

#53

Post by [deleted] »

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…

[deleted]

Re: Go Developer Survey 2022 Q2 Results

#54

Post by gregwebs »

klodolph wrote: post #17
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…

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…

In Rust you can use the anyhow library if you want a similar level of overhead to Go and similarly aren’t worried about differentiating error cases.

What do you think of adopting Zig’s error handling approaches to Go?

Re: Go Developer Survey 2022 Q2 Results

#55

Post by teraflop »

bheadmaster wrote: post #43
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…

> You don't have compile time checks for errors. Doesn't the fact that errors are values, combined with the fact that you cannot ignore values (except explicitly by assigning them to "_"), provide compile time check for errors?

Not really. It's idiomatic to use a single "err" variable for every error value in the same function body, and the compiler will only check whether that variable is used at least once; it doesn't perform a data flow analysis to ensure that every value that might be assigned is used.

So if you assign 10 different error results to the same variable at various points, but only actually check it 9 times and forget the 10th, the compiler will not tell you that anything's wrong.

Re: Go Developer Survey 2022 Q2 Results

#56

Post by indemnity »

klodolph wrote: post #17
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…

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'm generally a bit miserable when I try to deal with error handling in Rust, believe it or not.

Likewise. I'm a big Rust user, use it for all my personal projects, but error handling is totally unsolved there.

- Friction around mapping between error types if I need to "add context and rethrow"

- Often lack of stack/trace information for custom error types. Something went wrong the the DB query? Great! Where? Which line of code?

There are solutions for these, I try them, and I'm sure someone will pipe up mentioning them (e.g. anyhow, thiserror, miette, etc), but its just so much damn ceremony to do it properly at a particular call site, especially when you are mixing your own code with library code and each library's unique snowflake error types, that I don't do it consistently.

Re: Go Developer Survey 2022 Q2 Results

#57

Post by [deleted] »

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!

[deleted]

Re: Go Developer Survey 2022 Q2 Results

#58

Post by [deleted] »

throwaway893031 wrote: post #51

I begrudgingly use Go. Go really fucked us by not having sum types or exhaustive type-safe switches or pattern matching. It doesn't even have optionals, or type-safe nillables. The error handling is the least of my concerns. Moving on, I'd like to see an ML-like language (with hindly milner) that has M:N threading, with pre-emptive multitasking, and safe concurrency with borrow checker like Rust, with both structural…

[deleted]

Re: Go Developer Survey 2022 Q2 Results

#59

Post by stouset »

bheadmaster wrote: post #43
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…

> You don't have compile time checks for errors. Doesn't the fact that errors are values, combined with the fact that you cannot ignore values (except explicitly by assigning them to "_"), provide compile time check for errors?

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.

Re: Go Developer Survey 2022 Q2 Results

#60

Post by [deleted] »

tapanjk wrote: post #2

TLDR (listed under "key findings" in the post): - Generics has seen quick adoption. - Fuzzing is new to most Go developers. - Third-party dependencies are a top security concern. - We can do better when announcing new functionality. - Error handling remains a challenge.

[deleted]
Post reply on HN