I decided to start learning Go for a small handful of reasons:
- Go has massive concurrency
- Go emphasizes simplicity
- Go compiles down to a single binary so it’s easy to distribute
- I want to better understand pointers
- Companies and projects that I trust use it (Docker, K8s, Netflix, Twitch, Digital Ocean, Caddy, ddev, etc)
I want the software I build to be massively concurrent and have high degrees of interactivity. I think that most web-based software should have the level of collaborative interactivity of Google Sheets, and PHP/Django/Ruby were never going to get me there. Server-side JS theoretically could get me there, but I don’t believe that JavaScript’s ecosystem lends itself to quality software.
I wanted to audition both Go and Elixir for the back-end of a high-concurrency messaging app. I chose to learn Go first for the reasons listed in the bullet points above.
What I’ve learned from Go so far
A few interesting things have been happening as I’ve been learning Go.
For one, the Go community really values using the standard library. Like really values using it. They value using it so much that ORMs take a back seat in Go programming for the standard library’s database/sql package. Go developers seem to favor hand-rolling functions for queries, and loading necessary relationships within that function.
When I originally read the poorly-titled programming think piece The Vietnam of Computer Science, I hadn’t actually seen many serious examples of code & tools where some kind of high-level query abstraction wasn’t used. Be it WP_Query, Eloquent, Active Record, Django ORM, Prisma, Doctrine or Hibernate: every tool I saw used some kind of ORM.
The Go community is rich with example code of ORM-free programming. It’s verbose but it’s fine. What I’ve found particularly interesting is the idea of how to solve the partial-object problem. The partial-object problem is when only a certain subset of fields are loaded increase performance. This can cause problems if methods that depend on the omitted fields are called.
ORMs tend to be coupled with ideas of MVC programming, where the “M” is the model (or digital representation) of an item in a system. Whereas ORMs omit fields from an object, Go programmers seem to create another representation of the object itself via a new struct type, which will have a different set of methods limited to those that can handle the more limited set of attributes. Go’s structs also force the programmer to deal with the properties declaratively at the code level, whereas ORMs like Eloquent and Active Record make model properties a run-time concern.
Another interesting idea I’ve seen in Go is construction functions. This is a term I’m familiar with from ES-5 flavored JS and PHP, but what Go is getting at is a slightly different idea.
Go is strongly influenced by C. C doesn’t have objects as a first class citizen like Java; instead, it has structs. Structs can be thought of as strongly typed PHP associative arrays. You can theoretically throw pointers to functions in struct’s property value, but those functions don’t have knowledge of the exact struct it is attached to. I always thought of C’s imperative struct-based programming and object-oriented programming as completely discrete and diametrically opposed: I never saw anything that would lead me to believe otherwise.
Between reading Go could and watching YouTube videos of game engine programmers that code C++ in a C-liked style, I finally saw the code that threaded the needle between these two concepts:
p := newPost("Hello, World!", "This is my first post")
Just like that, it all suddenly clicked: the new keyword in PHP & JS, and the .new() method in Ruby are just syntax around an old C convention: a constructor function that constructs a struct. The constructor function validates any incoming data, sets appropriate properties, and news up any other structs needed as dependencies of that struct. Brilliant! I’m learning so much.
Finally, a couple of honorable mentions.
I hate writing if err != nil five times in each function, but it makes the language incredibly safe and it forces programmers to consider writing simpler control flow. I think this is a win for software stability, but it makes me never want to write Go.
I also hated using uppercase variable & function names for defining visibility when I first start using Go. I’ve come around on this one.
I have a decision to make
I decided to learn Go to make modern bulletin board software with concurrency for real-time communication with clients. I wanted to compare Go and Elixir for a back-end, then learn Kotlin and Swift to build the front-end.
But all the while, I’ve been desperate to build technology that crosses the digital threshold and escapes the glowing rectangle. I finally finished my first non-webapp Pi project that interacted with non-traditional user interfaces. I want to move into embedded hardware that interact with things in the real world instead of looking at a screen. Listening to Jonathan Blow and Casey Muratori have made me want to stop spending my potential building web apps and dive deep into learning what computers actually do and learn how to solve hard problems that have nothing to do with centering divs on a web page.
All of these roads lead to C.
I have a choice I need to make. Do I try to build a company that produces high quality boring software that could be very profitable someday? Or do I double down on becoming a better programmer building the things that actually excite me, though it will be less lucrative.
It’s not an obvious choice. Optimizing for profit now gives me the potential for much greater freedom to do whatever I want in the future. But that future is not guaranteed. And as I get older, neuroplasticity reduces and it becomes more difficult to learn new hard things. If I focus on building a boring business around a bulletin board, it could be ten years before I swing back around to the things that excite me.
I don’t need to make this choice today. It’ll be at least a few months before I feel comfortable enough with Go to consider picking up a new language. But this one is going to be a big choice with major impacts on where I take my career and life.
In the meantime, I should make a couple of YouTube videos and see what sticks.
Noise in F# 