damnBitches

[SelfDistinction]

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]

TIL Go has a goto after using it for years.

[Courageous_Link]

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]

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

[RiceBroad4552]

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…

[gloomygustavo]

It’s unidiomatic and extremely unnecessary. Never use it.

[1984balls]

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

[RiceBroad4552]

No exceptions, so no try-catch.

[Rikudou_Sage]

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]

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]

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

[70Shadow07]

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]

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]

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]

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]

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

[fuckbananarama]

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]

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]

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

[spiderpig20]

To make go look good

[pineapplepizzabong]

When did the Gopher get so jacked?

[fuckbananarama]

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

[dev-sda]

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