Da jeg først hørte om Go, Googles helt eget programmeringssprog, var jeg fascineret. Go, også kendt som Golang, blev designet og udgivet i 2007 og var blandt en række nye sprog – Rust, D, Nim, Scala, Clojure – der vakte opsigt i begyndelsen og midten af 2010’erne: På det tidspunkt syntes programmører at være ivrige efter at bevæge sig væk fra den tunge bagage fra ældre backend-sprog (Java, C++) samt den beregningsmæssige ineffektivitet og typeusikkerheden i dynamiske sprog, der anvendes på nettet (PHP, Ruby, Python). De ønskede typesikkerhed, hvilket betød, at de ønskede statisk typing. Og de ville have hastighed.
Det var nemt at finde historier om nystartede virksomheder som IronMQ, der gik fra dusinvis af servere, der blev brugt til hosting af Rails, til et par stykker, der kunne hostes i et sprog som Go. Og som en person, der på det tidspunkt var gennemsyret af PHP5 og alle dets problemer, talte jeg mig selv blandt mængden af interesserede.
Da jeg først stødte på Go i mit gamle job som CTO hos ActiveCampaign, prøvede jeg at skrive noget kode i det. Og jeg kunne ikke lide det. Den gav mig problemer, hver gang jeg lod en variabel stå ubrugt eller importerede en ubrugt pakke. Go var særlig streng med hensyn til typning – jeg var bekendt med PHP’s type coercion, men jeg var også vant til C og C++, hvor man kunne blande signerede og usignerede heltal samt blande heltalsstørrelser (16-bit, 32-bit, 64-bit).
Go havde ikke generics. Faktisk var en af de ledende sprogdesignere (Rob Pike) ret skarp om, hvad sproget manglede. Som Pike udtrykte det, var det en god ting, og det var godt for dig. Sproget var designet til de “gennemsnitlige” ingeniører, der arbejdede hos Google, hvis man kan kalde dem det. På en måde føltes det, man læste om Go på det tidspunkt, som en nedgørelse. Og den dag i dag er det ikke svært at finde folk, der fortsat deler den kritik.
Så hvad ændrede min mening?
Go er simpelt. Det adskiller sig fra andre sprog i den henseende. Enkelhed er en dyd, og enhver kompleksitet, som man indfører i sproget, er nøje overvejet.
I lang tid – alt for længe, hvis man spørger nogle – manglede Go en egentlig pakkehåndtering. Det var først i 2018 – efter flere runder med engagement fra fællesskabet og en uofficiel eksperimentel pakkehåndtering kaldet “dep” – at der blev tilføjet nogen officiel understøttelse af deres løsning (“modules”) til sproget.
Men inden for denne enkelhed finder du en masse værdi. Du kan nemt skrive nogle one-liners i Ruby, der gør nogle fede ting, men gemt i disse one-liners ligger der en masse magi: Det er svært for den anmassende udvikler altid at forstå den proces, der foregår bag kulisserne. Måske tager det fem linjer kode at skrive det samme i Go, men du ved, hvad de fem linjer gør.
Go fjerner også et af de klassiske koncepter i OOP: arv. Du kan ikke skrive en basisklasse i Go og få en anden klasse til at arve fra den. Faktisk har man slet ingen “klasser”.
I første omgang føles det som en enorm begrænsning at få taget et af de grundlæggende værktøjer til genbrug af kode og indkapsling fra sig. Og det er naturligt, at din første tilbøjelighed er en følelse af vrede.
Men i disse dage bruger du ofte ikke arv, selv om du kunne. Man bruger interfaces, man fokuserer på adfærd og abstraktioner – og det kan man sagtens gøre i Go. Faktisk er det alt, hvad du kan gøre i Go. Efter et stykke tid føles manglen på arv godt, fordi du undgår et lag af teknisk gæld ved ikke at skulle genbesøge den farlige rede af relationer, som du havde opbygget ved hjælp af arv. Måske var Pike alligevel på sporet af noget.
I dag har Go skabt sig en defineret plads i sprogets økosfære. Det forsøger ikke at erstatte C++, som det engang blev troet (og foreslået). For 10 år siden troede man måske, at man havde brug for Java til et bestemt projekt, men i dag er det måske bedre at gribe til Go.
Sprog at læreIngeniørledere diskuterer Ruby on Rails, C#, Python og JavaScript