Software-update: Go 1.23

Go, ook aangeduid als golang, is een programmeertaal die oorspronkelijk door Google is ontworpen en veel wordt gebruikt voor het bouwen van webservices en grote projecten, zoals bijvoorbeeld Kubernetes. Go heeft dan ook een vaste plaats in de top 10 van de Tiobe index van meest gebruikte programmeertalen. Go-code kan worden gecompileerd voor Android, Linux, macOS, FreeBSD en Windows, op i386-, amd64- en Arm-processorarchitecturen. De syntax van Go is vergelijkbaar met die van C en soortgelijke programmeertalen, hoewel er ook enkele opvallende verschillen zijn. Ook biedt Go de mogelijkheid voor gedistribueerd programmeren, waarbij verschillende processen tegelijk worden uitgevoerd. De complete releasenotes voor versie 1.23 zijn op deze pagina te vinden; dit is de aankondiging voor deze uitgave:

Introduction to Go 1.23

The latest Go release, version 1.23, arrives six months after Go 1.22. Most of its changes are in the implementation of the toolchain, runtime, and libraries. As always, the release maintains the Go 1 promise of compatibility. We expect almost all Go programs to continue to compile and run as before.

Versienummer	1.23
Releasestatus	Final
Besturingssystemen	Android, Linux, BSD, macOS, Solaris, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11
Website	Golang.org
Download	https://go.dev/dl/
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (25)

[Vibonacci]

Wil deze taal echt nog een keer een goede kans geven. Ik hoor veel positieve dingen ondanks dat de adoption rate niet zo hoog is.

[Ablaze]

Zelf vorig jaar gedaan en dit zijn mijn plussen en minnen:

+ Eenvoudig te leren, de taal is niet erg uitgebreid
+ Snel compileren en makkelijk crosscompilen
+ Meegeleverde libraries bieden standaard goede ondersteuning voor netwerkactiviteiten
+ Maakt kleine, native binaries

- Beperkte OO functionaliteit, bijvoorbeeld geen inheritance
- Eigenwijze standaard libraries die niet universeel genoeg zijn, zoals de datum/tijd library (eigenlijk vrijwel geen ondersteuning voor localization)
- Eigenwijze standaard settings die bijvoorbeeld niet toestaan dat je ongebruikte imports of variabelen hebt
- De standaard library is niet uitgebreid genoeg, zodat je al snel een reeks aan modules van anderen gebruikt in je project
- Debug ervaring is matig vergeleken met interpreted of intermediate languages
- Aparte afhandeling van errors die niet zo krachtig is als try/catch/throw

Persoonlijk vind ik de taal niet universeel genoeg, talen als C# en Java zijn veel uitgebreider, hebben betere debugging en goede standaard libraries. Maar goed, deze zijn niet native.
Rust is een ander alternatief en in Go programmeren is vergeleken daarmee sneller en gemakkelijker. Rust zou dan weer een betere keuze zijn voor grote of kritische applicaties.

Edit: mensen vinden de stdlib juist uitgebreid. Dat klopt ook wel, als je voornamelijk webservices bouwt. Voor andere toepassingen vond ik het tegenvallen.

[Reactie gewijzigd door Ablaze op 14 augustus 2024 22:50]

[Anoniem: 76058]

Edit: mensen vinden de stdlib juist uitgebreid. Dat klopt ook wel, als je voornamelijk webservices bouwt. Voor andere toepassingen vond ik het tegenvallen.

Diezelfde logica kan je dan ook toepassen op Python, PHP, Javascript enz ... hangt af wat voor programma je maakt.

- Aparte afhandeling van errors die niet zo krachtig is als try/catch/throw

Hier merk je snel op of iemand echt een Go applicatie gebouwd heeft of beetje mee rondspelende.

Try/Cache/Throw word al te vaak op een hogere niveau als algemene cacheall gedraaid, probleem is, dat eer je de error afhandelt, dat er andere acties gedraaid werden zoals DB inserts met mogelijke lege data. En als je dan geen automatisch opruim hebt, begint de vervuiling.

