1.1 O problema que Go ataca

Go nasceu na Google (2009) para uma dor específica: escrever serviços de rede concorrentes, em times grandes, com builds lentos (C++), deploy complicado (dependências de runtime) e curva de aprendizado longa. A resposta foi uma linguagem deliberadamente pequena: poucos conceitos, uma forma canônica de fazer cada coisa, compilação quase instantânea, e um binário estático único sem dependências.

1.2 Os pontos fortes

1.3 Onde Go domina

• Infraestrutura cloud-native: Docker, Kubernetes, Terraform, Prometheus, etcd, Consul, Vault, Grafana Loki, containerd — todos escritos em Go. Se você trabalha com plataforma/SRE, vai ler e escrever Go.
• APIs e microserviços de alta vazão e baixa latência.
• CLIs e ferramentas de linha de comando (binário único, cross-compile).
• Sistemas de rede: proxies, gateways, workers, daemons.
• Data plumbing: agentes, coletores, ETL leve.

1.4 Quando NÃO Go

• UI / front-end (WASM em Go existe mas é nicho).
• Ciência de dados / ML — o ecossistema é Python.
• Domínios que pedem forte modelagem de tipos (ADTs, pattern matching exaustivo) — Rust/Kotlin/F# encaixam melhor.
• Computação numérica pesada de baixíssimo nível — C/C++/Rust.
• Projetos onde a expressividade e o metaprogramming são o valor central.

2.1 O primeiro programa e o módulo

// go.mod define o módulo e as dependências
// go mod init github.com/voce/servico

package main

import (
    "fmt"
    "os"
)

func main() {
    if len(os.Args) < 2 {
        fmt.Fprintln(os.Stderr, "uso: saudar <nome>")
        os.Exit(1)
    }
    fmt.Printf("Olá, %s\n", os.Args[1])
}

• package main + func main() = executável. Outros pacotes são bibliotecas.
• Exportação por maiúscula: Nome é público (visível fora do pacote); nome é privado ao pacote. Não há public/private.
• Import não usado = erro de compilação. Go é rígido de propósito.
• gofmt (ou go fmt) formata; não há debate de estilo.

2.2 Tipos, structs e zero values

type Usuario struct {
    ID    string
    Nome  string
    Idade int
    Ativo bool
}

u := Usuario{ID: "u1", Nome: "Ana"}   // Idade=0, Ativo=false (zero values)
var v Usuario                              // tudo zero: "", "", 0, false

2.3 Slices e maps

// slice: janela dinâmica sobre um array; a estrutura de coleção que você usa 95% do tempo
nums := []int{1, 2, 3}
nums = append(nums, 4)              // append pode realocar; sempre reatribua
sub := nums[1:3]                    // [2 3] — compartilha o array subjacente!

// map: tabela hash
idade := map[string]int{"ana": 28}
idade["beto"] = 31
v, ok := idade["carol"]         // ok=false se ausente; v é o zero value
delete(idade, "ana")

• Slices têm comprimento (len) e capacidade (cap); append além da capacidade realoca — por isso sempre s = append(s, x).
• Um sub-slice compartilha memória com o original — cuidado ao mutar.
• Iterar map não tem ordem garantida (é aleatória de propósito).
• Acessar map nil para leitura é ok (retorna zero); escrever num map nil dá panic — inicialize com make ou literal.

2.4 Funções e múltiplos retornos

func dividir(a, b float64) (float64, error) {
    if b == 0 {
        return 0, fmt.Errorf("divisão por zero")
    }
    return a / b, nil
}

q, err := dividir(10, 2)
if err != nil {
    // trate o erro AQUI, agora (Módulo 4)
}

O idioma valor, err := f() seguido de if err != nil é onipresente em Go — a linguagem não tem exceções para fluxo normal (Módulo 4).

2.5 Ponteiros (sem aritmética, sem medo)

func envelhecer(u *Usuario) {   // recebe ponteiro → altera o original
    u.Idade++
}
u := Usuario{Nome: "Ana", Idade: 28}
envelhecer(&u)                   // & pega o endereço

