91 karma · joined April 9, 2016
I still know modern Java codebases where long descriptive class names are a must. So sadly, while I understand your sarcasm, it is not the case.
Many people coming into Go as a new language immediately start bickering about how they want their previous language features in Go rather than accept what Go has to offer and at least try to understand it. This is the equivalent of moving to another country and then refusing to integrate but being very vocal about how said country sucks.
I genuinely appreciate Go's error handling because it's clean and on the nose. It's not hidden behind weird syntax/values that you have to unpack. It's right in your face all the time. When you read the code, it reads cleanly and understandably, even for a beginner. They don't have to adapt to some weird combination of failures / unpacking/choosing something different when there is an error; you immediately see that there could be an error.
And regarding stack traces, wrapping errors will provide you with failure locations to the line code. You can have all sorts of nice output for errors you can later parse and identify.
I get that some people go into Go because of a shift in the company and have no choice; I feel you. For me, it was a life changer. I learned to love coding again after 15 years of writing Java Beans, Spring annotations, CreateMyFriggingObjectFactorySingletonBuilderFactoryBuilders.
It’s an excellent tool that has great encryption and handles multiple accounts and can paste into your clipboard with `totp account.name|pbcopy` and asks for a password on stderr. Pretty cool stuff.
This is not a self-validation story, nor is it trying to convince anyone about their way of being wrong. This is a story about me. :) And I hope an enjoyable one. Whatever works for you, dear reader is whatever works for you!
*Warning*: Light mode only on my blog, sorry. I'm working on it.