Gans het gedoe met Go's error handling op iedere functies, is dat je ogenblikkelijk moet stoppen, en enige overgebleven data moet opruimen. Hint: Defer ...

Als er iets vervelend is, is de 1001 if err != nil, dan ik VEEL liever zou zien met een try of whatever verkorte constructie, op de functie zelf.

- De standaard library is niet uitgebreid genoeg, zodat je al snel een reeks aan modules van anderen gebruikt in je project

Heb hier een massive project en in totaal zitten daar 8 externe niet-go lib spullen in, want dat zijn zaken zoals rar support, of mp3 etc...

De basis zit in de lib, en de enige klacht dat ik zou kunnen opnoemen is dat mysql/postgre/sqlite libs niet standaard erin zitten (wat ik dom vind).

- Debug ervaring is matig vergeleken met interpreted of intermediate languages

https://pkg.go.dev/net/http/pprof

Meer moet ik niet zeggen ...

- Eigenwijze standaard settings die bijvoorbeeld niet toestaan dat je ongebruikte imports of variabelen hebt

Dat is weeral zo een klacht dat je enkel maakt, als je voor 5 minuten met Go werkt en dat niet gewoon bent. Hint: Zet een _ voor een ongebruikte import en hij zal blijven staan.

+ Maakt kleine, native binaries

In de praktijk zijn ze niet klein... Als je beetje programma maakt, dan schieten ze snel naar de 20, 30, 50mb ... Is enkel als je iets simpel maakt dat ze kleine zijn.

- Beperkte OO functionaliteit, bijvoorbeeld geen inheritance

Is meer een issue voor iemand dat van OO komt.. en zijn kronkel niet kan omslagen.

Zoals Robtmus aanheeft, je lost dit op via promoted-methods/fields. Kan je verzekeren dat ik ook LANG moeite gehad heb om met 20 jaar ervaring in OO, in Go om te stappen. Je vloekt geregeld, je snapt niet waarom iets dat simpele is in OO niet werkt in Go. Tot je composite functies begint toe te passen en promote structs met fields, type interfaces (ja, die zitten in Go) enz.

Je vergeet ook zaken zoals:

* Performance ...
* Minimaal geheugen gebruik ...
* Geen noodzaak aan external programma zoals nginx, memcached enz... Het is dood simpel om een goed alternatieve snel in elkaar te krijgen.
* Concurrency ... Feit dat je dit niet opnoemde verbaast me ... Dood simpel concurrent aps te maken, goede atomic support, mutex enz. Channels voor de beginners
* Cross compiles naar zoveel platformen
* Easy peachy voor Micro services te maken.
* ...

Dat klopt ook wel, als je voornamelijk webservices bouwt. Voor andere toepassingen vond ik het tegenvallen.

Een taal moet niet gebruikt worden voor zaken dat het niet voor gebouwd is. Al te vaak zie ik mensen proberen om talen te veranderen in zaken dat ze niet goed in zijn. Het gevolg is dat je dan vaak een programma krijgt dat niet toekomst zeker is.

Go is voor CLI, Webapps, microservices, DBs enz ... maar het is geen kernel taal (gebruik Rust daarvoor) en het is geen Game/GUI dev taal. Komt er op neer, dat het alles kan buiten die GUI/Kernel toestanden. Ja, je kan GUI doen maar zie men punt boven.

Persoonlijk vind ik de taal niet universeel genoeg, talen als C# en Java zijn veel uitgebreider, hebben betere debugging en goede standaard libraries. Maar goed, deze zijn niet native.

Iedere taal heeft zijn voor en nadelen. Ik zou geen micro services maken in Java of C#. Zijn er firmas dat dit gedaan hebben, yep en ik hou er zo van om die gekende Java errors te zien in men browser

[DexterDee]

Concurrency ... Feit dat je dit niet opnoemde verbaast me ... Dood simpel concurrent aps te maken, goede atomic support, mutex enz. Channels voor de beginners