• Go passa tudo por valor (cópia). Para mutar o original, passe *T.
• Sem aritmética de ponteiro (segurança). nil pointer deref dá panic (recuperável).
• Regra prática de receiver: use ponteiro (func (u *Usuario) M()) se o método muta o struct ou se o struct é grande; senão valor. Seja consistente dentro do mesmo tipo.

3.1 Interfaces implícitas

Em Go, um tipo satisfaz uma interface só por ter os métodos certos — não há implements. Isso desacopla: a interface pode ser definida onde é consumida, mesmo sem o autor do tipo saber que ela existe.

type Notificador interface {
    Notificar(msg string) error
}

type EmailSender struct{ /* ... */ }
func (e EmailSender) Notificar(msg string) error { /* ... */ return nil }
// EmailSender satisfaz Notificador automaticamente — nenhuma declaração

func Alertar(n Notificador, msg string) error {
    return n.Notificar(msg)   // funciona com qualquer coisa que tenha Notificar
}

3.2 Interfaces pequenas

3.3 Aceite interfaces, retorne structs

Idioma clássico: uma função deve aceitar a interface mais estreita que precisa (flexibilidade para quem chama) e retornar o tipo concreto (o chamador vê tudo que o tipo oferece e você não trava a API numa interface). Exceção comum: retornar error (interface) e construtores que retornam interface por design de plugin.

3.4 Composição por embedding

type Logger struct{ /* ... */ }
func (l *Logger) Info(msg string) { /* ... */ }

type Servico struct {
    *Logger              // embedding: Servico "ganha" o método Info
    db *sql.DB
}

s := &Servico{Logger: &Logger{}, db: db}
s.Info("iniciado")          // promovido do Logger embutido

• Embedding promove os campos e métodos do tipo embutido — parece herança, mas é has-a, não is-a. Você pode "sobrescrever" definindo um método de mesmo nome no tipo externo.
• Não há hierarquia de classes, nem super, nem polimorfismo por herança. Polimorfismo é só via interface.
• Padrão útil: embutir uma interface num struct para satisfazê-la parcialmente e implementar só o que muda.

3.5 Type assertion e type switch

func descrever(v any) string {   // any == interface{}
    switch x := v.(type) {
    case int:
        return fmt.Sprintf("int %d", x)
    case string:
        return "string " + x
    case Notificador:
        return "sabe notificar"
    default:
        return "desconhecido"
    }
}

Use com parcimônia — any + type switch abandona a segurança de tipos. Boa para desserialização, plugins, e casos genuinamente dinâmicos.

4.1 A filosofia

Em Go, erros são valores comuns retornados pela função, não um mecanismo de fluxo separado. Você lida com eles explicitamente, ali, na hora. Isso é verboso (if err != nil por toda parte) mas torna o caminho de falha visível e local — você vê exatamente o que pode dar errado e o que é feito a respeito.

type error interface {   // a interface embutida — só isso
    Error() string
}

4.2 Criar e enriquecer erros

// erro simples
return errors.New("conexão recusada")
return fmt.Errorf("usuário %s não encontrado", id)

// wrapping: adiciona contexto SEM perder o erro original (o %w)
if err != nil {
    return fmt.Errorf("buscar pedido %s: %w", id, err)
}
// resultado: "buscar pedido o1: consultar db: connection reset"

4.3 Inspecionar erros: errors.Is e errors.As

if errors.Is(err, sql.ErrNoRows) {
    return nil, ErrPedidoNaoEncontrado   // traduz para o erro do seu domínio
}

var ve *ValidationError
if errors.As(err, &ve) {
    return respostaHTTP(422, ve.Campos)   // ve agora aponta para o erro tipado
}

4.4 Panic e recover

• panic é para o irrecuperável e o "nunca deveria acontecer": bug de programação, invariante violada, erro na inicialização de um programa. Não é o throw de outras linguagens.
• Não use panic para erro esperado (arquivo não existe, input inválido, timeout) — isso é error.
• recover (dentro de um defer) captura um panic e evita derrubar o processo. Uso legítimo: o topo de um handler HTTP / worker, para que o panic de uma requisição não mate o servidor — logando e devolvendo 500.

func comRecover(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if p := recover(); p != nil {
                slog.Error("panic no handler", "panic", p)
                http.Error(w, "erro interno", 500)
            }
        }()
        next.ServeHTTP(w, r)
    })
}

