Entfernung der Core Types und die schlanke Weiterentwicklung der Go-Sprache

• Mit der Einführung von Generics in Go 1.18 wurde auch das neue Konzept der Core Types hinzugefügt, doch es wurde beschlossen, es in 1.25 wieder zu entfernen
• Core Types sind ein abstraktes Konzept zur Vereinfachung der Compiler-Implementierung und ersetzen bei der Verarbeitung generischer Typoperanden den bisherigen Underlying Type
• Auch in der Sprachspezifikation wurde der bisherige „Underlying Type“ durch den „Core Type“ ersetzt

Typparameter und Type Constraints

• Typparameter dienen als Platzhalter für einen Typ, der erst später festgelegt wird, und werden zur Compile-Zeit bestimmt
• Type Constraints legen fest, welche Operationen für den jeweiligen Parametertyp möglich sind
• In Go werden Type Constraints durch die Kombination von Methoden- und Typanforderungen definiert; daraus entsteht ein Type Set
• Ein Type Set bezeichnet die Menge aller Typen, die ein bestimmtes Interface erfüllen

  type Constraint interface {  
    ~[]byte | ~string  
    Hash() uint64  
  }  
  

• Dieser auf Type Sets basierende Ansatz ist sehr flexibel und leistungsfähig für die Definition von Operationen auf generischen Typen

  func at[bytestring Constraint](s bytestring, i int) byte {  
    return s[i]  
  }  
  

Einführung und Grenzen der Core Types

• Core Types wurden als Regel definiert, um die Nutzung generischer Typen bei bestimmten Operationen zu vereinfachen
• So wird ein Core Type bestimmt:
  • Bei einem gewöhnlichen Typ ist der Core Type identisch mit dem Underlying Type dieses Typs
  • Bei einem Typparameter existiert ein Core Type nur dann, wenn alle Typen im Type Set denselben Underlying Type haben
• Dieser Ansatz führte jedoch zu mehreren Problemen:
  • Die Sprachspezifikation wurde komplexer, sodass selbst einfache Regeln schwerer verständlich wurden
  • Das Konzept der Core Types wurde unnötigerweise auch in nicht-generischem Code erwähnt
  • Einige Operationen mit Core Types waren übermäßig restriktiv, sodass in der Praxis sichere Operationen dennoch nicht erlaubt waren
  • Durch Inkonsistenzen mit Regeln, die keine Core Types verwenden, litt die Konsistenz des Sprachdesigns insgesamt

Entfernung der Core Types in Go 1.25

• Für das Release Go 1.25 (geplant für August 2025) wurde entschieden, das Konzept der Core Types aus der Sprachspezifikation zu entfernen
• Stattdessen werden die für jede Operation nötigen Constraints in expliziten Formulierungen beschrieben
• Die wichtigsten Auswirkungen dieser Änderung:
  • Weniger Konzepte erleichtern das Erlernen der Go-Sprache
  • Nicht-generischer Code wird klarer, ohne von generischen Konzepten abzuhängen
  • Für einzelne Operationen lassen sich flexiblere Regeln entwerfen
  • Es entsteht eine Grundlage für künftige Erweiterungen (z. B. Zugriff auf gemeinsame Felder, erweiterte Slice-Funktionen, bessere Typinferenz)

Wichtige Änderungen und erwartete Effekte

• Alle Formulierungen in der Spezifikation, die sich auf Core Types bezogen, werden entfernt oder durch explizite Sätze ersetzt
• Auch in Compiler-Fehlermeldungen entfällt der Begriff Core Type und wird durch konkretere Erklärungen ersetzt
• Das Verhalten bestehender Go-Programme ändert sich nicht
• Die Sprachspezifikation wird einfacher, und aus Sicht der Nutzer wird Go intuitiver und klarer

[GN⁺]

Hacker-News-Kommentare