Hier moet ik toch even goed gniffelen. Een heel opstel over de designkeuzes van Go en dan kom je met dit zinnetje. In de Go community zeggen we "Don't communicate by sharing memory; share memory by communicating". Channels zijn niet voor beginners, maar zijn juist het antwoord op het aanbrengen van kritieke paden / mutexes.

[Anoniem: 76058]

Iemand dat weeral niet kan lezen en commentaar moet geven, zonder de te zien op het einde... Begrijpend lezen is zo een lastig onderwerp in school deze dagen.

[DexterDee]

Je superieur niveau van sarcasme is inderdaad boven mijn hoofd gevlogen

[mbe81]

De meeste zaken die jij als minpunt benoemt (geen inheritance, geen ongebruikte imports en variabelen, de error afhandeling) zijn bewuste ontwerpkeuzes geweest.

Verder staat Go juist bekend om zijn uitgebreide standaard library. Je kan zonder externe libraries vrij eenvoudig een complete api bouwen. Alleen voor de database driver heb je een externe library nodig.

Edit: wat ik zelf een grote pré vind is de eenvoud van de taal. Er is weinig magie en door de code te lezen zie je al gauw wat er gebeurd. Dit samen met het crosscompilen. Vanaf mijn Mac maak ik eenvoudig een amd64 of arm Linux binary die ik op de betreffende platformen kan draaien zonder aanvullende libraries.

[Reactie gewijzigd door mbe81 op 14 augustus 2024 20:47]

[Xfade]

Dat iets een bewuste keuze is betekend natuurlijk niet dat het geen minpunt kan zijn.

[mbe81]

Zeker niet! Maar mogelijk wel dat je eerst moet snappen waarom die keuze is gemaakt voor je het gaat waarderen. Vooral als je het al jaren zo gewend bent.

[camper69]

C# kun je inmiddels wel native AOT bouwen. Maar nog niet alle libraries hebben ondersteuning hiervoor waardoor je bij gebruik van die libraries code wegtrimt of een grotere executable krijgt.

Hoewel ik blijer word van C# of Java, zou eigenlijk zou het eindresultaat de doorslag moeten geven: klein in distributie, performant, veilig (GC of een borrow checker), weinig resources verbruiken (vooral geheugen). Ik denk dat Go daarin een vinkje meer zet dan de tegenhangers Java of C#. Productiviteit zal bij Java en C# een fractie hoger liggen verwacht ik.

[gimbal]

Het is geen tegenhanger, Go en Java of C# zijn verschillende stukken gereedschap in de riem die elkaar complimenteren. Je gaat in Go echt geen SOAP webservice maken of consumeren of anderzijds grote XML stromen verwerken, daarvoor moet je lekker doorontwikkelde platformen zoals Java of C# gebruiken. Maar ik vind het sterk overkill om een Java of een C# in te zetten voor een simpele microservice wat enkel wat REST calls afhandelt en wellicht wat dingen en spullen met een database of key-value store doet. Om een voorbeeld te noemen.

[camper69]

Ik zie dat wat anders. Ik vind ze ongeveer in dezelfde klasse zitten: Garbage Collected en strong typed met een vergelijkbare performance. Maak je een microservice in C# kun je die met AOT ook op een scratch docker image zetten, als dat je voorwaarde is voor (wat simpele) REST calls. Gebruikt het vergelijkbaar weinig geheugen. Tegelijkertijd zou ik ook geen problemen hebben om een SOAP service in Go te maken als je daar in thuis bent, behalve dat het SOAP is.

Ik moet het eerste bedrijf van een normale omvang nog tegenkomen die per feature de ontwikkeltaal bepaalt. Met de voorwaarde dat JavaScript nodig is voor de browser ben ik al blij als het bedrijf niet voor een JavaScript backend kiest.

[Robtimus]

Er is inderdaad geen inheritance, maar je kan wel gebruik maken van promoted fields en promoted methods. Tijdens het aanroepen van fields en methods kun je doen alsof ze inherited zijn. Tijdens het aanmaken van instances zie je helaas die structuur wel heel duidelijk.

