Go 1.18 Released With Generics, Fully Integrated Fuzzing, ~20% Performance Improvements

[andrebrait]

So, a case of grass being greener on the other side?

What do you mean? I only ever wrote one service n Go, and occasionally interact with it trying to find out what went wrong on Minikube.

Nowadays I do Java 90% of the time, followed by Python and C. I only mentioned exceptions are not perfect because nothing really is, but it's by far a lot better than Go's ad nauseum if else for anything that isn't trivial.

[cl333r]

Did they fix their horrifically broken package management and public naming scheme yet?

There's a reason Discord of all companies replaced all their Go code with a far better language.

Yeah, I like Go far better than Rust, but Go's package management and naming is.. a complicated mess. Also, it doesn't even have an easy self update mechanism like "rustup update".

And yeah, Go's if/else mandatory usage is archaic.

[LubosD]

I'd say their "if error" handling was intentional to keep things simple and make error handling explicit. I hated it at start, but I must admit that for web service development, it does make coding a bit less error prone.

[aksdb]

What do you mean? I only ever wrote one service n Go, and occasionally interact with it trying to find out what went wrong on Minikube.

Nowadays I do Java 90% of the time, followed by Python and C. I only mentioned exceptions are not perfect because nothing really is, but it's by far a lot better than Go's ad nauseum if else for anything that isn't trivial.

I would say: veto (my opinion, obviously). I have been bitten far more often by exceptions than by Go's error handling. Missing to handle an error in Go is practically nonexistant. Missing to catch an exception in Java on the other hand happens all the fucking time. "Oh hey, one of the underlying libraries suddenly doesn't just throw an IOException, but sometimes now also some IFuckedUpBadly runtime exception."

Of course I can try...catch on the outer-most layer, but then actually dealing with the error is ugly (since I don't know for sure at which point of the code it happened). If I want it more precise, I now have to wrap _every_ function call in try...catch. Which is much more ugly than checking the return value of a simple function as in Go.

[cynic]

I'd say their "if error" handling was intentional to keep things simple and make error handling explicit. I hated it at start, but I must admit that for web service development, it does make coding a bit less error prone.

I'd say that this way of handling error is the opposite of being explicit and very error prone.

it IS error prone because one can simply "forget" checking errors and this is exactly because errors are NOT explicit.
In Java (for instance) errors are explicit and the compiler will force you to handle them.

that said, I love both Go and Java

[aksdb]

In Java (for instance) errors are explicit and the compiler will force you to handle them.

Only checked exceptions. Not every exception is checked.

[cynic]

Only checked exceptions. Not every exception is checked.

that is for a precise design principle.
Unchecked exceptions are for errors you can do anything to recover from.

[andrebrait]

I would say: veto (my opinion, obviously). I have been bitten far more often by exceptions than by Go's error handling. Missing to handle an error in Go is practically nonexistant. Missing to catch an exception in Java on the other hand happens all the fucking time. "Oh hey, one of the underlying libraries suddenly doesn't just throw an IOException, but sometimes now also some IFuckedUpBadly runtime exception."

Of course I can try...catch on the outer-most layer, but then actually dealing with the error is ugly (since I don't know for sure at which point of the code it happened). If I want it more precise, I now have to wrap _every_ function call in try...catch. Which is much more ugly than checking the return value of a simple function as in Go.

Go's approach is like if every exception was a checked Exception in Java and every method has to be enclosed in a one line try-catch block, even if the exception is ignored.

I do agree it's not perfect, but it's far better for me to have readable, easily parseable code than to have 100% certainty of errors being handled in a mess of if-else blocks, just like I could be enclosing every methof call in a try-catch, but I don't. Except in Go that's not an option if I ever want to handle errors. It makes writing any form of clean code simply impossible because I always have to check if I got an error.

Something as simple as "get the user from database, apply this transformation and respond to the request" and letting an exception handler handle it becomes "get the user from the database, if we got an error respond with 500, or else apply this transformation, if we got an error, respond with 500, then finally return it". And it gets worse the more complex it gets.

[bug77]

Only checked exceptions. Not every exception is checked.

And what shitstorm we had about those, too...

[squash]

Guys, if Go was "more like java" or "more like rust" then what would be the point of Go?

Go programmers don't care that you prefer how Java's exceptions work vs checking and handling errors immediately, in fact most of us think Java's exceptions (and classes!) are a glaring example of how not to do it. If we liked the way Java did things, we'd use Java.

If it's not your thing, if you really just want to create Factory Factories all day and throw exceptions for things that aren't exceptional, your needs are well covered and keep on keeping on.