4.5 defer

defer agenda uma chamada para quando a função retornar (em ordem LIFO). Uso canônico: liberar recursos junto de onde são adquiridos, para não esquecer em nenhum caminho de saída.

f, err := os.Open(path)
if err != nil { return err }
defer f.Close()              // roda ao sair da função, sempre
// ... use f livremente; todo return já fecha

5.1 Goroutines

Uma goroutine é uma função executando concorrentemente, gerida pelo runtime de Go (não pelo SO). Custa ~2 KB de stack inicial (que cresce sob demanda), então você pode ter centenas de milhares. O runtime as multiplexa sobre poucos threads do SO (Módulo 9).

go processar(pedido)        // dispara; main NÃO espera

// problema: se main() retorna, o programa acaba e a goroutine morre.
// você precisa de um mecanismo de sincronização.

5.2 Channels

Um channel é um tubo tipado por onde goroutines enviam e recebem valores, com sincronização embutida. É o mecanismo de comunicação idiomático.

ch := make(chan int)         // sem buffer: send bloqueia até alguém receber
buf := make(chan int, 10)     // com buffer 10: send bloqueia só quando cheio

go func() {
    ch <- 42            // envia
}()
v := <-ch              // recebe (bloqueia até ter valor)

close(ch)              // fecha; receber de canal fechado retorna zero, ok=false
for v := range ch {      // itera até o canal ser fechado
    _ = v
}

5.3 select

select {
case v := <-entrada:
    processar(v)
case resultado <- calcular():
    // enviou
case <-time.After(2 * time.Second):
    return errTimeout          // timeout idiomático
case <-ctx.Done():
    return ctx.Err()           // cancelamento (Módulo 6)
}

select espera em vários channels ao mesmo tempo e age no primeiro que estiver pronto (aleatório se vários). É o coração de timeouts, cancelamento e multiplexação.

5.4 Quando channels não bastam: o pacote sync

5.5 O race detector

Duas goroutines acessando a mesma memória sem sincronização, com pelo menos uma escrevendo = data race — comportamento indefinido. Go tem um detector embutido: go test -race, go run -race. Rode-o no CI. Ele não pega tudo (só o que executou), mas pega muito.

6.1 context.Context

Context carrega cancelamento, deadline/timeout e valores de escopo de requisição através da árvore de chamadas. Convenção: é o primeiro parâmetro de qualquer função que faz I/O, chamada de rede, ou trabalho longo — func Buscar(ctx context.Context, id string) (...).

ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second)
defer cancel()   // SEMPRE — libera recursos do context

row := db.QueryRowContext(ctx, query, id)   // a query é abortada se ctx expira

// numa goroutine que faz trabalho longo:
select {
case <-ctx.Done():
    return ctx.Err()   // context.Canceled ou context.DeadlineExceeded
case res := <-worker:
    return res
}

• O ctx de uma requisição HTTP (r.Context()) é cancelado quando o cliente desiste — propague-o para não desperdiçar trabalho.
• context.WithValue só para dados verdadeiramente de escopo de requisição (trace id, usuário autenticado) — não para passar parâmetros opcionais (anti-padrão).
• Sempre chame o cancel() retornado (via defer), mesmo que o timeout não dispare — senão vaza.

6.2 Padrões de concorrência

import "golang.org/x/sync/errgroup"

g, ctx := errgroup.WithContext(ctx)
g.SetLimit(10)                        // no máximo 10 concorrentes
for _, u := range urls {
    u := u
    g.Go(func() error {
        return baixar(ctx, u)         // se retornar erro, ctx é cancelado p/ as outras
    })
}
if err := g.Wait(); err != nil {   // espera todas; primeiro erro
    return err
}

6.3 Goroutine leaks

Uma goroutine que bloqueia para sempre (num channel que ninguém vai fechar, num send sem receptor) nunca é coletada — vaza memória e recursos. Causas e prevenções:

• Sempre haja um caminho de saída: toda goroutine deve terminar quando o ctx é cancelado ou o channel de entrada é fechado.
• Quem escreve fecha o channel (nunca o leitor); um channel só é fechado uma vez.
• Cuidado com select sem case <-ctx.Done() num loop infinito.
• Ferramentas: goleak (Uber) nos testes; pprof mostra a contagem de goroutines em produção — se cresce sem parar, é leak.

