Getting Started with Go

Normally, I would go slowly through all the setup and getting started with a new programming language, but, while I haven't done anything with Go recently (certainly not recently enough to have a compiler on any of my machines), it isn't totally unfamiliar to me and it also seems to be very well documented.

So, in brief:

• I followed the instructions to download and install the compiler and tools on both my Mac and Linux box as described in the Go guide;
• I installed the official Go plugin on VS Code;
• I researched project layouts on the internet and fixed on this self-describing one;
• I bought a copy of the Go programming language;
• And I borrowed the one book on Go that I could find in the Manchester library system.

(I should perhaps clarify that simply buying or borrowing a book is not the same as reading it. That is an ongoing parallel process.)

I didn't bother with any of the tutorials.

Ready to Go

So, with all that being said, I feel ready to get going on this project. I'm going to whip through the first phase (building a client/server web application) because it isn't what I want to focus on this time.

I created a new project structure (this is not under my usual IgnoranceBlog) and created a new git repo for it at:

https://github.com/gmmapowell/ChainLedger

I populated that with a go.mod file:

module github.com/gmmapowell/ChainLedger

go 1.23

The first line is a unique "module identifier" which seems to be the basic git url of most projects. I can't tell if that's just a convention as it is in Java package names (this is a good one in a world that increasingly uses git and github) or whether it really expects that it can find the source code there if it goes looking for it.

The second line indicates the version of go that is used by the project.

And then I created some of the recommended standard directories:

• cmd/chainledger/ - a directory to hold the main function for the ChainLedger node; this will build to an executable called chainledger;
• cmd/ledgerclient/ - a directory to hold the main function for the client; this will build to an executable called ledgerclient;
• internal/ - a directory to hold all the packages we will create to provide the common code.

In line with what seems to be the recommendation, I plan to have just one file - main.go - in each of the cmd directories, and that will only have one function in it - main() - and everything else will be buried somewhere inside internal. If I have understood things correctly, no code that is not in a subdirectory called pkg will be available to any other Go programs. Don't get me wrong - I'm not selfish - but it seems that at this time I am building something for myself and sharing it to an unsuspecting world would be unkind.

Initial Impressions

My initial impressions of Go (this time around) are generally favourable. While I had some issues getting set up and started, they were relatively minor and just reflected inexperience on my part. I think, as much as anything, I was having issues with VSCode.

• The error annotations in VSCode seem odd; I think I'm struggling to understand when I see something underlined what the problem is. And in particular, I have had issues with how "opinionated" Go is about things like unused variables and imports. So I was trying to understand why the import I'd just added was an error, rather than getting on and writing the next line of code that, by using the import, would fix the error.
• In the same vein, sometimes VSCode is able to find a module I've referenced and will automatically include the import when I save the file; other times it makes me do it myself. I'm not sure why.
• I have found interpreting the error messages to be difficult from time to time, and sometimes even had to Google them to get an explanation. If this happens in the future, I will call it out and explain what I discover.
• I haven't yet found any errors for which the VSCode plugin can offer me a "quick fix". As somebody who thinks that Eclipse can write all my code by just pushing "C-1" frequently enough, this is annoying.
• I love the way that code formatting is not up for debate and that the plugin reformats your code correctly every time you save. I don't care (that much) about code layout, but consistency is massively important to me. And not having people argue about trivia is priceless.
• The use of case to indicate whether something is "public" or "private" is simultaneously very clear and very odd to me. I like the fact that you can look at something and know by its name which it is, but it seems somehow understated.
• The use of error return codes rather than having exception handling feels, contrariwise, very cluttered. I have a lot of lines of boilerplate error-handling code that doesn't seem "normal" to me. I'm looking to see if there is some convention I have missed. On the other hand, I do know that automated exception unwinding is expensive to implement, so I guess it does mean you have more control and the code can be more efficient. Everything is a trade-off.
• I have been sufficiently long in the Java/JavaScript world that the explicit use of & and * to turn objects to pointers and back again is confusing to me. As are the consequences (such as that if you store pointers in a map you won't find it by using a different pointer to the same "value"). This is just something I will have to get used to again. It's further complicated by the fact that whenever you pass around an interface, there appears to be an extra layer of automatic "pointer-ness" going on that is messing with my head.
• It is nice, though, that even though it has the "feel" of a C/C++ language, it does have automatic memory allocation and deallocation, and especially that it automatically handles the placing of objects on the stack or heap depending on what happens to them.
• The "object definition" model is going to take a bit of getting used to. While I am a big fan of "implicit interface declarations", both the declaration and the use feel a little uncomfortable. We'll see how it goes.

I have a lot to learn. Hopefully I can share some of that.

Let's get started writing some code! If you have checked out the git repository above and are reading this as I publish it, you may well find that the code is ahead of the blog. I have tried very hard to use tags to keep track of the history, but I don't always reference the tag in the blog. I'm working towards having that happen more automatically.