I like go, but a lot of little things stop me from loving it.
Like, enums. I get a lot out of the box when I use an enum in Java or Kotlin. Converting to/from a String is trivial. Type safety ... exists.
I can do that in Go, but I have to hack it in, for every single enum type I want to represent. Enums are not a thing in the language, which means its easier to keep the language in your brain all at once, but at the expense of making it harder to keep the software I'm writing in my head. Is this "enum" the same as that "enum"? I have to go read the code to figure it out.
But Go is excellent at a lot of things. Compile times, static binaries, resources compiled right into that binary, execution speed ... there is a lot to love.
The anti-exception mind virus of the 2010s did a lot of damage. Go designers finally caved and added panic & recover, but jeez, the damage was done. The whole ecosystem has exception derangement syndrome.
Go had panic/recover right from the get go. Nobody “caved.” And indeed, you are free to use panic/recover for error handling in your code. That was always allowed.
That said, the key insight of the exception craze is that error returns are a normal part of a functions behaviour and as such should not use extraordinary control flow to take place.
Exceptions (panics) are used for things that should never happen or are indicative of a programmer error, like nil dereferences or out-of-bounds array accesses. That is, things where the programmer is not expected to provide reasonable behaviour on the API level if it happens (but perhaps there is a whole-program fault handler to shut down cleanly).
Opening a file that does not exist? Database record not found? Invalid credentials? These should be anticipated by the programmer and can occur at any time. Not exceptions, normal return values. Go requests that you think about these possibilities instead of pretending they can be ignored.
You're right about recover being in 1.0 of golang.
I definitely fully understand the trade-offs of returning result/error unions vs handling thrown exceptions. Exception handling is clearly superior to me. That said, the typical performance complaints made against the most common implementations of exceptions are valid.
> I definitely fully understand the trade-offs of returning result/error unions vs handling thrown exceptions. Exception handling is clearly superior to me.
Then you definitely don't understand the tradeoffs after all, and/or don't know the history of error handling.
Exceptions are an outdated concept that's inferior to explicit error returns for 99% of software.
The tradeoffs are super simple here - exceptions require very little of your input but lead to terrible spaghetti due to hidden control flow. Explicit error returns are seemingly the opposite, but their verbosity issues have mostly gone away thanks to modern language improvements, so they're just better, unless you're writing short scripts and the like.
The situation is very similar to static vs dynamic typing - dynamic typing used to make a lot of sense in the days of extremely verbose Java type declarations, but modern static type systems with inference have made dynamic typing basically obsolete.
> That said, the typical performance complaints made against the most common implementations of exceptions are valid.
This also sounds off and outdated to me. If anything, exceptions typically have better performance, so long as errors aren't common. Indeed, if optimized correctly, exceptions have zero cost if not thrown, which can get you better perf than error returns, which have a low, but constant cost.
Like, enums. I get a lot out of the box when I use an enum in Java or Kotlin. Converting to/from a String is trivial. Type safety ... exists.
I can do that in Go, but I have to hack it in, for every single enum type I want to represent. Enums are not a thing in the language, which means its easier to keep the language in your brain all at once, but at the expense of making it harder to keep the software I'm writing in my head. Is this "enum" the same as that "enum"? I have to go read the code to figure it out.
But Go is excellent at a lot of things. Compile times, static binaries, resources compiled right into that binary, execution speed ... there is a lot to love.