Stephan Schmidt

Grok or Stockholm

Is your programming language holding you hostage?


I ❤️ Go. Mostly from the beginning.

I didn’t like error the handling of Go

v, err := call()
if err != nil {
  return err
}

But now I like it. It is simple and understandable. Even when I come back after some months.

Would I wish for

v := call()!

as syntactic sugar for the code above? I would have said yes some months ago, I’m not so sure any more (there are many problems with the syntactic sugar, like wrapping errors, and you end up with From like in Rust etc.).

Does that mean I finally grokked Go (understood). Or does that mean I’m the victim of Stockholm syndrome, loving Go for taking me hostage?

For the first time I wondered about this decades ago with Monad transformers. People loved them. I loved them. But they solved a problem that you would not have without Monads. And Monads solved a problem that you would not have without restricted effects. So did I love Monad transformers because I grokked them after writing lots of code, or because I loved them for holding me hostage?

I think this is a question everyone needs to ask themselves. For the programming language they are advocating, for the job they have been doing (I’m interested of the opinion of new hires after two months about the company, later there is always the danger they don’t see the problems anymore), and many more things. Grok or Stockholm?

For now, I ❤️ Go and keep using it, even with the error handling it has.

Join CTO Newsletter

Join more than 2700 CTOs and Engineering Managers

More Stuff from Stephan

Other interesting articles for CTOs

Best books for CTOThe CTO BookExperienced CTO CoachCTO CoachingConsulting and Workshops to Save you TimeCTO MentorCTO MentoringCTO NewsletterHow many developers do you need?Postgres for Everything Technology and RoadmapsHow to become a CTO in a company - a career path

Other Articles

Selfhealing Code for Startup CTOs and Solo Founders

Dear CTO - This is Why Marketing is Getting All the Money

Best Books for a CTO

Musings about error handling mechanisms in programming languages

Reasons for Technical Debt