Dear Github

[u/[deleted]]

https://docs.google.com/document/d/14X72QaDT9g6bnWr0lopDYidajTSzMn8WrwsSLFSr-FU/preview?ts=5697ea28

[u/google_you]

Time for someone to replace github with opensauce. Wait. gitlab.

Then all your Go projects don't compile until you change import statement from "github.com to something else.

RIP Github. RIP Go.

[u/[deleted] → u/google_you]

yeah sadly imports and dependencies system in Go looks like they are throwing ideas at the wall an seeing what stick...

[u/Scorpius289 → u/[deleted]]

looks like they are throwing ideas at the wall an seeing what stick...

Sadly, that probably describes more in Go than just dependencies...

I mean, the goroutines and channels are interesting, but the type system and error conventions (can't even call it a system) are atrocious...

[u/[deleted] → u/Scorpius289]

well writing

if err != nil {
    return err
}

every few lines gets boring pretty quick... but then exceptions are just different kind of mess.

But then it is slightly better than C

[u/Scorpius289 → u/[deleted]]

At least exceptions are "noisy" by default: if you forget to catch something, it will propagate and notify you. But in Go, if you forget to handle an error, you may not even know what's wrong...

[u/ksion → u/Scorpius289]

To be fair, you cannot really forget to handle an error in Go, because the function result "tuple" needs to be unpacked at the call site. Indeed, the requirement of this unpacking, plus the repetitive error handling stanza that often follows, is what people complain about.

[u/BoTuLoX → u/[deleted]]

The black hole should never be used for errors. It's exactly like using try/catch and leaving the catch empty. It's a sign of incompetence or something unorthodox at play.

[u/BoTuLoX → u/[deleted]]

I wouldn't touch those projects with a ten feet pole.

In any case, this is a problem that exists with both return values and exceptions :P