Forem: Matheus Mina

Destrinchando o pacote sync do Go

Matheus Mina — Thu, 02 Oct 2025 12:10:26 +0000

Na minha opinião, Go fornece um excelente suporte a se trabalhar concorrentemente não só pelas goroutines, mas pelo ecossistema da linguagem. Um grande exemplo disso é o pacote sync, que auxilia na sincronização das rotinas concorrentes. Neste post, vamos aprofundar em tudo que este pacote pode nos oferecer.

Waitgroups

Waitgroups são utilizados para coordenar a execução de diversas rotinas. Ele facilita a criação e a garantia de que todas as sub-rotinas serão finalizadas antes de finalizar a rotina principal. No post sobre waitgroups explico melhor como elas funcionam e o que mudou com a versão 1.25 do Go.

Mutex

Mutex é o mesmo que mutual exclusion locker, ou em português, tranca de exclusão mútua. A sua função é travar o acesso a um recurso enquanto uma operação é executada, evitando que outras rotinas tentem escrever nesse recurso ao mesmo tempo. Por exemplo, qual o retorno da função a seguir?

func count() int {
    counter := 0
    wg := sync.WaitGroup{}

    for i := 0; i < 1000; i++ {
        wg.Go(func() {
            counter++
        })
    }

    wg.Wait()
    return counter
}

Se a resposta foi 1000, existe alguma chance de você ter acertado, mas é bem improvável. Isso acontece, pois como as rotinas são executadas concorrentemente, elas podem tentar escrever no recurso ao mesmo tempo. Para garantir que isso não aconteça, basta adicionar uma mutex e travar o acesso àquele recurso.

func count() int {
    counter := 0
    mu := sync.Mutex{}
    wg := sync.WaitGroup{}

    for i := 0; i < 1000; i++ {
        wg.Go(func() {
            mu.Lock()
            counter++
            mu.Unlock()
        })
    }

    wg.Wait()
    return counter
}

O uso é bem simples, para travar o acesso a um registro você usa a função Lock e, ao finalizar, é só utilizar o Unlock. Só é necessária atenção para não cair em deadlock. Também existe a função TryLock, que valida se existe uma trava ativa ou não, porém seu caso de uso é mais raro.

RW Mutex

O RW Mutex é uma evolução da mutex onde existem travas específicas para escrita e leitura. Essa distinção é bastante útil quando uma ou mais rotinas precisam acessar um recurso só para leitura, mas não querem que o objeto seja modificado durante sua execução. Contudo, é importante citar que a escrita tem mais prioridade que a leitura e, dessa forma, Go evita o starvation.

var numbers []int
var mu sync.RWMutex

func store(x int) {
    mu.Lock()
    numbers = append(numbers, x)
    mu.Unlock()
}

func avg() float64 {
    mu.RLock()
    defer mu.RUnlock()

    size := len(numbers)
    sum := 0
    for _, n := range numbers {
        sum += n
    }

    return float64(sum) / float64(size)
}

No exemplo acima, podemos ter diversas rotinas chamando o avg para pegar a média da lista de inteiros, contudo, se uma rotina decidir inserir mais um valor, todos vão ter que esperar essa escrita finalizar.

Atomic

O atomic é um subpacote do pacote sync que implementa suporte à concorrência em tipos primitivos. Atualmente, ele suporta os seguintes tipos: bool, int32, int64, pointer, uint32, uint64, uintpointer e value. Com ele, podemos simplificar o exemplo utilizado na mutex:

func countWithAtomic() atomic.Int32 {
    var counter atomic.Int32
    wg := sync.WaitGroup{}

  counter.Add(1)
    for i := 0; i < 1000; i++ {
        wg.Go(func() {
            v, ok := counter.Load

        })
    }

    wg.Wait()
    return counter.Load()
}

É necessário notar que as operações básicas, como adição, foram reimplementadas para garantir que as rotinas não concorram pelo recurso.

Map

O Map é como qualquer outro map normal. Ele fornece funções para comparar, trocar, atribuir ou recuperar os valores, com a diferença de ser seguro para a concorrência.

func mapExample() int {
    var m sync.Map
    wg := sync.WaitGroup{}

    for i := 0; i < 1000; i++ {
        wg.Go(func() {
            m.LoadOrStore(i, i*i)
        })
    }

    wg.Wait()

    v, _ := m.Load(0)
    return v.(int)
}

A própria documentação sugere que ele deve ser utilizado em dois casos:

Quando uma chave é escrita somente uma vez, mas lida diversas vezes. Um exemplo é um cache que só cresce.
Quando múltiplas goroutines leem e escrevem grupos distintos de chaves.

Qualquer outro caso é melhor utilizar o map tradicional com mutexes.

Once

O tipo Once garante que algo será executado uma única vez, mesmo que diversas rotinas tentem executar. Um exemplo disso poderia ser a inicialização de recursos, como é demonstrado pela documentação do Go.

func doSomething() int {
    wg := sync.WaitGroup{}
    o := sync.Once{}
    result := 0

    for i := 0; i < 10; i++ {
        wg.Go(func() {
            o.Do(func() {
                result++
            })
        })
    }

    wg.Wait()
    return result
}

É importante se atentar que, caso a função entre em pânico, ela não será reexecutada.

Cond

Como o próprio nome diz, o Cond funciona a partir de uma condicional, ou seja, quando algo acontece, ele libera a execução de uma rotina. Essa execução pode ser liberada uma a uma utilizando a função signal ou ativando todas de uma só vez com o broadcast.

func condExample() {
    mu := sync.Mutex{}
    cond := sync.NewCond(&mu)
    wg := sync.WaitGroup{}
    active := false

    for i := 0; i < 1000; i++ {
        wg.Go(func() {
            cond.L.Lock()
            defer cond.L.Unlock()

            for !active {
                cond.Wait()
            }

            fmt.Println("Active is true, printing: ", i)
        })
    }

    // Activate all goroutines after some time
    time.Sleep(time.Second * 5)
    fmt.Println("Setting Active to true...")
    active = true
    fmt.Println("Wake up one goroutine...")
    cond.Signal()

    time.Sleep(time.Second * 5)
    fmt.Println("Wake up all goroutines...")
    cond.Broadcast()

    wg.Wait()
    fmt.Println("All goroutines finished.")
}

Primeiro, iniciamos um cond com algum Locker, uma interface que implementa as funções Lock e Unlock, no exemplo, utilizamos um mutex. Ao inicializar cada goroutine, é necessário garantir o lock e então a colocamos em estado de espera com o Wait, que retira o lock, permitindo que as novas rotinas sejam iniciadas. Quando uma rotina é liberada com o Signal ou Broadcast, o Wait pega o Lock novamente e libera a execução do código. A documentação do Go recomenda que o Wait aconteça dentro de um laço esperando uma condição, pois o Cond sozinho não consegue dizer se algo aconteceu ou não, mas isso não é estritamente necessário. O fluxo geral então é:

