Rust neu schreiben

Rust neu schreiben

• Die Programmiersprache Rust fühlt sich wie ein Produkt der ersten Generation an
• Rusts anfängliche Attraktivität: algebraische Typen, Speichersicherheit, kein Performance-Verlust, moderner Paketmanager
• Nach vier Jahren Nutzung ist Rust nicht immer perfekt
• Die Weiterentwicklung der Sprache hat sich stark verlangsamt
• Viele instabile Features wurden nicht in stabiles Rust übernommen

Eine fantastische Sprache

• Ich möchte den Rust-Compiler forken und eine neue Edition namens "seph" erstellen
• Dabei könnten die bestehenden Features von Rust erhalten und gleichzeitig neue Funktionen hinzugefügt werden

Funktionstraits (Effekte)

• Rust definiert Traits für Structs, aber es müssen auch Traits für Funktionen definiert werden
• Damit lassen sich verschiedene Eigenschaften von Funktionen ausdrücken
  • ob eine Funktion einen Panic auslösen kann
  • ob sie eine feste Stack-Größe hat
  • ob die Funktion bis zum Ende läuft oder unterwegs pausiert
  • ob die Funktion rein ist
  • ob sie unsicheren Code ausführt
  • ob sie Terminierung garantiert

Compile-Time-Features

• Viele Rust-Projekte verwenden zahlreiche Third-Party-Crates
• Diese Crates erhöhen das Supply-Chain-Risiko
• Vorgeschlagen wird ein Feature, mit dem sich sicherheitsrelevante Funktionsaufrufe explizit erlauben lassen
• Um Features wie fs_write aufzurufen, müsste dies ausdrücklich erlaubt werden

Pin, Move und das Ausleihen von Structs

• Pin ist ein komplexer Hack, um Probleme des Borrow Checkers in Rust zu lösen
• Statt Pin wäre ein Marker-Trait Move sinnvoller
• Vorgeschlagen wird zusätzliche Syntax, mit der sich Struct-Felder als verliehen markieren lassen
• Vorgeschlagen wird die Einführung eines Marker-Traits Move und eines Traits Mover

Compile-Time

• Einführung von Zigs comptime-Feature als Ersatz für Rusts Makrosprache
• Hinzufügen eines kleinen Interpreters, der Code zur Compile-Time ausführen kann
• Statt Rusts Makrosprache würde Rust selbst verwendet

Kleine Anpassungen

• impl<T: Copy> for Range<T> korrigieren
• derive mit assoziierten Typen korrigieren
• logisches AND in if-let-Ausdrücken unterstützen
• die Nutzbarkeit von Raw Pointers verbessern
• allen eingebauten Collection-Typen ein Allocator-Argument hinzufügen

Abschließende Gedanken

• Auch die asynchronen Features brauchen Verbesserungen, dafür wäre aber ein eigener Beitrag nötig
• Die meisten Änderungen sind nicht mit bestehendem Rust kompatibel
• Möglicherweise ist eine neue Rust-Edition erforderlich
• Statt sich weiter am GitHub-RFC-Prozess aufzureiben, wird erwogen, den Compiler direkt zu forken

Zusammenfassung von GN⁺

• Rust ist trotz seiner anfänglichen Attraktivität nicht perfekt
• Die Weiterentwicklung der Sprache verlangsamt sich, und viele instabile Features wurden nicht in stabiles Rust übernommen
• Es gibt verschiedene Vorschläge, darunter Funktionstraits, Compile-Time-Features sowie Verbesserungen bei Pin und Move
• Diese Vorschläge könnten die Nutzbarkeit von Rust deutlich verbessern
• Eine andere Sprache mit ähnlichen Features ist Zig

[GN⁺]

Hacker-News-Kommentare

• Meinung zum Rust-RFC-Prozess

  • Dass das Rust-Kernteam es schwer macht, neue Funktionen hinzuzufügen, ist die richtige Entscheidung, um die Konsistenz und Vorhersehbarkeit der Sprache zu bewahren.
  • Bei Swift führte die Einführung vieler neuer Funktionen zu mehr Komplexität, sodass man Swift am Ende aufgegeben hat.
  • Es ist wichtig, Rust so knapp wie möglich zu halten.

• Rusts Abhängigkeitsproblem

  • Am Beispiel des Crates Cargo-watch: Es ist zwar eine einfache App zur Dateiüberwachung, umfasst durch seine Abhängigkeiten aber 4 Millionen Codezeilen.

• Rusts aktueller Zustand

  • Rust befindet sich jetzt in der Phase „Arbeit für breite Akzeptanz“.
  • Langsame Feature-Entwicklung ist natürlich und gesund, und falsche Designentscheidungen können größeren Schaden anrichten.
  • Rusts Reiz liegt weniger in neuen Funktionen als in Speichersicherheit und darin, eine produktionsreife Sprache ohne GC zu sein.

• Meinung zum Rewrite von Rust

  • Rust in Rust neu zu schreiben wirkte wie ein meta-satirischer Witz.

• Unzufriedenheit mit Rusts Entscheidungsprozess

  • Es gibt Unmut über den langsamen Entscheidungsprozess, aber das ist eher ein Problem von Menschen und Zeit als ein technisches.
  • Einige ältere Funktionen sind ins Stocken geraten, aber viele Funktionen werden voraussichtlich nicht stabilisiert.

• Kommentar von Josh Triplett

  • Er weist darauf hin, dass ein bestimmtes Beispiel falsch ist, und teilt dazu einen relevanten Link.

• Meinung zu Rusts Komplexität

  • Rust hat bereits viele Funktionen, aber es gibt Leute, die noch mehr verlangen.
  • Zig ist einfacher, schneller und hat weniger Community-Drama.

• Meinung zu Rusts Geschwindigkeit

  • Wenn ein Projekt reift, ist viel Aufwand nötig, um bestehende Funktionen zu verfeinern.
  • Die Zusammenarbeit zwischen Teams ist schwieriger geworden, und es gibt Projektziele, um das zu verbessern.

• Meinung zu Mutex-Verbesserungen

  • Es wurde viel daran gearbeitet, Rusts Synchronisationsprimitive zu verbessern.
  • Funktionen wie asynchrone Funktionen wurden hinzugefügt; sie bilden die Grundlage für komplexere Features.

• Meinung zur Geschwindigkeit der Feature-Entwicklung in Rust

  • Es gibt Leute, die sich beschweren, dass sich die Sprache zu schnell oder zu langsam entwickelt.
  • Einige bestimmte Features kommen nur schleppend voran, aber insgesamt läuft viel Aktivität.

• Meinung zum Feature-Design in Rust

  • Bei Features wie Function Traits gab es zuletzt größere Design-Erkundungen.
  • Compile-Time-Features lassen sich nicht auf Sprachebene lösen; Lösungen wie WebAssembly sind wahrscheinlicher.

• Probleme mit Rusts Borrow Checker

  • Selbstreferenzielle Strukturen zu verstehen ist ein sehr schwieriges Problem.
  • Wie man partielles Borrowing unterstützt, ist bereits bekannt, aber das Problem ist, dies im Typsystem offenzulegen.

• Rusts Compile-Time-Features

  • Es wurde ein RFC geschrieben, um Makroregeln mächtiger zu machen.
  • Für programmgesteuertes Parsing ist mehr Arbeit nötig.

• Rusts instabile Features

  • Es gibt viele instabile Features, und es ist nötig, diese aufzuräumen.

• Meinung zu Rusts Entwicklungstempo

  • Durch Mozillas Ausstieg wurde das Projekt langsamer, aber das ist immer noch besser, als den falschen Weg einzuschlagen.