Val la pena aprendre Go el 2026?

Fa un parell d’anys em vaig fer la mateixa pregunta que probablement t’ha portat aquí: val la pena aprendre Go? Venia d’anys treballant amb Kotlin i Python, amb incursions a Java i una mica de Node. Tenia un stack estable, projectes funcionant, i cap necessitat urgent d’afegir un altre llenguatge. Però Go feia temps que apareixia en ofertes de feina que m’interessaven, en eines que feia servir cada dia (Docker, Kubernetes, Terraform) i en converses tècniques que no podia ignorar. Així que vaig posar-me a aprendre’l. I el que vaig trobar era bastant diferent del que esperava.

No et vendré Go com el llenguatge perfecte. No ho és. Però sí que t’explicaré amb honestedat quan té sentit invertir temps a aprendre’l i quan estàs millor amb el que ja tens.

El que Go ofereix i altres llenguatges no

Cada llenguatge té la seva proposta de valor. La de Go no és ser el més expressiu, ni el més flexible, ni el que té més features. I crec que aquí és on molta gent es confon quan l’avalua. La proposta de Go és una altra: fer poques coses, però fer-les extremadament bé.

Simplicitat real, no simplicitat de màrqueting

Quan dic simplicitat no em refereixo que sigui fàcil d’aprendre en el sentit de Python. Em refereixo que Go té molt poques maneres de fer la mateixa cosa. No hi ha herència, no hi ha excepcions, no hi ha generics complexos (els que hi ha van arribar en 1.18 i són deliberadament limitats), no hi ha decoradors, no hi ha màgia de reflexió amagada.

Això té una conseqüència directa: llegeixes codi Go d’una altra persona i l’entens. No necessites conèixer dotze patrons de disseny ni saber quin framework s’ha usat per entendre què fa una funció. El codi és explícit, lineal, quasi avorrit. I sent honestos, al principi em semblava una limitació. Però després de mantenir codi d’altres en producció, vaig començar a veure-ho com un avantatge brutal.

Go no intenta ser elegant. Intenta ser clar. I quan portes mesos mantenint codi d’altres, agraïm aquesta decisió de disseny.

Compilació ràpida i binari únic

Go compila en segons. No minuts, no “una estona mentre et prens un cafè”. Segons. I el resultat és un binari estàtic que pots copiar a qualsevol màquina i executar sense dependències. Sense JVM, sense intèrpret, sense virtualenv, sense node_modules.

Això sembla menor fins que ho compares amb el teu flux de treball actual. En projectes Spring Boot, un rebuild pot portar 30-60 segons. A Python, un pip install mal resolt et pot arruïnar la tarda. A Go, compiles, copies el binari, executes. Fi. El primer cop que ho vaig experimentar vaig pensar que alguna cosa havia anat malament, que no podia haver acabat tan ràpid.

Concurrència com a ciutadà de primera classe

Les goroutines i els channels són la feature estrella de Go, i amb raó. Llençar milers de tasques concurrents és trivial: go laFuncio(). No necessites thread pools, ni executors, ni async/await, ni callbacks. El runtime de Go gestiona les goroutines sobre un nombre petit de threads del sistema operatiu, i el model de comunicació per channels fa que compartir dades sigui segur sense locks explícits.

Si has treballat amb concurrència a Java (pre-virtual threads) o Python (GIL), la diferència és abismal. Go fa que la concurrència sigui alguna cosa que uses cada dia sense pensar-ho dues vegades, no alguna cosa que reserves per a casos complexos. Però compte: que sigui fàcil llençar goroutines no significa que sigui fàcil fer concurrència bé. Les race conditions segueixen existint, simplement la barrera d’entrada per començar a usar-la és molt més baixa.

Desplegament sense friccions

Compiles per a Linux des del teu Mac amb una línia: GOOS=linux GOARCH=amd64 go build -o app. Puges aquell binari a un contenidor scratch de 10 MB. No necessites imatge base amb JDK, ni Python, ni Node. El teu Dockerfile té tres línies.

En el món de microserveis i cloud, això no és un detall menor. És un avantatge operatiu real que es tradueix en imatges més petites, arrancades més ràpides i menys superfície d’atac. Però aquí ve la pregunta que no sempre ens fem: quants de nosaltres estem realment limitats per la mida de les nostres imatges Docker? Si la resposta és “no gaires”, l’avantatge segueix sent real però el pes que li donis depèn del teu context.