goroutine garante o lock → wait libera o lock → wait aguarda um sinal → wait recebe um sinal → wait garante novo lock → wait libera a execução → goroutine realiza o trabalho → goroutine libera o lock

Pool

O Pool fornece uma maneira de se lidar com objetos de curta duração na memória. Isso ajuda a aliviar a pressão no GC, pois o espaço de memória é sempre reutilizado. A documentação oficial cita como exemplo o pacote fmt, que usa pools como buffers temporários de saída que ajustam seu tamanho conforme a necessidade.

type Message struct {
    Text string
}

var p = sync.Pool{
    New: func() any { return new(Message) },
}

func poolExample() {
    v := p.Get().(*Message)
    defer p.Put(v)

    v.Text = "hello guys"
}

Para inicializar uma Pool precisamos definir a sua função de inicialização. Ao utilizar o Get recuperamos o que está salvo na memória e com o Put escrevemos um novo valor nela. O New só é utilizado se não existir nada alocado na memória.

Conclusão

O pacote sync fornece diversas funcionalidades que são extremamente úteis ao se trabalhar com múltiplas goroutines. É possível controlar a execução com os tipos Cond e Once. Waitgroups garantem que tudo será executado. Mutex, RWMutex e os tipos atômicos evitam a concorrência pelos recursos. Por fim, o Pool alivia o trabalho do GC quando é possível trabalhar com objetos de curta duração na memória. Sem sombra de dúvidas, esse pacote é crucial para quem trabalha com goroutines. Caso você queira entender os detalhes de implementação deste pacote, recomendo a palestra apresentada na Gophercon UK 2025, Deep dive into the sync package, apresentada pelo Jesus Hawthorn. E também tem uma apresentação que fiz na Golang SP sobre o tema. Diga nos comentários se já utilizou este pacote e se de alguma forma ele te ajudou. Se ainda não utilizou, comente o que achou do post.

Links Extras

Breaking down Go's sync package

Matheus Mina — Thu, 02 Oct 2025 12:08:36 +0000

In my opinion, Go provides excellent support for concurrent work, not only due to goroutines but also because of the language's ecosystem. A great example of this is the sync package, which helps synchronize concurrent routines. In this post, we'll dive into everything this package has to offer.

Waitgroups

Waitgroups are used to coordinate the execution of multiple routines. They make it easy to create and ensure that all sub-routines will finish before the main routine ends. In the post about waitgroups I explain better how they work and what changed with Go version 1.25.

Mutex

Mutex stands for mutual exclusion locker. Its function is to lock access to a resource while an operation is being executed, preventing other routines from trying to write to that resource at the same time. For example, what is the return of the following function?

func count() int {
  counter := 0
  wg := sync.WaitGroup{}

  for i := 0; i < 1000; i++ {
    wg.Go(func() {
      counter++
    })
  }

  wg.Wait()
  return counter
}

If your answer was 1000, there's a chance you might have gotten it right, but it's unlikely. This happens because, as routines are executed concurrently, they might try to write to the resource at the same time. To ensure this doesn't happen, simply add a mutex and lock access to that resource.

func count() int {
  counter := 0
  mu := sync.Mutex{}
  wg := sync.WaitGroup{}

  for i := 0; i < 1000; i++ {
    wg.Go(func() {
      mu.Lock()
      counter++
      mu.Unlock()
    })
  }

  wg.Wait()
  return counter
}

Usage is quite simple: to lock access to a record you use the Lock function, and when finished, just use Unlock. You just need to be careful not to fall into deadlock. There's also the TryLock function, which validates whether an active lock exists or not, but its use case is rarer.

RW Mutex

The RW Mutex is an evolution of the mutex where there are specific locks for writing and reading. This distinction is quite useful when one or more routines need to access a resource for reading only, but don't want the object to be modified during its execution. However, it's important to mention that writing has higher priority than reading, and thus, Go avoids starvation.

var numbers []int
var mu sync.RWMutex

func store(x int) {
  mu.Lock()
  numbers = append(numbers, x)
  mu.Unlock()
}

func avg() float64 {
  mu.RLock()
  defer mu.RUnlock()

  size := len(numbers)
  sum := 0
  for _, n := range numbers {
    sum += n
  }

  return float64(sum) / float64(size)
}

In the example above, we can have several routines calling avg to get the average of the integer list. However, if a routine decides to insert another value, everyone will have to wait for that write to finish.

Atomic

The atomic is a subpackage of the sync package that implements concurrency support for primitive types. Currently, it supports the following types: bool, int32, int64, pointer, uint32, uint64, uintpointer, and value. With it, we can simplify the example used in the mutex:

func countWithAtomic() atomic.Int32 {
  var counter atomic.Int32
  wg := sync.WaitGroup{}

  counter.Add(1)
  for i := 0; i < 1000; i++ {
    wg.Go(func() {
      v, ok := counter.Load

    })
  }

  wg.Wait()
  return counter.Load()
}

It's necessary to note that basic operations, such as addition, have been re-implemented to ensure that routines do not contend for the resource.

Map

The Map is like any other normal map. It provides functions to compare, swap, assign or retrieve values, with the difference that it is safe for concurrency.

func mapExample() int {
  var m sync.Map
  wg := sync.WaitGroup{}

  for i := 0; i < 1000; i++ {
    wg.Go(func() {
      m.LoadOrStore(i, i*i)
    })
  }

  wg.Wait()

  v, _ := m.Load(0)
  return v.(int)
}

The documentation itself suggests it should be used in two cases:

When a key is written only once, but read multiple times. An example is a cache that only grows.
When multiple goroutines read and write distinct groups of keys.

Any other case is better to use the traditional map with mutexes.

Once

The Once type guarantees that something will be executed only once, even if multiple routines try to execute it. An example of this could be resource initialization, as demonstrated by the Go documentation.

func doSomething() int {
  wg := sync.WaitGroup{}
  o := sync.Once{}
  result := 0

  for i := 0; i < 10; i++ {
    wg.Go(func() {
      o.Do(func() {
        result++
      })
    })
  }

  wg.Wait()
  return result
}

It's important to note that if the function panics, it will not be re-executed.

Cond

As the name suggests, Cond works based on a conditional, meaning that when something happens, it releases the execution of a routine. This execution can be released one by one using the signal function or activating all at once with broadcast.

