Go e o futuro do backend

Desde quando eu comecei na programação, os arautos da morte das linguagens de programação decretaram a morte do PHP. Hoje, quase 8 anos depois, estou escrevendo numa página justamente criada nessa linguagem. Todo esse macanismo de digitação está rodando num servidor com PHP, a linguagem morta.

Quando partimos para o âmbito do Java, há quem a compare com COBOL. “Já não tem mais futuro”, “as empresas estão procurando outros perfis de linguagem”, não é difícil encontrar na internet quem mate do Java, desde a versão 8. É certo que existem linguagem mais atuais que, pode até parecer mais performática, mas o Java ainda roda em 8 a cada 10 maiores empresas do mundo. São milhões de linhas de código (legado ou não) que sustentam a economia de bancos, seguradoras, transportadoras, sistemas de saúde, etc. E não estamos falando do seu banquinho digital (que provavelmente roda Java também), nem do seu plano de saúde que atende só seu bairro, estamos falando de bancos que processam transações entre nações, seguradoras de transporte marítimo, sistemas de saúde de um país inteiro. É sobre isso.

Nesse contexto, devemos nos perguntar: as linguagens como Go, uma forte candidata a substituir o Java, tem a maturidade de alcançar um sistema desses? Não devemos negar que a performance e a simplicidade da linguagem realmente é um ponto muito atrativo, mas será que bilhões de dólares valem uma experiência nova? Nem Java por si só é uma linguagem estruturada e madura o suficiente frente ao COBOL, vide tantos mainframes que ainda estão em operação no mundo. (Sigam gotoCobol no Youtube).

Me fiz essa pergunta ontem a noite e parei um pouco com os meus estudos em React para me debruçar no Go. Primeiro, deixando claro: ainda hoje eu acho aquele mascote uma das coisas mais feias que já fizeram nosse aspecto na história da programação. Nem o Duke, do Java, que não tem olhos nem boca é mais simpático do que essa coisa tosca.

Enfim, reclamações à parte, a linguagem parece ser bem promissora mesmo. Só tem 25 palavras reservadas:

			
break case chan const continue default defer else fallthrough for func go goto if import interface map package range return select struct switch type var

O que a torna uma linguagem muito simples e intuitiva de ler. A curva de aprendizado deve ser incrivelmente curta. Outro ponto é a filosofia de ser “direta ao ponto”. Não existem classes, arquiteturas mirabolantes, interfaces de interfaces, poli-não-sei-o-quê… Ou seja, é uma linguagem que se propõe a fazer e fazer direito (e direto).

Mas o ponto que eu acho que deve ser o grande atrativo dela são as go-routines. Basicamente são estruturas de concorrência que rodam de maneira muito mais ágil do que outras linguagens padrão. Consumindo, claro, menos memória. E hoje, agilidade e menos consumo de memória é algo raro de se ver. Ou você cai em linguagens como C ou C++ ou vai para o Rust mesmo, aí é escovar bits quase que na placa-mãe.

Outro ponto positivo que eu ia me esquecendo: Go é uma linguagem compilada. Ela não depende de um interpretador apartado para fazer acontecer. É o programa e a máquina, a máquina e o programa. Isso deixa a velocidade dos executáveis bem maior em comparação com Python por exemplo.

Aqui embaixo temos o exemplo de um programa simples em Go que se comporta como um pequeno servidor:

			
package main
import (
	"fmt"
	"net/http"
)
func helloHandler(w http.ResponseWriter, r *http.Request) {
	if r.Method != http.MethodGet {
		http.Error(w, "Método não permitido", http.StatusMethodNotAllowed)
		return
	}
	w.Header().Set("Content-Type", "text/plain; charset=utf-8")
	w.WriteHeader(http.StatusOK)
	
	fmt.Fprint(w, "Hello World")
}
func main() {
	http.HandleFunc("/", helloHandler)
	fmt.Println("Servidor rodando na porta 8080...")
	if err := http.ListenAndServe(":8080", nil); err != nil {
		fmt.Printf("Erro ao iniciar o servidor: %v\n", err)
	}
}

		

