{"id":121950,"date":"2025-02-15T14:22:29","date_gmt":"2025-02-15T12:22:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/go-1-24"},"modified":"2025-02-15T14:22:29","modified_gmt":"2025-02-15T12:22:29","slug":"go-1-24","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/go-1-24","title":{"rendered":"Gehe 1.24","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Gehe <\/a> <\/p>\n

Die neue Version von Go, Version 1.24, erscheint sechs Monate nach Go 1.23<\/a>. Die meisten \u00c4nderungen betreffen die Implementierung des Toolchains, der Laufzeit und der Bibliotheken. Wie immer gew\u00e4hrleistet die Ver\u00f6ffentlichung das Versprechen der Kompatibilit\u00e4t<\/a> Go 1. Die Entwickler der Sprache erwarten, dass fast alle Go-Programme weiterhin wie gewohnt kompiliert und funktionieren.<\/p>\n

<\/noindex><\/noindex> <\/p>\n

\u00c4nderungen in der Sprache<\/h2>\n

<\/p>\n

Go 1.24 unterst\u00fctzt jetzt vollst\u00e4ndig generische Typalias<\/a>: Ein Typalias kann parametrisiert werden wie ein deklarierter Typ. Weitere Details finden Sie in der Sprachspezifikation<\/a>. Momentan kann diese M\u00f6glichkeit durch das Setzen von GOEXPERIMENT=noaliastypeparams deaktiviert werden; jedoch wird die Option aliastypeparams in Go 1.25 entfernt.<\/p>\n

<\/noindex> <\/p>\n

Werkzeuge<\/h2>\n

Der Befehl go<\/h3>\n

<\/p>\n

Go-Module k\u00f6nnen jetzt ausf\u00fchrbare Abh\u00e4ngigkeiten verfolgen, indem die Tool-Direktive in go.mod verwendet wird. Dies beseitigt die Notwendigkeit einer vorherigen Umgehungsl\u00f6sung, um Tools als leere Importe in die Datei hinzuzuf\u00fcgen, die normalerweise 'tools.go' genannt wird. Der Befehl go tool kann jetzt diese Tools zus\u00e4tzlich zu den mit Go gelieferten Tools ausf\u00fchren. Weitere Informationen sind zu finden in Dokumentation<\/a>.<\/p>\n

<\/noindex> <\/p>\n

Das neue Flag -tool f\u00fcr go get f\u00fchrt zur Hinzuf\u00fcgung der Werkzeugdirektive zum aktuellen Modul f\u00fcr die angegebenen Pakete, zus\u00e4tzlich zur Hinzuf\u00fcgung der Abh\u00e4ngigkeitsdirektiven.<\/p>\n

<\/p>\n

Neu Meta-Muster tool<\/a> verweist auf alle Werkzeuge im aktuellen Modul. Dies kann verwendet werden, um sie alle \u00fcber go get tool zu aktualisieren oder um sie in Ihr GOBIN-Verzeichnis \u00fcber go install tool zu installieren.<\/p>\n

<\/noindex> <\/p>\n

Ausf\u00fchrbare Dateien, die \u00fcber go run erstellt wurden, und das neue Verhalten von go tool werden jetzt im Go-Build-Cache zwischengespeichert. Dies optimiert wiederholte Ausf\u00fchrungen dank erh\u00f6htem Cache. #69290<\/a>.<\/p>\n

<\/noindex> <\/p>\n

Die Befehle go build und go install akzeptieren jetzt das Flag -json, das Ausgaben und Build-Fehler als strukturierten JSON-Ausgabe auf der Standardausgabe meldet. Einzelheiten zum Format finden Sie in go help buildjson.<\/p>\n

<\/p>\n

Dar\u00fcber hinaus meldet go test -json jetzt Ausgaben und Build-Fehler in JSON, vermischt mit dem Testresultat-JSON. Diese k\u00f6nnen aufgrund neuer Action-Typen unterschieden werden, aber wenn sie Problem im Testintegrationssystem verursachen, kann man auf die textuelle Build-Ausgabe \u00fcber die Einstellung GODEBUG<\/a> gotestjsonbuildtext=1. zur\u00fcckgreifen.<\/p>\n

<\/noindex> <\/p>\n

Die neue Umgebungsvariable GOAUTH bietet eine flexible M\u00f6glichkeit zur Autorisierung privater Modulimporte. Detaillierte Informationen finden Sie in go help goauth.<\/p>\n

<\/p>\n

Der Befehl go build installiert jetzt die Version des Hauptmoduls<\/a> im kompilierten Bin\u00e4rformat, basierend auf dem Tag und\/oder dem Commit des Versionskontrollsystems. Der Suffix +dirty wird hinzugef\u00fcgt, falls nicht kommittierte \u00c4nderungen vorhanden sind. Der Flag -buildvcs=false kann verwendet werden, um Versionierungshinweise aus dem Bin\u00e4rformat zu entfernen.<\/p>\n

<\/noindex> <\/p>\n

Neu GODEBUG-Einstellung<\/a> toolchaintrace=1<\/a> kann jetzt verwendet werden, um den Prozess der Auswahl des Toolchains im Befehl go zu verfolgen.<\/p>\n

<\/noindex> <\/p>\n

Cgo<\/h3>\n

<\/p>\n

Cgo unterst\u00fctzt neue Annotationen f\u00fcr C-Funktionen zur Verbesserung der Laufzeitleistung. #cgo noescape cFunctionName teilt dem Compiler mit, dass der an die C-Funktion cFunctionName \u00fcbergebene Speicher nicht entglitten darf. #cgo nocallback cFunctionName teilt dem Compiler mit, dass die C-Funktion cFunctionName keine Go-Funktionen zur\u00fcckruft. Weitere Informationen sind in der Cgo-Dokumentation<\/a>.<\/p>\n

<\/noindex> <\/p>\n

Cgo lehnt derzeit kompilierte Aufrufe von C-Funktionen ab, die mehrere inkonsistente Deklarationen haben. Beispielsweise, wenn f sowohl als void f(int) als auch als void f(double) deklariert ist, wird cgo einen Fehler melden, anstatt eine falsche Aufrufsequenz f\u00fcr f(0) zu generieren. Neu in dieser Version ist die verbesserte Erkennung dieses Fehlerzustands, wenn inkompatible Deklarationen in verschiedenen Dateien auftreten. #67699<\/a>.<\/p>\n

<\/noindex> <\/p>\n

Objdump<\/h3>\n

Das Tool objdump unterst\u00fctzt jetzt das Disassemblieren auf 64-Bit LoongArch (GOARCH=loong64), RISC-V (GOARCH=riscv64) und S390X (GOARCH=s390x).<\/p>\n

Vet<\/h3>\n

Der neue Tests-Analyzer meldet h\u00e4ufige Fehler in Testdeklarationen, Fuzzern, Benchmarks und Beispielen in Testpaketen, wie z. B. falsch formatierte Namen, ung\u00fcltige Signaturen oder Beispiele, die nicht existierende Identifikatoren dokumentieren. Einige dieser Fehler k\u00f6nnen dazu f\u00fchren, dass Tests nicht ausgef\u00fchrt werden.<\/p>\n

<\/p>\n

Der bestehende printf-Analyzer meldet jetzt Diagnosen f\u00fcr Aufrufe der Form fmt.Printf(s), wobei s ein String mit nicht konstantem Format ist, ohne weitere Argumente. Solche Aufrufe sind fast immer ein Fehler, da der Wert s das Zeichen % enthalten kann; verwenden Sie stattdessen fmt.Print. 60529<\/a>. Diese \u00dcberpr\u00fcfung neigt dazu, Funde im bestehenden Code zu machen, und wird daher nur angewendet, wenn die Sprachversion (festgelegt durch die Anweisung go im go.mod-Datei oder durch die Kommentare `\/\/go:build) mindestens Go 1.24 betr\u00e4gt, um zu vermeiden, dass bei der Aktualisierung auf das Go 1.24-Toolchain dauerhafte Integrationsfehler auftreten.<\/p>\n

<\/noindex> <\/p>\n

Der vorhandene buildtag-Analyser gibt nun Diagnosen aus, wenn es eine falsche Build-Einschr\u00e4nkung der \u00e4lteren Version gibt.<\/a> Go-Direktive \/\/go:build. Zum Beispiel verweist \/\/go:build go1.23.1 auf ein Punkt-Release; stattdessen verwenden Sie \/\/go:build go1.23. #64127<\/a>.<\/p>\n

<\/noindex> <\/p>\n

Der vorhandene copylock-Analyser gibt nun Diagnosen aus, wenn eine Variable, die in einer dreifachen 'for'-Schleife deklariert wird, wie for i := iter(); done(i); i = next(i) { ... }, ein sync.Locker wie sync.Mutex enth\u00e4lt. Go 1.22<\/a> \u00e4nderte das Verhalten solcher Schleifen so, dass jede Iteration eine neue Variable erstellt und Werte von der vorherigen Iteration kopiert; diese Kopie ist f\u00fcr Locks unsicher. #66387<\/a>.<\/p>\n

<\/noindex> <\/p>\n

GOCACHEPROG<\/h3>\n

<\/p>\n

Das interne Bin\u00e4rprogramm cmd\/go und der Test-Caching-Mechanismus k\u00f6nnen jetzt von Kindprozessen implementiert werden, die \u00fcber ein JSON-Protokoll zwischen dem cmd\/go-Tool und dem Kindprozess kommunizieren, benannt durch die Umgebungsvariable GOCACHEPROG. Zuvor war dies durch GOEXPERIMENT m\u00f6glich. Details des Protokolls sind zu sehen in Dokumentation<\/a>.<\/p>\n

<\/noindex> <\/p>\n

Ausf\u00fchrungszeit<\/h2>\n

<\/p>\n

Mehrere Leistungsverbesserungen in der Runtime haben die CPU-Overhead um durchschnittlich 2\u20133 % innerhalb einer Reihe von repr\u00e4sentativen Benchmarks reduziert. Die Ergebnisse k\u00f6nnen je nach Anwendung variieren. Diese Verbesserungen umfassen eine neue eingebaute Implementierung von Maps, die auf Schwedischen Tabellen<\/a>, effizienterem Speicher f\u00fcr kleine Objekte und einer neuen internen Runtime-Implementierung von Mutexen.<\/p>\n

<\/noindex> <\/p>\n

Die neue eingebaute Implementierung von Maps und der neue interne Runtime-Mutex k\u00f6nnen w\u00e4hrend des Builds durch die Einstellungen GOEXPERIMENT=noswissmap und GOEXPERIMENT=nospinbitmutex deaktiviert werden.<\/p>\n

Compiler<\/h2>\n

Der Compiler hat bereits das Definieren neuer Methoden mit Empf\u00e4ngertypen, die mit cgo generiert wurden, verboten, aber es war m\u00f6glich, dieses Verbot durch Typalias zu umgehen. Go 1.24 gibt jetzt immer einen Fehler aus, wenn der Empf\u00e4nger einen generierten cgo-Typ direkt oder indirekt (durch Typalias) bezeichnet.<\/p>\n

Linker<\/h2>\n

Der Linker generiert jetzt standardm\u00e4\u00dfig eine GNU-Build-ID (Eintrag ELF NT_GNU_BUILD_ID) auf ELF-Plattformen und UUID (Mach-O LC_UUID-Boot-Befehl) auf macOS. Die Build-ID oder UUID wird aus der Build-ID von Go abgeleitet. Dies kann mit dem Linker-Flag -B none deaktiviert oder mit dem Linker-Flag -B 0xNNNN mit einem benutzerdefinierten hexadezimalen Wert \u00fcberschrieben werden.<\/p>\n

Rollout<\/h2>\n

<\/p>\n

Wie in den Release-Notizen zu Go 1.22 angegeben<\/a>, Go 1.24 erfordert jetzt Go 1.22.6 oder sp\u00e4ter zum Kompilieren. Die Entwickler erwarten, dass Go 1.26 zum Kompilieren ein Patch-Release von Go 1.24 oder sp\u00e4ter ben\u00f6tigen wird.<\/p>\n

<\/noindex> <\/p>\n

Standardbibliothek<\/h2>\n

Eingeschr\u00e4nkter Verzeichniszugriff auf das Dateisystem<\/h3>\n

<\/p>\n

Neuer Typ os.Root<\/a> erm\u00f6glicht es, Dateisystemoperationen innerhalb eines bestimmten Verzeichnisses auszuf\u00fchren.<\/p>\n

<\/noindex> <\/p>\n

Funktion os.OpenRoot<\/a> \u00f6ffnet ein Verzeichnis und gibt zur\u00fcck os.Root<\/a>. Die Methoden auf os.Root<\/a> arbeiten innerhalb dieses Verzeichnisses und erlauben keine Pfade, die auf Standorte au\u00dferhalb des Verzeichnisses verweisen, einschlie\u00dflich solcher, die symbolischen Links au\u00dferhalb des Verzeichnisses folgen. Die Methoden auf os.Root spiegeln die meisten Dateisystemoperationen wieder, die im os-Paket verf\u00fcgbar sind, einschlie\u00dflich zum Beispiel os.Root.Open<\/a>, os.Root.Create<\/a>, os.Root.Mkdir<\/a> und os.Root.Stat<\/a>.<\/p>\n

<\/noindex> <\/p>\n

Neue Benchmark-Funktion<\/h3>\n

<\/p>\n

Benchmarks k\u00f6nnen jetzt eine schnellere und weniger fehleranf\u00e4llige Methode testing.B.Loop<\/a> f\u00fcr Iterationen in Benchmarks wie for b.Loop() { \u2026 } anstelle typischer Schleifenstrukturen mit b.N wie for range b.N verwenden. Das bietet zwei wesentliche Vorteile:<\/p>\n

<\/noindex> <\/p>\n