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 Go 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.
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.
All in all, though, a lot of good design was put into Go, both in the language and its tooling.