Go 1.24 veröffentlicht

 (go.dev)
1 Punkte von GN⁺ 2025-02-15 | 1 Kommentare | Auf WhatsApp teilen
  • Go 1.24 ist das offizielle Update nach Go 1.23 und umfasst eine breite Palette an Änderungen, die Entwickler direkt spüren werden – von Sprachfunktionen über Runtime und Standardbibliothek bis hin zu WebAssembly
  • Auf Sprachebene werden generische Typ-Aliasse nun vollständig unterstützt, sodass sich Typ-Aliasse wie definierte Typen parametrisieren lassen
  • Die Runtime zeigt mit einem map auf Basis von Swiss Tables, Verbesserungen bei kleinen Objekt-Allokationen und Änderungen an internen Mutexen in repräsentativen Benchmarks im Schnitt 2–3 % weniger CPU-Overhead
  • Der go-Befehl ergänzt einen Ablauf zum Nachverfolgen und Ausführen von Tool-Abhängigkeiten eines Moduls, und go vet erkennt Fehler in testbezogenen Deklarationen besser
  • Auch Standardbibliothek und Plattformunterstützung wurden erweitert; unter anderem sollten FIPS 140-3, testing.B.Loop, os.Root, runtime.AddCleanup, go:wasmexport sowie WASI-Reactor-/Library-Builds geprüft werden

Umfang der Änderungen in Go 1.24

  • Go 1.24 ist ein Release mit verschiedenen Verbesserungen gegenüber Go 1.23; die vollständige Liste der Änderungen findet sich in den Go 1.24 release notes
  • Die neue Version kann auf der Go-Download-Seite heruntergeladen werden

Sprachänderung: generische Typ-Aliasse

  • Go 1.24 unterstützt generic type aliases nun vollständig
  • Typ-Aliasse lassen sich wie definierte Typen parametrisieren, was den Ausdrucksspielraum in generischem Code erweitert
  • Die genaue Syntax ist in der language spec enthalten

Verbesserte Runtime-Performance

  • Durch Verbesserungen an der Runtime sinkt der durchschnittliche CPU-Overhead um 2–3 % über eine repräsentative Benchmark-Sammlung hinweg
  • Die Leistungsänderungen beruhen vor allem auf drei Punkten
    • einer neuen eingebauten map-Implementierung auf Basis von Swiss Tables
    • effizienterer Speicherallokation für kleine Objekte
    • einer neuen internen Mutex-Implementierung der Runtime

Verbesserungen an den Go-Tools

  • Der go-Befehl bietet einen Mechanismus zum Nachverfolgen von Tool-Abhängigkeiten eines Moduls
    • go get -tool fügt dem aktuellen Modul eine tool-Direktive hinzu
    • go tool [tool name] führt ein in der tool-Direktive deklariertes Tool aus
    • Weitere Details stehen in den Release Notes zum go command
  • Zum Unterbefehl go vet wurde ein neuer Analyzer namens test hinzugefügt
    • Er meldet häufige Fehler in Deklarationen von Tests, Fuzzern, Benchmarks und Beispielen in Testpaketen
    • Weitere Details stehen in den Release Notes zu vet

Ergänzungen in Standardbibliothek und Runtime-API

  • Die Standardbibliothek enthält ein neues Paket von Mechanismen zur Unterstützung der Einhaltung von FIPS 140-3
    • Um die neuen Mechanismen für zugelassene Algorithmen zu verwenden, sind keine Änderungen am Anwendungscode erforderlich
    • Weitere Details stehen in den Release Notes zur FIPS 140-3 compliance
  • Zusätzlich zu FIPS 140 werden mehrere Pakete, die zuvor im Modul x/crypto lagen, nun in der Standardbibliothek bereitgestellt
  • Benchmark-Code kann die Methode testing.B.Loop verwenden
    • Sie führt Benchmark-Iterationen in der Form for b.Loop() { ... } aus
    • Damit lässt sich die übliche Schleifenstruktur mit b.N ersetzen, etwa for range b.N
    • Dieser Ansatz ist schneller und weniger fehleranfällig
  • Der neue Typ os.Root ermöglicht Dateisystemoperationen, die auf ein bestimmtes Verzeichnis und dessen Unterstruktur beschränkt sind
  • Zur Runtime wurde der neue Bereinigungsmechanismus runtime.AddCleanup hinzugefügt

Verbesserte WebAssembly-Unterstützung

  • Go 1.24 ergänzt die neue Direktive go:wasmexport, mit der Go-Programme Funktionen an WebAssembly-Hosts exportieren können
  • Go-Programme lassen sich als WASI-reactor/library bauen
  • Weitere Details stehen in den Release Notes zu WebAssembly

Weitere Hinweise und Feedback

  • Alle Details finden sich in den Go 1.24 release notes
  • Einige Themen werden in späteren Blogbeiträgen ausführlicher behandelt
  • Falls Probleme entdeckt werden, kann ein issue eingereicht werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-02-15