func condExample() {
  mu := sync.Mutex{}
  cond := sync.NewCond(&mu)
  wg := sync.WaitGroup{}
  active := false

  for i := 0; i < 1000; i++ {
    wg.Go(func() {
      cond.L.Lock()
      defer cond.L.Unlock()

      for !active {
        cond.Wait()
      }

      fmt.Println("Active is true, printing: ", i)
    })
  }

  // Activate all goroutines after some time
  time.Sleep(time.Second * 5)
  fmt.Println("Setting Active to true...")
  active = true
  fmt.Println("Wake up one goroutine...")
  cond.Signal()

  time.Sleep(time.Second * 5)
  fmt.Println("Wake up all goroutines...")
  cond.Broadcast()

  wg.Wait()
  fmt.Println("All goroutines finished.")
}

First, we initialize a cond with some Locker, an interface that implements the Lock and Unlock functions. In the example, we use a mutex. When initializing each goroutine, it's necessary to ensure the lock and then we put it in a waiting state with Wait, which releases the lock, allowing new routines to be started. When a routine is released with Signal or Broadcast, Wait acquires the Lock again and releases the code execution. Go's documentation recommends that Wait happens inside a loop waiting for a condition, because Cond alone can't tell if something has happened or not, but this is not strictly necessary. The general flow then is:

goroutine acquires the lock → wait releases the lock → wait waits for a signal → wait receives a signal → wait acquires a new lock → wait releases execution → goroutine performs work → goroutine releases the lock

Pool

The Pool provides a way to deal with short-lived objects in memory. This helps relieve pressure on the GC, as memory space is always reused. The official documentation cites the fmt package as an example, which uses pools as temporary output buffers that adjust their size as needed.

type Message struct {
  Text string
}

var p = sync.Pool{
  New: func() any { return new(Message) },
}

func poolExample() {
  v := p.Get().(*Message)
  defer p.Put(v)

  v.Text = "hello guys"
}

To initialize a Pool we need to define its initialization function. When using Get we retrieve what is saved in memory and with Put we write a new value to it. New is only used if there is nothing allocated into the memory.

Conclusion

The sync package provides several functionalities that are extremely useful when working with multiple goroutines. It's possible to control execution with Cond and Once types. Waitgroups ensure everything will be executed. Mutex, RWMutex, and atomic types prevent resource contention. Finally, Pool relieves the GC's work when it's possible to work with short-lived objects in memory. Without a doubt, this package is crucial for anyone working with goroutines. If you wish to understand the implementation details of this package, I recommend watching the talk presented at Gophercon UK 2025, Deep dive into the sync package by Jesus Hawthorn. There is also a talk that I presented at Golang SP about it. Tell me in the comments if you have already used this package and if it helped you in any way. If you haven't used it yet, comment on what you thought of the post.

Extra Links

Waitgroups: what they are, how to use them and what changed with Go 1.25'

Matheus Mina — Sat, 23 Aug 2025 15:13:39 +0000

Imagine the following problem: you need to process hundreds of records and generate a single output. One way to solve this is to process each record sequentially and unify the output only at the end. However, this can be extremely slow, depending on the time spent processing each record. Another way is to process them concurrently, speeding up the overall time. In my post about introduction to concurrency, I talked a bit about goroutines and channels. Now, I've decided to talk about waitgroups, a way to simplify the management of multiple goroutines.

Waitgroups are part of the sync package, and their use is relatively simple. For each goroutine you start, you must add 1 to the sync counter, and then you have to wait for all goroutines to finish their work. Each goroutine must reduce the counter by 1 to indicate its completion. For example:

func Before1_25() {
  r := rand.IntN(10)
  wg := sync.WaitGroup{}
  wg.Add(1) // Wait for 1 more goroutine to process
  go doSomethingTheOldWay(&wg, r) // Doing something async
  wg.Wait() // Wait until all goroutines finishes
}

func doSomethingTheOldWay(wg *sync.WaitGroup, sleep int) {
  defer wg.Done() // Tell the waitgroup you're done. It the same as wg.Add(-1)

  time.Sleep(time.Duration(sleep) * time.Second)
}

Although they are easy to use, you must always ensure the correct number of goroutines in the waitgroup. In other words, for every goroutine added with wg.Add, you must have a wg.Done. If this doesn't happen, it can cause a deadlock during wg.Wait. This occurs, for example, if we add a goroutine to the waitgroup and never call wg.Done. The reverse of this problem is finishing more goroutines than were added to the waitgroup, which generates a panic with the message panic: sync: negative WaitGroup counter. However, this problem is intermittent, as the main process might finish before the goroutine. To avoid these cases, the goleak library implements a goroutine leak validator.

func TestCases(t *testing.T) {
  t.Run("Before1_25", func(t *testing.T) {
    defer goleak.VerifyNone(t)

    Before1_25()
  })
}

Starting with Go version 1.25, everything changed, and our API became even simpler and free of these problems! Instead of manually having to control which goroutines were added and signal their end, we can simply use the new function wg.Go, which does this automatically.

func After1_25() {
  r := rand.IntN(10)
  wg := sync.WaitGroup{}
  wg.Go(func() { doSomethingTheNewWay(r) })
  wg.Wait()
}

func doSomethingTheNewWay(sleep int) {
  time.Sleep(time.Duration(sleep) * time.Second)
}

Since this function accepts a func() as an argument, you need to wrap your function inside another one if you need to pass arguments. As the increment and decrement are now handled automatically, the problems mentioned above no longer exist, and it has indeed become even simpler to work concurrently.

Although it is not the focus of this post, I want to mention another improvement in this version of the language. Before version 1.25, if your application ran on Kubernetes, you needed to use a library like automaxprocs to get a valid CPU value for goroutines. Now, this is done for us automatically. For those interested, I recommend reading the article Container-aware GOMAXPROCS.

In the next post, I want to explore more about the sync package and how we can use its other functionalities to manage concurrent work more simply. The examples are in this repository. Comment below what you thought of the post and the new features in Go 1.25!

Waitgroups: o que são, como usar e o que mudou com o Go 1.25

Matheus Mina — Sat, 23 Aug 2025 15:12:27 +0000

Imagine o seguinte problema: é necessário processar centenas de registros e gerar uma única saída. Uma forma de resolver é processar cada registro sequencialmente e só no fim unificar a saída. Contudo isso pode ser extremamente lento, dependendo do tempo gasto para processar cada registro. Outra forma é fazer o processamento de forma concorrente, acelerando o tempo gasto para o processamento. No meu post sobre introdução à concorrência falei um pouco sobre goroutines e channels e agora decidi falar sobre os waitgroups, uma forma de simplificar a gestão de múltiplas goroutines.