[Reactie gewijzigd door Robtimus op 14 augustus 2024 22:12]

[roelboel]

De stdlib is de sterkste van alle talen die ik ken. Wat mis je zoal? En zeg alsjeblieft niet: een web framework. Die bestaan enkel ter glorie van de makers en voegen niets toe. Zeker niet met de recente mux-uitbreiding.

[MaestroMaus]

Ik weet niet veel van GO, maar zelfs ik weet dat het niet hebben van inheritance een design keuze is van GO. Het is een feature, not a bug. De redenen hiervoor uitzoeken vond ik zeer interessant en heeft me aan het denken gezet. Dus ik raad anderen aan om ook uit te zoeken waarom dit zo gedaan is.

[Sp3ci3s8472]

Ik werk er veel mee op dit moment, maar als ik s'avonds iets voor mijzelf mag programmeren dan ben ik maar al te blij als ik weer met C# bezig kan gaan.

• Een van de minpunten van go is de rare iterator, het doet net niet wat je verwacht. Ik ben een duidelijk onderscheid tussen for en foreach gewent en de range iterator van go lijkt op een for each maar werkt als een for loop.
• Generics zijn best beperkt, waardoor je soms hele omslachtige dingen moet bouwen.
• De error handling, elke keer een err != nill.

Verder is de taal prima, al had de syntax wat netter en vrijer gemogen en dan doel ik op acolades.

[Robtimus]

De error handling vind ik dramatisch. Go kent geen exceptions, in plaats daarvan zijn errors deel van de returnwaarde. Dat kan omdat in Go functies tuples als returnwaarde kunnen hebben. Het effect is iets wat ik altijd omschrijf als "try-catch voor elk statement" - na elke call moet je checken of de error returnwaarde nil is of niet, en zo ja dan heb je vaak een "return nil, err" statement om de error door te geven naar de caller.

Als je daarmee kan leven dan is Go inderdaad een best prettige taal om mee te werken. Omdat ik van strongly-typed talen hou staat hij voor mij boven Python en Ruby.

[Nindustries]

Dit vind ik juist een heel prettige toevoeging. Het is inderdaad even wennen en lijkt ‘teveel administratie’, maar de expliciteit, die je nog meer vind in Go, is heerlijk.

[mbe81]

Eens! Als je er eenmaal aan gewend bent, dan mis je de try catch zeker niet en is dit een hele fijne manier. Althans, mijn mening!

[BlueSix]

Dit wordt het Result Pattern genoemd en zie ik in bijvoorbeeld .NET ook steeds vaker (bijv. ErrorOr). Gedachte is dat Exceptions een exceptie moeten zijn en niet gebruikt moeten worden voor “Flow Control”.

[camper69]

Het is juist goed dat je ALTIJD iets met het resultaat moet doen van een aanroep. Excepties werden en worden nogal eens verkeerd ingezet of niets mee gedaan. Alleen Go is inderdaad wat beperkt en dus omslachtig in de afhandeling van die err. Een oplossing zoals in Rust of vooral ZIG, wat een lower level taal zou zijn, is zoveel eleganter.

Behalve wat syntactische ontberingen is er heel erg weinig mis met Go.

[bantoo]

Exceptions zijn er wel, Panic en Recover zijn equivalent en throw/catch. het was een opzettelijke keus om voor values voor error handling te gaan in de standard library enzovoort maar niks verplicht je dat patroon te volgen in eigen code.

[Crew One]

Wij (grote e-commerce site) zijn fan.

Erg makkelijk te leren, perfect voor microservices en implementatie van backends die verschillende databases aan elkaar knopen. Performt goed, goede tools in o.a. vscode en ontwikkelt snel.

Het enige minpuntje is het wel erg Spartaanse errormanagement, maar na integratie met datadog is daar een deel van weg.

[roelboel]

Ik wist dat er iets met Go gedaan werd bij Bol, maar heeft het nog tractie?

[thomasv]

Zelfde hier, en geldt voor mij ook een beetje voor Rust (als memory safe C(++) tegenhanger).