Temos uma função que faz propriamente a resposta HTTP, tomando dois parâmetros: w do tipo http.ResponseWrite e r do tipo *http.Request. O primeiro é o escritor da resposta, propriamente dito e o segundo é um ponteiro (eu tenho que fazer um post ainda sobre esse conceito) com as informações da requisição: método, URL, cabeçalhos, etc.

Tendo essa função criada, no método principal (main) eu chamo a função http.HandleFunc passando a rota “/” e a função que a gente acabou de criar. Eu executo e armazeno o resultado nesse campo especial err e se err for diferente de nil, ou seja, existir um erro, ele mostra que não pode iniciar o servidor.

Pronto, só com isso você já consegue um serviço simples rodando. Se você joga localhost:8080/no navegador, ele vai te retornar um “Hello Word”. Simples, rápido, dá pra entender todos esses conceitos em uma tarde. Em Python eu tenho o mesmo serviço assim:

			
from http.server import BaseHTTPRequestHandler, HTTPServer
class SimpleHandler(BaseHTTPRequestHandler):
  def do_GET(self):
    self.send_response(200)
    self.send_header("Content-Type", "text/plain; charset=utf-8")
    self.end_headers()
    self.wfile.write(b"Hello World")
if __name__ == "__main__":
  print("Servidor rodando na porta 8080...")
  HTTPServer(("", 8080), SimpleHandler).serve_forever()

		

Bem menor, né? Mas a que custo?

*Comparativo médio das requisições por segundo contra latência média*
*Gerado pelo Google Gemini*¹

Esse é o custo. Uma linguagem mais fácil de entender vai ser mais custoso pro computador processar.

Isso quer dizer que Go vai dominar todas as plataformas e reinar sobre todas as linguagens de programação?

Calma aí, paizão…

Go pode ser bem performática e executar processos coreografados de maneira bem performática, mas estamos esquecendo de um fator importante para programação: abstração. Não adianta uma linguagem ser rápida, performática e compilada se ela não atende os requisitos do seu gestor. Se, para com ela, você precisa de 500 linhas de código para abstrair um contrato de compra e venda. Entende o meu ponto? Nesses casos, Java ainda continua reinando porque o nível de abstração dela é muito superior.

Ok, então isso quer dizer que devemos abandonar Go para sempre? Também não. Como vimos, Go é muito boa para processos concorrentes, como envio de mensagens numa fila, processamentos de lote, busca/inserção no banco de dados… Ou seja, ainda existem uma infinidade de maneira de você conseguir casar uma tecnologia com a outra.

Hoje em dia temos mecanismos para uma mesma equipe trabalhar com várias linguagens de programação ao mesmo tempo. Go para processamento de rotinas e arquivos, Java para core business, Python para análise de dados, JS para frontend, COBOL para recursos legado e assim por diante. O que vale aqui é a máxima: Não existe bala de prata.

Com tudo isso eu quero demonstrar que sim, Go pode ser o futuro do backend, mas não só. Ele é dotado de muitas capacidades, mas sozinho acaba criando mais problemas do que resolvendo. A melhor maneira de encaixá-lo no teu projeto é avaliando a arquitetura, as condições e considerando implementá-lo ou deixá-lo na gaveta. E tá tudo bem você não usar. Isso não quer dizer que você não deva aprender sobre. Conhecimento nunca é de mais.

Os dados de performance são baseados em testes comparativos padrão da comunidade (como o TechEmpower Benchmarks e documentações oficiais do Go e Python) simulando requisições HTTP síncronas básicas. O módulo http.server do Python foi projetado primariamente para testes/desenvolvimento local (conforme nota da Python Software Foundation), enquanto a biblioteca net/http do Go é pronta para produção de alta escala. ↩︎