Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie

Software-update: Go 1.15.5 / 1.14.12

Go logo (79 pix)Go, ook aangeduid als golang, is een programmeertaal die sinds 2007 wordt ontwikkeld door Google en de opensourcegemeenschap. De taal wordt onder andere door CloudFlare, Google, Netflix en Uber gebruikt. 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. Het team heeft Go versies 1.15.5 en 1.14.12 vrijgegeven met de volgende aanpassingen:

Go 1.15.5 and Go 1.14.12 are released

We have just released Go 1.15.5 and Go 1.14.12 to address recently reported security issues. We recommend that all users update to one of these releases (if you’re not sure which, choose Go 1.15.5).
  • math/big: panic during recursive division of very large numbers
    A number of math/big.Int methods (Div, Exp, DivMod, Quo, Rem, QuoRem, Mod, ModInverse, ModSqrt, Jacobi, and GCD) can panic when provided crafted large inputs. For the panic to happen, the divisor or modulo argument must be larger than 3168 bits (on 32-bit architectures) or 6336 bits (on 64-bit architectures). Multiple math/big.Rat methods are similarly affected.
    crypto/rsa.VerifyPSS, crypto/rsa.VerifyPKCS1v15, and crypto/dsa.Verify may panic when provided crafted public keys and signatures. crypto/ecdsa and crypto/elliptic operations may only be affected if custom CurveParams with unusually large field sizes (several times larger than the largest supported curve, P-521) are in use. Using crypto/x509.Verify on a crafted X.509 certificate chain can lead to a panic, even if the certificates don’t chain to a trusted root. The chain can be delivered via a crypto/tls connection to a client, or to a server that accepts and verifies client certificates. net/http clients can be made to crash by an HTTPS server, while net/http servers that accept client certificates will recover the panic and are unaffected.
    Moreover, an application might crash invoking crypto/x509.(*CertificateRequest).CheckSignature on an X.509 certificate request or during a golang.org/x/crypto/otr conversation. Parsing a golang.org/x/crypto/openpgp Entity or verifying a signature may crash. Finally, a golang.org/x/crypto/ssh client can panic due to a malformed host key, while a server could panic if either PublicKeyCallback accepts a malformed public key, or if IsUserAuthority accepts a certificate with a malformed public key.
    Thanks to the Go Ethereum team and the OSS-Fuzz project for reporting this. Thanks to Rémy Oudompheng and Robert Griesemer for their help developing and validating the fix.
    This issue is CVE-2020-28362 and Go issue golang.org/issue/42552.
  • cmd/go: arbitrary code execution at build time through cgo
    The go command may execute arbitrary code at build time when cgo is in use. This may occur when running go get on a malicious package, or any other command that builds untrusted code.
    This can be caused by malicious gcc flags specified via a #cgo directive, or by a malicious symbol name in a linked object file.
    Thanks to Imre Rad and to Chris Brown and Tempus Ex respectively for reporting these issues.
    These issues are CVE-2020-28367 and CVE-2020-28366, and Go issues golang.org/issue/42556 and golang.org/issue/42559 respectively.
Versienummer 1.15.5 / 1.14.12
Releasestatus Final
Besturingssystemen Windows 7, Linux, BSD, macOS, Solaris, UNIX, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016, Windows Server 2019
Website The Go Programming Language
Download https://golang.org/dl/
Licentietype Voorwaarden (GNU/BSD/etc.)

Door Japke Rosink

Meukposter

Update-historie

Reacties (9)

Wijzig sortering
Leuke taal, maar met de komst van C# Native, en Rust wordt Go in de toekomst wel in het nauw gedrukt ben ik bang. Het is in ieder geval niet een taal die nog 20 jaar lang mee gaat.
C# is wel erg Windows gefocused, en Rust is veel complexer dan Go. Golang is voor mij en vele anderen de go-to taal wanneer de performance van Python niet voldoet. Het heeft vergelijkbare performance als C/C++, maar is véél makkelijker om mee te werken.

Wat mij betreft samen met bv Python, Javascript en C/C++ absoluut een van de talen van de toekomst..
Golang is voor mij en vele anderen de go-to taal wanneer de performance van Python niet voldoet.
Hoe bepaal je dan dat de performance van python niet voldoet / wat voor applicaties praten we over dat je dit kan merken?

Want voor mij volstaat in de praktijk elke taal wel zo ongeveer qua performance.
En als ik kijk naar een gebied als ML (waar veel cpu-gebruik inzit) dan heeft toch python de voorkeur, dus zo langzaam zal het toch niet zijn.

Heb je een real-world voorbeeld van iets waar de performance van python niet voldoet en je echt zou over moeten stappen naar golang (en waarom stap je dan niet gelijk door naar c/c++/asm)?

