Introduction

There's always been enough changing in the Javascript and TypeScript ecosystem that there's always been another thing to learn. Although I knew go would be faster, I had always thought that it would complicate the stack as a single developer or even a small team of developers to have to clutter the stack with another language.

What I found was that once past the initial learning curve, the speed and simplicity of go made it a great addition to my toolbelt. Here are ten things I learnt that made me a better JS developer.

Simplicity

Go actually has a relatively small surface area. It has fewer choices in many areas because the go team and community have made so many decisions and placed a lot into the standard library.

Interface oriented design

Coming from languages like javascript there are always the option to use classes. Interfaces provide a clean way to implement a contract without the need for classes. If it walks like a duck and talks like a duck, it's a duck (ok Ruby I know you taught that to us too but classes tempt everyone to the dark side).

I've never loved inheritance and it's great to see that you can design great things without them entirely. Rust is also a modern language that has completely done away with classes.

Error handling

There's no try catch in go. The preferred interface is to return an error as a second argument. This means a few things:

• Errors are handled when they occur
• Errors are not silently ignored
• You can use the successful return without extra boilerplate

func main() {
    result, err := doSomething()
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println(result)
 
    sum, err := doSomethingElse()
    if err != nil {
        log.Fatal(err)
    }
}

The main thing to note here is that the result can be used without the problem in javascript of defining a value outside of a closure. Also we don't have a giant catchall that has to figure out far from the error what the error was.

The more javascript equivalent would be:

function main() {
  let result
  try {
    result = doSomething()
  } catch (err) {
    console.error(err)
  }
  console.log(result)
 
  let sum
  try {
    sum = doSomethingElse()
  } catch (err) {
    console.error(err)
  }
}

But in reality we normally see a giant try catch block around the entire function and so many errors are silently ignored.

In JS I've experimented with neverthrow which definitely helps to use a more explicity return type but there's definitely a learning curve to the rest of the team and while the small try catch loop is a bit ugly, there's not necessarily as much to learn. Which leads me to...

More features aren't always better

It's better to have simpler code, fewer good ways to do something, and have code look the same than to have hundreds and everyone doing something different.

A better api is often the simpler one.

It's ok to have short variable names

This is a hard one for me, I've always liked descriptive names but in go it's common to have short variable names. This is because the scope of the variable is often very small and the type is often very clear. Lean to having smaller more focused scopes and good interfaces describing the variables. Even declaring a func is shortened!

Early return

Early return isn't just recommended, it's the norm. This is because the error handling is so explicit and the return values are so clear that it's easy to see what's happening. This helps prevent a lot of nested if's and code that is hard to follow because it's not clear what the return value is or has shifted so much to the right.

Comments are documentation

Comments are just // in go. There's no go doc special formatting to learn. If the comment appears above a function, it magically becomes the documentation for it. func add(a int, b int) example:

// Adds two numbers together
func add(a int, b int) {
    return a + b
}

contrast this with jsdoc

/**
 * Adds two numbers together
 * @param {number} a
 * @param {number} b
 * @returns {number}
 */
function add(a, b) {
  return a + b
}

Context

Context is a special concept in go that allows to pass around both values (which is normal but not idiomatic in js), but also a way to timeout or cancel a request. This is a great way to handle timeouts and cancellations in a way that is built into the language.

 
func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()
 
    result, err := doSomething(ctx)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println(result)
}
 
func doSomething(ctx context.Context) (string, error) {
    select {
    case <-ctx.Done(): // this check allows a function to check for the timeout and exit gracefully
        return "", ctx.Err()
    default:
        return "done", nil
    }
}

Ordered params are ok

Ordered params are ok in other languages but I've long held the belief that named params are better. In go, the idiomatic way is to use ordered params. This is because the function signature is often very clear and the function is often very small.

So I've updated my belief that if the function is small and the params are clear, ordered params are ok. I'm still going to dread refactoring back to a named param function (or single interface in go) when I want to go back.

Don't use util packages

This is not a hard and fast rule but something I learned from more people in the go community than not. This is because it's often better to have a small package that does one thing well and is easy to understand. This is a great way to keep the codebase clean and easy to understand.

This post from Dave Cheney explains it well.

Name your packages after what they provide, not what they contain.

Still there's things I miss

There's still a few thorns in the roses.

• I miss default initializers for params. There's no easy way to do const { a = 1 } = {} in go.

Conclusion

There's far more to like about go than dislike, and I'm glad I took the time to learn it. It's made me a better JS developer and I'm sure it will make me a better developer in general. I'm looking forward to using it more in the future.