6.4 Graceful shutdown

srv := &http.Server{Addr: ":8080", Handler: mux}

go func() { srv.ListenAndServe() }()

// espera SIGINT/SIGTERM
ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
defer stop()
<-ctx.Done()

// dá 15s para as requisições em andamento terminarem
shutCtx, cancel := context.WithTimeout(context.Background(), 15*time.Second)
defer cancel()
srv.Shutdown(shutCtx)

7.1 net/http e o roteador da stdlib

Desde o Go 1.22, o http.ServeMux da biblioteca padrão faz roteamento por método e path params — muitos serviços não precisam mais de um roteador externo (chi, gorilla/mux, gin) para o básico.

mux := http.NewServeMux()
mux.HandleFunc("GET /pedidos/{id}", getPedido)
mux.HandleFunc("POST /pedidos", criarPedido)

func getPedido(w http.ResponseWriter, r *http.Request) {
    id := r.PathValue("id")
    p, err := svc.Get(r.Context(), id)
    if errors.Is(err, domain.ErrNotFound) {
        problema(w, 404, "pedido não encontrado"); return
    }
    if err != nil {
        slog.Error("getPedido", "err", err); problema(w, 500, "erro interno"); return
    }
    writeJSON(w, 200, p)
}

7.2 Middleware

Middleware em Go é uma função func(http.Handler) http.Handler — você encadeia: logging, recover (Módulo 4), autenticação, rate limit, CORS, tracing.

func comLog(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        início := time.Now()
        rec := &statusRecorder{ResponseWriter: w, status: 200}
        next.ServeHTTP(rec, r)
        slog.Info("http", "method", r.Method, "path", r.URL.Path,
            "status", rec.status, "dur_ms", time.Since(início).Milliseconds())
    })
}

handler := comLog(comRecover(comTrace(mux)))

7.3 Logging estruturado com slog

Desde o Go 1.21, log/slog é o logger estruturado da stdlib: níveis, atributos chave-valor, saída JSON para produção, e context-aware.

logger := slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{Level: slog.LevelInfo}))
slog.SetDefault(logger)

slog.Info("pedido criado", "pedido_id", id, "valor_cents", 1990, "trace_id", tid)
// {"time":"...","level":"INFO","msg":"pedido criado","pedido_id":"o1",...}

7.4 Banco de dados

• database/sql (stdlib) + um driver (pgx para PostgreSQL, o mais recomendado; pgx também tem API nativa mais rica).
• Sempre passe ctx: QueryContext, ExecContext — cancelamento propaga ao banco.
• Configure o pool: SetMaxOpenConns, SetMaxIdleConns, SetConnMaxLifetime — o default é ilimitado e derruba o banco sob carga.
• Geradores de código para SQL type-safe: sqlc (escreve SQL, gera Go tipado) é muito popular; sqlx para menos boilerplate; ORMs (GORM, Ent) existem mas a comunidade tende a SQL explícito.
• Migrations: golang-migrate, goose, atlas.

7.5 Testes

// table-driven test: o idioma de Go para cobrir muitos casos
func TestValidarCPF(t *testing.T) {
    casos := []struct {
        nome string
        in   string
        want bool
    }{
        {"válido", "11144477735", true},
        {"dígito errado", "11144477730", false},
        {"curto", "123", false},
    }
    for _, c := range casos {
        t.Run(c.nome, func(t *testing.T) {
            if got := ValidarCPF(c.in); got != c.want {
                t.Errorf("ValidarCPF(%q) = %v, quer %v", c.in, got, c.want)
            }
        })
    }
}

• testing na stdlib; testify (assert/require/mock) é adição comum.
• net/http/httptest para testar handlers sem subir servidor.
• testcontainers-go para testes de integração com Postgres/Redis reais em Docker.
• go test -race -cover ./... no CI; benchmarks com func BenchmarkX(b *testing.B).

8.1 Docker: imagem minúscula

# build multi-stage: compila num estágio, copia só o binário para outro
FROM golang:1.23 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /app ./cmd/api

