Software-update: Go 1.25

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.25 zijn op deze pagina te vinden; dit is de aankondiging voor deze uitgave:

Introduction to Go 1.25

The latest Go release, version 1.25, arrives in August 2025, six months after Go 1.24. 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. There are no languages changes that affect Go programs in Go 1.25. However, in the language specification the notion of core types has been removed in favor of dedicated prose. See the respective blog post for more information.

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

Reacties (19)

[Boedie]

Ik heb recent voor het eerst met Go te maken, waar de afgelopen jaren veel met Python is gewerkt. Ik ben erg tevreden en de learning curve is goed te doen. Wat fundamentele zaken als de Goroutines zijn wel even een lastige geweest, maar inmiddels onder de knie. Heb er inmiddels mooie microservices mee kunnen bouwen!

[Power2All]

GO is ook een top alternatief voor Python inderdaad, minder module drama e.d.
Voor dit soort doeleinden is het prima te gebruiken.

[fenrirs]

Ben wel benieuwd naar wat voor module drama he dan tegenaan gelopen bent

[AddictIT]

Nou, virtual environment en dan pip3 install -r requirements.txt

Het loopt keer op keer fout bij mij, of er zijn dependency issues.
En ik heb echt geen zin om me erin te verdiepen. (Hoe leuk/krachtig ik Python ook vind als taal).


Op dat vlak is Go een verademing, cross-platform, single executable en geen dependencies. Heerlijk :-)

[satya]

Voor mij als niet developer verbazingwekkend zelfs. Coroot en Gitea zijn mooie voorbeelden van programma's geschreven in GO.

[Power2All]

Gitea gebruik ik ook in mijn projecten, zeer goed product en werkt prima.
Minder zwaar sowieso dan Gitlab, de runner van Gitea is ook een top oplossing.

[berchtold]

Poetry is daar de oplossing voor

[annejouke]

Zo'n beetje een van mijn favoriete taaltjes, maar dat zal je niet veel developers horen zeggen. Het is niet echt een taal waar techneuten ontzettend mee kunnen knutselen, om de syntax zo eenvoudig mogelijk te houden laten ze vooral veel dingen weg. Het heeft weinig syntax sugar vergeleken bij talen als C#, PHP, Rust en Typescript - die met heel veel taal features toestaan om hele korte, krachtige expressies neer te zetten, mids je alle smaken en syntax truukjes weet. Dat is voor een engineer vaak toch leuker, omdat je je kennis kan gebruiken om zo beknopt mogelijke statements neer te zetten.

Mede dankzij deze eenvoud hebben ze de taal gigantisch kunnen optimaliseren. De runtime is razendsnel voor een taal met een garbage collector, maar in development recompiled het echt ongelofelijk snel. Met een handig tooltje als `air` voor Go, laat ik mijn web API's vaak elke save opnieuw startten, waardoor back-end development net zo vlot en reactief voelt als werken met een van bekende front-end frameworks.

Go deploy je als enkele binary, dus als je daar een SQLite naast zet is je devops situatie debiel eenvoudig: Letterlijk twee files. Dat maakt bij een goed doorgetestte CI/CD pipeline niet uit natuurlijk, maar als je er even niks meer van snapt op de remote omgeving, is het wel verschrikkelijk handig dat je niet tegen een situatie aanloopt als "Oh, dat PHP bestandje stond op de verkeerde plek..." (na 3 uur zoeken).

In een recent project lukt het me maar niet om met Go tot de juiste uitdrukking te komen -- alles voelt wollig, onnodig complex en geeft niet de type-safety die ik wil. Goed, dan pak je een andere taal en voor de eenvoudige projectjes is Go dan weer genieten.

Puntje bij 't paaltje zijn alle programmeertalen een pot nat: Het lijkt op C, Lisp of ML en het heeft net wat andere features als de rest. Een beetje net zoals Linux distro's. (Tijd om de schuilkelder op te zoeken)

[Crew One]

Is ook voor mij (senior developer, een van de grootste Nederlandse e-commerce sites) toch wel mijn favoriete taal. De snelheid en eenvoud waarmee je microservices kan ontwikkelen is echt ongekend, en - opgevoed in de jaren negentig met C++ bij de faculteit Technische Informatica op de Universiteit Twente, voelt het _bijna_ als echt programmeren - iets wat in het dagelijks leven in het e-commerce landschap niet veel meer voorkomt.

Daarnaast is de performance, zeker als je er een klein beetje moeite in stopt, gewoon top.

[Power2All]

Die performance is helaas naar mijn ervaring niet goed gebleken.
Heb een torrent back-end tracker draaien met pak hem beet 60000 connecties per seconden, daar ging GO in eerste instant heel goed mee om, tot de garbage collector om de hoek kwam kijken, en de applicatie letterlijk halve minuut tot een minuut gehalt had, elke keer als het geheugen gebruik een bepaalde piek bereikte, waardoor er geen enkele connecties meer behandeld werden, en er timeouts ontstond.

Voor een high-availability server, vind ik GO hierom dus nou niet bepaald geschikt.
Maar als jij er nog geen last van hebt gehad, is dat prima lijkt me, maar heb zelf helaas slechte ervaring ermee.

[Reactie gewijzigd door Power2All op 14 augustus 2025 08:23]

[Left]