Want ik ken wel de microbenchmarks, alleen die vind ik nooit zo relevant, aangezien print("") wel 100x zo snel kan in golang, zeer specifieke uitzonderingen daargelaten zal een print-commando nooit meer als 0,1% van mijn performance bepalen.

En zolang ik voor 5000 euro een nieuwere processor erin kan zetten hoef ik niet 2 weken golang te leren (en is hardware dus goedkoper)
Hoe bepaal je dan dat de performance van python niet voldoet / wat voor applicaties praten we over dat je dit kan merken?
Een recent voorbeeldje: ik had een analyse geschreven voor een stuk time series data. Één analyse run over onze data deed er in Python 6 uur over. Na een herschrijving in Go deed het er 4 minuten over. Tel uit je winst.

Daarnaast heeft Python een GIL die parallelle taken heel moeilijk maken. Ik ben ook bezig met een programma dat verschillende sensoren tegelijkertijd uitleest en op basis daarvan beslissingen maakt. Dan moet je dus 5 processen tegelijk hebben draaien en dat kan bijna niet met Python. En nee, dat los je niet op met async/await achtige constructies.
en waarom stap je dan niet gelijk door naar c/c++/asm?
Omdat Go dus véél makkelijker is, en je daardoor mega snel een programma in elkaar hebt dat de snelheid van C benadert.
En als ik kijk naar een gebied als ML (waar veel cpu-gebruik inzit) dan heeft toch python de voorkeur, dus zo langzaam zal het toch niet zijn.
Dit is natuurlijk onzin. Ja de code om de analyses en learning te starten wordt in Python gedaan, maar de daadwerkelijke "werk-code" is in die gevallen altijd in C/C++ (bekijk de sources maar eens). Python is véél en véél te langzaam voor ML.
Want voor mij volstaat in de praktijk elke taal wel zo ongeveer qua performance.
Dat is goed om te horen, maar dan ben je dus niet met CPU-intensieve taken bezig. In die gevallen volstaat Python idd perfect en is het ook mijn keuze. Zijn we het daarover eens.. :-)

[Reactie gewijzigd door kramer65 op 14 november 2020 18:31]

Een recent voorbeeldje: ik had een analyse geschreven voor een stuk time series data. Één analyse run over onze data deed er in Python 6 uur over. Na een herschrijving in Go deed het er 4 minuten over. Tel uit je winst.
Nou ben ik geen programmeur en zelfs hobby-programmeur zou teveel eer zijn, maar hier vraag ik me toch af: Is dat programma in Python wel goed geschreven, als de winst in een andere taal op dezelfde hardware 8900% is?

edit: typo.

[Reactie gewijzigd door Jack Flushell op 15 november 2020 11:12]

Een valide vraag natuurlijk. Nou werk ik al jaren met heel grote datasets in onder meer Python, dus ik pretendeer er wel iets van te weten ja.. :-)

Misschien heb je gelijk. Maar mijn collega's en ik hebben die potentieel enorme fout er geen van allen in gezien, en een rewrite in Go had zo'n enorm effect dat we (voor die analyse) niet eens meer om hebben gekeken naar de Python code. Of het nou een moeilijke optimalisatie was (een simpele was het sowieso niet) over het hoofd hebben gezien of dat Go idd zo enorm veel beter presteerde zullen we dus misschien nooit weten, maar welke van de twee het ook was (misschien een combo), Go werkte voor ons beter dan Python.. :-)
Go is gewoon de zoveelste in het rijtje fringe programmeertalen wat giga-groot is en wat ook altijd wel ergens een toepassing zal kennen.

En in datzelfde rijtje hoort ook Rust thuis.

Het is niet dat de ene taal de andere gaat vervangen, de toepassing / het specialisme is gewoon anders.

Feitelijk wordt het alleen veels te vaak door de mainstream verkeerd gebruikt omdat het de hype of the moment is en tja diezelfde mainstream gebruikt ook de volgende hype of the moment weer verkeerd.
Denk ook dat Go een Niche taal is. Maar wel goed zijn ding doet, maar Go ging ooit tussen C/C++ en Java/C# zitten. Nu heb je Rust, en C# kun je compilen naar native wat het meer zoals GO maakt. Dus wat ik ermee bedoel is dat andere talen ook dichterbij Go komen.
Go is erg sterk in het bouwen van microservices en netwerk afhandeling. Concurrency support is ook zeer elegant en eenvoudig te gebruiken. Wat mij betreft is rust op andere vlakken weer sterker maar een groot gemis is nog een echt goede jetbrains IDE voor rust. En dan bedoel ik niet IDE X met plugins y en z maar native support.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch (OLED model) Apple iPhone SE (2022) LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S22 Garmin fēnix 7 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True