So, I was doing some code reviews at work recently, and I saw a place where a co-worker needed to create a list of a single item. We use Java at my company, and Java has a lot of different ways to do this. The way that he had chosen seemed wrong to me, but I couldn’t quite put my finger on why.

The two standard ways (since Java 9) that I think most people would do this are either

List<String> stuff = List.of("first", "second");

or

List<String> stuff = Arrays.asList("first", "second");

He had chosen to use the latter, however I always use the former. I assumed that the end-result was the same – after all, they both create a List<String>.

The difference

In short, List.of creates an immutable List, while Arrays.asList creates a mutable List. They’re both implementations of the List interface, and they both have the same methods available, but the former is immutable. For example...

Go is generally an exceptionally simple language, and that’s reflected through it’s very small number of keywords – one of the lowest of any modern language (source). There are also some built-in functions that I’m sure you use every day – append(), make(), and copy() are the main ones. You might even use new() to create a pointer. But did you know that there are actually over a dozen of these built-in functions, and some of them aren’t even guaranteed to be permanent?

What are all of these built-in functions

For reference, the Go documentation has the full list here, but I’ll at least mention them all in this article.

• len(x): You’re probably familiar with this one – it gives you the length of x, and handles different types in different ways. In an array or slice, you get the number of elements contained within it. For a string, you get the number of bytes.
• cap(x): This is a...

I was working on the Blog Engine (Bla) as one of my first big projects written in Go. I did a bit of planning, then started organizing code into a way that I felt made sense. It quickly fell into chaos, since I was using certain OO design patterns that don’t make any sense in a language like Go. This happened in different ways on two rewrites of the project – until I finally had to make a switch in implementation, and it blew half the project apart.

I decided to rewrite the entire project from the ground-up, and to take plenty of time to make sure everything is designed in a flexible and meaningful way. I looked to open-source projects for inspiration, watched lots of talks online, researched through documentation, and found an exceptional article by Go veteran Mat Ryer detailing his experience. Here is the culmination of lessons learned from these sources and my own experience:

Free

At first glance, it seemed like it would be easy

So a little bit of background first. I’m currently working on designing my own open source blog system right now, but it’s not yet completed. I thought it would be fun to write about my progress here until my actual site is done. It might be a while.

I’ve been learning Go in my free time on and off for the last few months. It’s a great programming language, and I’d highly recommend it if you’ve never tried it. Go makes a lot of things easy through its simple syntax and the amazing standard library. If there happens to be anything missing, the community also has an enormous volume of libraries. It’s a language that makes things nearly as simple as Python, but it’s compiled to machine code, so it’s really fast.

There are dozens of other reasons to love the language, but that’s not what this is about. I’m here to talk about everything...