Dat probleem ga je hebben met iedere taal met garbage collection. Maar je kan er ook iets aan doen: simpelweg niet zoveel nieuwe objecten creeren. Google bijvoorbeeld eens naar object pool.

[Power2All]

Dat was precies wat ik ook probeerde, maar frameworks waren vaak niet optimaal, en dan liep het geheugen ook extreem snel vol. Eerste instantie dacht ik mogelijk memory leak o.i.d., maar dit is gewoon hoe Python en GO functioneren.
Rust heeft ook garbage collection, maar doen dit onderwater bij elke "functie" exit, dus je voelt er bijna tot niks van, en onderbreekt je applicatie niet (dit is hoe mij dit was uitgelegd).

Pools is een oplossing, maar uiteindelijk ga je toch een limitatie raken, vooral als je met miljoenen aan hashes werkt (btreemap), daar kan GO niet optimaal mee omgaan.

[Left]

Rust heeft ook garbage collection, maar doen dit onderwater bij elke "functie" exit

Dit kun je dus ook zelf doen in een taal zoals Go: je functie least een object uit de object pool, voor de functie exit geeft je dat object weer terug. Waarschijnlijk is dit nog wel efficienter dan in Rust, omdat Rust vroeger of later alsnog gaat garbage collecten. (Maar natuurlijk zou je in Rust ook een object pool kunnen gebruiken).

[Power2All]

Het is technisch gezien geen Garbage Collecting bij Rust:

Rust is a general-purpose programming language that is both type-and memory-safe. Rust does not use a garbage collector, but rather achieves these properties through a sophisticated, but complex, type system. Doing so makes Rust very efficient, but makes Rust relatively hard to learn and use.

https://dl.acm.org/doi/10.1145/3510003.3510107#:~:text=Rust%20is%20a%20general%2Dpurpose,hard%20to%20learn%20and%20use.

Door gebruik te maken van deze techniek, is Garbage Collecting niet noodzakelijk.
Voor veel mensen is dit een "garbage collecting" methode, maar voor een grote andere groep wordt deze techniek juist als geen garbage collection gezien.

Ja, het duurde voor mij even voor ik Rust wou omarmen, de leer-curve versus Go is wel hoger, maar als je de structuur snapt, wordt het een stukken makkelijker, en simpeler in gebruik.

[Reactie gewijzigd door Power2All op 14 augustus 2025 14:44]

[Crew One]

Ik ga niet claimen dat wij 60000 connecties hebben. Maar als je die aantallen hebt, zul je toch moeten werken aan zero allocation strategieën en optimalisaties buiten de frameworks om. Maargoed, als je GO daarvan de schuld wilt geven - prima. Het zal niet voor ieder project geschikt zijn.

Ondertussen hebben we microservices die al bijna een jaar online zijn; dat is wat mij betreft 'high availability' genoeg.

[Power2All]

Zoals ik ook al zei, als het voor jou werkt, is dat helemaal prima.
Ik run deze services al sinds 2003, en heb geruim al veel ervaring in optimalisaties.
Python/GO is helaas, naar mijn mening (want iedereen heeft mogelijk een eigen mening hierover) geen goede optimale taal voor high availability oplossingen.

[Power2All]

Ben helaas van Go snel weg gegroeid.
Was begonnen in Quick Basic, toen door gestapt naar Visual Basic (4, 5, 6), om vervolgens de stap naar PHP te maken. Heel lang in geprogrammeerd voordat ik overstapte naar Python, GO en vervolgens op Rust waar ik nu naast PHP nog altijd gebruik van maak.

Had een zwaar belastende web service draaien, en de garbage collector constant onderbrak de werking van het programma. Uiteindelijk op Rust overgestapt, waar dat niet gebeurd, en tot nu toe ook een zeer stabiele omgeving gebleken.

De meeste frameworks (of zeg maar alle) in Go bouwen veel geheugen gebruik op, en na een tijdje moet die gedropte data weer opgeruimd worden, dat doet hij dus tijdens een garbage collector routine, maar deze "halt" dus je applicatie, vaak ook voor een halve minuut als het extreem veel is, en dat is helaas problematisch als je bijv. met streaming bezig bent.

Go is perfect voor kleine micro-services, maar ook als vervanger voor Python (die tevens ook een garbage collector heeft).

[Reactie gewijzigd door Power2All op 14 augustus 2025 08:26]

[Crew One]

Nou, laten we het er op houden dat wij dit hier echt niet herkennen. Ik, noch de go servers die wij gebruiken (Weaviate, Docker - allemaal in Go geschreven) of zelf hebben geschreven hebben ooit echt last gehad van de GC van Go.

Maargoed, nogmaals, je hoeft geen Go te gebruiken.

[Power2All]

Zoals ik al zei, Go is niet geschikt voor veel data verwerking, en hun Btreemap implementatie heeft nogal wat haken en ogen. Dit is een van de dingen waarom ik naar Rust ben gaan kijken (naast C# en C++). Tot nu toe trekt Rust prima het karretje, en heb ik geen onderbrekingen meer.

Go is een prima programmeertaal voor parsings e.d., maar als webserver o.i.d. is het naar mijn gevoel gelimiteerd goed. Het is makkelijk op te zetten, maar performance haal je meer uit Rust frameworks als Actix.

Maar goed, zoals ik je reactie lees, heb jij een andere mening hierover, en dat is prima. Iedereen heeft eigen ervaringen met de applicaties die men gebruikt.