Waitgroups são parte do pacote sync e seu uso é relativamente simples. Para cada goroutine disparada, é necessário adicionar 1 ao contador do sync e depois, deve-se esperar que todas goroutines terminem seus trabalhos. É necessário que cada goroutine reduza 1 do contador para indicar seu fim. Exemplificando:

func Before1_25() {
    r := rand.IntN(10)
    wg := sync.WaitGroup{}
    wg.Add(1) // Wait for 1 more goroutine to process
    go doSomethingTheOldWay(&wg, r) // Doing something async
    wg.Wait() // Wait until all goroutines finishes
}

func doSomethingTheOldWay(wg *sync.WaitGroup, sleep int) {
    defer wg.Done() // Tell the waitgroup you're done. It the same as wg.Add(-1)

    time.Sleep(time.Duration(sleep) * time.Second)
}

Apesar de o uso ser fácil, é necessário se preocupar em sempre ter o número correto de goroutines no waitgroup, ou seja, para cada goroutine adicionada com wg.Add é necessário ter um wg.Done. Se isso não ocorrer, pode-se causar com um deadlock durante o wg.Wait. Isso acontece, por exemplo, se adicionarmos uma goroutine ao waitgroup e nunca finalizarmos com o wg.Done. O inverso deste problema é finalizar mais goroutines do que foram adicionadas ao grupo de espera. Neste caso, um panic é gerado durante a execução do seu programa com a mensagem panic: sync: negative WaitGroup counter. No entanto esse problema é intermitente, pois o processo principal pode finalizar antes da goroutine. Para evitar estes casos, a biblioteca goleak implementa um validador de vazamento de goroutines.

func TestCases(t *testing.T) {
    t.Run("Before1_25", func(t *testing.T) {
        defer goleak.VerifyNone(t)

        Before1_25()
    })
}

A partir da versão 1.25 do Go, tudo mudou e nossa API ficou ainda mais simples e sem esses problemas! Em vez de manualmente ser necessário controlar quais goroutines foram adicionadas e sinalizar o seu fim, podemos simplesmente utilizar a nova função que já faz isso automaticamente com o wg.Go.

func After1_25() {
    r := rand.IntN(10)
    wg := sync.WaitGroup{}
    wg.Go(func() { doSomethingTheNewWay(r) })
    wg.Wait()
}

func doSomethingTheNewWay(sleep int) {
    time.Sleep(time.Duration(sleep) * time.Second)
}

Como essa função recebe um func () como argumento, é necessário encapsular nossa função dentro de outra, caso seja necessário fornecer argumentos. Como o incremento e decremento passaram a ser feitos de forma automática, os problemas citados acima não existem mais e, de fato, ficou ainda mais simples de se trabalhar de forma concorrente.

Apesar de não ser o foco desta postagem, quero citar outra melhoria a partir desta versão da linguagem. Antes da versão 1.25, se sua aplicação executava em Kubernetes, era necessário utilizar alguma biblioteca como automaxprocs para obter um valor de CPU válido para as goroutines e agora isso é feito para nós automaticamente. Para quem tiver interesse, recomendo a leitura do artigo Container-aware GOMAXPROCS.

No próximo post, quero destrinchar mais sobre o pacote sync e como podemos utilizar suas outras funcionalidades para gerenciar o trabalho concorrente de forma mais simples. Os exemplos estão neste repositório. Comente abaixo o que achou do post e das novidades do Go 1.25!

testcontainers: melhorando testes E2E

Matheus Mina — Thu, 24 Jul 2025 16:24:28 +0000

Em um post anterior mostrei algumas formas de melhorar os testes criando mocks das APIs que chamamos. Porém, isso nem sempre é suficiente e podemos precisar de testes E2E (ou testes de aceitação), como, por exemplo, para testar integrações com banco de dados, serviços de mensageria ou qualquer outra coisa. Para esses casos, venho apresentar a ferramenta Testcontainers.

O testcontainer é uma biblioteca open-source que permite que você crie containers durante a execução dos testes. A ideia é que as dependências de teste da sua aplicação sejam parte do código, evitando a necessidade de mocks e até mesmo a instalação local de dependências. Outra grande vantagem é que dessa forma é mais fácil conseguirmos isolamento entre os testes e replicabilidade entre os desenvolvedores. A ferramenta suporta diversas linguagens de programação como Go, Ruby, Elixir, Java, etc.

Para começar, é necessário ter o Docker instalado em sua máquina ou algum substituto como o Rancher ou Colima. Dependendo da sua instalação, será necessário configurar alguns passos adicionais na sua máquina que podem ser encontrados aqui. Com o ambiente configurado, vamos escrever um teste para demonstrar o seu uso.

Imagine que exista uma tabela chamada posts, que possui um id e um campo content e você quer testar a funcionalidade de inserção de dados.

func insertPost(db *sql.DB, content string) error {
    query := `INSERT INTO posts (content) VALUES ($1);`
    _, err := db.Exec(query, content)
    if err != nil {
        return fmt.Errorf("error inserting post: %w", err)
    }

    log.Println("Post inserted successfully")
    return nil
}

Para testar essa função, podemos utilizar o testcontainers para subir um banco de dados (no caso, um Postgres) para os testes. Dessa forma, nós temos um container do DB exclusivo para o teste, garantindo que os testes gerenciem suas dependências e minimizando falhas causadas por interdependência entre os testes.

func TestInsertTable(t *testing.T) {
        postgresContainer, err := postgres.Run(context.Background(),
        "postgres:16-alpine",
        postgres.WithDatabase("test"),
        postgres.WithUsername("user"),
        postgres.WithPassword("password"),
        postgres.BasicWaitStrategies(),
    )

    if err != nil {
        t.Fatalf("Failed to start PostgreSQL container: %v", err)
        return nil, err
    }
    defer postgresContainer.Terminate(t.Context())

  // omiting DB connection and setup

    content := "Hello, Testcontainers!"
    err = insertPost(db, content)
    if err != nil {
        t.Fatalf("Failed to insert post: %v", err)
    }
}

No exemplo acima, usamos um módulo já pronto de um Postgres, mas além dele existem inúmeros outros que podem ser encontrados aqui. Contudo, algumas vezes precisamos criar o nosso próprio módulo. Imagine agora uma função que consuma uma API e faça algo com ela.

func getData(url string) error {
    resp, err := http.Get(url)
    if err != nil {
        return fmt.Errorf("Error fetching: %v", err)
    }
    defer resp.Body.Close()

    if resp.StatusCode != http.StatusOK {
        return fmt.Errorf("Error fetching: %v", resp.Status)
    }

    // do something with the response

    return nil
}