# imagem final: distroless (só libc + certs) ou scratch (nada)
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /app /app
USER nonroot
ENTRYPOINT ["/app"]

• CGO_ENABLED=0 ⇒ binário estático puro ⇒ roda em scratch/distroless (imagem de poucos MB, superfície de ataque mínima, sem shell).
• -ldflags="-s -w" tira símbolos de debug (binário menor).
• Rodar como nonroot; sem shell = mais difícil de explorar.

8.2 gRPC em Go

Go é cidadão de primeira classe do gRPC. Fluxo: escrever o .proto → protoc (ou buf) gera o código Go → implementar a interface do servidor → registrar no grpc.Server. Interceptors são o "middleware" do gRPC. Ver apostila de API Design para o design do contrato; aqui, a mecânica:

lis, _ := net.Listen("tcp", ":50051")
s := grpc.NewServer(
    grpc.ChainUnaryInterceptor(logInterceptor, recoverInterceptor),
)
pb.RegisterOrderServiceServer(s, &orderServer{svc: svc})
s.Serve(lis)

Para expor a mesma API em REST sem reescrever: grpc-gateway (gera um proxy HTTP/JSON a partir do proto) ou Connect (protocolo que fala gRPC, gRPC-Web e HTTP/JSON no mesmo endpoint).

8.3 O ecossistema Kubernetes

• client-go: o cliente oficial da API do Kubernetes — listar/criar/observar (watch) recursos.
• controller-runtime + Kubebuilder / Operator SDK: o framework para escrever operators e controllers — o loop de reconciliação ("estado desejado vs atual") que é o coração do Kubernetes. Se você vai estender o K8s, é Go.
• CRD + reconciler: você define um recurso custom (ex.: Database) e um controller que o materializa em Deployments/Services/Secrets reais.
• Bibliotecas de operação: cobra (CLIs), viper (config), kustomize, helm (SDK).

8.4 Observabilidade

• Métricas: prometheus/client_golang — expor /metrics; contadores/histogramas RED (rate, errors, duration).
• Tracing: OpenTelemetry Go SDK — instrumentação automática de net/http, database/sql, gRPC; propaga traceparent; exporta para Jaeger/Tempo/vendor.
• Logs: slog JSON (Módulo 7) com trace id, coletados por Loki/ELK.
• Health: endpoints /healthz (liveness) e /readyz (readiness — checa deps).

8.5 12-factor em Go

• Config por variável de ambiente (não arquivo commitado); os.Getenv + validação no boot, ou envconfig.
• Logs para stdout (o orquestrador coleta) — não escreva arquivos de log.
• Processo stateless; estado em Postgres/Redis/S3.
• Graceful shutdown em SIGTERM (Módulo 6) — o K8s manda SIGTERM e espera o terminationGracePeriod.
• Um binário, uma responsabilidade; cmd/api, cmd/worker, cmd/migrate.

9.1 O runtime: scheduler G-M-P

• G = goroutine, M = thread do SO, P = processador lógico (por padrão GOMAXPROCS = nº de CPUs). O scheduler multiplexa muitos G sobre poucos M, cada M ligado a um P com sua fila de goroutines prontas.
• Preempção: o runtime pode interromper uma goroutine (desde 1.14, até em loops apertados) para dar vez a outra — sem isso, uma goroutine CPU-bound travava o P.
• Work stealing: um P ocioso "rouba" goroutines da fila de outro — balanceamento automático.
• Chamada bloqueante do SO (I/O de arquivo, syscall): o M se desprende do P e outro M assume, então goroutines continuam rodando. I/O de rede usa o netpoller (epoll/kqueue) e não bloqueia thread.

9.2 Garbage collector e escape analysis

• GC concorrente, tricolor, mark-and-sweep, otimizado para latência (pausas < 1 ms típicas), não para throughput máximo.
• GOGC (default 100) controla o trade-off: menor = GC mais frequente, menos memória; maior = menos GC, mais memória. GOMEMLIMIT (1.19+) põe um teto suave de memória — útil em contêiner.
• Escape analysis: o compilador decide se um valor fica na stack (barato, sem GC) ou "escapa" para a heap (custa GC). go build -gcflags='-m' mostra. Retornar ponteiro de uma variável local, guardar em interface, ou capturar em closure tende a fazer escapar.
• Reduzir alocação (quando o profiler apontar): pré-alocar slices com make([]T, 0, n), reusar buffers com sync.Pool, evitar conversões []byte↔string desnecessárias, cuidar de fmt em caminho quente.

