Voltar ao blog

Go vs Rust em 2026: comparação honesta para backend

O Go é a escolha certa por omissão para backend em 2026. Esta comparação cobre concorrência, ecossistema, salários, curva de aprendizagem e casos de estudo da Discord, Cloudflare e AWS, com uma fonte primária para cada afirmação.

Go vs Rust em 2026: comparação honesta para backend

Última atualização: 29 de abril de 2026

Go vs Rust: visão geral

AspetoGo (Golang)Rust
DesempenhoExcelente para I/O. Suficientemente rápido para quase todo o trabalho de CPU.Ligeiramente mais rápido em ciclos numéricos apertados.
Modelo de memóriaPausas de GC abaixo de um milissegundo com o coletor Green Tea. Não tens de gerir a memória tu mesmo.Ownership e borrowing. Sem GC, mas tens de raciocinar sobre lifetimes em todo o lado.
ConcorrênciaGoroutines e channels com um scheduler preemptivo. Sem a palavra-chave async e sem coloração de funções.Futures do Tokio e async cooperativo. Tens de lidar com async, pinning e segurança no cancelamento.
Curva de aprendizagemProdutivo numa semana. 25 palavras-chave e uma forma óbvia de fazer a maioria das coisas.Meses. Borrow checker, lifetimes, trait bounds, Pin, Send/Sync.
Tempos de compilaçãoSegundos, com builds incrementais abaixo de um segundo.Minutos em builds limpos e de CI.
EcossistemaDomina o cloud-native: Kubernetes, Docker, Terraform, Prometheus, todos os SDKs de cloud.Stack async sólida (Axum, Tokio). Cobertura de SDKs mais limitada.
Mercado de trabalhoMuito maior, com procura em cloud, fintech, infraestrutura e devtools.Mais pequeno e concentrado em sistemas e cripto.
Ideal paraAPIs CRUD, microsserviços, planos de controlo, CLIs, ferramentas cloud-native. A maior parte do que vais construir.Proxies, hipervisores, bases de dados, codecs, sistemas embebidos.
A evitar emTempo real estrito, trabalho de kernel.A maioria dos backends CRUD e MVPs de iteração rápida.

O Go fica à frente em quase tudo o que uma equipa de backend otimiza. As vantagens do Rust contam para uma pequena parte do trabalho de sistemas.

Devo escolher Go ou Rust?

