Why Go is my new favorite language

There are a couple languages out there at excite me a lot to think about. When I read about swift I light up with ideas about all the beautiful apps I will write with just emojis (I think that’d be fun). When I read about Rust I imagine all the low level but still very safe code I’ll be able to write. Heck, maybe I’ll be the guy who figures out how to make games with it! Speaking of games, why not learn C++ the language of games, operating systems, and the best dev tools??

But over time, I’ve been increasingly drawn to one language in particular: Go.

I first heard about Go sometime in 2013. I was working at FAU’s College of Medicine and walked in to the School’s dean office for something and found a guy writing their new website in… of all things Go. I was like “why aren’t you using something like at least PHP or Rails?” He just was learning it for fun. I guess that’s a good enough reason, but back then writing an essentially static website for non-technical people was probably managed better by some other language. I wrote off Go as some esoteric language that probably wouldn’t take off and wouldn’t be useful to me any time soon.

But things started to change for me in the past year or so. I’ve been thinking more and more about how to get some services we have to be more efficient and design for scaling. Part of it is to impress recruiters at bigger companies I wanted to work at, but the other part is more practical…

When I knew Link to heading

At some point in Late-2014 I was running a really brittle private git hosting system on a VPS. It was hard to make new repos, see what condition they were in, and even figure out what was there without logging in to the server it self. I needed a new solution.

I also had recently gotten a new $15/year server with 80 GB of space suggested to me by a friend and I wanted to put to use. However, for only $15/year it only had 128 MB (Yes, megabytes) so things like GitLab where WAY out of the question. But, I seriously couldn’t stand setting up any of the other slim git hosting. I had already taken that road twice before on the same server and hated the whole experience but did it because there weren’t any other options. The docs were horrible, the interfaces subpar, and it was starting to look like I’d give up and use bitbucket or pay github for everything I wanted.

Then I stumbled on to Gogs.

Written in Golang, this project was an all-in-one git hosting solution. It handled the git repos, the web interface to manage them, the ssh handlers to request the repos and provide the authentication to protect the code easily. I could add my friends to the site easily and add them as contributors to any number of projects I wanted. I got to work getting my roughly 100+ mostly archival repos over from the old server to this new one. Everything worked perfectly.

A few months went by. Then a few more. One day I just decided I was going to start a new project and logged in to Gogs again and created the repository. Then I thought I’d checkout the stats it keeps on the admin page for kicks. What I saw blew my mind.

I don’t remember the exact number, but in the many months of constant uptime and frequent personal use Gogs had allocated only a couple Gigs of ram ever. It was sitting around 10mb used for a fairly complicated website. I even checked in the control panel my host gave me and saw it never really went above that. The uptime of Gogs could have measured in years if the OpenVZ cluster it ran on would stop restarting every 6 months.

Coming from making websites in PHP with Laravel or Python with Django I’m used to seeing a web application soak up memory to get the job done. At least with PHP the memory gets released, but with Python you’re looking at minimum 100mb of ram usage to get the interpreter in to memory. And of course, thanks to the GIL you need 4 of those on the server behind Gunicorn to run it properly.

And here is this little Go web app that no one seemed to know about and I saw the immediate potential of Go and it completely disrupted what I thought I should be learning and doing.

The long road Link to heading

After I immediately fell in love with Go I began my quest to find every little thing wrong with it.

First off. This thing doesn’t even have versioning. Npm has versioning. Pip has versioning. Cargo and Composer use the best versioning of all the ones I mentioned. Definitely an issue.

Then what about the actual speed? Yea it’s fast, but it has a GC. So it’s algorithmically going to be more complicated and slow. It will do more computation than a well written program in C++. And Java has way better written GCs so even though they both have one Java will be faster.

Speaking of Java. It’s faster. People have written tons of code for it. Concurrency isn’t easy, but it’s not like it’s impossible. In fact, it’s really good. Why not use Java? Why even touch Go? And didn’t Rob Pike see the whole issue with Object in the early days of Java? More static typing is better! Why is this new language messing around with such a crappy type system compared to the likes of Rust??

All those issues I listed scared me from Go for a long time. But I kept my ears open and I kept hearing the same thing: Yes, these things are real. But, ask anyone using it day to day if that matters. Most don’t think so and many complaints about the type system eventually go away when they apparently realize how brilliantly simple it is.

Brilliant? They have structs with methods attached and interfaces. What in the world is so special about that?

Coming home… Link to heading

After a lot of internal arguing and debates with close friends I’ve decided that Go is not only one of the best languages to use on your next project, but a key language to learn for the future of your career.

Excluding the importance of Javascript for any web developer, especially those who call them selves full-stack like myself, Go provides a special niche that no other language can comfortably own.

There are three categories of languages that are held up for one advantage or another.

Between these categories developers who are most likely to pick up Go are on the far right like me. We use slower, easier to iterate languages that probably don’t have very good type safety. But for some reason, everyone compares Go not to python, but to Rust. Which is not even in the same category here and has a whole different use case where it is perfect, but the web development I do, where often times the goal or system is not fully realized because you’re not quite sure of the market’s exact needs, needs a language that compiles quickly, deploys easily, and allows easy iteration.

And if compare Go to Java you probably know what your choice should be: Java. But, thanks to the JVM Java doesn’t have the memory efficiencies of Go. Not to mention the culture of Java is that of over engineering and complicating solutions. I think much of the reason for those excessive designs and patterns is issues with the language itself which require these patterns to be used to get the best results. All that complexity comes at a cost though and for small start ups, teams, and projects Go is a much better option.

Small projects are now the norm with Service Oriented Architectures and Micro-services taking over the mind share of developers everywhere. In that world simplicity rules and simplicity is exactly what Go excels in.

Realize that at this point I want to use Go for only two main reasons: Memory efficiency and simplicity. Nothing to do with channels, the standard library, the go command, easy testing/benchmarking, interface{}, or it’s super easy import statement. Although those all contribute parts to what I want most from Go, and it’s what most people hold up as the biggest reasons to use Go, I just want to make efficient, simple, and scalable software that can literally grow from my 128mb OpenVZ box to the largest Amazon virtual machines.

Few languages provide what I want in a package of such simplicity and with a culture that values obvious code over pre-maturely optimized code.

And thats why I’ve decided that Go is not only a language worth learning, but a language worth investing my self in.