Original post

Posted on April 13, 2018 by Chris Hodapp

After I wrote my post on Python and asyncio, I had the opportunity to work with the Go language for some other projects, and I started jotting down my opinions on it as I did so.

After using it for a bit, I decided that it’s mostly C with concurrency, seamless M:N threading, garbage collection, fast compilation, namespaces, multiple return values, packages, a mostly sane build system, no C preprocessor, minimal object-oriented support, interfaces, anonymous functions, and closures. Those aren’t trivialities; they’re all rather great things.

I’m a functional programming nerd. I just happen to also have a lot of experience being knee-deep in C and C++ code. I’m looking at from two perspectives: compared to C, and compared to any other programming language that might be used to solve similar problems.

It still has goto. This makes the electrical engineer in me happy. Anyone who tells me I should write in a C-like language without goto can go take a flying leap.

The concurrency support is excellent when compared to C and even compared to something like Python. The ability to seamlessly transition a block of code in between running sychronously and running asynchronously (by making it into a goroutine) is very helpful, and so is the fact that muxes these goroutines onto system threads more or less transparently.

Concurrency was made a central aim in this language. If you’ve not watched Rob Pike’s Concurrency is not parallelism talk, go do it now. While it’s perhaps not my favorite approach to concurrency. While I may not be a fan of the style of concurrency that it uses (based on CSP rather than the more Erlang-ian message passing), this is still a far superior style to the very popular concurrency paradigm of Concurrency Is Easy, We’ll Just Ignore It Now and Duct-Tape the Support On Later. Why I went from Python to Go (and not node.js), in my opinion, is spot-on.

Many packages are available for it, and from all I’ve seen, they are sensible packages – not leftpad-style idiocy. I’m sure that if I look more carefully, a lot of packages mostly exist in order to patch over limitations in the language – but so far, I’ve yet to encounter a single 3rd-party uber-package that is effectively a requirement for doing any “real” work in the language, while the standard libraries don’t look excessive either.

I don’t exactly make it a secret that I am not a fan of object-oriented programming. I like that Go’s support for OOP is rather minimal: it’s just interfaces and some syntactic sugar around structs.

The syntax and typing are very familiar to anyone who has used C, and they seem to make it easy for editors/IDEs to integrate with (likely by design). It all feels very solid.

However, while defer, panic, and recover are an improvement over C, I’m not a fan of its oppositions to exceptions as a normal error-handling mechanism. Also, while I tend to prefer strongly-typed and statically-typed languages, I feel like the type system is also still very limited (particularly, things like the lack of any parametric polymorphism). I’d probably prefer something more like in Rust.

My objections aren’t unique. Ten Reasons Why I Don’t Like Golang and Why Go Is Not Good have criticisms I can’t really disagree with.

All in all, though, a lot of good design was put into Go, both in the language and its tooling.

Please enable JavaScript to view the comments powered by Disqus.