Meinungen auf Hacker News

  • Die schnellere map-Implementierung ist besonders erfreulich, und es ist auch gut, dass text/template jetzt range-over-func unterstützt.
    In Go 1.23 kam range über Funktionstypen hinzu, aber in Go-Templates funktionierte das bislang nicht.

  • Gefällt mir, weil es geradezu langweilig unspektakulär ist.

  • Ich frage mich, wofür os.Root gedacht ist.
    Soweit ich es verstehe, geht es dabei um Sicherheit, wie in https://github.com/golang/go/issues/67002, aber da intern kein Chroot verwendet wird, könnte am Ende vielleicht doch jemand einen Weg finden, aus Root auszubrechen.

    • chroot ist nur sinnvoll, wenn eine Anwendung verbindlich festlegen kann, dass sie auch künftig nur innerhalb eines einzigen Verzeichnisses arbeiten wird.
      Außerdem braucht der Prozess Superuser-Rechte, daher ist es für Anwendungen, die mit normalen Benutzerrechten laufen, nicht nutzbar.
      os.Root() ist eher so etwas wie ein Sicherheitsgurt für Dateisystemoperationen. Zum Beispiel kann man Arbeiten rund um den Anwendungscache auf das Cache-Verzeichnis beschränken oder einen Dateiserver nur Dateien innerhalb eines passenden freigegebenen Verzeichnisses ausliefern lassen. Es ist keine eiserne Garantie wie chroot, verhindert aber einfache Directory-Traversal-Angriffe.
    • Ich sehe nicht, warum man chroot verwenden müsste.
      Zusammen mit Sandbox-Funktionen wie Capsicum kann man ein Verzeichnis öffnen, bevor man in den Capability Mode wechselt, und später mit os.Root Dateien im Dateisystembaum unterhalb dieses geöffneten Verzeichnisses öffnen.

  • Ich frage mich, ob man Tags angeben kann, die beim Installieren von Tools verwendet werden, die über die tools-Direktive festgelegt wurden.
    Ich habe es wie unten versucht, aber es scheint ohne Tags installiert zu werden.
    go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest

  • Bei GODEBUG=fips140=only heißt es, dass kryptografische Algorithmen, die FIPS 140-3 nicht erfüllen, Fehler zurückgeben oder paniken. Dass die Standardbibliothek absichtlich panikt, gefällt mir nicht besonders.
    Ich habe den Code noch nicht angesehen, frage mich aber, ob das wegen Abwärtskompatibilität nur bei Funktionen passiert, die derzeit keinen Fehler zurückgeben.

    • Das ist eine Funktion, die in Regierungsumgebungen gebraucht wird.
      Wenn man zur Laufzeit nicht prüft, ob FIPS gesetzt ist, riskiert man Compliance-Verstöße, die am Ende zu Audits und endlosen Meetings führen. Ein 30-minütiger Ausfall durch einen Panic ist aus meiner Sicht deutlich besser, als tagelang neue Kontroll- und Prüfverfahren aufzusetzen.
    • Dann setzt man dieses Flag eben nicht.
      Dieses Verhalten ist nützlich für Situationen, die nur zur Laufzeit erkennbar sind. Schon grundlegende Testabdeckung würde das sofort sichtbar machen.
    • Die einzige realistische Alternative ist, einen Fehler zurückzugeben, aber Fehler kann man abfangen und ignorieren.
      Ob das bei Kryptografie wünschenswert ist, ist fraglich. Ein Warning-Log-Level sollte man meiner Meinung nach vermeiden. Wenn etwas wichtig und handlungsrelevant ist, sollte es ein Fehler oder ein Fatal-Log sein; andernfalls reicht ein Info-Log.
    • Ich habe gelesen, dass dieser Teil wohl in Go 1.25 bereinigt wird.
      https://devblogs.microsoft.com/go/go-1-24-fips-update/
    • Wie in den Geschwisterkommentaren erwähnt, ist in manchen Fällen Durchsetzung nötig.
      Man kann es auch als Weg sehen, versteckte Bugs zu vermeiden. Es ist ähnlich wie "The server chose violence" [1] [2], und man sollte auch bedenken, wie sehr Postels Gesetz die Interoperabilität ausgebremst hat. Dieser Punkt wird bei vielen Aspekten der FIPS-Zertifizierung oft vergessen.
      [1] https://cliffle.com/blog/hubris-reply-fault/
      [2] https://news.ycombinator.com/item?id=40178652

  • Endlich sind generische Typ-Aliase da; diese Funktion war längst überfällig.

  • Auf das neue tool-Flag freue ich mich am meisten. Jetzt kann man das unschöne tools.go loswerden.

  • Gut. Auf dieses Release habe ich wegen GOAUTH gewartet.
    Ich hoffe, dass die Arbeit mit privaten git-Repositories weniger lästig wird, aber nach go help goauth zu urteilen, sollte man wohl nicht zu viel erwarten.