hpr-knowledge-base/hpr_transcripts/hpr1793.txt

Episode: 1793
Title: HPR1793: Some thoughts about the Go language
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1793/hpr1793.mp3
Transcribed: 2025-10-18 09:23:01

---

This is HPR Episode 1793 entitled Some Thoughts About the Go language.
It is hosted by Stilroyd and is about 9 minutes long.
The summary is, I've been learning go recently.
Here are my initial thoughts about the language and framework.
This episode of HPR is brought to you by An Honesthost.com.
Get 15% discount on all shared hosting with the offer code HPR15, that's HPR15.
Better web hosting that's Honest and Fair at An Honesthost.com.
Hello and welcome to another episode of Hacker Public Radio.
I'm Stilroyd and I'm going to talk to you about my experiences of starting to learn
the go language from Google.
But first I have an admission.
I've had a week off work and the intention to record something for HPR all week, but I've
been unable to think of a single topic.
This is actually recording of a blog post that I wrote a couple of weeks ago.
Most of the time when I've got some software I want to write.
I do it in Python or sometimes Bash.
Occasionally though, I like to slip into something with a few more brackets.
I've written a bit of C in the past and love it, but recently I've been learning go
and what's really struck me is how clever it is.
I'm not just talking about the technical merits of the language itself, it's clever
in several areas.
The first of these is that you don't need to install anything to run go binaries.
At first I'm sure like many others I felt a little revulsion when I heard that go compiles
to statically linked binaries, but after having used and played with go a bit over the past
few weeks I think it's rather clever and was somewhat ahead of the game.
In the current climate where DevOps folks and developers are getting excited about containers
and componentized services, being able to simply pull down a binary file from the internet
and have it usable within your container without needing to install a stack of dependencies
is actually quite powerful.
It seems to me there's a general trend towards preferring readiness of use over efficiency
of space used both in RAM and disk space and it makes sense.
Storage is cheap these days, a 10 maybe byte binary is no concern even if you need several
of them, when you have a tabby byte drive in your machine.
The extravagance of large binaries is no longer so relevant when you're comparing it with
your collection of two Gabby byte Blu-ray rips.
The days of needing to count the bytes are gone.
I should probably take a moment now to explain my use of the terms maybe byte, Gabby byte,
Tabby byte, because probably not everybody listening to HPR has heard of these terms.
You're probably more familiar with megabytes, gigabytes, terabytes, etc.
However, as an article on Wikipedia, which you can find quite easily, will explain, the
more traditional terms are using prefixes that have meanings outside of computer science.
Kilo means 1000, mega means 1 million, giga means 1000 times that again, and so on.
Whereas in the field of computing, we're used to the terms meaning powers of 1024,
1000 and 24 itself being the nearest power of 2 to 1000, which makes it a much easier
number to deal with in the land of bits and bytes where everything is based around the
number 2.
So the new prefixes represent those two base numbers, kibby, maybe, gibby, tabby, and so on.
Personally I think they are much clearer to use and much less open to abuse.
I'm sure many of you listening will have been caught out by the promise of a new USB
drive you bought, which claims to have 32 gigabytes of space, but when you plug it in,
it shows something closer to 29.
That's because they were talking about gigabytes, and your computer tells you things in
gibby bytes.
Anyway, I hope that's cleared up my use of those terms for anyone who wasn't familiar
with them.
So back to go, the second thing that I think is quite clever about go is that it gives
you the feeling of programming in C, but you don't have the ability to do all that kind
of mucking around in memory.
It's not as dangerous.
Sometimes you just feel like you need to write something quite low level and you want
more direct control than you have while you're working from the comfort blanket of Python
or Ruby.
Go gives you the ability to have well-defined data structures and to care about how much
memory you're eating when you know your application needs to process tabby bytes of data.
Go doesn't give you is the freedom to muck about in memory, fall off the end of a raise,
leave pointers dangling all over the place, and generally make tiny, tiny mistakes that
take years for anyone to discover.
For an example of the kind of bug that I'm talking about, go read about Heartbleed on Wikipedia.
The next clever feature about go is that the build system is designed around how we,
as developers, use code hosting facilities.
Go has a fairly impressive set of features built into it, but if you need something that's
not already included, there's a good chance that someone out there has written what you
need.
Go provides a package search tool that makes it very easy to find what you're looking
for, and when you've found it, using it is stupidly simple.
You add an import declaration into your code.
You just type something like import github.com slash code gangster slash CLI.
That's a library that I've been using recently.
This makes it very clear where the code has come from and where you would need to go to
have a look at the source code or the documentation.
Next, pulling the code down and compiling it ready for linking into your own binary is
a very simple command.
You simply type go get github.com slash code gangster slash CLI.
Same example again.
Go implicitly understands git and the various methods of retrieving code, so you just need
to tell it where to look and it will figure the rest out.
The three features I've just outlined, not needing to install any dependencies to run
the binaries, protection from the direct memory access that languages like C give you,
and simple integration with sites like github.
Make me start to wonder if Google have a time machine.
Go seems to have nicely predicted several worries and trends since its announcement back
in 2009.
There's a trend towards ease of deployment and not having to install the loaded dependencies
when you need something and seeing software packages as appliances that you simply install
and use and you don't need to worry about how they integrate with everything else.
And go seems to target that very well.
Secondly, go addresses the concerns of direct memory access from languages like C by providing
the power and expressiveness of C but without the ability to directly manipulate memory
and cause all the bugs like heartbleed, etc.
If I was wearing a tinfoil hat, I might suggest that Google already knew something about
heartbleed and the like back when they were first designing go, luckily I'm not wearing
a tinfoil hat.
And lastly, go seems to have predicted the advent of social coding, this idea that everybody
can put something up on github and everybody sharing code and I can make a pull request
from your repository and make something new from it.
After all, my experience of learning Go so far has been a rewarding and interesting one.
Go for me at least combines some of my favourite features from C and Python and it has a really
powerful set of features built into the standard library.
I've already knocked up a couple of simple command line utilities that I use every single
day because it's just so easy to quickly knock some things together.
It still feels to me that Go has a bit of a niche appeal.
It's very well geared towards writing fairly small utilities that do very bespoke things
and it's quite easy to bring those small utilities together, perhaps lots of them all
together, parts of a larger project.
But at the moment, Go is designed to be cross platform, it's available for Linux, Mac
and Windows and so its APIs are fairly generic.
It's easy to access, stand it in and stand it out to get and receive data from the
command line, but not so easy to do interesting terminal effects.
I don't think I've seen a curse's library for Go, for example.
And certainly there doesn't seem to be an X Windows library.
It's possible these things will change, it's possible they already have and I just haven't
seen them yet, but certainly I've not heard of anything like a window manager or a text
editor or a mail client written in Go.
But I have seen quite a lot of server side tools and small command line utilities and maybe
that's the way things are going to go.
There are a couple of really prominent applications that I use literally every single day that are
written in Go.
The first of them is Docker and the second is Sync Thing.
I strongly recommend you look at both of those if you haven't before.
I'm considering doing an episode on HPR about Docker, so I'd be particularly keen to receive
any feedback to let me know that you're interested or what particular aspects of Docker you
think I should cover.
I think that's just about wraps up everything I have to say about Go without delving into
some pretty technical stuff that I don't think would really come across in a podcast.
Thanks for taking the time to listen to me.
If you've enjoyed listening to this, please consider recording something of your own,
even if it's just to read out an old blog post you wrote a while back.
Bye for now.
You've been listening to HECCA Public Radio at HECCA Public Radio dot org.
We are a community podcast network that releases shows every weekday, Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast, then click on our contributing to find out
how easy it really is.
HECCA Public Radio was founded by the Digital Dog Pound and the Infonomicom Computer Club
and is part of the binary revolution at binwreff.com.
If you have comments on today's show, please email the host directly, leave a comment on
the website or record a follow-up episode yourself.
Unless otherwise stated, today's show is released on the creative commons, attribution,
share a like, free dot org license.