Diese Fallstricke können Rust-Bestrebungen erodieren lassen.James M Crittenden | shutterstock.com Eine neue Programmiersprache zu erlernen, ist nicht nur Eitel Sonnenschein, sondern birgt auch erhebliches Frustrationspotenzial. Insbesondere, wenn es um neue, komplexe Zusammenhänge geht – die man zum Einstieg (noch) nicht wirklich durchdringen muss. In diesem Artikel haben wir vier Don’ts zusammengetragen, die sich Developer mit Rust-Ambitionen zu Herzen nehmen sollten. 1. Aktualität voraussetzen Rust ist eine Sprache, die sich rasant weiterentwickelt. Seine Dokumentation hält dabei nicht immer Schritt. Hüten Sie sich deshalb vor Lernmaterialien, die Sie mit veralteten Beispielen in die Irre führen. In diese Falle kann grundsätzlich jeder tappen – allerdings ist diese Gefahr bei Neulingen, die nicht mit dem Status Quo vertraut sind, ungleich höher. Ältere Versionen von Rust beinhalteten beispielsweise ein Makro namens try!, das verwendet wurde, um Ergebnisse zu “unwrappen” und eventuell zurückgegebene Fehler weiterzugeben. Inzwischen wurde dieses durch den ?-Operator ersetzt, der nativer Bestandteil der Rust-Syntax ist. Es ist nur ein Beispiel von vielen, das Sie auf veraltete Wege führt. Grundsätzlich ist deshalb jedes Rust-Tutorial, das älter als zwei Jahre ist, mit Vorsicht zu genießen. Ebenso wie undatiertes Material. 2. In alte Gewohnheiten zurückfallen Einige Konzepte, die in Rust zur Anwendung kommen, können anfangs frustrieren. So gehen etwa Ownership/Borrowing-Metaphern für das Memory Management oder typbasiertes Error Handling mit steilen Lernkurven einher. An dieser Stelle einfach die Konzepte anderer Sprachen heranzuziehen, wäre jedoch nicht zielführend. Insbesondere sollten Sie unbedingt davon absehen, Memory Management im Stil von C (oder gar C++) verwenden oder direkten Raw-Memory-Zugriff über Pointer herstellen zu wollen. Referenzen sind diesbezüglich “safe”, weil sie immer über Borrowing und Ownership getrackt werden. Pointer (deren Verwendung Sie explizit aktivieren müssen) können in der Theorie auf alles mögliche verweisen, weswegen sie von Natur aus “unsafe” sind. Die Lösung besteht an dieser Stelle allerdings nicht darin, Ihren Code großzügig mit unsafe{} auszuschmücken, um Pointer innerhalb dieser Bereiche dereferenzieren zu können. Nutzen Sie stattdessen von Anfang an Referenzen und machen Sie sich mit Typen wie Box, Rc und Arc vertraut. Sie ermöglichen es, Ownership-Regeln für beliebige Memory-Bereiche zu nutzen. So müssen Sie sich gar nicht erst mit dem Thema Raw Pointer beschäftigen. Und sollten Sie wirklich keine andere Wahl haben: Beschränken Sie Pointer auf die kleinstmöglichen unsafe{}-Bereiche und extrahieren Sie aus diesen Rust-Werte, die “safe” sind. Insbesondere C++-Entwickler versuchen oft, die gewohnten Idiome in Rust zu reproduzieren. Wenn Sie zu diesen geplagten Kandidaten gehören, kann das “C++ to Rust Phrasebook” unter Umständen eine Hilfestellung bieten, um elegant von C++- zu Rust-Konzepten überzugehen. 3. Sämtliche String-Typen durchdringen wollen Innerhalb des Rust-Ökosystems existieren diverse String-Typen, um Text zu verarbeiten. Diese sind in vielen Fällen für spezifische Tasks gedacht. Falls Sie lediglich Strings zwischen Funktionen übergeben oder auf der Konsole ausgeben möchten, müssen Sie sich darüber (erst einmal) keine Gedanken machen. Konzentrieren Sie sich stattdessen zunächst lieber auf die beiden gängigsten String-Typen: str (unveränderlich, entspricht im Wesentlichen dem, was String-Literale im Code liefern) und String (veränderlich, wird immer im Heap gespeichert). Nutzen Sie str, um String-Konstanten zu erstellen und &str, um “borrowed” Referenzen auf vorhandenen String-Werten abzurufen. Alles andere kann vorerst warten. 4. Auf Cloning verzichten Ihr Erfolg als Rust-Programmierer hängt ganz wesentlich davon ab, erkennen zu können, wann Memory Management unerlässlich ist. Solange Sie allerdings noch nicht mit der Syntax und den Tools der Sprache vertraut sind, kann dieser Aspekt eine enorme Belastung darstellen. Ein Weg, die Borrowing-Sorgen vergessen zu machen, besteht darin, Objekte zu klonen – statt die Ownership zu übertragen. Im Rahmen dieses Cloning-Prozesses wird eine neue Instanz derselben Daten erstellt, jedoch mit einem neuen, unabhängigen Owner. Die ursprüngliche Instanz behält hingegen ihren ursprünglichen Owner, so dass es keine Object-Ownership-Probleme entstehen können. Und: Wie beim Originalobjekt wird auch der Klon automatisch gelöscht, sobald er den Scope verlässt. Der Nachteil: Cloning kann Performance kosten, insbesondere wenn Sie darauf mehrere Male innerhalb eines Loops zurückgreifen. Speziell wenn es um leistungssensitiven Code geht, sollten Sie das deshalb vermeiden. Bis Sie diese Art von Code erstellen (und gelernt haben, wie Sie Metriken nutzen, um Hot Paths im Code zu erkennen), können Sie auf Cloning setzen, um die Ownership-Chain Ihrer Objekte klarer herauszustellen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
4 Don’ts für Rust-Einsteiger
Diese Fallstricke können Rust-Bestrebungen erodieren lassen.James M Crittenden | shutterstock.com Eine neue Programmiersprache zu erlernen, ist nicht nur Eitel Sonnenschein, sondern birgt auch erhebliches Frustrationspotenzial. Insbesondere, wenn es um neue, komplexe Zusammenhänge geht – die man zum Einstieg (noch) nicht wirklich durchdringen muss. In diesem Artikel haben wir vier Don’ts zusammengetragen, die sich Developer mit Rust-Ambitionen zu Herzen nehmen sollten. 1. Aktualität voraussetzen Rust ist eine Sprache, die sich rasant weiterentwickelt. Seine Dokumentation hält dabei nicht immer Schritt. Hüten Sie sich deshalb vor Lernmaterialien, die Sie mit veralteten Beispielen in die Irre führen. In diese Falle kann grundsätzlich jeder tappen – allerdings ist diese Gefahr bei Neulingen, die nicht mit dem Status Quo vertraut sind, ungleich höher. Ältere Versionen von Rust beinhalteten beispielsweise ein Makro namens try!, das verwendet wurde, um Ergebnisse zu “unwrappen” und eventuell zurückgegebene Fehler weiterzugeben. Inzwischen wurde dieses durch den ?-Operator ersetzt, der nativer Bestandteil der Rust-Syntax ist. Es ist nur ein Beispiel von vielen, das Sie auf veraltete Wege führt. Grundsätzlich ist deshalb jedes Rust-Tutorial, das älter als zwei Jahre ist, mit Vorsicht zu genießen. Ebenso wie undatiertes Material. 2. In alte Gewohnheiten zurückfallen Einige Konzepte, die in Rust zur Anwendung kommen, können anfangs frustrieren. So gehen etwa Ownership/Borrowing-Metaphern für das Memory Management oder typbasiertes Error Handling mit steilen Lernkurven einher. An dieser Stelle einfach die Konzepte anderer Sprachen heranzuziehen, wäre jedoch nicht zielführend. Insbesondere sollten Sie unbedingt davon absehen, Memory Management im Stil von C (oder gar C++) verwenden oder direkten Raw-Memory-Zugriff über Pointer herstellen zu wollen. Referenzen sind diesbezüglich “safe”, weil sie immer über Borrowing und Ownership getrackt werden. Pointer (deren Verwendung Sie explizit aktivieren müssen) können in der Theorie auf alles mögliche verweisen, weswegen sie von Natur aus “unsafe” sind. Die Lösung besteht an dieser Stelle allerdings nicht darin, Ihren Code großzügig mit unsafe{} auszuschmücken, um Pointer innerhalb dieser Bereiche dereferenzieren zu können. Nutzen Sie stattdessen von Anfang an Referenzen und machen Sie sich mit Typen wie Box, Rc und Arc vertraut. Sie ermöglichen es, Ownership-Regeln für beliebige Memory-Bereiche zu nutzen. So müssen Sie sich gar nicht erst mit dem Thema Raw Pointer beschäftigen. Und sollten Sie wirklich keine andere Wahl haben: Beschränken Sie Pointer auf die kleinstmöglichen unsafe{}-Bereiche und extrahieren Sie aus diesen Rust-Werte, die “safe” sind. Insbesondere C++-Entwickler versuchen oft, die gewohnten Idiome in Rust zu reproduzieren. Wenn Sie zu diesen geplagten Kandidaten gehören, kann das “C++ to Rust Phrasebook” unter Umständen eine Hilfestellung bieten, um elegant von C++- zu Rust-Konzepten überzugehen. 3. Sämtliche String-Typen durchdringen wollen Innerhalb des Rust-Ökosystems existieren diverse String-Typen, um Text zu verarbeiten. Diese sind in vielen Fällen für spezifische Tasks gedacht. Falls Sie lediglich Strings zwischen Funktionen übergeben oder auf der Konsole ausgeben möchten, müssen Sie sich darüber (erst einmal) keine Gedanken machen. Konzentrieren Sie sich stattdessen zunächst lieber auf die beiden gängigsten String-Typen: str (unveränderlich, entspricht im Wesentlichen dem, was String-Literale im Code liefern) und String (veränderlich, wird immer im Heap gespeichert). Nutzen Sie str, um String-Konstanten zu erstellen und &str, um “borrowed” Referenzen auf vorhandenen String-Werten abzurufen. Alles andere kann vorerst warten. 4. Auf Cloning verzichten Ihr Erfolg als Rust-Programmierer hängt ganz wesentlich davon ab, erkennen zu können, wann Memory Management unerlässlich ist. Solange Sie allerdings noch nicht mit der Syntax und den Tools der Sprache vertraut sind, kann dieser Aspekt eine enorme Belastung darstellen. Ein Weg, die Borrowing-Sorgen vergessen zu machen, besteht darin, Objekte zu klonen – statt die Ownership zu übertragen. Im Rahmen dieses Cloning-Prozesses wird eine neue Instanz derselben Daten erstellt, jedoch mit einem neuen, unabhängigen Owner. Die ursprüngliche Instanz behält hingegen ihren ursprünglichen Owner, so dass es keine Object-Ownership-Probleme entstehen können. Und: Wie beim Originalobjekt wird auch der Klon automatisch gelöscht, sobald er den Scope verlässt. Der Nachteil: Cloning kann Performance kosten, insbesondere wenn Sie darauf mehrere Male innerhalb eines Loops zurückgreifen. Speziell wenn es um leistungssensitiven Code geht, sollten Sie das deshalb vermeiden. Bis Sie diese Art von Code erstellen (und gelernt haben, wie Sie Metriken nutzen, um Hot Paths im Code zu erkennen), können Sie auf Cloning setzen, um die Ownership-Chain Ihrer Objekte klarer herauszustellen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
4 Don’ts für Rust-Einsteiger Diese Fallstricke können Rust-Bestrebungen erodieren lassen.James M Crittenden | shutterstock.com Eine neue Programmiersprache zu erlernen, ist nicht nur Eitel Sonnenschein, sondern birgt auch erhebliches Frustrationspotenzial. Insbesondere, wenn es um neue, komplexe Zusammenhänge geht – die man zum Einstieg (noch) nicht wirklich durchdringen muss. In diesem Artikel haben wir vier Don’ts zusammengetragen, die sich Developer mit Rust-Ambitionen zu Herzen nehmen sollten. 1. Aktualität voraussetzen Rust ist eine Sprache, die sich rasant weiterentwickelt. Seine Dokumentation hält dabei nicht immer Schritt. Hüten Sie sich deshalb vor Lernmaterialien, die Sie mit veralteten Beispielen in die Irre führen. In diese Falle kann grundsätzlich jeder tappen – allerdings ist diese Gefahr bei Neulingen, die nicht mit dem Status Quo vertraut sind, ungleich höher. Ältere Versionen von Rust beinhalteten beispielsweise ein Makro namens try!, das verwendet wurde, um Ergebnisse zu “unwrappen” und eventuell zurückgegebene Fehler weiterzugeben. Inzwischen wurde dieses durch den ?-Operator ersetzt, der nativer Bestandteil der Rust-Syntax ist. Es ist nur ein Beispiel von vielen, das Sie auf veraltete Wege führt. Grundsätzlich ist deshalb jedes Rust-Tutorial, das älter als zwei Jahre ist, mit Vorsicht zu genießen. Ebenso wie undatiertes Material. 2. In alte Gewohnheiten zurückfallen Einige Konzepte, die in Rust zur Anwendung kommen, können anfangs frustrieren. So gehen etwa Ownership/Borrowing-Metaphern für das Memory Management oder typbasiertes Error Handling mit steilen Lernkurven einher. An dieser Stelle einfach die Konzepte anderer Sprachen heranzuziehen, wäre jedoch nicht zielführend. Insbesondere sollten Sie unbedingt davon absehen, Memory Management im Stil von C (oder gar C++) verwenden oder direkten Raw-Memory-Zugriff über Pointer herstellen zu wollen. Referenzen sind diesbezüglich “safe”, weil sie immer über Borrowing und Ownership getrackt werden. Pointer (deren Verwendung Sie explizit aktivieren müssen) können in der Theorie auf alles mögliche verweisen, weswegen sie von Natur aus “unsafe” sind. Die Lösung besteht an dieser Stelle allerdings nicht darin, Ihren Code großzügig mit unsafe{} auszuschmücken, um Pointer innerhalb dieser Bereiche dereferenzieren zu können. Nutzen Sie stattdessen von Anfang an Referenzen und machen Sie sich mit Typen wie Box, Rc und Arc vertraut. Sie ermöglichen es, Ownership-Regeln für beliebige Memory-Bereiche zu nutzen. So müssen Sie sich gar nicht erst mit dem Thema Raw Pointer beschäftigen. Und sollten Sie wirklich keine andere Wahl haben: Beschränken Sie Pointer auf die kleinstmöglichen unsafe{}-Bereiche und extrahieren Sie aus diesen Rust-Werte, die “safe” sind. Insbesondere C++-Entwickler versuchen oft, die gewohnten Idiome in Rust zu reproduzieren. Wenn Sie zu diesen geplagten Kandidaten gehören, kann das “C++ to Rust Phrasebook” unter Umständen eine Hilfestellung bieten, um elegant von C++- zu Rust-Konzepten überzugehen. 3. Sämtliche String-Typen durchdringen wollen Innerhalb des Rust-Ökosystems existieren diverse String-Typen, um Text zu verarbeiten. Diese sind in vielen Fällen für spezifische Tasks gedacht. Falls Sie lediglich Strings zwischen Funktionen übergeben oder auf der Konsole ausgeben möchten, müssen Sie sich darüber (erst einmal) keine Gedanken machen. Konzentrieren Sie sich stattdessen zunächst lieber auf die beiden gängigsten String-Typen: str (unveränderlich, entspricht im Wesentlichen dem, was String-Literale im Code liefern) und String (veränderlich, wird immer im Heap gespeichert). Nutzen Sie str, um String-Konstanten zu erstellen und &str, um “borrowed” Referenzen auf vorhandenen String-Werten abzurufen. Alles andere kann vorerst warten. 4. Auf Cloning verzichten Ihr Erfolg als Rust-Programmierer hängt ganz wesentlich davon ab, erkennen zu können, wann Memory Management unerlässlich ist. Solange Sie allerdings noch nicht mit der Syntax und den Tools der Sprache vertraut sind, kann dieser Aspekt eine enorme Belastung darstellen. Ein Weg, die Borrowing-Sorgen vergessen zu machen, besteht darin, Objekte zu klonen – statt die Ownership zu übertragen. Im Rahmen dieses Cloning-Prozesses wird eine neue Instanz derselben Daten erstellt, jedoch mit einem neuen, unabhängigen Owner. Die ursprüngliche Instanz behält hingegen ihren ursprünglichen Owner, so dass es keine Object-Ownership-Probleme entstehen können. Und: Wie beim Originalobjekt wird auch der Klon automatisch gelöscht, sobald er den Scope verlässt. Der Nachteil: Cloning kann Performance kosten, insbesondere wenn Sie darauf mehrere Male innerhalb eines Loops zurückgreifen. Speziell wenn es um leistungssensitiven Code geht, sollten Sie das deshalb vermeiden. Bis Sie diese Art von Code erstellen (und gelernt haben, wie Sie Metriken nutzen, um Hot Paths im Code zu erkennen), können Sie auf Cloning setzen, um die Ownership-Chain Ihrer Objekte klarer herauszustellen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!