This blog is just about Go, but each post will have some background info. that is not required reading.

Background

General


About Me

I’ve been developing software for more than 40 years (mainly C and C++) - using Go for 6 years now.

In the past I’ve also been the author of magazine articles (C/C++ Users Journal etc), and in 2011 I started a general software development blog (see Software Development Methodologies). I’ve also written a few popular open-source projects (Github).

More recently, I’ve been writing about Go, and spoken at the Sydney Go Meetup a few times.

Looking for a New Great Language

I learnt C++ in 1987. In 2015 I had been programming in it for about 20 years, but was frustrated that I still did not feel entirely proficient in it.

There is a lot I love about C++ such as the STL. C++11 had a lot of new useful stuff such as lambdas (that made the STL even better).

The trouble was there was just too much stuff, especially all the inheritance rules that I could never remember.

So I was looking for a new language to concentrate on. I looked at Go and Rust, and rejected Go because it had:

  • no parametric polymorphism (ie, generics)
  • GC (I’d had bad experiences with Java & C#)
  • I did not realise it had lambdas (closures)
  • Go slices were not as simple as I expected
  • it seemed to be missing obvious stuff
  • Google had too much control (bad impression)

I liked Rust especially its innovative memory/resource management. Also, it had something akin to the STL.

So I learnt Rust and started looking for a way to use it.

New Job

In January 2017 I got a new C++ job in a group that created software infrastructure, supporting several other groups using different languages (Python, Delphi, C#, Java, PHP, …). They also seemed keen on Rust.

A few months into the job they put me on a project to support another language, but it turned out to be Go not Rust. My first task was to write C++ code to generate Go code then I created a Go package to support our message passing infrastructure. It only took me a few weeks to realise that my initial impression of Go was way off track.


Go


Complexity

I started my previous blog 12 years ago. It was a response to a general uneasiness I had - that creating software continues to become more and more (unnecessarily) complex.

My very first blog post (see Handling Software Complexity) concluded that the way to conquer complexity is to use the principle of divide and conquer.

Of course, there’s more to it, which I got into with later blog posts about “Agile” development - talking about things like automated testing (“unit testing”), emergent design and the wild goose chase of reusability.

Simplicity of Go

It wasn’t until I started using Go that I realised that the programming language is a critical part of the solution. Other languages make software development more complex; Go (and it’s infrastructure) really makes things simpler.



Why Go?

My first impression of Go (8 years ago) was disappointment – this seems to be the experience of a lot of people. It was not until I started to use it (2 years later) that I started to get it.

When I think back over decades of coding, I really appreciate how much simpler my life is, now that I mainly use Go.

I’m not just talking about coding (though that is also simpler). I mean all the problems I used to spend 90% of my time on - compatibility, upgrading, portability, maintenance, testing, documenting, etc. Even just upgrading to a new compiler release could be a nightmare - a problem Go has virtually eliminated.

There are many reasons I would now choose to use Go over other languages. Some are well recognized; some (which I hope to share) are not generally appreciated.

Favourite Go Feature

Like everyone who uses Go, I wish it had some feature(s) that I have used in some other language.

But, somewhat paradoxically, my favourite feature of Go is that it does not have my favourite features. Avoiding the bells and whistles has allowed the language to stay simple (to use).

My favourite Go feature is how simple it makes everything.

Why another Go Blog?

There are already a lot of Go blogs (good and bad :); I’m not trying to compete with them, but fill in the gaps. Eg, things like I’m thinking of are:

  • coping with insufficient memory
  • optimization, such as PGO, inlining, …
  • GC issues
  • goroutine preemption
  • processor affinity
  • escape analysis
  • useful uses of generics
  • etc.

There are also occasionally concepts in Go that I have seen explained poorly (or not at all).

I’ll also keep an eye on new developments in Go issues, golang-nuts and the official Go blog, and elsewhere.

The Silver Gopher

Some reasons I started The Silver Gopher:

  • having a blog solely focussed on Go will attract the audience I am trying to help
  • my old blog is looking a bit tired
  • I want to help others to learn, and appreciate Go
  • address that Go is misrepresented (to the uninitiated)

Why Silver?

Some people consider Go to be a “second class” language, like the way silver is considered inferior to gold.

In fact, silver has far more uses than gold. (Fun fact: silver is the best conductor of all the metals?)

There are gold languages that are more superficially attractive and showy than Go. But, like silver, Go is unembellished and far more useful.

Conclusion

That’s all for now, but there will be more soon.

I hope you enjoy reading the blog as much as I (will) enjoy writing it.

Updated:

Comments