El mercat laboral: demanda de Go el 2026

Però deixem les features tècniques i parlem d’alguna cosa que a la majoria ens importa més del que admetem: el mercat. Siguem concrets, perquè aquí és on molts articles es perden en generalitats.

On és la demanda

Go no és el llenguatge amb més ofertes de feina en termes absoluts. Això segueix sent Java, Python i JavaScript. Però Go té una demanda creixent i molt concentrada en sectors que paguen bé:

• Cloud-native i infraestructura: Kubernetes, Docker, Terraform, Prometheus, Grafana, etcd. Tot està escrit en Go. Si vols contribuir o treballar en aquest ecosistema, Go és un requisit.
• Backend d’alt rendiment: APIs que necessiten gestionar milers de requests per segon amb baixa latència. Fintech, adtech, plataformes de streaming.
• DevOps i SRE: Eines internes, CLIs, automatització d’infraestructura. Go és el llenguatge de facto per a tooling en aquest espai.
• Startups tècniques: Moltes startups trien Go per al seu backend perquè els permet moure’s ràpid amb equips petits i desplegar amb poca infraestructura.

Els números que importen

L’enquesta de Stack Overflow de 2025 situa Go consistentment entre els llenguatges més estimats i millor pagats. En mercats com els EUA o Europa occidental, els salaris de desenvolupadors Go senior estan a la par o per sobre dels de Java o Python. Encara que convé prendre aquestes dades amb una mica de perspectiva: el perfil que busca Go sol ser ja de per si més senior, cosa que infla la mitjana salarial.

Però compte: Go no és un llenguatge generalista quant a mercat. No trobaràs ofertes de Go per fer frontends, ni per a data science, ni per a desenvolupament mòbil. La demanda està concentrada, i això pot ser un avantatge (menys competència, rols més especialitzats) o un problema (menys opcions si la teva zona geogràfica té poques empreses cloud-native).

Si el teu objectiu és treballar en infraestructura, cloud o backend d’alt rendiment, Go t’obre portes que altres llenguatges no. Si el teu objectiu és el generalisme o la flexibilitat màxima, probablement Python o TypeScript et donin més opcions.

Quan Go té sentit

Llavors la pregunta ja no és “Go és bo?” sinó “Go és bo per al que jo faig?”. No tot projecte necessita Go. Però hi ha escenaris on és una elecció excel·lent.

Microserveis i APIs REST/gRPC

Go brilla aquí. La biblioteca estàndard ja inclou un servidor HTTP potent (net/http), i frameworks com Gin o Echo afegeixen just el necessari sense convertir-se en monstres de configuració. El rendiment out-of-the-box és molt alt, i el consum de memòria és baix.

Si vens de Spring Boot o Django, la diferència en footprint és notable. Un microservei Go arrenca en mil·lisegons, consumeix 10-20 MB de RAM i serveix milers de requests per segon sense tuning especial.

CLIs i eines de línia de comandes

Go és, crec, el millor llenguatge que existeix avui per crear CLIs. O almenys el més pràctic. El binari únic elimina el problema de distribució, la llibreria cobra és un estàndard de facto, i el rendiment és instantani. Sense warm-up, sense intèrpret.

Kubectl, Hugo, Terraform, gh (el CLI de GitHub)… tots estan escrits en Go. No és casualitat.

Cloud-native i Kubernetes

Si vols treballar en l’ecosistema Kubernetes, escriure operadors, crear controladors custom o contribuir a projectes cloud-native, Go és el llenguatge. No és una opinió: és un fet. El client-go, la SDK d’operadors, els CRDs, tot l’ecosistema assumeix que treballes en Go.

Sistemes amb alta concurrència

Processament d’esdeveniments en temps real, workers que consumeixen cues, pipelines de dades, proxies reversos. Qualsevol cosa on necessitis gestionar moltes connexions o tasques simultànies és terreny natural de Go.

Quan Go NO té sentit

I aquí és on molts articles pro-Go callen. Però crec que ser honest amb les limitacions és més útil que vendre fum.

Data science i machine learning

