John Carmack: Mit der Goose Language wird aus „vieles geht so“ plötzlich „im Grunde alles“

Ich bin neugierig, für jemanden, der mit Goose besser vertraut ist: Wie stellt man eine beliebige Anzahl dynamisch großer Werte dar? Wenn man eine feste Anzahl von Stacks hat, scheint es, als könnten sich nur eine feste Anzahl von Werten zu einem bestimmten Zeitpunkt in der Größe ändern.

Zum Beispiel, wie würde man eine Hashtabelle darstellen, bei der die Werte Strings sind und das Programm zufällig einen zufälligen String einfügt oder löscht?

Das scheint nichts zu sein, was man leicht darstellen könnte. Die einzige Möglichkeit, die mir einfällt, ist, einen Stack zu halten, der alle deine Strings enthält, und ihn regelmäßig zu kompaktieren.

Edit: Vielleicht könnte man auch einen separaten Stack für Strings verschiedener Größen haben. Einen für Strings kleiner als 8, 16, ... Bytes. Aber dann implementiert man im Grunde genommen sein eigenes malloc von Hand.

Edit: Fwiw ich finde Goose wirklich cool! Ich musste in Rust schon viel ähnliches von Hand schreiben, um die Speicherverwaltung zu beschleunigen

"Threads, die nichts teilen. Ein Worker wird als separates Programm mit eigenem Speicher kompiliert, und flache Werte überqueren typisierte Warteschlangen als memcpy. Data Races, Locks, Atomics und Memory Orderings existieren in der Sprache nicht."

Das erinnert mich an Dart Isolates - https://dart.dev/language/isolates

Ich meine mich zu erinnern, dass die ML-Leute diesen Weg eingeschlagen haben. Ich glaube, sie nannten es Regions.

Soweit ich in der Literatur gelesen habe, erinnere ich mich, dass es genug Programme mit deutlich mehr Speicherverbrauch gab, dass sie entschieden, dieser Ansatz sei eine Sackgasse.

Weiß jemand mehr Details?

"Das sieht wirklich ordentlich aus! Die automatische Analyse und Nutzung mehrerer Datenstacks und größenveränderbarer Felder bringt es von 'viel Arbeit kann so erledigt werden' zu 'im Grunde alles kann so erledigt werden'.

Die relativen Referenzen und die eingebaute binäre Strukturvalidierung ermöglichen auch direktes Memory-Mapping von Datenstrukturen und sofortige Nutzung von Netzwerkdaten. 'Parsing' von Datei- und Netzwerkdaten ist oft 100x langsamer als nötig." - John Carmack

Das sieht sehr interessant aus! Ich schreibe meistens in garbage-collected Sprachen (soweit ich überhaupt noch etwas von Hand schreibe...) also bin ich in Debatten über Speicherverwaltung nur Zuschauer, aber es ist mir oft aufgefallen, dass Heap-Management mehr Kunst als Wissenschaft ist. Die Idee, Speicher eher wie Stacks zu behandeln, leuchtete mir sofort intuitiv ein. Ich bin auch fasziniert von der Thread-Implementierung, obwohl ich nicht genug Wissen habe, um die potenziellen Vor- und Nachteile gegenüber anderen Ansätzen zur Nebenläufigkeit durchzudenken.

Ich frage mich, ob der Name der Sprache von der Art inspiriert wurde, wie Gänse in Formation fliegen, wobei die hinteren Vögel Energie sparen, indem sie im aerodynamischen Schatten der Anführer fliegen und nach Bedarf wechseln. Wenn ja, eine sehr schöne Metapher für das Speicherverwaltungsmodell.

Ich war auch von der Dokumentation beeindruckt. Wie wir wissen, neigen KI-generierte Dokumente dazu, eher mittelmäßig zu sein, aber der Autor hat offensichtlich Zeit investiert, um sie lesbar zu machen, so dass die Relevanz und Begründung von Designentscheidungen den Kontext liefern, den ein neugieriger Programmierer braucht, um zu verstehen, warum Dinge auf eine bestimmte Weise implementiert sind.

Ich habe die detaillierten Beispiele sehr geschätzt, von einfachen algorithmischen Theoremen bis hin zu einem kleinen Spiel. Wiederum habe ich nicht die Erfahrung, die Sprache mit anderen zu vergleichen, aber ich war beeindruckt, wie lesbar der Code war und wie einfach es war, dem Aufgabenfluss zu folgen. Nicht über Klassen nachdenken zu müssen, ist immer ein Plus!

Jedenfalls, ich begrüße normalerweise das Angebot einer neuen Sprache mit Gelassenheit […]

Goose ist ziemlich cool. Die Idee ist, dass man nicht alle Programme darstellbar machen muss: eine Sprache für einen eingeschränkten Zweck ist in Ordnung. Solange man die Anzahl der wachsenden Speicherbereiche statisch angeben kann, kann man Goose verwenden. Da es jedoch keine Garbage Collection gibt, muss man wahrscheinlich vorsichtig mit dem Speicherverbrauch während der Laufzeit eines Programms sein. Das heißt: Die Stacks können zu groß werden, wenn man sie immer weiter wachsen lässt, selbst wenn alte Daten nicht mehr verwendet werden.

Dennoch ist es für eine große Anzahl von Programmen – wie datenorientierte Anwendungen – wahrscheinlich gut geeignet. Es könnte mit Entity-Component-Spielsystemen funktionieren, solange man alten Speicher wiederverwendet…

Wie würde das im Wasm-Land funktionieren? Die Frage ist etwas schlecht formuliert, weil sie viel Kontext auslässt – Wasm – wo, wie, welche Implementierung –, aber nach meinem einfachen Verständnis läuft das meiste Wasm als 32-Bit im Browser. Damit das funktioniert, braucht es einen echten virtuellen 64-Bit- (oder 48-Bit-) Adressraum. Der Host, also der Browser oder etwas anderes, könnte ihn bereitstellen, aber....

Wenn der Host mehrere dieser .wasm-Dateien laden muss, die mit Goose kompiliert wurden, dann muss er sie auch in separaten (Browser-)Instanzen ausführen (oder vielleicht funktioniert Wasm standardmäßig so – nicht sicher).

Es hat mich einfach zum Nachdenken gebracht – die Sprache ist darauf vorbereitet, in JavaScript-Worker übersetzt zu werden, weil sie von Natur aus wirklich single-threaded ist mit Kommunikation zwischen Threads (oder in der Dart-Sprache "Isolates"), was sie perfekt für den Browser macht. Jetzt ist die einzige Frage das Speicherlayout.