5 min read

Go is Korean, Lisp is Japanese

Recently I took a fresh at look at the Go programming language after having last taken a look at it before version 1.0 was released back in 2009. What I've found in just a few days is shocking in a really really good way.
Go is Korean, Lisp is Japanese
Interactive OpenGL programming with Go

(The metaphoric title of this post draws parallels using the single dimension of the complexity of each human language's writing system to programming languages.
Please bear with the author.)

As a Programming Language Theory geek for almost 20 years now I've learned about 2 dozen languages and professionally used over a dozen languages in my career in large scale real world projects. Like many who have this time consuming hobby I have long had a strong appreciation for functional programming and its idioms, strong-static typing and other less popular language features.
Recently I took a fresh at look at the Go programming language after having last taken a look at it before version 1.0 was released back in 2009.
What I've found in just a few days of really using it for serious projects is incredibly shocking, in a really really good way.

Lisp (and larger languages with fancy features)

Common Lisp is a vast language with its official text "Common Lisp. The Language" weighing in at around 1000 pages. Lisp is an old language and often inconsistent with many powerful features. I've used it in production applications and it can work but it suffers from the lack of not having enough libraries as its not popular even after being around for almost four decades now. That said many amazing features have lived on in other mainstream languages that originated in Common Lisp.

Enter Clojure, this is considered a practical Lisp and because it runs on the JVM and has easy Java inter-op it does not suffer from not having enough libraries. Clojure is far more consistent than Common Lisp and its worth learning just for the ability think differently about problems from a functional programming point of view.
I used Clojure over a decade ago to write some very large global-scale systems while I worked in the salt mines at Amazon. It worked really really well and operationally it minimized many problems that existed with languages like Java.
That said Clojure is a terse language but this does not make it a simple language.
Many Clojurists would argue with me endlessly about this. Sorry Rich and company but "simple made easy" is just a cartoon of real world programming and language design.
Clojure has many powerful language features but this is part of its problem and Clojure, while it can be easy to write, is not as easy to read over time between programmers and even by the original author.

In this way Clojure is kind of like the Japanese writing system with its 3 scripts in that there is plain Clojure, Clojure calling Java and then macros which(even though powerful) make code even more opaque. All useful but adding to the overall complexity.

I won't bother mentioning Scheme, its just not a professional grade Lisp. Nothing of note has ever been written using it in the real world that I'm aware of.

Lisp has a very old heritage and is a very powerful language family but this is part of the "Lisp Curse" which has always held it back from becoming a popular and practical team language. In reality Lisp is not really a programming language at all but more of a programming language fabric, a meta-language where you have direct access to the abstract syntax tree even if that is self-reference in the very same program !

Should I stay or should I Go now ?

(with apologies to The Clash)

Go is a unique language in that it is a systems language in a class of its own.
It is in the family as C and C++ as well as the awful and most recently hyped systems language of all ... Rust.

I've used Rust professionally for 3-4 years building non-trivial distributed systems as well as working on block-chain applications. Before professional use I followed it since 1.0 all the way back to 2014. It is an incredibly hyped language, that in my experience just doesn't deliver. The people that "love it" in those surveys are usually developers that have little to no long term professional experience with it. It is a language that sounds awesome in theory but in practice is far from an ergonomic language on multiple levels.

  • It will not automatically prevent security and concurrency issues as many believe more than many other modern systems languages such as Go and Swift or even byte code languages like Java or C#. If you must have real-time performance and absolute mission critical safety then use Ada which has proved itself over 50 years (strange that the Rust community ignored it completely).
  • It is not a productive language even for people that have been using it for years. Rust is a poor language to write in but even worse to read not only for the rest of your team but even the original author.
  • Error handling is broken beyond belief and has been for years. It makes Go error-handling look really nice by comparison.
  • Structuring large code bases is a major problem that no one really talks about.
  • Most importantly though, there are serious problems with the overly political Rust community and how they treat not only outsiders but even their own core contributors and important 3rd party library devs, many who have left on bad terms.


Yes yes, many would argue Go is not a systems language at all because it has Garbage Collection. While this is true in theory and seems like it would make Go unusable for systems programming there are numerous widely used systems level projects that are implemented in Go such as distributed databases, devops tools like Terraform, Docker and Kubernetes and many more high-throughput, low-latency, robust, highly scaled and secure distributed systems.
How can this be ? well its due to Go being a simple and ergonomic language that is not Object Oriented and so does not end up creating convoluted object trees on the heap like Java that requires a big memory footprint for its garbage collectors.
Quite the opposite, most of the time structs are allocated on the stack.
At the same time it beats Rust with its unnecessarily complex and numerous features by far in terms of productivity while coming very close in performance and equaling it in safety. It is also a better C and there is just no comparison with regards to the mess that is C++.

For the functional programmer in you, like me, Go supports first-class functions and closures. I think this is just the right amount of functional-programming and while it might not be considered sophisticated enough for some FP purists its quite incredible just how much power you can get out of this FP paradigm alone while still keeping the language simple.

Give it a decent try, you will be shocked at what you find. I even tried it out for something that it was not designed for, 3D graphics and was surprised at how smoothly this went. It has amazing library support, probably better than most languages I've used.
So to wrap up the maybe not so great metaphor, Go is the Hangul of programming languages : one of the easiest to write and read that I have ever encountered.  

GitHub - jgrant27/boing_ball_go: Amiga Boing Ball in Go !
Amiga Boing Ball in Go ! Contribute to jgrant27/boing_ball_go development by creating an account on GitHub.