Go: Egotistical Minimalism

Recently, I've been tinkering with the language Go. I do believe that the language at some point had extremely high promise. Go, being a language whose official spec allows for interpretation and compilation is on paper extremely powerful. But, as always, there are extreme issues with the standard maintainers.

What Go does Well

Despite me not enjoying the extensiveness of the Go standard (or the lack thereof), Go as a language has some amazing design aspects:

• Concurrency
  • Go is one of the best languages for concurrency from a face-first standpoint. The amazing idea of building channels directly into the specification makes writing parallel code amazing by comparison to even some of the highest abstraction languages
• Simplicity
  • It might sound stupid to talk about simplicity while complaining about the lack of a "larger" STD, but all will be explained in the bad chapter. For now, it's impressive how Go is able to be learned in pretty much a day no matter what language background you come from. It has extremely forward syntax only flipping a few C designs on their head.

What Should a Standard Library be

Taking a quick break before the bad, a straight-forward definition of what a perfect standard library should be is important. A Standard Library (STD) should encapsulate everything that the developer user-base could want for quality-of-life. Examples of amazing STDs can be seen in languages like Python and Rust. Both Python and Rust are still being grown with many of the requested features, which are logical, getting published into the official language specification / library.

That design philosophy and commitment to developer ease-of-life is in my eyes a near perfect STD. Now, to go onto the bad of Go.

What Go Does Poorly

Go along with every language has issues, but Go has some that need to be addressed before this language can be used over languages like Python and Rust.

• Standard Library Conservatism
  • Have you ever been using Go and wondered, "I wonder if the standard library has something for this"? If you're someone like me expecting functional iterators you've been completely disappointed. It leaves you feeling like you were using C with no benefits. This extends to plenty of places even the math library. Recently, when problem solving I was in need of a clamp method to simplify the readability of code. Sadly, I was highly disappointed to not see a implementation, but it was rejected.
  • Rejections in a standard on features as minimal as clamp show the ridiculous righteousness of the maintainers to not "taint" their standard.
• Bad Typing
  • Typing in Go was a headache comparing it to any other statically typed language; How many different ways do you believe you can write
    personAge = 0? Well, if you didn't answer 3 you'd be wrong. Even that count is misleading considering the permutations of specifying the primitive 0 is supposed to represent.

Future of Go

I highly doubt Go will be going anywhere within even the next decade. Alas, within that decade of progression it can only be prayed for that the standard has its shackles removed and it is given the freedom it deserves to spread its little arms and legs.