Rust-Traits versus Go-Interfaces: explizites impl, implizite Erfüllung

Worum es geht

Go: Die Spezifikation besagt, dass ein Typ ein Interface implementiert, wenn er zur Typmenge des Interfaces gehört, was bei reinen Methoden-Interfaces bedeutet, dass er diese Methoden besitzt; keine Deklaration verknüpft die beiden. Rust: Ein Trait deklariert erforderliche und optional auch Standardmethoden, und ein Typ erhält ihn nur über impl Trait for Type. Das Rust-Buch erklärt die Waisenregel (orphan rule) als Teil der Kohärenz: Eine Implementierung ist nur zulässig, wenn der Trait oder der Typ lokal zur aktuellen Crate gehört, was garantiert, dass zwei Crates keine widersprüchlichen Implementierungen ausliefern können. Traits können assoziierte Typen und Konstanten tragen, als Bounds für Generics dienen (fn f<T: Display>(x: T) oder impl Display in Argument- oder Rückgabeposition) und in Trait-Objekte umgewandelt werden (Box<dyn Display>). Das Buch beschreibt Generics als zur Kompilierzeit monomorphisiert (eine Codekopie pro konkretem Typ, statischer Dispatch) und Trait-Objekte als dynamischen Dispatch, der zur Laufzeit aufgelöst wird. Go-Interface-Werte werden immer dynamisch dispatcht; Go-Generics (seit 1.18) verwenden stattdessen Interfaces als Constraints.

Warum es wichtig ist

Beide beantworten die erste Frage, die sich Programmierende aus dynamischen Sprachen stellen: wie sich Code für mehrere Typen schreiben lässt, ohne Vererbung. Rusts explizites impl bedeutet, dass ein Typ einen Trait nicht versehentlich erfüllen kann, und die Waisenregel bedeutet, dass ein fremder Trait nicht direkt für einen fremden Typ implementiert werden kann; das Newtype-Muster (eine Wrapper-Struktur mit einem Feld) ist der übliche Weg, das zu umgehen. Gos Implizitheit bedeutet, dass ein Interface nachträglich, auf Seiten des Verbrauchers, für Typen definiert werden kann, die der Verbraucher nicht besitzt – so injizieren Tests Fakes für Clients von Drittanbietern.

So wird es angewendet

• In Go kleine Interfaces am Ort der Verwendung definieren; in Rust Traits dort definieren, wo das Verhalten festgelegt wird, und sie bei Bedarf über ein lokales Newtype für fremde Typen implementieren.
• In Rust bei heissen Pfaden und homogenen Sammlungen Generics mit Bounds bevorzugen, und dyn Trait, wenn eine Sammlung unterschiedliche Typen aufnehmen muss oder wenn Kompilierzeit und Binärgrösse stärker zählen als die Dispatch-Kosten.
• Standardmethoden und Blanket-Implementierungen (impl<T: Display> Describe for T) nutzen, um vielen Typen auf einmal Verhalten zu geben; Go kennt kein Äquivalent und setzt auf Embedding und Hilfsfunktionen.
• Standard-Traits (Debug, Clone, PartialEq) mit #[derive] ableiten; in Go String() und Error() von Hand implementieren.

Stolpersteine

Rust: Ein Trait muss im Scope stehen (use), damit seine Methoden aufrufbar sind, und das Buch weist darauf hin, dass Rust Regeln dafür hat, wo dynamischer Dispatch verwendet werden darf – genannt dyn-Kompatibilität –, sodass nicht jeder Trait zu einem dyn Trait werden kann. Go: Ein Typ mit Pointer-Receiver-Methoden erfüllt das Interface nur als Pointer, und ein Interface-Wert, der einen nil-Pointer enthält, ist selbst nicht nil.