flowchart TD
    Start(["`**Building a backend service in 2026**`"])
    Start --> Q{"`Systems-level software?`"}

    Q -->|"`**No** — 90%+ of backend work`"| Go(["`**Go**`"])
    Q -->|"`**Yes** — a narrow strip`"| Rust(["`**Rust**`"])

    Go --> GoUse["`**What you build**
    ─────────────
    CRUD APIs
    Microservices
    Control planes
    CLIs and operators
    Cloud-native tooling
    gRPC services`"]
    GoUse --> GoProof["`**Shipping in production**
    ─────────────
    Kubernetes · Docker
    Terraform · etcd
    Prometheus · Grafana
    CockroachDB · Caddy
    Tailscale · containerd

    Backends at Uber, Netflix,
    Cloudflare, Twitch, Monzo`"]

    Rust --> RustUse["`**What you build**
    ─────────────
    Hypervisors
    Hot-path proxies
    Database engines
    Codecs and crypto
    Sub-ms tail latency`"]
    RustUse --> RustProof["`**Shipping in production**
    ─────────────
    Cloudflare Pingora
    AWS Firecracker
    Discord Read States
    Polkadot
    Linkerd2-proxy`"]

    classDef start fill:#0b2942,color:#d6deeb,stroke:#1d3b53,stroke-width:1px,rx:8,ry:8
    classDef question fill:#0b2942,color:#d6deeb,stroke:#1d3b53,stroke-width:2px
    classDef goPick fill:#00ADD8,color:#011627,stroke:#5DC9E2,stroke-width:3px
    classDef goPanel fill:#0b2942,color:#d6deeb,stroke:#00ADD8,stroke-width:2px,rx:6,ry:6
    classDef rustPick fill:#CE3263,color:#fff,stroke:#ef5350,stroke-width:3px
    classDef rustPanel fill:#0b2942,color:#d6deeb,stroke:#CE3263,stroke-width:2px,rx:6,ry:6

    class Start start
    class Q question
    class Go goPick
    class GoUse,GoProof goPanel
    class Rust rustPick
    class RustUse,RustProof rustPanel

    linkStyle 0 stroke:#7a8fa3,stroke-width:1.5px
    linkStyle 1 stroke:#00ADD8,stroke-width:2.5px
    linkStyle 2 stroke:#CE3263,stroke-width:2.5px
    linkStyle 3 stroke:#00ADD8,stroke-width:2.5px
    linkStyle 4 stroke:#00ADD8,stroke-width:2.5px
    linkStyle 5 stroke:#CE3263,stroke-width:2.5px
    linkStyle 6 stroke:#CE3263,stroke-width:2.5px

A maior parte do trabalho de backend cai do lado do Go. O ramo do Rust cobre um conjunto estreito e bem definido de sistemas.

Na internet, o debate Go vs Rust costuma soar como se as duas linguagens competissem pelo mesmo tipo de trabalho. Na maior parte dos casos, não competem. O Go foi desenhado para trabalho de backend distribuído e concorrente, que é aquilo de que é feita a maior parte da infraestrutura moderna. O Rust foi desenhado para a programação de sistemas, o território que antes pertencia ao C e ao C++.

Este artigo ajuda-te a perceber de que lado está o teu projeto e porque é que quase todas as equipas de backend em 2026 acabam do lado do Go. Sempre que existe uma fonte primária, a ligação está no próprio texto para poderes confirmar o número por ti.

Índice


A resposta curta

Para backend, escolhe Go por omissão. Eis o que ganhas:

  • Entregas mais rápidas. As novas contratações contribuem com alterações relevantes na primeira semana.
  • Recrutamento mais fácil, porque o talento disponível em Go é muito maior do que em Rust.
  • Boa concorrência sem cerimónias. Goroutines, channels e context cobrem a maior parte do que precisas.
  • A stack cloud-native dominante. Kubernetes, Docker, Terraform e Prometheus são escritos em Go, e todos os grandes SDKs de cloud têm versão em Go.
  • Um runtime suficientemente rápido para deixares de pensar nele.

Recorre ao Rust só quando tiveres uma necessidade estrita e duradoura de latência de cauda previsível abaixo dos 10 ms, pegadas de memória muito pequenas ou abstrações de custo zero sobre o hardware. Isso significa proxies, bases de dados, hipervisores, agentes embebidos e codecs. Não significa mais um serviço HTTP.

Desempenho: o Rust é mais rápido do que o Go em 2026?

A maioria dos serviços de backend é limitada por I/O. Passam o tempo à espera da base de dados, da rede ou do serializador, por isso o runtime raramente é o ponto de estrangulamento.

Em trabalho intensivo de CPU, como parsing, compressão e criptografia, o Rust pode ganhar vantagem, sobretudo em ciclos numéricos com inlining e sem verificação de limites. O trabalho de CPU que um serviço de backend típico faz é JSON, protobuf, hashing e regex. O compilador e a biblioteca padrão do Go estão bem afinados para isso, e em produção a diferença costuma ser demasiado pequena para se notar.

Cuidado com o benchmark dos «10x». O número de destaque da reescrita do Aurora DSQL na AWS (Werner Vogels: «Basta fazê-lo escalar») compara Kotlin sobre a JVM com Rust, num plano de controlo que batia nos limites de aquecimento e de GC da JVM. Não é um número de Go vs Rust, e migrar um serviço em Go não te vai dar nada parecido com esse multiplicador.

As versões recentes do Go continuam a encurtar a diferença onde importa:

O Go também lida bem com alocações. O compilador faz uma análise de escape agressiva, por isso muito do que parece uma alocação no heap acaba na pilha, onde sai barato. Go idiomático que usa sync.Pool, strings.Builder e slices pré-alocados é eficiente.

example.gogo
package main

import (
    "fmt"
    "strings"
)

func main() {
    parts := []string{"go", "is", "fine", "for", "most", "things"}
    var b strings.Builder
    for _, p := range parts {
        b.WriteString(p)
        b.WriteString(" ")
    }
    fmt.Println(strings.TrimSpace(b.String()))
}

O equivalente em Rust também funciona. Mas pagas por ele à cabeça, a pensar em lifetimes e ownership em cada linha, incluindo nas linhas em que isso não importa:

example.rustrust
fn main() {
    let parts = ["rust", "is", "strict", "but", "predictable"];
    let mut s = String::with_capacity(64);
    for p in parts {
        s.push_str(p);
        s.push(' ');
    }
    println!("{}", s.trim_end());
}

Saber qual das linguagens é mais rápida importa menos do que saber se é suficientemente rápida para deixares de pensar nisso. Para trabalho de backend, o Go é. Quando não for, faz profiling primeiro. O ponto de estrangulamento é quase sempre uma consulta à base de dados ou uma chamada N+1, não o runtime.

Gestão de memória: o GC do Go vs o ownership do Rust

A proposta do Rust aqui é o determinismo. A memória é libertada quando o ownership termina, por isso não há coletor em segundo plano nem orçamento de heap para afinar. O preço é teres de raciocinar sobre lifetimes em todo o lado, mesmo em código que seria seguro sem isso.

O GC do Go é muito bom. Depois de anos de uso em produção, e agora com o coletor Green Tea, pausas abaixo de um milissegundo em heaps de vários gigabytes são normais. Em serviços comuns, a correr em VMs de longa duração, não vais dar por ele, seja numa API CRUD, num plano de controlo ou num microsserviço.

O caso da Discord é real, mas restrito. O serviço Read States da Discord guardava milhões de entradas numa cache LRU em memória, e a versão em Go tinha picos de latência sempre que o GC percorria essa cache. A reescrita em Rust acabou com os picos (Engenharia da Discord: porque é que a Discord está a mudar de Go para Rust).

Os próprios engenheiros da Discord apontam os limites no mesmo artigo:

  • Foi um serviço específico a correr a uma escala extrema.
  • O resto do backend da Discord continua a ser Go.
  • O artigo diz «Go served us well» («o Go serviu-nos bem») tal e qual.

Nas cargas de trabalho que a maioria das equipas corre (APIs CRUD, microsserviços, planos de controlo, CLIs), o GC do Go não vai aparecer nos teus traces. O modelo de memória do Rust só fica à frente com caches em memória muito grandes, orçamentos de latência de cauda muito apertados ou deployments edge densos onde a memória escasseia.

Concorrência: goroutines vs Tokio

Esta é a diferença mais profunda entre as duas linguagens, e é onde o argumento a favor do Go como escolha por omissão é mais claro.

O modelo do Go é stackful e preemptivo.

  • Cada goroutine tem a sua própria pilha, que pode crescer.
  • O runtime pode pausar uma goroutine para executar outra.
  • Escreves código bloqueante e o runtime torna-o concorrente.
  • Não há palavra-chave async, nem coloração de funções, nem quebra-cabeças de segurança no cancelamento.
  • As goroutines são baratas, por isso podes lançar milhares.

Se as goroutines são novidade para ti, o curso Go Concurrency Fundamentals explica go, channels, select e o cancelamento com context através de exemplos que podes executar.

example.gogo
package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    var wg sync.WaitGroup
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            time.Sleep(10 * time.Millisecond)
            fmt.Printf("worker %d done\n", id)
        }(i)
    }
    wg.Wait()
}

O modelo do Rust é stackless e cooperativo.

  • As funções async devolvem Futures, e um executor (quase sempre o Tokio) trata de os executar.
  • A coloração de funções faz com que uma async fn se propague a todos os chamadores.
  • Aprendes Pin, lifetimes através de .await e segurança no cancelamento da pior maneira.
  • O que deve acontecer quando um future é descartado a meio de um await ainda está a ser discutido ativamente (Cancelar async em Rust, Oxide RFD 400).
example.rustrust
use tokio::time::{sleep, Duration};

#[tokio::main]
async fn main() {
    let mut handles = vec![];
    for i in 0..5 {
        handles.push(tokio::spawn(async move {
            sleep(Duration::from_millis(10)).await;
            println!("worker {i} done");
        }));
    }
    for h in handles {
        h.await.unwrap();
    }
}

Porque é que as goroutines são a escolha certa por omissão para backend:

  • Encaixam na forma como os programadores já pensam em trabalho paralelo.
  • Compõem-se sem coloração de funções.
  • Distribuir trabalho, esperar e recolher resultados leva poucas linhas óbvias, em vez de um quebra-cabeças de lifetimes.
  • O race detector do Go apanha condições de corrida quando os testes correm. Isso dá-te a maior parte da segurança sem a sobrecarga do sistema de tipos.
  • go, channels, sync, context e o race detector, em conjunto, fazem correr alguns dos maiores sistemas concorrentes em produção, incluindo Kubernetes, Docker e etcd.

Para os padrões de concorrência que costumam apanhar as equipas desprevenidas em produção, vê 10 erros comuns em Go a evitar.

Quando precisas mesmo desse controlo, o async do Rust é a ferramenta mais poderosa. Pagas por ele em cada linha, quer o uses quer não, e os serviços de backend normalmente não precisam dele.

Curva de aprendizagem: o Rust é mais difícil do que o Go?

O Go é pequeno de propósito. Tem 25 palavras-chave, uma biblioteca padrão compacta e, normalmente, uma forma óbvia de fazer as coisas. As novas contratações leem o código existente e fazem alterações relevantes na primeira semana. Essa rapidez de integração é uma vantagem de negócio subestimada, e volta a compensar com cada pessoa que contratas.

O Rust é grande de propósito. O borrow checker, os lifetimes, os trait bounds, Pin, Send/Sync e a semântica async são o preço de entrada, não extras opcionais. Quando uma equipa ultrapassa essa barreira, o compilador passa a ser um parceiro útil de pair programming. Mas a barreira é real, e as equipas pagam por ela com uma adaptação mais longa, revisões mais lentas e tempo gasto a lutar com os tipos em vez de entregar funcionalidades.

A diferença também se vê na revisão de código. Os pull requests em Rust tendem a ser mais longos e a ser revistos com mais cuidado. Os pull requests em Go tendem a ser mais pequenos e a avançar mais depressa. Se a tua equipa dá importância a entregar, depurar em produção e integrar engenheiros depressa, o modelo de produtividade do Go é difícil de bater.

O curso Go Generics Masterclass mostra mais ou menos onde fica o teto de complexidade do Go: parâmetros de tipo, restrições e padrões genéricos autorreferenciais. É mais ou menos o código mais complexo que vais escrever em Go idiomático.

Tempos de compilação: velocidade de build em Go vs Rust

Um serviço Go de dimensão média compila em segundos, e os builds incrementais terminam normalmente em menos de um segundo. O Rust é muito mais lento, sobretudo em builds limpos e em CI baseada em Docker.

A equipa do Rust tem continuado a melhorar isto, e o novo trait solver e o front-end paralelo chegaram ambos em versões recentes. A diferença continua grande.

Isto importa sobretudo para equipas que entregam muitos serviços pequenos e iteram depressa. Com builds rápidos, corres os testes mais vezes, fazes push mais vezes e manténs os ciclos de feedback curtos. Com o Rust esperas, e a espera muda a forma como as pessoas trabalham.

Ecossistema e frameworks

Os dois ecossistemas estão maduros em 2026, de formas diferentes.

O ecossistema web do Go já assentou e foi posto à prova a sério em produção.

  • O net/http da biblioteca padrão recebeu grandes melhorias de encaminhamento na versão 1.22 e continua a melhorar. Muitos serviços nem precisam de uma framework.
  • database/sql com pgx para PostgreSQL é a escolha aborrecida e correta para o acesso a dados.
  • Entre as frameworks, o relatório Go Ecosystem in 2025 da JetBrains coloca o Gin em cerca de 48 %, o Echo em cerca de 16 % e o Fiber em cerca de 11 %.
  • slog e o SDK do OpenTelemetry dão-te logs estruturados, métricas e traces com muito pouca configuração.

O ecossistema web do Rust assentou no Axum, que é mantido pela equipa do Tokio e é a framework web de Rust mais usada em inquéritos recentes. O Actix Web continua popular para código sensível ao desempenho, e o SQLx e o SeaORM são as principais opções para acesso a bases de dados.

A vantagem do Go está na amplitude. SDKs de cloud, bibliotecas nativas de Kubernetes e operators saem primeiro em Go, por isso, se queres um SDK de primeira linha para um grande fornecedor de cloud desde o primeiro dia, a resposta é Go. O Rust já recuperou terreno nas peças que mais importam, mas a vantagem do Go é real e mantém-se.

Casos de estudo reais

A maior parte da conversa na internet gira à volta de um punhado de reescritas em Rust muito mediáticas. O panorama muda quando contas com os sistemas que fazem funcionar grande parte da internet moderna sem chegarem às manchetes.

Onde o Go sustenta a cloud

A stack cloud-native está escrita em Go: Kubernetes, Docker, containerd, etcd, Terraform, Prometheus, Grafana, CockroachDB, InfluxDB, Caddy, Traefik, Hugo, Gitea e Tailscale. O mesmo acontece com os microsserviços por trás de Uber, Twitch, Netflix, Cloudflare, Dropbox, Mercari e Monzo.

Estes projetos escolheram o Go pela velocidade de entrega, pela facilidade de integrar contribuidores, pela concorrência previsível e por um desempenho suficientemente rápido. Lidam todos os dias com tráfego à escala da internet. É a parte aborrecida do panorama, e de longe a maior.

Golang vs Rust: empregos e salários em 2026

Os dados salariais variam muito conforme a fonte. Estes são os números que apareceram de forma consistente no início de 2026.

FonteMédia reportada de Go (EUA)Média reportada de Rust (EUA)Notas sobre a amostra
Salary.com~135.000 USD~140.000 USDMediana nacional para todos os níveis de experiência
Glassdoor~120.000 USD base~120.000 USD baseSalário base reportado para nível intermédio
ZipRecruiter~125.000 USD~135.000 USDCom base em ofertas de emprego abertas
Payscale~117.000 USD~130.000 USDMédias por competência
Jobicy~130.000 USD~147.000 USDAmostra com muito trabalho remoto

Última verificação a 29 de abril de 2026. Considera os intervalos indicativos, não definitivos.

Em conjunto:

  • Os salários de Go ficam aproximadamente entre 120.000 e 135.000 USD.
  • Os salários de Rust ficam aproximadamente entre 110.000 e 147.000 USD. A dispersão é maior porque a amostra é mais pequena.
  • O Rust ainda paga um prémio, mas é mais pequeno do que em 2022 e reflete sobretudo escassez, não engenheiros mais produtivos.

A procura importa mais do que o salário. As ofertas de emprego em Go superam as de Rust de forma consistente e por larga margem em todos os grandes portais, e quase todas as empresas cloud-native, de fintech e de ferramentas de infraestrutura usam Go em produção.

Quanto à opinião dos programadores, o 2025 Stack Overflow Developer Survey coloca o Rust perto do topo dos «mais admirados» e o Go na parte superior da tabela. As duas linguagens têm utilizadores satisfeitos, mas o Go tem um mercado de recrutamento muito maior.

Se estás a escolher o que aprender, o Go é a melhor primeira aposta para quase toda a gente. O mercado de trabalho é muito maior, ficas empregável mais cedo e trabalhas diretamente com a stack cloud-native dominante. O curso Go Fundamentals da LevelUpGo é um bom sítio para começar.

Quando usar Go vs Rust: guia de decisão

Escolhe Go quando (isto cobre a maior parte do trabalho de backend):

  • Estás a construir um serviço CRUD, uma API ou um microsserviço.
  • Estás a construir um plano de controlo, uma CLI ou uma ferramenta para programadores.
  • A tua equipa é pequena, tem experiência mista ou está a recrutar depressa.
  • O tempo até chegar ao mercado importa, nem que seja um pouco.
  • Entregas muitos serviços e valorizas iterar depressa.
  • Queres ferramentas de primeira linha para Kubernetes, SDKs de cloud, gRPC ou operators.
  • Precisas de concorrência sólida sem transformar o sistema de tipos async num projeto à parte.
  • O teu orçamento de desempenho tem folga medida em milissegundos. (Quase sempre tem.)

Escolhe Rust quando (um conjunto mais pequeno e específico de casos):

  • Uma latência de cauda previsível abaixo dos 10 ms é um requisito obrigatório (proxies, trading, sistemas de tempo real).
  • A pegada de memória tem de ser mínima (edge workers, sistemas embebidos, sidecars densos).
  • Estás a escrever um motor de base de dados, um runtime, um compilador, um hipervisor ou um componente de kernel.
  • O trabalho é computação pesada limitada por CPU (codecs, criptografia, parsers, inferência de ML).
  • Podes suportar uma adaptação mais longa e tens engenheiros seniores para orientar a equipa nesse processo.

Usa os dois quando operas a grande escala

Um padrão comum em 2026 é Go para serviços aplicacionais e planos de controlo, com o Rust reservado para componentes do plano de dados no caminho crítico. Os dois interoperam sem problemas através de gRPC, filas de mensagens partilhadas ou FFI, quando é preciso.

Perguntar que linguagem ganha não te ajuda muito. Pergunta de que precisa este serviço em concreto e que linguagem te leva lá com o menor custo total ao longo de cinco anos. Para a grande maioria dos serviços de backend, essa linguagem é o Go.

Perguntas frequentes

O Rust é mais rápido do que o Go?

Em microbenchmarks apertados e limitados por CPU, o Rust é muitas vezes ligeiramente mais rápido, com diferenças que vão de poucos por cento até 2x em ciclos numéricos. Em serviços de backend reais que esperam por bases de dados e pela rede, a diferença costuma desaparecer, e o Go é suficientemente rápido para que o runtime raramente seja o que te limita.

Devo aprender Go ou Rust em 2026?

Aprende Go. O mercado de trabalho é muito maior, a linguagem é pequena o suficiente para seres produtivo numa semana e a stack cloud-native assenta nela (Kubernetes, Docker, Terraform, Prometheus, todos os grandes SDKs de cloud). O Rust é uma boa segunda linguagem para mais tarde, se quiseres fazer trabalho ao nível de sistemas.

Go ou Rust: qual é melhor para desenvolvimento backend?

Go. É a escolha certa por omissão para quase todo o trabalho de backend em 2026, o que inclui serviços CRUD, microsserviços, planos de controlo e APIs. O Rust só é a melhor escolha para um conjunto restrito de cargas de trabalho ao nível de sistemas, onde a latência determinística ou pegadas de memória mínimas fazem diferença.

Porque é que a Discord mudou de Go para Rust?

A Discord reescreveu um serviço específico, o Read States, porque o GC do Go provocava picos de latência ao percorrer uma cache em memória muito grande, com milhões de entradas. A reescrita acabou com esses picos. A maior parte do backend da Discord continua a ser Go, e os engenheiros da Discord dizem-no no artigo original.

O Rust está a substituir o Go?

Não. O Rust está a substituir o C e o C++ em trabalho de sistemas crítico para o desempenho, como proxies e hipervisores. O Go continua a dominar a infraestrutura cloud-native, os microsserviços de backend e as ferramentas para programadores, e as ofertas de emprego, a atividade open source e a amplitude do ecossistema mostram a sua presença a crescer.

É possível usar Go e Rust em conjunto?

Sim. A maioria das grandes organizações que usam os dois corre Go nos serviços aplicacionais e Rust nos componentes do plano de dados no caminho crítico, ligados através de gRPC, filas de mensagens partilhadas ou FFI. Pôr a fronteira num protocolo de comunicação estável costuma ser mais fácil do que embutir um runtime dentro do outro.

Qual tem mais ofertas de emprego, Go ou Rust?

Go, por larga margem. Quase todas as empresas cloud-native, de fintech e de ferramentas de infraestrutura usam Go em produção. As vagas de Rust concentram-se em programação de sistemas, blockchain e num punhado de empresas muito conhecidas, como a AWS, a Cloudflare e a Discord.

O Go é mais fácil de aprender do que o Rust?

Sim, muito mais fácil. O Go tem 25 palavras-chave, uma biblioteca padrão pequena e uma cultura de «uma forma óbvia», e a maioria dos engenheiros já contribui de forma produtiva na primeira semana. O Rust obriga-te a aprender o borrow checker, lifetimes, trait bounds e a semântica async antes de conseguires construir algo não trivial.

Fontes

Fontes primárias citadas neste artigo (última verificação a 29 de abril de 2026):

Continua a aprender

Se optaste pelo Go, o curso Go Fundamentals da LevelUpGo leva-te de package main até um serviço pronto para produção, com lições interativas que compilam e correm no navegador com a toolchain de Go mais recente.

Quando a concorrência começar a importar, o curso Go Concurrency Fundamentals cobre goroutines, channels, select e o cancelamento com context. O Go Generics Masterclass trata de parâmetros de tipo e restrições quando precisares deles.

Para trabalho de portefólio, o capstone e os cursos de projeto põem-te a construir serviços completos:

Para ler mais: Qual é a melhor linguagem de programação para backend?, 10 erros comuns em Go a evitar e Novidades do Go 1.26.

Escreve Go como um engenheiro sénior

Lições interativas no navegador. As primeiras são grátis.

Experimenta uma lição grátisOu cria uma conta gratuita