9.3 Profiling e benchmarks

// benchmark
func BenchmarkParse(b *testing.B) {
    for i := 0; i < b.N; i++ {
        _ = Parse(entrada)
    }
}
// go test -bench=. -benchmem   → ns/op, B/op, allocs/op

// pprof em produção: expor via net/http/pprof (rota protegida)
import _ "net/http/pprof"
// go tool pprof http://host/debug/pprof/profile?seconds=30   (CPU)
// go tool pprof http://host/debug/pprof/heap                 (memória)
// go tool pprof http://host/debug/pprof/goroutine            (leaks!)

Fluxo: meça antes de otimizar. Benchmark do trecho suspeito com -benchmem; pprof de CPU e heap em carga real; o flame graph mostra onde o tempo/memória vai. Otimização sem profiling é chute.

9.4 Generics (1.18+) — com critério

func Map[T, U any](s []T, f func(T) U) []U {
    r := make([]U, len(s))
    for i, v := range s {
        r[i] = f(v)
    }
    return r
}

• Use para estruturas de dados genéricas (árvores, sets, filas) e utilitários de coleção type-safe (slices, maps na stdlib desde 1.21).
• Não substitua interfaces por generics onde a interface expressa melhor a intenção (polimorfismo de comportamento). "Se dúvida, não use generics" ainda é a orientação da comunidade.

9.5 Estrutura de repositório e supply chain

• Layout: cmd/<binário>/main.go (entrypoints finos); internal/ (código privado ao módulo — o compilador impede import externo); pkg/ só se você quer exportar bibliotecas; domínio no centro, adapters na borda (hexagonal — ver apostila de Arquitetura).
• Dependências: Go Modules; go.sum fixa hashes; GOFLAGS=-mod=readonly no CI; revisar go.mod em PR.
• Segurança: govulncheck (oficial) no CI — reporta só vulnerabilidades em código que você realmente chama; go vet, staticcheck, golangci-lint.
• Reprodutibilidade: build com -trimpath; versão embutida via -ldflags "-X main.version=..." ou runtime/debug.ReadBuildInfo.

10.1 Onde Go abre portas

10.2 Roadmap de estudo (7–9 semanas)

10.3 Banco de perguntas de entrevista (com a resposta que aprova)

10.4 Projetos de portfólio que geram entrevista

1. Serviço idiomático completo (âncora): API REST + gRPC, Postgres via sqlc, slog, middleware, graceful shutdown, table-driven tests + testcontainers, CI com -race/govulncheck, Dockerfile distroless, métricas Prometheus + tracing OTel. README explicando cada escolha.
2. Ferramenta de concorrência: um crawler/baixador com worker pool configurável, errgroup, limite, timeout, retry, e um teste que prova ausência de leak (goleak).
3. Operator/controller de Kubernetes: um CRD simples (ex.: provisiona um recurso) com Kubebuilder — mostra domínio do padrão de reconciliação.
4. CLI multiplataforma: com cobra, cross-compile no CI, releases com goreleaser.
5. Estudo de performance: um trecho profilado e otimizado, com flame graphs e números de -benchmem antes/depois.

10.5 Fontes para continuar

• Oficial: "A Tour of Go", "Effective Go", "Go Code Review Comments", o blog do Go, os release notes de cada versão.
• Livros: The Go Programming Language (Donovan & Kernighan); Learning Go (Jon Bodner) — atualizado, ótimo para idiomas modernos; 100 Go Mistakes and How to Avoid Them (Teiva Harsanyi).
• Concorrência: Concurrency in Go (Katherine Cox-Buday); os talks "Concurrency is not Parallelism" e "Go Concurrency Patterns" (Rob Pike).
• Prática: ler o código de um projeto CNCF de porte médio; Gophercises; os padrões de golang-standards/project-layout (com senso crítico — não é oficial).