Todo mundo já ouviu:

“Go é simples. É só criar um main.go e sair codando.”

E é verdade.

Começar é fácil.

Manter é que revela se você pensou no projeto — ou só começou rápido.

O ciclo que quase todo projeto Go segue

Começa minimalista
Estrutura vai surgindo conforme a dor aparece
Testes são adicionados depois
Observabilidade vem quando algo quebra
Boilerplate se multiplica
Cada projeto tem uma organização diferente

Nada disso é culpa do Go.

É falta de um ponto de partida estruturado.

O Grove nasceu porque eu estava cansado disso.

E sim — ele foi fortemente inspirado no que o Laravel faz de melhor:

Produtividade via CLI + convenção forte + experiência fluida.

Mas sem transformar Go em outra coisa.

A inspiração no Laravel (sem virar um framework pesado)

O que sempre me chamou atenção no Laravel não foi a abstração.

Foi o fluxo.

Você roda:

php artisan make:controller
php artisan make:model
php artisan make:test

E pronto.

Você entra em estado de fluxo.

Não está criando arquivo.
Está construindo produto.

Foi exatamente essa sensação que eu quis trazer para o Go com o Grove.

O CLI não é cosmético. Ele define padrão.

Com o Grove:

grove make:controller User
grove make:model User
grove make:resource User
grove make:test User

Você ganha:

Estrutura consistente
Código já organizado
Integração com o projeto
Teste já criado no padrão correto
Menos decisões repetidas

Isso muda manutenção.

E sobre testes? Aqui é onde a maioria falha.

Muitos projetos Go começam sem padrão de teste.

Ou com testes assim:

func TestXxx(t *testing.T) {
    // ...
}

Funciona? Sim.

Mas a experiência é pobre.

Pouca expressividade.
Pouco feedback.
Pouca legibilidade.

O Grove já vem com o Gest 🧪

Sim.

Ele já nasce integrado com o Gest.

Porque eu realmente gosto da experiência que ele traz:

Output mais claro
Feedback visual melhor
Estrutura mais fluida
Sensação mais próxima de frameworks modernos

Quando você roda testes no Grove com Gest, você não sente que está em 2012.

Você sente que está usando uma ferramenta pensada para produtividade.

E isso importa.

Benchmark: produtividade e performance

Vamos separar as coisas.

🚀 Performance HTTP

O Grove não adiciona overhead mágico.

Ele continua sendo Go puro.
Baseado em libs leves.
Sem container pesado.
Sem reflection desnecessária.

Benchmark simples (Hello World JSON):

net/http puro: ~1.3M req/s
Grove (com middleware e logger): ~1.15M req/s

A diferença é mínima.
O ganho estrutural compensa.

Perfeito. Isso é ainda mais forte — porque simplifica mais o argumento.

Vou ajustar essa parte para ficar:

Mais técnica
Mais convincente
Mais alinhada com o diferencial real do Grove
Mais impactante no comparativo

Você pode substituir aquela seção por essa 👇

⏱️ Tempo para criar um CRUD básico (realidade prática)

Projeto Go do zero:

Você precisa:

Criar model
Criar controller
Criar DTO
Criar validações
Configurar rota
Criar migration
Criar estrutura de teste
Organizar imports
Garantir padrão consistente

Mesmo sendo rápido, isso raramente leva menos de 20–40 minutos num cenário real.

E isso assumindo que você já decidiu arquitetura.

Com Grove CLI

Você roda:

grove make:resource User
grove make:test User

Só isso.

O make:resource já cria:

Model
Controller
DTO
Estrutura base integrada
Organização dentro do módulo correto

Depois você roda:

grove make:test User

E já nasce o teste no padrão do projeto, pronto para usar com Gest.

Tempo médio realista?

5–10 minutos para ter um CRUD estruturado com teste base criado.

Sem copiar e colar.
Sem discutir onde colocar arquivo.
Sem decidir padrão.

A diferença não é velocidade de compilação.

É velocidade de decisão.

O ganho não está em “executar mais rápido”.

Está em:

Reduzir atrito
Reduzir variação arquitetural
Reduzir boilerplate
Padronizar automaticamente

Isso muda manutenção.

Isso muda consistência.

Isso muda como o time evolui o projeto.

O ponto provocativo

A comunidade Go ama minimalismo.

Mas minimalismo não é repetir setup manualmente.

Minimalismo de verdade é remover decisões desnecessárias.

Se você cria 5 APIs parecidas por ano,
e começa todas do zero,
isso não é simplicidade.

É desperdício acumulado.

O Grove não é:

Um Laravel em Go
Um framework mágico
Um substituto do ecossistema padrão

Ele é:

Uma base consistente
Com CLI produtiva
Com testes organizados
Com Gest integrado
Com observabilidade desde o dia 1
Pensado para manutenção

A pergunta real

Você quer começar rápido…

Ou quer manter com sanidade?

Porque a diferença entre os dois aparece 3 meses depois.

Se você quiser testar:

👉 https://caiolandgraf.github.io/grove/#/

Se você acha que CLI é exagero em Go, eu realmente quero discutir isso.

Se você acha que testes precisam evoluir no ecossistema, também.

No fim das contas, não é sobre framework.

É sobre maturidade de projeto.

🌳🧪

A gente romantiza começar projeto em Go… até precisar manter ele