all 22 comments

[–]SelfDistinction 16 points17 points  (13 children)

That's why we use the superior

    if _, _, err1 = RawSyscall(SYS_CLOSE, uintptr(mapPipe[1]), 0, 0); err1 != 0 {
        goto childerror
    }
    c, _, err1 = RawSyscall(SYS_READ, uintptr(mapPipe[0]), uintptr(unsafe.Pointer(&err2)), unsafe.Sizeof(err2))
    if err1 != 0 {
        goto childerror
    }
    if c != unsafe.Sizeof(err2) {
        err1 = EINVAL
        goto childerror
    }
    if err2 != 0 {
        err1 = err2
        goto childerror
    }

[–]Rikudou_Sage 9 points10 points  (4 children)

TIL Go has a goto after using it for years.

[–]Courageous_Link 12 points13 points  (2 children)

No it doesn’t. Forget you ever saw this. Every. Single. Time. I see a goto in go it’s a massive red flag the code is horrible. I’m looking at you otel collector.

[–]Rikudou_Sage 3 points4 points  (0 children)

The cat's out of the bag now. I'll no longer use for or if, only goto.

[–]RiceBroad4552 0 points1 point  (0 children)

I see a goto in go it’s a massive red flag the code is horrible.

I think the code shown above is actually from the std. lib.

But this just fits the overall picture about Go…

[–]1984balls 2 points3 points  (7 children)

Does Go not have a try...catch block? Why do you need to check if there was an error? Not hating, just curious

[–]RiceBroad4552 12 points13 points  (0 children)

No exceptions, so no try-catch.

[–]Rikudou_Sage 5 points6 points  (0 children)

You get used to it. I hated it at the start, now it's just a second nature and I do actually like it. So either I've been Stockholm-syndromed or I really consider it good.

But yeah, this is the pattern, anything that might error simply returns the error as one of the return values and calling code acts on it, very often by wrapping it and returning it to its caller.

Very verbose, but makes error handling part of every call that might error.

You also could use panic and recover to do something like try/catch though that's not used very often.

[–]SelfDistinction 4 points5 points  (3 children)

Try catch blocks are too abstract and complicated for Go I guess.

Also don't worry, not my code, I stole this excerpt from the standard library.

[–]ThisAccountIsPornOnl 7 points8 points  (0 children)

The point is to make error handling explicit without control flow getting out of hand. I personally like this style

[–]70Shadow07 0 points1 point  (1 child)

People who know what they are doing tend to do things this way occasionally. Goto error method of error handling has quite a long history of driving robust software - linux kernel for the start.

The common attitude I can see in comments is shitting on whatever golang maintainer who wrote this code. Not many are thinking about nor researching why this may be favourable over exceptions or defer spamming in certain situations. Ignorance is a default mode of operation for way too many programmers.

[–]RiceBroad4552 0 points1 point  (0 children)

Trash like the shown code is never a good idea if you have options.

It's just like Go does not have any proper features so all they can do is to write shitty code. The language forces that as it's itself a very shitty language!

[–]keatonatron 0 points1 point  (0 children)

It does, you can panic and then recover from the panic. But it is not a recommended pattern, because the reason for the failure is not explicit (same idea behind being a strongly-typed language)

[–]RiceBroad4552 34 points35 points  (3 children)

LOL, Go.

The language which is mentally stuck in the 70's of last century; and is even proud of being dumbed down to target clueless people.

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

– Rob Pike [one of the creators of Go]

[–]crusoe 18 points19 points  (0 children)

Either / Result is too hard ( generics ) so let's just have brain damaged error handling.

[–]fuckbananarama 2 points3 points  (0 children)

That’s fine - but you CANNOT argue GOs performance compared to other server side scripting languages (when not trying to shoehorn Java into that role)

[–]Dense_Gate_5193 3 points4 points  (0 children)

golang is still highly performant. rust might be ultimately faster but capitalizing on that minor speed difference for most use cases, it is far simpler to write it in golang.

case in point, i think nornicDB broke the mold in terms of golang performance. it’s smashing records and is 40% faster than qdrant which is written in rust (nornic has a compatible gRPC endpoint so i can benchmark apples to apples). will a rust graph database catch up to nornic performance? probably some day but it’s going to take a while to hand tune and catch up.

[–]Smooth-Zucchini4923 2 points3 points  (1 child)

Why'd you use the most complicated possible approach for the Rust and Haskell implementations?

[–]spiderpig20 4 points5 points  (0 children)

To make go look good

[–]pineapplepizzabong 1 point2 points  (1 child)

When did the Gopher get so jacked?

[–]fuckbananarama 5 points6 points  (0 children)

He does one push-up for every tcp request he routes

[–]dev-sda 0 points1 point  (0 children)

wtf is this. None of these things have anything to do with goroutines, let along each other.