• Es ist gut, dass das Go-Team Änderungen an der Spezifikation sehr vorsichtig behandelt

  • Go-Generics sind eine große Veränderung und können schwer zu verwenden sein
  • Ich denke, dass Einschränkungen einen übermäßigen Einsatz von Generics verhindern
  • Ich habe in Java- und Typescript-Projekten gesehen, dass ein übermäßiger Einsatz des Typsystems den Code unklar macht
  • Ich hoffe, dass das Go-Team die Sprache weiterhin konservativ weiterentwickelt

• Die letzten 10 Jahre des Go-Entwicklungsteams waren ein Prozess, das Gleichgewicht zwischen Funktionen und Einfachheit zu finden

  • Generics zeigen diese Dynamik sehr gut
  • Ein Typsystem wie in Rust auf Go aufzusetzen, bringt zu viel Komplexität mit sich
  • Eine leichte Rückkehr in Richtung stärkerer Einfachheit ist gut
  • Go zielt darauf ab, für Teams mit Ingenieuren auf mittlerem Niveau das bessere Java zu sein

• Go 1.25 fügt keine echten Sprachfeatures hinzu

  • In 1.30 könnten Sum Types hinzukommen

• Ich verfolge Go seit der Zeit vor den Windows-Builds

  • Alles, was ich 2011 gelernt habe, ist immer noch gültig
  • Ich hatte keine Gelegenheit, mit Go zu arbeiten, habe es aber mit kleinen Projekten gelernt
  • In einem Interview mit Go-Entwicklern war ich enttäuscht über die Aussage, dass Generics wohl nicht in Go eingeführt würden
  • Jetzt, da Generics eingeführt wurden, plane ich, mit Go ein Side-Project zu starten

• Dass beim Argument von close als Typparameter alle Typen Kanäle mit demselben Elementtyp sein müssen, stimmt tatsächlich nicht

  • Der Elementtyp hat keinen Einfluss auf close, und auch bei Type Sets mit unterschiedlichen Elementtypen wird sauber kompiliert
  • Die Dokumentation muss verbessert werden
  • Ich hoffe, dass flexible Erweiterungen wie gemeinsame Felder schneller vorankommen

• Ich lerne Go gerade langsam und habe einen C++-Hintergrund

  • Ich frage mich, ob das etwas Ähnliches wie Template-Spezialisierung ist
  • Ich wünschte, mehr Sprachen würden das unterstützen

• [dead]

• Jetzt kann generative KI Code schreiben, da frage ich mich, ob ein Garbage Collector überhaupt noch nötig ist

[aer0700]

Jetzt, da generative KI Code schreiben kann, frage ich mich, ob wir überhaupt noch einen Garbage Collector brauchen.
> Das ist vielsagend ...

[galadbran]

Oh … wenn KI einmal Code auf diesem Niveau schreiben kann (Code, der die Speicherverwaltung perfekt beherrscht), wird es für menschliche Entwickler wohl schwer, weiterhin dieselbe Rolle wie heute zu haben.

[kandk]

Wenn sich 1+1=2 mathematisch lösen lässt, warum sollte man es dann unbedingt mit KI lösen..

[jeiea]

Hat nicht auch GC eine Bedeutung, wenn es darum geht, Boilerplate, die Menschen lesen müssen, und den Codekontext, den man nachverfolgen muss, zu verringern?
Wenn damit vorhergesagt wird, dass man den Code irgendwann gar nicht mehr lesen muss, dann weiß ich auch nicht.
Wenn man sieht, dass schon der ursprüngliche Kommentar ausgegraut ist, scheint er auch nicht auf viel Zustimmung gestoßen zu sein.

[savvykang]

Lässt sich Reference Counting nicht entfernen, wenn sich der Zeitpunkt der Speicherallokation und -freigabe zur Compile-Zeit berechnen lässt? Es scheint, als würde der Verfasser des ursprünglichen Hacker-News-Kommentars das Problem der Speicherwiederverwendung nicht verstehen.