golang: Go en Rust

Je staat op het punt een nieuwe service te schrijven en iemand vraagt waarom niet in Go, en iemand anders zegt dat het Rust moet zijn, en je hebt zelf nog geen regel code getypt.

Beide talen zijn gemaakt om hetzelfde probleem op te lossen: C en C++ laten je te veel fouten maken die pas tijdens runtime opduiken, en de bestaande talen met garbage collector zijn te langzaam of te onvoorspelbaar voor systeemwerk. Go en Rust pakken dat probleem aan, maar ze zijn het fundamenteel oneens over hoe.

Go komt uit een klein team bij Google. Robert Griesemer, Rob Pike en Ken Thompson begonnen er in 2007 aan, en dat drietal vertelt je meteen veel over de bedoeling. Thompson schreef Unix en de B-taal, Pike zat aan Plan 9 en UTF-8, en hun conclusie was dat de industrie te veel tijd kwijt was aan compileren en aan het lezen van andermans slimme code. Hun antwoord was een taal met weinig features.

In januari 2008 bouwde Thompson de eerste compiler. In mei 2008 begon Ian Taylor, buiten het kernteam, aan een front-end voor Go binnen GCC. Russ Cox sloot zich eind 2008 aan. Op 10 november 2009 ging Go open source, en op 28 maart 2012 kwam Go 1: vanaf dat punt belooft de taal achterwaartse compatibiliteit. Code die je vandaag tegen Go 1.22 compileert, blijft over tien jaar werken.

Rust begon eerder dan de meeste mensen denken. Versie 0.1.0 verscheen op 20 januari 2012, de stabiele 1.0.0 pas op 15 mei 2015. Drie jaar tussen eerste release en stabiliteit zegt iets over hoeveel er nog moest veranderen. Het project is community-gedreven, met Mozilla jarenlang als belangrijkste geldschieter, en die afkomst zie je terug in hoe beslissingen worden genomen: via RFC's, open discussie, en een proces dat traag is omdat iedereen mag meepraten.

Het echte verschil zit in het geheugen.

Go heeft een garbage collector. Je maakt een object, je gebruikt het, en op een moment dat jij niet kiest ruimt de runtime het op. Dat is makkelijk. Je hoeft niet na te denken over wie wat bezit, en je kunt een middag leren en dan productieve code schrijven. De prijs is dat de garbage collector af en toe werk doet terwijl jouw programma wil rekenen. Voor de meeste services merk je daar niets van. Voor een trading systeem met een latency budget in microseconden is het een probleem dat je niet wegpoetst.

Rust heeft geen garbage collector. In plaats daarvan moet je bij het compileren bewijzen dat je geheugen klopt, via ownership, borrowing en lifetimes. Elk object heeft één eigenaar, je kunt referenties uitlenen, en de compiler weigert te bouwen als je iets doet dat later fout kan gaan. Dat betekent dat een hele categorie bugs — use-after-free, double free, dataraces — niet in je productie terechtkomt, want ze halen de build niet.

De prijs daarvan is dat je soms een uur bezig bent met een functie die in Go in tien minuten stond. De compiler is niet gemeen, maar hij is wel grondig, en grondig voelt in het begin als tegengewerkt worden. Reken op weken voor je productief bent in Rust, tegen dagen in Go.

Dat verschil in leercuveau is geen detail, het is de hele afweging. Een team van vijf mensen dat volgende maand iets moet opleveren, kan zich geen Rust veroorloven tenzij ze het al kennen. Een team dat een netwerkdaemon schrijft die tien jaar moet meegaan en waarvan een geheugenbug een outage betekent, kan zich Go misschien niet veroorloven.

Hoe ze met gelijktijdigheid omgaan, verschilt net zo scherp. Go heeft goroutines en channels: lichtgewicht threads die je met een paar tekens start, en kanalen om data tussen hen te sturen. Het model is bewust simpel gehouden, en de scheduler verdeelt goroutines over de beschikbare cores. Je schrijft concurrent code alsof het sequentiële code is, en meestal werkt dat.

