Go

After many years working with Ruby, I migrate to Go without much experience with the language. My first friction was with dependency management because I always find it bad, with fuzzy commands and, the worst, without distinction between development and production dependencies, since both of them are included in the binary. Let’s take a look at a go.mod from a PoC:

module github.com/mfbmina/poc_circuit_breaker

go 1.24

require github.com/sony/gobreaker/v2 v2.0.0 // indirect

Time goes by, these issues were solved, I was able to understand how this management worked, and I’m still working mainly with Go. When I read that the 1.24 version will bring the “go tool” feature, I was excited about it, and usually I’m not the kind of guy that follows the upcoming versions, but after testing it out, I was disappointed.

One of my favorite features in Go is the possibility of writing benchmark tests. At Go 1.24, this feature has a new look, making it easier to use.

To demonstrate these changes, let’s suppose a function that calculates the factorial recursively and one that calculates it through loops.

func FatorialRecursive(n int) int {
  if n == 0 {
    return 1
  }

  return n * FatorialRecursive(n-1)
}

func FatorialLoop(n int) int {
  aux := 1
  for i := 1; i <= n; i++ {
    aux *= i
  }

  return aux
}

Previously, to write a benchmark, it was necessary to write down the whole execution loop of the test. When done, we need to run the command $ go test -bench .

Nowadays, a huge part of a developer’s work consists in calling APIs, sometimes to integrate with a team within the company, sometimes to build an integration with a supplier.

The other big role in daily work is to write tests. Tests ensure (or should guarantee :D) that all the code written by us works on how it is expected and, therefore, it will not happen any surprises when the feature is running at production environment.

At the developing world, it is necessary to know how the application that you’re working on is behaving, and the most known way of doing that is by metrics. They can be of several types, such as performance, product, or health. Nowadays, Prometheus is the market way for collecting metrics.

It is an open-source service maintained by CNCF , the Cloud Native Computing Foundation. It works like the following: an endpoint is exposed, and it responds with a desired body format. Then Prometheus calls this endpoint time to time, collecting all the information from there.

The first time I heard about RPC, I was in a distributed systems class while completing my bachelor’s in computer science. I like it but didn’t fully understand why I should use it instead of REST. Time passed, and I started working at a company where the legacy services use SOAP. I remember thinking: “hm, that’s cool! It is like RPC but using XML instead! Years later, I heard for the first time about gRPC, but I’ve never fully understood it until now!

Today it is common for our applications to have a couple of dependencies, especially when working in a microservice environment. It isn’t rare when our app reports errors, we find out that one dependency is down.

One good practice for improving our resilience is to shut down the communication with those apps that are not behaving well. Looking into other fields, we learned the concept of circuit breakers from electrical engineering, where a switch turns off when a failure happens. In Brazil, all houses have these switches that automatically shut down if our electric network becomes unstable.

Building a game is an excellent way of starting programming. Tons of people have started programming because they wanted to create computer games. Even me, back in 2010, had one of my first projects to write a small game when I was still in my Technician course.

In this course, we used Python to develop a slide puzzle. It was very challenging because I had to learn about the game mechanics and GUI, but I could handle the project. When I started to work with Ruby, I also built one to compare with what I did with Python.

Linter is a static code analysis tool used to find programming errors, bugs, leaks of code standards, and even security flaws. These tools help developers because they save time by identifying issues before they happen in the production environment. It also keeps developers from unnecessarily checking if your colleague used the team standards.

Each programming language has their own tools: Ruby has Rubocop , JS has Eslint , and Go can’t be different. Searching at Awesome Go , a curated list of Go software, many tools can lint your code, but my favorite is golangci-lint . It is an aggregator of linting tools, meaning you only need one tool for multiple linters in your project.

Computer and programming languages were born to make our lives easier, as they automatize day-to-day tasks. Programmers and software engineers usually have to build files that are almost the same as others, where the only change is one field or another. For example, there are configuration files, invoices, XMLs, HTMLs or any file which we can use to build other files. There is a simple solution for this problem: we can create a template and change the parts that I need manually! That works, but it is not the best way to deal with the problem because it is scalable. We can use technology to help.

The Kong, quoting its own documentation , is an open-source API gateway, cloud-native, platform-agnostic, scalable API Gateway distinguished for its high performance and extensibility via plugins. Kong has a lot of official plugins that allow us to customize what we need, and when there aren’t any available, you can build your own.

The default language for building plugins its Lua, but other languages are supported, including Go. I don’t have much experience writing code with Lua, so using Go allows me a higher development speed and quality on my plugins.