Golang

a language that makes it quite easy for enterprises to deal with developers as cogs. – HN

Overview

GO syntax is very regressive comparing to where we hopped programming languages should go. I believe GO success is partly because in recent years, we have many new specialized engineers that programming isn’t their main focus (DevOps, Data Scientists, SREs) and naturally they are looking for tooling with shorter learning curve. - HN

Both of these decisions, in major modern languages, solve certain classes of problems—and both pay a price for their choices. Go’s error handling has become a meme, for example. Articles to help with understanding lifetimes in Rust are nearly as ubiquitous as monad tutorials for the aspiring Haskeller, and it turns out that a lot of important data structures are pretty hard to implement when you have to worry about them. Still, you can’t say that either language has failed in its goals—it’s just that each has chosen different tradeoffs. In other words: every decision made in order to simplify a program will cost something. - The Danger of “Simplicity” - HN

(No) Exception

I think we all agree that panic is throw, recover is catch, and defer is finally. - Panic recover in Go v.s. try catch in other languages

Panic/Recover are function scoped. It’s like saying that you’re only allowed one try/catch block in each function and the try has to cover the whole function. This makes it really annoying to use Panic/Recover in the same way that java/python/c# etc. use exceptions. This is intentional. This also encourages people to use Panic/Recover in the way that it was designed to be used. You’re supposed to recover() from a panic() and then return an error value to the caller.

see also

Written on April 2, 2019, Last update on February 5, 2023
lang golang simplicity complexity graph compiler exception c++