Rust geeft je geen runtime die dit voor je regelt. Je kiest zelf: threads uit de standard library, of async met een runtime zoals Tokio. De compiler controleert vervolgens of je geen data deelt op een manier die een datarace oplevert. Dat is strenger dan Go, en het betekent ook dat je zelf moet nadenken over wat je runtime kost. Tokio is geen gratis laag.

Waar je de talen in het wild tegenkomt, volgt die scheidslijn. Docker, Kubernetes, Prometheus, Terraform: allemaal Go. Ze zijn geschreven door teams die snel iets werkends wilden hebben, en de prestaties waren goed genoeg. Rust zit in de Servo-engine, in delen van de Linux-kernel, in laag-niveau netwerktools, en in steeds meer tooling waar C vroeger stond. Het patroon is niet toeval: Go voor orchestration en services, Rust voor de laag eronder.

Dat betekent niet dat Go niet laag kan, of Rust niet hoog. Het betekent dat de standaardkeuze per laag verschilt, en dat je daar met een reden van afwijkt.

Wat je ook moet wegen: hoe de taal evolueert. Go wordt geleid door Google, met een klein team dat de richting bepaalt. Dat gaat snel en voorspelbaar, en het betekent ook dat als Google iets anders belangrijk vindt dan jij, jouw wens niet wint. De taal is open source, de besluitvorming is dat niet helemaal.

Rust heeft een open governance model met werkgroepen en een jaarlijkse editie. Dat is trager en rommeliger, maar niemand kan in zijn eentje beslissen dat jouw use case niet belangrijk is. Voor bedrijven die een decennium vooruit kijken, weegt dat soms zwaarder dan een feature die een half jaar eerder klaar is.

Er is ook de vraag wat je team al kent. Een team dat Python en JavaScript schrijft, stapt makkelijker over naar Go. De syntax is klein, de tooling zit ingebouwd, en `go build` levert één binary zonder afhankelijkheden. Een team dat C of C++ doet, herkent in Rust de controle die het miste, en heeft minder moeite met de strengheid omdat het de problemen kent die de compiler voorkomt.

Beide talen hebben een goede toolchain, en dat is geen toeval: beide zijn gemaakt door mensen die genoeg hadden van Makefiles en externe build-systemen. `go test`, `go fmt`, `go mod` zitten er standaard in. Rust heeft `cargo`, en dat is inmiddels de maatstaf waar andere ecosystems zich aan meten. Bij beide talen is de eerste dag geen gevecht met de tooling.

Wat de compiler betreft: Go compileert snel, ook bij grote codebases. Dat is een expliciet doel van het ontwerp, en het is de reden dat je bij Go zelden zit te wachten. Rust compileert trager, en bij grote projecten met veel generics kan dat oplopen tot minuten per build. Incrementeel compileren helpt, maar het is geen wedstrijd die Rust wint.

Er is geen taal die je hier moet kiezen omdat hij objectief beter is. Er is een taal die past bij hoeveel tijd je hebt, hoe goed je team is, hoe streng je moet zijn op geheugen, en hoe lang het moet blijven werken.

Als je een service bouwt die volgend kwartaal live moet, en je team kent geen van beide: Go is dan de realistische keuze, en de garbage collector is een probleem dat je waarschijnlijk nooit zult tegenkomen. Als je iets bouwt waar een geheugenbug een beveiligingsincident is, of waar latency voorspelbaar moet zijn tot op de microseconde, dan betaal je de weken leertijd voor Rust en ben je daarna blij dat de compiler je tegenhoudt.

En als je het niet zeker weet: begin met Go, en kijk of je ooit tegen de grens aanloopt. De meeste projecten doen dat niet. De projecten die het wel doen, weten meestal precies waarom.