Para ter um teste de aceitação válido, precisamos consumir alguma API. Para este caso, vamos criar um container de teste que vai prover uma API qualquer.

func TestGetData(t *testing.T) {
    ctr, err := testcontainers.GenericContainer(t.Context(), testcontainers.GenericContainerRequest{
        ContainerRequest: testcontainers.ContainerRequest{
            Image:        "mitchallen/random-server:latest",
            ExposedPorts: []string{"3100"},
            WaitingFor:   wait.ForLog("random-server:2.1.15 - listening on port 3100!"),
        },
        Started: true,
    })

    if err != nil {
        t.Fatalf("Failed to start container: %v", err)
    }

    defer ctr.Terminate(t.Context())

    url, err := ctr.Endpoint(t.Context(), "http")
    if err != nil {
        t.Fatalf("Failed to get container host: %v", err)
    }

    err = getData(url)
    if err != nil {
        t.Fatalf("Failed to get data: %v", err)
    }
}

Como pode ser notado, a criação é bem simples e lembra um Docker compose qualquer. Podemos configurar diversas opções como a imagem, portas expostas, Dockerfile para a build, healthcheck ou o que for necessário para o container. Dessa forma, garantimos que os testes gerem as suas dependências e que simulam um ambiente bem mais próximo do real, aumentando a confiabilidade deles.

Essa biblioteca tem ajudado bastante nos testes e estou utilizando sempre que necessário. A documentação é bem completa e detalhada e não tive dificuldades ao configurar ou utilizar. Os diversos módulos prontos também facilitam bastante a vida do desenvolvedor, dispensando a recriação de containers de aplicações genéricas como banco de dados ou mockservers.

Se você quiser ver o exemplo todo, recomendo acessar o repositório no Github. O que achou do post? Comente aqui abaixo suas impressões!

testcontainers: improving E2E tests

Matheus Mina — Thu, 24 Jul 2025 16:23:44 +0000

In a previous post I showed some ways to improve tests by creating API mocks that we call. However, that's not always enough, and we might need E2E tests (or acceptance tests), for example, to test integrations with databases, messaging services, or anything else. For these cases, I'm here to introduce the Testcontainers tool.

The Testcontainers library is an open-source tool that lets you create containers during test execution. The idea is for your application's test dependencies to be part of the code, avoiding the need for mocks and even local dependency installation. Another big advantage is that it makes it easier to achieve test isolation and replicability among developers. The tool supports various programming languages like Go, Ruby, Elixir, Java, etc.

To get started, you need to have Docker installed on your machine or an alternative like Rancher or Colima. Depending on your setup, you might need to configure some additional steps on your machine, which you can find here. With the environment configured, let's write a test to demonstrate its use.

Imagine there's a table called posts, which has an id and a content field, and you want to test the data insertion functionality.

func insertPost(db *sql.DB, content string) error {
  query := `INSERT INTO posts (content) VALUES ($1);`
  _, err := db.Exec(query, content)
  if err != nil {
    return fmt.Errorf("error inserting post: %w", err)
  }

  log.Println("Post inserted successfully")
  return nil
}

To test this function, we can use testcontainers to spin up a database (in this case, a Postgres) for the tests. This way, we have a dedicated DB container for the test, ensuring tests manage their dependencies and minimizing failures caused by interdependency between tests.

func TestInsertTable(t *testing.T) {
    postgresContainer, err := postgres.Run(context.Background(),
    "postgres:16-alpine",
    postgres.WithDatabase("test"),
    postgres.WithUsername("user"),
    postgres.WithPassword("password"),
    postgres.BasicWaitStrategies(),
  )

  if err != nil {
    t.Fatalf("Failed to start PostgreSQL container: %v", err)
    return nil, err
  }
  defer postgresContainer.Terminate(t.Context())

  // omiting DB connection and setup

  content := "Hello, Testcontainers!"
  err = insertPost(db, content)
  if err != nil {
    t.Fatalf("Failed to insert post: %v", err)
  }
}

In the example above, we used a ready-made Postgres module, but there are countless others you can find here. However, sometimes we need to create our own module. Now, imagine a function that consumes an API and does something with it.

func getData(url string) error {
  resp, err := http.Get(url)
  if err != nil {
    return fmt.Errorf("Error fetching: %v", err)
  }
  defer resp.Body.Close()

  if resp.StatusCode != http.StatusOK {
    return fmt.Errorf("Error fetching: %v", resp.Status)
  }

  // do something with the response

  return nil
}

To have a valid acceptance test, we need to consume an API. For this case, we'll create a test container that will provide any API.

func TestGetData(t *testing.T) {
  ctr, err := testcontainers.GenericContainer(t.Context(), testcontainers.GenericContainerRequest{
    ContainerRequest: testcontainers.ContainerRequest{
      Image:        "mitchallen/random-server:latest",
      ExposedPorts: []string{"3100"},
      WaitingFor:   wait.ForLog("random-server:2.1.15 - listening on port 3100!"),
    },
    Started: true,
  })

  if err != nil {
    t.Fatalf("Failed to start container: %v", err)
  }

  defer ctr.Terminate(t.Context())

  url, err := ctr.Endpoint(t.Context(), "http")
  if err != nil {
    t.Fatalf("Failed to get container host: %v", err)
  }

  err = getData(url)
  if err != nil {
    t.Fatalf("Failed to get data: %v", err)
  }
}

As you can see, creating it is quite simple and resembles a Docker Compose setup. We can configure various options like the image, exposed ports, Dockerfile for the build, health check, or whatever is needed for the container. This way, we ensure that the tests manage their dependencies and simulate an environment much closer to reality, increasing their reliability.

This library has been very helpful in my tests, and I'm using it whenever necessary. The documentation is very complete and detailed, and I haven't had any difficulties setting it up or using it. The various ready-made modules also make a developer's life much easier, eliminating the need to recreate containers for generic applications like databases or mock servers.

If you want to see the full example, I recommend checking out the Github repository. What did you think of the post? Share your thoughts below!

Eliminating dead code in Go projects

Matheus Mina — Thu, 19 Jun 2025 15:39:19 +0000

As the software we work on grows, the code tends to undergo various changes and refactorings. During this process, we might simply forget pieces of code that were once used but no longer make sense in the project, the infamous dead code. A very common example is when an API is deactivated, and only the handler is removed, but all the business logic remains, unused.

Dead code can be defined as a function that exists within your codebase, is syntactically valid, but is not used by any other part of your code. In other words, it's an unreachable function. Dead code brings indirect problems to a project, such as outdated libraries, legacy code, code bloat, security vulnerabilities, and so on. If it's still not clear what dead code is, see the example below:

package main

import "fmt"

