Het korte antwoord
Voor een backend die je met AI bouwt en die jaren moet blijven draaien, kiezen wij Go. Go is een gecompileerde taal met strenge types: de compiler weigert code die niet klopt, nog voordat die ooit draait. Als een model het meeste schrijfwerk doet, is dat de eigenschap die het zwaarst weegt.
Node.js blijft een goede keuze als je team al volledig in TypeScript werkt en de backend vooral data doorgeeft aan een frontend. Voor de rest is Go onze standaard. Elk nieuw project begint bij ons op dezelfde basis: een Go-backend, een React-frontend en PostgreSQL als database.
Het verschil in één oogopslag
| Node.js | Go | |
|---|---|---|
| Types | Optioneel via TypeScript, en bij het draaien weer verdwenen. | Verplicht, en gecontroleerd voordat het programma bestaat. |
| Wanneer een fout opvalt | Vaak pas als die ene regel draait, soms in productie. | Bij het compileren, binnen een paar seconden. |
| Foutafhandeling | Exceptions die je kunt vergeten op te vangen. | Elke fout is een waarde die je zichtbaar moet afhandelen. |
| Afhankelijkheden | Een node_modules-map met honderden pakketten. | Een sterke standaardbibliotheek en weinig externe pakketten. |
| Uitrollen | Runtime plus pakketten in de container. | Eén zelfstandig bestand, klein en snel opgestart. |
| Hoeveel het model ervan heeft gezien | Enorm veel, verspreid over vele frameworks en stijlen. | Minder, maar in één stijl die al tien jaar nauwelijks verandert. |
Waarom AI de taalkeuze verandert
Zolang mensen alle code typten, ging de vergelijking over hoe prettig een taal schrijft en hoe snel hij draait. Met AI is typen goedkoop geworden. Wat duur blijft is controleren of het klopt. Een model schrijft in een minuut honderd regels die er goed uitzien, en de vraag wordt hoeveel fouten daarvan er doorheen glippen.
Daar maakt de taal een groot verschil. In Go is de compiler een reviewer die nooit moe wordt en elke regel leest. Een verkeerd type, een functie die niet bestaat, een variabele die nergens gebruikt wordt, een import die er niet hoort: Go weigert te bouwen tot het klopt. Eén opmaakstijl via gofmt, dus elk bestand ziet er hetzelfde uit, wie of wat het ook schreef.
Een AI-agent die in Go werkt, krijgt zijn eigen fouten binnen seconden terug van de compiler. Die fixt hij zelf, nog voordat een mens de code onder ogen krijgt.
Dat is de lus waar het om draait. De agent schrijft code, draait go build, go vet en de tests, leest de foutmeldingen en past het aan. Alles wat de compiler vangt, hoeft een mens niet meer te vangen. De review gaat dan over de vragen die ertoe doen: doet dit wat er gevraagd is, en is het veilig.
Is TypeScript dan niet net zo goed?
TypeScript in strikte modus dicht een groot deel van het gat, en daarom bouwen we onze frontends er ook in. Op de backend blijven er drie lekken over die er met AI toe doen.
De types verdwijnen bij het draaien
TypeScript wordt omgezet naar JavaScript, en daarna controleert niemand meer of de data uit een API of database echt de vorm heeft die je beloofde. Een model gaat daar graag van uit.
Er is altijd een nooduitgang
Met any, as unknown as of een ts-ignore-commentaar maak je elke typefout stil. Een model dat vastloopt, kiest die uitweg sneller dan je zou willen, en de code bouwt gewoon.
Vergeten fouten blijven onzichtbaar
Een exception die niemand opvangt valt pas op als hij optreedt. In Go geeft elke functie die kan falen een fout terug, en code die die fout negeert zie je in de review meteen staan.
Het nadeel: modellen kennen minder Go
Er is minder Go-code op internet dan JavaScript of Python, dus modellen hebben er minder van gezien. Dat merk je soms: een model grijpt naar een verouderd patroon, of verzint een functie uit een bibliotheek die net anders heet.
In de praktijk weegt dat lichter dan je zou denken, om twee redenen. Go is een kleine taal die bewust weinig verandert, en code van tien jaar geleden compileert vandaag meestal nog gewoon. Wat het model heeft gezien, is dus grotendeels nog geldig en in één herkenbare stijl geschreven. En een verzonnen functie komt in Go nooit verder dan de compiler. In JavaScript is de berg trainingsdata groter, maar verspreid over CommonJS en ES-modules, Express en NestJS, callbacks en async. Meer voorbeelden betekent daar ook meer manieren om het net anders te doen.
Snelheid en uitrol
Go compileert naar één zelfstandig bestand. Geen runtime om te installeren, geen map met pakketten om mee te leveren, een kleine container die in een fractie van een seconde opstart. Met goroutines verwerkt een Go-dienst duizenden gelijktijdige verbindingen zonder dat je er een apart framework voor nodig hebt.
Node.js is ook snel voor het meeste webwerk, zeker voor API’s die vooral wachten op een database. Het verschil wordt groot bij rekenwerk en bij veel gelijktijdige verbindingen, waar Node.js standaard op één thread draait en Go alle processorkernen benut. Voor de meeste bedrijfssoftware is de winst in snelheid mooi meegenomen. De winst in betrouwbaarheid is de reden.
Zo bouwen wij met Go
Elk project begint bij ons vanuit hetzelfde sjabloon, en dat is met opzet zo opgezet dat een AI-agent er goed in kan werken. Growthdesk, ons eigen platform, draait op precies dezelfde opbouw.
Vaste lagen met één taak
Een verzoek gaat van de route naar een controller, naar een service met alle bedrijfsregels, naar een repository en dan de database. Elke laag doet één ding, dus een model weet altijd waar nieuwe code hoort.
SQL met hand geschreven, Go-code gegenereerd
Queries schrijven we als gewone SQL. sqlc maakt daar getypte Go-functies van, dus een kolom die niet bestaat is een compileerfout in plaats van een storing om drie uur 's nachts.
Rechten bovenaan elke functie
Wie iets mag, staat op één vaste plek bovenaan elke servicefunctie, met een regel commentaar erbij. Een reviewer ziet in één oogopslag of een nieuwe functie beschermd is.
Tests tegen een echte database
Tests draaien tegen een echte PostgreSQL in Docker, met nep-gebruikers in plaats van een nep-database. Wat groen is in de test, werkt ook echt.
Eén voorbeeld door alle lagen heen
Het sjabloon bevat één voorbeeldonderdeel dat door elke laag loopt, van migratie tot scherm. Een agent kopieert dat patroon voor het eerste echte onderdeel, en de instructies in de repo vertellen hem de rest.
Daaromheen staan een React-frontend, inloggen via Zitadel en foutmeldingen die in Sentry terechtkomen. De agent werkt vanuit een geschreven spec, zoals we beschreven in spec-driven development vs vibe coding, en binnen een harnas van regels en controles, zoals in harness engineering. Go is de laatste schakel in die keten: wat door de spec en het harnas heen glipt, houdt de compiler tegen.
Wanneer Node.js wel de betere keuze is
Je team schrijft alleen TypeScript
Als jullie de software zelf gaan onderhouden en niemand Go kent, is een Go-backend een last. De beste taal is er een die je team over twee jaar nog kan lezen.
De backend is dun
Een paar routes die data van een database of een andere dienst doorgeven aan een Next.js-frontend vragen geen aparte taal. Houd het dan in één codebase.
Je bouwt een prototype
Om te ontdekken of een idee iets waard is, wint de taal waarin het model het snelst iets laat zien. Begint het prototype echte gebruikers te krijgen, dan is dat het moment om opnieuw te kiezen.
Gaat het om data-analyse of AI-modellen, dan kijken we naar Python, omdat daar de bibliotheken voor bestaan. Hoe we die afweging per project maken, lees je bij backend development.
Conclusie: kies de taal die fouten vroeg vangt
Met AI verschuift het werk van schrijven naar controleren. Een taal die fouten vangt voordat de code draait, maakt dat controleren goedkoper, en dat weegt zwaarder dan de iets kleinere hoeveelheid Go in de trainingsdata van een model.
Node.js = één taal van voor tot achter
Sterk als je team al in TypeScript leeft en de backend dun blijft. Reken wel op meer controlewerk bij elke regel die een model schrijft.
Go = de compiler leest mee
Strenge types, zichtbare foutafhandeling en één zelfstandig bestand. Daarom is het onze standaard voor software die jaren moet draaien.
Is Go beter dan Node.js voor een backend?
Is Go sneller dan Node.js?
Waarom is Go geschikt voor code die AI schrijft?
Kennen AI-modellen Go wel goed genoeg?
Is TypeScript niet net zo veilig als Go?
Welke stack gebruikt 010 Coding Collective?
Een backend laten bouwen die jaren meegaat?
We bouwen met AI op een vaste Go-basis, met een mens die elke regel checkt voordat die live gaat.
