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

131–140 of 186 posts

Re: Go Developer Survey 2022 Q2 Results

#131

Post by morelisp »

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…

2) doesn’t get better just because you put a name that maps to a url in some XML file.

3) we’re six versions into go.mod by default. Nobody has this problem anymore.

4) Just untrue. Go proxies have been by far the easiest thing to deploy and secure because they’re so transparent in the toolchain.

Re: Go Developer Survey 2022 Q2 Results

#132

Post by metaltyphoon »

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

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?"

Re: Go Developer Survey 2022 Q2 Results

#133

Post by nathants »

Macha wrote: post #73
nemothekid wrote: post #40

Earlier quoted context omitted.

A real problem is when something like this occurs x, err := thisFuncFails(); // some other lines of code, but err is not checked x.callMethod(); // this crashes at runtime unless you explicitly ignore `err`, the compiler shouldn't allow you to use `x` without checking err. In Rust/Zig this is accomplished with the union types, which doesn't allow to use `x` until you have checked it's not an error. This is also very…

The problem is worst with procedural functions os.Mkdir("foo") looks pretty innocent but with no return value to use, the compiler is no help in reminding you this is a fallible function

add errcheck and ineffassign to your build script. the compiler should really do this itself.

Re: Go Developer Survey 2022 Q2 Results

#134

Post by metaltyphoon »

Gibbon1 wrote: post #128
marwatk wrote: post #101

Earlier quoted context omitted.

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

The thing with try/catch is that many times, code that throws doesn't have to be handled on the call site! So you can easily have a happy path and kick the bucket to a location where the error can ACTUALLY be handled property.

Re: Go Developer Survey 2022 Q2 Results

#135

Post by metaltyphoon »

eikenberry wrote: post #42
pipe_connector wrote: post #14

Earlier quoted context omitted.

If I'm reading your feedback correctly it sounds like you want: 1) Syntactic sugar for if err != nil { return err }; similar to ? in Rust 2) The errcheck linter to be enforced (part of go vet, maybe?) 3) Exhaustive switch statements The first point was looked at and no one has proposed a solution enough of the community could agree was an improvement while maintaining sufficient explicitness. If someone has a really…

> 1) Syntactic sugar for if err != nil { return err }; similar to ? in Rust IMO they could exactly use what you wrote, ie. change gofmt to have it all on one line like that. The biggest annoyance with the error return boilerplate is the waste of vertical space and just squashing it into 1 line would fix that.

Or perhaps allow variable assignment to be used in the same scope.

if x, err := someMethod(); err != nil { return err }

x <- is usable here.

Re: Go Developer Survey 2022 Q2 Results

#136

Post by [deleted] »

bilinguliar wrote: post #116
37ef_ced3 wrote: post #113

Earlier quoted context omitted.

Are you seriously suggesting that the language should not have notation for allocating zeroed primitive types and receiving the address of the allocation? var ( p1 = new(int) p2 = new(*int) p3 = new(**int) p4 = new(complex64) p5 = new(complex128) ) I feel like you must be joking. Should we say var ( c complex128 p = &c ) every time?

In five years, I needed to do the latter only once or twice because a library I was using demanded a pointer to a primitive. Forgive my arrogance, but why does one need a pointer to a zero-value primitive in Go? I sincerely believe there is a use case for it, but I never needed this.

[deleted]

Re: Go Developer Survey 2022 Q2 Results

#137

Post by mardifoufs »

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…

I'm curious about your last point. What's the problem with async/await?

Re: Go Developer Survey 2022 Q2 Results

#138

Post by kitkat_new »

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

Re: Go Developer Survey 2022 Q2 Results

#139

Post by randomdata »

throw_m239339 wrote: post #109
randomdata wrote: post #87

Earlier quoted context omitted.

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

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

Re: Go Developer Survey 2022 Q2 Results

#140

Post by arccy »

convolvatron wrote: post #126
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.

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
Post reply on HN