func main() {
  fmt.Println("Hello, World!")

  reachable()
}

func unreachable() {
  fmt.Println("This function will never be called")
}

func reachable() {
  fmt.Println("This function is reachable")
}

func Public() {
  fmt.Println("This is a public function but it is unused")
}

In this code, we have the private functions unreachable and reachable. By default, gopls will tell you that the unreachable function is not being used and can be removed. However, this doesn't prevent the project from compiling. gopls is a language server used by editors to enable features like code completion, syntax corrections, etc. But if the function becomes public, this error won't be flagged because it can theoretically be used by other packages.

This problem expands when dealing with packages, as unused packages are also not reported. Imagine a package with private and public functions that isn't used in the project:

package unused

import "fmt"

func UnusedFunction() {
  fmt.Println("This function is unused")

  indirectUnreachable()
}

func indirectUnreachable() {
  fmt.Println("This function is unreachable")
}

The Go team then provided a solution to this problem with the deadcode tool. It's worth mentioning that the tool should always be run from main, as it searches for dead code based on what would be executed in production. When you run this tool, you finally get all unused functions:

$ go tool deadcode ./...
> main.go:11:6: unreachable func: unreachable
> main.go:19:6: unreachable func: Public
> unused/unused.go:5:6: unreachable func: UnusedFunction
> unused/unused.go:11:6: unreachable func: indirectUnreachable

This way, we can easily find dead code in our project. To install the tool, simply run the command:

$ go get -tool golang.org/x/tools/cmd/deadcode@latest

This tool is very useful to run after project refactorings and has helped me a lot to keep the code lean and containing only what truly matters to the project. If you're interested and want to know more, I recommend reading the official post. Tell me in the comments what you think of the tool, and if you want to see the full code, access it here.

Acabando com código morto nos projetos Go

Matheus Mina — Thu, 19 Jun 2025 15:38:41 +0000

Conforme o software que trabalhamos vai crescendo, a tendência é do código passar por diversas mudanças e refatorações. Nesse processo, podemos simplesmente esquecer pedaços de código que um dia foram utilizados e que agora não fazem mais sentido no projeto, os famosos códigos mortos. Um exemplo muito comum é quando uma API é desativada e só o handler é removido, porém, toda a lógica de negócio continua ali, mas sem ser utilizada.

Pode-se dizer que o código morto é basicamente uma função que existe dentro da sua base de código que é sintaticamente válida, porém não é utilizada por nenhuma outra parte do seu código, ou seja, é uma função inalcançável. Códigos mortos trazem problemas indiretos para o projeto, como bibliotecas desatualizadas, códigos legados, inchaço da base de código, falhas de segurança e por aí vai. Se ainda não ficou claro o que é um código morto, veja o exemplo abaixo:

package main

import "fmt"

func main() {
  fmt.Println("Hello, World!")

  reachable()
}

func unreachable() {
  fmt.Println("This function will never be called")
}

func reachable() {
  fmt.Println("This function is reachable")
}

func Public() {
  fmt.Println("This is a public function but it is unused")
}

Neste código temos as funções privadas unreachable e reachable. Por padrão, gopls vai dizer que a função unreachable não está sendo utilizada e que pode ser removida, entretanto, isso não impede a compilação do projeto. O gopls é um language server utilizado pelos editores para habilitar funcionalidades como completamento de código, correções de sintaxe, etc. Porém, se a função se tornar pública, este erro não vai ser apontado, pois ele teoricamente pode ser utilizado por outros pacotes.

Esse problema se amplia ao lidarmos com pacotes, pois pacotes não utilizados também não são reportados. Suponha então um pacote com funções privadas e públicas, porém que não é utilizado no projeto.

package unused

import "fmt"

func UnusedFunction() {
  fmt.Println("This function is unused")

  indirectUnreachable()
}

func indirectUnreachable() {
  fmt.Println("This function is unreachable")
}

A equipe do Go trouxe então uma solução para este problema, a ferramenta deadcode. Vale a pena mencionar que a ferramenta sempre deve ser executada a partir da main, pois ela procura por código morto a partir do que seria executado em produção. Ao rodar essa ferramenta, temos finalmente o resultado de todas as funções não utilizadas.

$ go tool deadcode ./...
> main.go:11:6: unreachable func: unreachable
> main.go:19:6: unreachable func: Public
> unused/unused.go:5:6: unreachable func: UnusedFunction
> unused/unused.go:11:6: unreachable func: indirectUnreachable

Assim, podemos facilmente encontrar código morto em nosso projeto. Para instalar a ferramenta, é basicamente rodar o comando:

$ go get -tool golang.org/x/tools/cmd/deadcode@latest

Essa ferramenta é bem útil para ser executada após refatorações no projeto e tem me ajudado bastante a manter o código enxuto e somente com o que de fato importa para o projeto. Se você ficou interessado e quer saber mais, recomendo a leitura do post oficial. Me diz nos comentários o que você achou da ferramenta e, se quiser ver o código todo, acesse aqui.

Exploring the Rate package and the Token Bucket algorithm

Matheus Mina — Fri, 16 May 2025 00:31:42 +0000

At my Circuit Breaker post, I mentioned that nowadays it is common that the application has to communicate with other ones, and with that, traffic control strategies become essential. Recently I've discovered the Token Bucket, a strategy based on tokens used to control the traffic.

Imagine that you have 5 tickets to a ride, and every new hour you get a new ticket, but you can never exceed the limit of 5. Every time you ride, a ticket is used. So, if you use all your tickets, you can't ride anymore until you get a new one. It is a very interesting algorithm, used by the PIX (a Brazilian instant payment method), for not allowing an attacker to scrape all users' data.

Translating to code, let's propose a scenario where 10 goroutines are initialized and execute something. If you don't know yet about goroutines and concurrency, I recommend my post about it.

package main

import  "golang.org/x/time/rate"

func main() {
  c := make(chan int)

  for i := range 10 {
    go doSomething(i, c)
  }

  for range 10 {
    <-c
  }
}

func doSomething(x int, c chan int) {
  fmt.Printf("goroutine %d did something\n", x)

  c <- x
}

While running the code above, it is noticeable that the goroutines were executed without any control.

The Token Bucket algorithm comes from the necessity of controlling the execution, and, as always, Go or its community gives us a solution. In this case, it is the rate package. Using it is quite simple. At first a new Limitter is initialized with the maximum number of tokens and a Limit, which defines how many tokens are created per second.

package main

import  "golang.org/x/time/rate"

func main() {
  c := make(chan int)
  r := rate.Limit(1.0) // refreshes 1 token per second
  l := rate.NewLimiter(r, 5) // allows 5 tokens max

  ... // do more stuff
}