Si el teu món és pandas, scikit-learn, PyTorch o TensorFlow, no miris cap a Go. L’ecosistema de ML en Go és testimonial. Existeixen llibreries, sí, però no tenen ni la maduresa, ni la comunitat, ni les integracions de Python. Per a data science, Python no té rival real, i Go no aspira a ser-ho.

Modelatge de domini complex

Go no té classes, no té herència, no té tipus algebraics rics. Si el teu projecte requereix un domain model sofisticat amb jerarquies complexes de tipus, Go es queda curt. Pots modelar coses amb interfaces i structs, però l’expressivitat és limitada comparada amb Kotlin, Scala o fins i tot Java modern amb sealed classes i records.

Si vens de DDD (Domain-Driven Design) amb Kotlin o Java, sentiràs que Go t’obliga a pensar diferent. No necessàriament pitjor --- i de fet hi ha qui argumenta que és més honest, que et força a no amagar complexitat darrere de jerarquies de tipus --- però sí diferent i amb menys eines per expressar restriccions de domini en el tipus de dada.

Frontend i aplicacions d’escriptori

Go no és un llenguatge frontend. Existeix suport Wasm i projectes experimentals, però no és el seu terreny. Si necessites UI, mira cap a un altre lloc.

Quan el teu equip ja domina una altra cosa

Això és pragmatisme pur, i potser el punt més important d’aquesta secció. Si tens un equip sènior de Java/Kotlin amb anys d’experiència, un ecosistema Spring madur i tot funciona, introduir Go té un cost d’adopció real. Go és fàcil d’aprendre, sí, però la productivitat màxima requereix temps. I canviar de stack sense una raó tècnica sòlida és una decisió que has de justificar bé. Ho dic perquè he vist equips fer aquest canvi per moda, i el resultat no sempre és el que esperaven.

Maduresa de l’ecosistema Go

Passem a l’ecosistema, perquè hi ha una pregunta legítima que molta gent es fa abans d’invertir temps: té Go prou llibreries i eines per fer coses serioses?

La biblioteca estàndard

La stdlib de Go és una de les més completes que existeixen. HTTP server i client, JSON encoding, crypto, testing, benchmarking, profiling, templates… moltes coses que en altres llenguatges necessiten dependències externes, en Go estan incloses i són de qualitat producció.

Això té un efecte col·lateral positiu: els projectes Go tendeixen a tenir menys dependències. Menys coses a actualitzar, menys risc d’atacs a la cadena de subministrament, menys incompatibilitats.

Llibreries de tercers

L’ecosistema ha madurat molt. Per a les necessitats habituals de backend hi ha opcions sòlides i estables:

• HTTP: Gin, Echo, Chi, Fiber
• ORM / SQL: sqlx, GORM, ent
• Testing: testify, gomock
• Logging: zerolog, zap
• Configuració: Viper
• CLI: Cobra
• gRPC: grpc-go (suport oficial de Google)
• Missatgeria: sarama (Kafka), amqp

Hi ha menys opcions que a Java o Python? Sí. Falten coses? Per al 90% de casos d’ús backend, no.

Tooling

Aquí Go destaca especialment. El tooling oficial és excel·lent:

• go fmt: formata el codi amb un estil únic. Sense debats de format.
• go vet: anàlisi estàtica bàsica.
• go test: testing i benchmarking integrats.
• go mod: gestió de dependències que simplement funciona.
• go generate: generació de codi.
• gopls: LSP server per a editors.

No necessites Maven, ni Gradle, ni pip, ni npm. Tot ve amb el llenguatge. Compiles, testes, formates i gestiones dependències amb el mateix binari.

El tooling de Go és un argument infravalorat. No te n’adones del còmode que és fins que tornes a barallar-te amb un build system de Java o un requirements.txt trencat.

Go comparat amb les alternatives

No faré aquí una comparativa exhaustiva perquè ja tinc articles específics per a això:

• Go vs Python: Python guanya en versatilitat i ecosistema ML. Go guanya en rendiment, concurrència i desplegament.
• Go vs Java: Java té un ecosistema enterprise més madur. Go té menys cerimònia, compila més ràpid i consumeix menys recursos.

La versió resumida:

El que jo diria és: Go no reemplaça Python ni Java. Complementa. En el meu cas, segueixo usant Kotlin per a projectes enterprise amb Spring, Python per a automatitzacions i dades, i Go per a serveis on el rendiment i la simplicitat operativa importen més que l’expressivitat del llenguatge.

L’argument de la simplicitat

Aquest punt mereix la seva pròpia secció perquè és el més controvertit i el més malinterpretat. I sent honestos, part de la crítica és justa.

Go rep crítiques constants per allò que li falta: no té excepcions (usa if err != nil), no té herència, els generics són limitats, no hi ha enums de veritat, no hi ha pattern matching. I tot això és cert. No hi ha manera de maquillar-ho.

Però la tesi de Go és que menys features implica codi més mantenible. I després de treballar amb Go en producció, he de dir que hi ha veritat en això. No tota la veritat --- de vegades l’absència de features t’obliga a escriure codi tediós que un bon sistema de tipus evitaria --- però sí la suficient perquè valgui la pena pensar-hi.

Menys màgia, menys sorpreses

En un projecte Spring Boot gran, pots passar hores entenent què fa una anotació, quin interceptor s’executa abans del teu controller, o per què un bean no s’injecta com esperes. A Go, el flux és lineal. Si una funció necessita alguna cosa, la rep com a paràmetre. Si alguna cosa falla, retorna un error que gestiones explícitament. Sense màgia.

Tot l’equip escriu igual

go fmt formata tot el codi de la mateixa manera. Sense debats sobre tabs vs espais, ni sobre on posar les claus. Però més enllà del format, la pròpia simplicitat del llenguatge fa que dos desenvolupadors escriguin solucions molt similars al mateix problema. Això redueix la fricció en code reviews i facilita l’onboarding.

El cost del if err != nil

Sí, és verbose. Sí, escrius més línies per gestionar errors que a Kotlin o Python. Però aquest cost té una contrapartida: sempre saps on es gestiona cada error. Sense excepcions que bubugen tres nivells sense que ningú les capturi. Sense panics silenciosos (o no n’hi hauria d’haver). El maneig d’errors és explícit i visible.

És tediós? De vegades, bastant. És millor que un try-catch genèric que empassa errors? Crec que sí, encara que entenc perfectament a qui discrepi.

La simplicitat de Go no és manca d’ambició. És una decisió de disseny que prioritza la lectura sobre l’escriptura, l’equip sobre l’individu, i la producció sobre el prototip.

Com començar si decideixes que sí

Si després de tot això decideixes que Go mereix el teu temps --- i no passa res si decideixes que no --- aquí va el camí que a mi em va funcionar:

1. Comença per les bases: el Tour of Go oficial és excel·lent. Aprendre Go des de zero si vols una guia més estructurada.
2. Fes un projecte real com més aviat millor: una CLI, una API REST, un worker. No et quedis en exercicis de sintaxi.
3. Llegeix codi Go de projectes reals: Docker, Kubernetes, Hugo. Veure com s’estructura un projecte real t’ensenya més que qualsevol tutorial.
4. No intentis escriure Go com si fos Java o Python. Go té els seus propis patrons i convencions. Si llueites contra ells, patiràs.

L’eina que no sabia que necessitava

Val la pena aprendre Go el 2026? Depèn de la teva situació, però seré directe. Si treballes o vols treballar en backend d’alt rendiment, infraestructura o cloud-native, sí. Si values la simplicitat operativa de compilar, desplegar i mantenir amb mínima fricció, també. I si t’interessa l’ecosistema Kubernetes/Docker/cloud, Go és quasi obligatori. En canvi, si el teu focus és data science, necessites modelatge de domini molt expressiu, o el teu equip ja lliura bé amb el seu stack actual, no hi ha raó per forçar el canvi.

Go no és el llenguatge que promet més coses. No té l’expressivitat de Kotlin, ni la versatilitat de Python, ni l’ecosistema enterprise de Java. Però és un dels llenguatges que menys soroll posa entre la idea i el desplegament. Escrius, compiles, desplegues. I el que desplegues arrenca ràpid, consumeix poc i es manté bé.

Per a mi, aprendre Go no va reemplaçar Kotlin ni Python. Va afegir una eina que faig servir quan les altres no encaixen. I això, venint d’algú que no necessitava un altre llenguatge, diu bastant.