Live Reload Go Projects with wgo
Building web apps in Go is extremely rewarding. However, as Go’s a compiled language, to see changes, you need to restart the app. Needless to say that’s quite tedious! With live reloading, it doesn’t need to be.
If I could sum up today’s session in one word, it would be: fascinating. This is mainly because I started learning about pointers again!
Pointers
Pointers are a topic that has always been more than just a little bit confusing for me, ever since I first started learning them (way back in 1997), when I was learning C. For example, am I accessing the pointer’s value, or it’s location in memory? And, when I update a pointer, I’m not updating it, rather the value at the location in memory which it points to.
Ah, the joys of pointer derefencing or indirection. To come back to the topic so many years later – especially after so many years using PHP and other languages such as Ruby, Python, and Java, which don’t have pointers – made today extra special.
I’m determined to drum the concept into my head this time, and I’m heartened by the feeling that, today, it made just that much more sense. That said, while I was playing with them using structs, as in the example below, I was a little confused. But after a bit more time, it started to make sense.
1
2
3
numbers := Numbers{21, 48}
pointerToFirst := &numbers
pointerToFirst.Second = pointerToFirst.First + pointerToFirst.Second
Structs
I’m pretty familiar with structs, but it still was fun to learn more about them. I’m impressed by how flexible Go makes working with them. Actually, I’m coming to appreciate so many of the small conveniences Go makes.
Arrays & Slices
What took most of the time in today’s session was understanding arrays and slices. This is mainly because, while they seem pretty straightforward at first, they seem to break their own rules.
For example, I first read that arrays are created with a fixed size which is not able to be changed. Then, I read that slices don’t contain values, rather, they reference an underlying array, which they, in effect, provide a movable window to. What I mean by that is that they can link to a portion of, all of, or none of an underlying array.
Take the example below.
It initialises an array, a, which contains 10 integers.
Then, it initialises a slice, b, which is a view on the 1st, 2nd, and 3rd elements (2, 3, & 4) of a.
1
2
a := [10]int{1, 2, 3, 4, 5, 6, 7, 8, 9, 0}
b := a[1:4]
However, later in the Go Tour, I learned about the built-in make function which lets you create dynamically-sized arrays, and the append function which lets you append new values to a slice.
To give more background to append, the Tour says:
If the backing array of the slice is too small to fit all the given values a bigger array will be allocated. The returned slice will point to the newly allocated array.
I get that this is great for convenience, which I’m fully behind. However, as someone getting into the language, it seems to contradict itself.
I could well be wrong here, or be over-thinking it. If I am, and you’re an experienced Go developer, please let me know in the comments.
Regardless, that was a quick summary of today’s session.
See you next time!
Join the discussion
comments powered by Disqus