The coolest thing from the rate package is it has three different strategies. The first strategy is called allow.

func doSomethingWithAllow(l *rate.Limiter, x int, c chan int) {
  if l.Allow() {
    fmt.Printf("Allowing %d to run\n", x)
  }

  c <- x
}

At this strategy, the execution is allowed if there is a token to be consumed at that moment, and, if not, nothing will happen.

The second one is called wait and by the package author, it is probably the most common one of being used.

func doSomethingWithWait(ctx context.Context, l *rate.Limiter, x int, c chan int) {
  err := l.Wait(ctx)
  if err != nil {
    fmt.Printf("Error waiting for %d: %v\n", x, err)
    c <- x
    return
  }

  fmt.Printf("Allowing %d to run\n", x)
  c <- x
}

With wait, the goroutine will be held until there is a token available for use.

At last, we have the reserve strategy. As the name says, you reserve the next available ticket and wait until it is created.

func doSomethingWithReserve(l *rate.Limiter, x int, c chan int) {
  r := l.Reserve()
  if !r.OK() {
    return
  }

  fmt.Printf("Reserving %d to run\n", x)
  d := r.Delay()
  time.Sleep(d)
  fmt.Printf("Allowing %d to run\n", x)

  c <- x
}

This strategy is similar to the wait, however, it allows us to control it with more details and know when it is possible to execute again.

Besides all that, all these strategies can burn more than one ticket if it is necessary. For example, the Allow() function turns into AllowN(t time.Time, n int), where t is the time allowed to happen n events.

Another cool feature was the possibility of making a simple Circuit Breaker with this package and the type Sometimes. You can configure the following parameters:
First: first Nth calls will be executed.
Every: every Nth call will be executed.
Inverval: calls within the time interval.

package main

import (
  "fmt"

  "golang.org/x/time/rate"
)

func main() {
  s := rate.Sometimes{Every: 2}

  for i := range 10 {
    s.Do(func() { fmt.Printf("Allowing %d to run!\n", i) })
  }
}

As we can see, at every two calls, one call is blocked.

Conclusion

The Token Bucket is a fascinating traffic control algorithm since it allows us to block exceeding executions and book future executions. The Go implementation is simple to use and safe to use with multiple goroutines.

The rate package also provides a simple circuit breaker implementation, preventing us from adding more third-party libs to the code if it is needed to use both methods in our application.

But it is important to say that this package is still experimental and can change the contract between versions, or be discontinued, or even be added to the stdlib.

To sell all the examples, access this repository.

Useful links

Explorando o pacote Rate e o algoritmo de Token Bucket

Matheus Mina — Fri, 16 May 2025 00:24:43 +0000

No post sobre Circuit Breaker, citei que atualmente é comum que a sua aplicação tenha que se comunicar com outras e, com isso, estratégias de controle de tráfego se tornam essenciais. Recentemente descobri o Token Bucket, uma estratégia baseada em tokens para controlar o tráfego.

Imagine que você tenha 5 ingressos para um brinquedo e que a cada hora você ganhe um novo ingresso, mas nunca podendo exceder o limite de 5. A cada ida ao brinquedo, um ticket é usado. Dessa forma, ao utilizar todos os seus tickets, você não pode ir ao brinquedo até ganhar um novo ticket. É um algoritmo bem interessante, utilizado, por exemplo, pelo PIX, para controlar a busca de chaves e evitando que um malfeitor pegue dados de usuários.

Traduzindo para código, vamos propor um cenário em que 10 goroutines sejam inicializadas e vão executar uma ação qualquer. Caso você ainda não conheça sobre goroutines e concorrência, recomendo o meu post sobre o tema.

package main

import  "golang.org/x/time/rate"

func main() {
  c := make(chan int)

  for i := range 10 {
    go doSomething(i, c)
  }

  for range 10 {
    <-c
  }
}

func doSomething(x int, c chan int) {
  fmt.Printf("goroutine %d did something\n", x)

  c <- x
}

Ao executar o código acima, pode-se notar que as goroutines foram executadas sem nenhum controle maior.

O algoritmo de Token Bucket vem da necessidade de controlar essa execução e, como sempre, a própria linguagem e/ou a comunidade Go nos fornecem uma solução, neste caso o pacote rate. Seu uso é bem simples, primeiro é necessário inicializar um novo Limitter, que recebe a quantidade máxima de tokens disponível e um Limit, que define a taxa com que novos tokens são gerados por segundo.

package main

import  "golang.org/x/time/rate"

func main() {
  c := make(chan int)
  r := rate.Limit(1.0) // refreshes 1 token per second
  l := rate.NewLimiter(r, 5) // allows 5 tokens max

  ... // do more stuff
}

O legal do pacote rate é que ele possui três estratégias diferentes. A primeira delas é a estratégia de allow.

func doSomethingWithAllow(l *rate.Limiter, x int, c chan int) {
  if l.Allow() {
    fmt.Printf("Allowing %d to run\n", x)
  }

  c <- x
}

Nesta estratégia, a execução será permitida se existir um token para ser consumido naquele momento e, caso não exista, nada será executado.

A segunda estratégia é chamada de wait e é provavelmente a estratégia mais comum de ser utilizada, segundo o autor do pacote.

func doSomethingWithWait(ctx context.Context, l *rate.Limiter, x int, c chan int) {
  err := l.Wait(ctx)
  if err != nil {
    fmt.Printf("Error waiting for %d: %v\n", x, err)
    c <- x
    return
  }

  fmt.Printf("Allowing %d to run\n", x)
  c <- x
}

Nesta estratégia, a goroutine vai esperar até existir um token disponível para ser usado.

Por fim, temos a estratégia de reserve. Como o nome diz, você reserva o próximo ticket disponível e aguarda até o momento dele ser emitido.

func doSomethingWithReserve(l *rate.Limiter, x int, c chan int) {
  r := l.Reserve()
  if !r.OK() {
    return
  }

  fmt.Printf("Reserving %d to run\n", x)
  d := r.Delay()
  time.Sleep(d)
  fmt.Printf("Allowing %d to run\n", x)

  c <- x
}

Esta estratégia é bem parecida com a de wait, contudo nos permite controlar com mais detalhes e saber quando é possível executar novamente.

Além disso, todas essas estratégias permitem você queimar mais de um ticket, caso seja necessário. Por exemplo, a função Allow() vira AllowN(t time.Time, n int), onde t é o tempo para acontecer n eventos.

Outra funcionalidade que achei bem legal, foi a possiblidade de se fazer um Circuit Breaker simples utilizando esse pacote e o tipo Sometimes. Nele é possível configurar os seguintes parâmetros:

