"Project soup" is my Golang Rite of Passage
I have been a software dev for 10+ years, but learned Golang recently.
A big moment for me was when I started remixing parts of multiple open source projects into my own little project soup.
By the way, I’m being ethical here: Projects were MIT licensed, I am not selling anything I made this way, etc.
Anyway, the Project soup:
- Built from the ground up
- Know exactly how it works
- “Stolen” code integrated as modules
- Project setup did not become a mess
- Still compiles super fast
I think this is an example where many of the strengths of Golang come together in a beautiful way, and will try to shine some light on what made it possible for me to do this.
1 Go developers actually KISS
(Keep It Super Simple)
In Golang, there many things the language designers intentionally saved you from:
- Doing Object Oriented Programming with
class
es - Deciding where to handle
Exception
s - Extreme use of the type system
- Doing too much on one line of code
- Fiddling with code formatting
But!
There is also things that would be allowed, but Golang developers seem to avoid:
- Lots of abstractions piled on top of each other
- Extremely function flavored programming
- Bad use of libraries
- Overusing generics
The reasons for why Golang devs do not tend to do these things are probably complex.
I believe Golang attracts pragmatic developers that align with the goals and vibes of the language and prioritizing “getting shit done” over many other things, as well as KISSing.
Golang also changes the developers mindset to some degree by the errors and warnings the compiler emits. It does a good job of severly discouraging many practices without making them completely impossible. I would argue this is relevant, it certainly worked for me, and is a cool use of nudging. If ever there was a population that needed to be nudged, it is software developers.
Anyway, the absence of these practices is wonderful, and it is the most important piece for making the project soup possible, because reading other peoples code is not a cognitive nightmare! Hooray.
2 Nice Standard Library, Bro
I think the golang stdlib strikes a difficult balance very well. It embodies the KISS culture I was talking about while offering most of the things a golang user needs to do most of the time, and doing them well enough.
While I acknowledge various criticisms of it, developers did not feel the need to use a bunch of competing alternative standard libraries all over their code base (like in JS).
Notably neither the language itself, nor the golang stdlib has also not been fucked up by big changes to the language. I do not care how big the flaws in your language or stdlib are: If you make breaking changes, it is almost always a horrible trap. Just leave it alone.
Golang has been super careful to avoid this horrible trap. Thank you.
3 The Modules / Library system does not suck
The way imports/modules work is clear, debugging them is intuitive, and nothing major about them is messed up. If this sounds like table stakes to you, well, I wish you the best of luck with other languages.
Tips
I used some of the
replace github.com/foo/bar => ./bar
syntax in mygo.mod
files so that I could develop two separate projects in tandem. This is awesome.Take note of the
go vendor
command, which automates the annoying work of cloning package manager dependencies into your own source code.
The end!
I could ramble about cool Golang things more, but writing this is taking too much time.
PS
If you are trying out Golang, and annoyed about “unused variables” being a compiler error: It makes sense, don’t let it stop you from trying out this language :)