First: as primeiras N chamadas serão executadas.
Every: A cada N chamadas executadas, uma será bloqueada.
Inverval: o limite de chamadas no tempo.

package main

import (
  "fmt"

  "golang.org/x/time/rate"
)

func main() {
  s := rate.Sometimes{Every: 2}

  for i := range 10 {
    s.Do(func() { fmt.Printf("Allowing %d to run!\n", i) })
  }
}

Como podemos ver, a cada duas chamadas, uma é bloqueada.

Conclusão

O token bucket é um algoritmo de controle de tráfego extremamente interessante, já que ele permite barrar execuções excedentes e agendar execuções futuras. A implementação em Go é simples de se utilizar, além de ser segura ao se utilizar em múltiplas goroutines.

O pacote rate ainda provê uma simples implementação de circuit breaker, evitando assim a adição de mais bibliotecas de terceiros em seu código, caso você deseje utilizar ambos os métodos em sua aplicação.

Contudo, vale a pena citar que o pacote ainda é experimental, podendo mudar o contrato entre as versões, ser descontinuado ou até mesmo incorporado a stdlib.

Para ver todos os exemplos, acesse este repositório.

Links úteis

Go Tool: tudo o que ninguem pediu

Matheus Mina — Sat, 05 Apr 2025 15:29:53 +0000

Depois de muitos anos trabalhando com Ruby, migrei para trabalhar com Go sem muita experiência com a linguagem. Meu primeiro atrito foi com a gestão de dependências, pois sempre achei a versão de dependências de Go ruim, com os comandos confusos e, o pior, sem distinção entre dependências de desenvolvimento e dependências produtivas, pois ambas são incluídas no binário final. Vamos olhar o exemplo do go.mod de uma PoC:

module github.com/mfbmina/poc_circuit_breaker

go 1.24

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

Mas o tempo passou, os atritos foram superados e acabei entendendo como essa gestão funcionava e aqui estou trabalhando com Go até hoje. Quando li que a versão 1.24 ia trazer a funcionalidade de "gestão de ferramentas" fiquei super animado, e geralmente não sou o tipo de pessoa que fica acompanhando as novidades da próxima versão de alguma linguagem, mas confesso que após testar a funcionalidade fiquei bem desapontado.

O go tools, como o próprio nome diz, é uma funcionalidade para você adicionar as ferramentas que seu projeto usa, como, por exemplo, goreleaser, golangci-lint, etc. Para instalar uma nova ferramenta, é só rodar o comando $ go get -tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint@v2.0.2. Uma vez instalada, você a utiliza pela CLI do Go: $ go tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint run. Para listar todas as ferramentas instaladas, rode $ go tool.

module github.com/mfbmina/poc_circuit_breaker

go 1.24

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

// omiting a lot of indirect dependencies...

tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint

A primeira vista parece excelente, já que você pode ter as ferramentas no seu arquivo de dependências, mas o ponto principal ainda não foi resolvido. Ele até mesmo piora dependendo do seu ponto de vista, pois além de incluir todas as dependências de produção e desenvolvimento num mesmo arquivo go.mod, ele ainda traz as ferramentas utilizadas no desenvolvimento, sem a possibilidade de só instalar alguns deles. Inclusive, ferramentas como o golangci-lint não recomendam esse tipo de instalação, justamente para isolar essa ferramenta das dependências reais. Existem algumas estratégias para se utilizar o go tools, mas confesso que não testei por simplesmente ter perdido o interesse na funcionalidade.

O que eu esperava era algo na linha de se poder criar grupos de dependências, assim como aplicações Ruby, JavaScript, PHP, etc. Como exemplo, vamos olhar um Gemfile, um arquivo de dependências Ruby:

# copied from https://github.com/sidekiq/sidekiq/blob/main/Gemfile
source "https://rubygems.org"

gemspec

gem "rake"
RAILS_VERSION = "~> 8.0"
gem "actionmailer", RAILS_VERSION
gem "actionpack", RAILS_VERSION
gem "activejob", RAILS_VERSION
gem "activerecord", RAILS_VERSION
gem "railties", RAILS_VERSION
gem "redis-client"
# gem "bumbler"
# gem "debug"

gem "sqlite3", "~> 2.2", platforms: :ruby
gem "activerecord-jdbcsqlite3-adapter", platforms: :jruby
gem "after_commit_everywhere", require: false
gem "yard"
gem "csv"
gem "vernier" unless RUBY_VERSION < "3"
gem "webrick"

group :test do
  gem "maxitest"
  gem "simplecov"
  gem "debug"
end

group :development, :test do
  gem "standard", require: false
end

group :load_test do
  gem "toxiproxy"
  gem "ruby-prof"
end

Dessa maneira, podemos instalar somente as dependências dos grupos que queremos. Essa funcionalidade foi tudo o que ninguém pediu, justamente por trazer algo para solucionar um problema que não era real, ou pelo menos que não incomodava tanto. Ou talvez eu tivesse expectativas erradas sobre a funcionalidade...

De qualquer forma, ainda sigo na expectativa de ter meus binários em Go sem minhas dependências de teste e desenvolvimento. Quem sabe isso não venha nas próximas versões.

Go Tool: tudo o que ninguem pediu

Matheus Mina — Sat, 05 Apr 2025 15:29:53 +0000

module github.com/mfbmina/poc_circuit_breaker

go 1.24

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

module github.com/mfbmina/poc_circuit_breaker

go 1.24

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

// omiting a lot of indirect dependencies...

tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint

# copied from https://github.com/sidekiq/sidekiq/blob/main/Gemfile
source "https://rubygems.org"

gemspec

gem "rake"
RAILS_VERSION = "~> 8.0"
gem "actionmailer", RAILS_VERSION
gem "actionpack", RAILS_VERSION
gem "activejob", RAILS_VERSION
gem "activerecord", RAILS_VERSION
gem "railties", RAILS_VERSION
gem "redis-client"
# gem "bumbler"
# gem "debug"

gem "sqlite3", "~> 2.2", platforms: :ruby
gem "activerecord-jdbcsqlite3-adapter", platforms: :jruby
gem "after_commit_everywhere", require: false
gem "yard"
gem "csv"
gem "vernier" unless RUBY_VERSION < "3"
gem "webrick"

group :test do
  gem "maxitest"
  gem "simplecov"
  gem "debug"
end

group :development, :test do
  gem "standard", require: false
end

group :load_test do
  gem "toxiproxy"
  gem "ruby-prof"
end

De qualquer forma, ainda sigo na expectativa de ter meus binários em Go sem minhas dependências de teste e desenvolvimento. Quem sabe isso não venha nas próximas versões.