Von C zu Rust wechseln?

[Jodocus]

Hattest du nicht mal so ein nützliches GreaseMonkey-Skript?

[Rustiger]

Es zwingt dich keine hier zu lesen oder zu antworten. Hier wird Sicherheit auf dem Silbertablett präsentiert und einige verschmähen dies. Was solls, mich wundert in dieser Welt gar nichts mehr. Es gibt ja auch Leute, denen die totale Überwachung gefällt und die dann auf Sicherheit durch Verschlüsselung scheißen. In diesem Sinne will ich hier nun auch wirklich nicht mehr nerven. Rust hat auf jedenfalls das Zeug ein C++ Killer zu werden, denn dafür wurde es entwickelt und das kann es in zukünftigen Mozilla-Produkten dann auch beweisen.

[volkard]

Rustiger schrieb:

Rust hat auf jedenfalls das Zeug ein C++ Killer zu werden, denn dafür wurde es entwickelt

Java auch und eigentlich versprechen sich das die Entwickler fast jeder neuen Sprache.

[volkard]

Jodocus schrieb:

Hattest du nicht mal so ein nützliches GreaseMonkey-Skript?

Ich erwarte, daß die Forenleitung einschreitet. Das sollte in Fachforen so sein. Wir verlieren einfach viel zu viele gute Leute, solange die Leitung nur Quark im Sack hat. Oder wir kriegen keine Neuen mehr, weil alle nach spätestend drei Wochen wieder weggehen.

[Rustiger]

Wenn du fachlich einer der hier gemachten Aussagen widerlegen kannst, dann kannst du das gerne tun.

Rust ist halt wie HD-Fernsehen von Bluray für mich, einmal geschaut und dann will man kein SD mehr auf DVD kaufen.

Du kannst hier gerne nach den Mods schreien und mich Mundtod machen und die Trollkeule raus holen, oder was auch immer. Ich bin nur einer der Rust mag, es gibt aber viele von uns und es werden täglich mehr. Du kannst uns nicht alle löschen, Sicherheit ist wichtig!

[volkard]

Rustiger schrieb:

Wenn du fachlich einer der hier gemachten Aussagen widerlegen kannst, dann kannst du das gerne tun.

Rust ist halt wie HD-Fernsehen von Bluray für mich, einmal geschaut und dann will man kein SD mehr auf DVD kaufen.

Du kannst hier gerne nach den Mods schreien und mich Mundtod machen und die Trollkeule raus holen, oder was auch immer. Ich bin nur einer der Rust mag, es gibt aber viele von uns und es werden täglich mehr. Du kannst uns nicht alle löschen, Sicherheit ist wichtig!

Sicherheit ist mir auch wichtig. Deswegen halte ich ausschau nach Diskussionskanälen, die sich besser schützen.

[großbuchstaben]

Rustiger schrieb:

Genau in C++ ist Sicherheit abhängig vom Entwickler, das ist immer schlecht und war auch ein guter Grund von C auf C++ zu wechseln.

Nenne doch mal bitte ein Codeschnipsel, das mit Rust ein neue Niveau an Sicherheit aufweist, damit wir uns überlegen können, wie man das in C++ nachbilden kann. C++ (und gerade in der 11er Version) bietet ja mit const, "smart pointers", auto, explicit, delete, default, usw inzwischen zahlreiche Hilfsmittel.

C++ hat die Vorteile und Nachteile jedes mächtigen Werkzeugs - richtig angewandt, ist es effizient, elegant und sicher, in den falschen Händen kann man viel Unsinn mit anstellen.

Rustiger schrieb:

Willst du noch mehr automatische Sicherheit ist dies ein guter Grund von C++ auf Rust zu wechseln. Rust ist der nächste logische Schritt, den kann man gehen oder auch nicht.

bei der Phrase "automatische Sicherheit" denke ich als erstes an Prolog. Da überläßt man die Programmierung gleich dem Computer und beschreibt nur die Aufgabenstellung.

[Rustiger]

Ownership und Borrowing nachzubauen bringt nichts, es muss Teil des Sprachkerns sein. Beim Nachbauen hängt es wieder beim Entwickler, ob er dieses Feature nutzt oder nicht und das will man nicht. Das C++ Vektor Beispiel mit dem undefinierten Verhalten würde in Rust er gar nicht kompilieren:

#include <iostream>
#include <vector>
#include <string>

using namespace std;

int main() {
    vector<string> v;
    v.push_back("Hello");
    string& x = v[0];
    v.push_back("world");
    cout << x;
}

fn main() {
    let mut v = vec![];
    v.push("Hello");
    let x = &v[0];
    v.push("world");
    println!("{}", x);
}

$ rustc main1.rs
main1.rs:5:5: 5:6 error: cannot borrow `v` as mutable because it is also borrowed as immutable
main1.rs:5     v.push("world");
               ^
main1.rs:4:14: 4:15 note: previous borrow of `v` occurs here; the immutable borrow prevents subsequent moves or mutable borrows of `v` until the borrow ends
main1.rs:4     let x = &v[0];
                        ^
main1.rs:7:2: 7:2 note: previous borrow ends here
main1.rs:1 fn main() {
...
main1.rs:7 }           ^

Warum es in Rust zu nicht möglich ist Speicherfehler solcher Art zu produzieren kann man nachlesen oder sich bei YouTube anschauen. Das sind Profis für Programmiersprachen, die können das besser erklären als ich. Ich bin nur Anwender und glaube da den Profis von Mozilla einfach mal.

[Cybertec]

Rustiger schrieb:

Willst du noch mehr automatische Sicherheit ...

Wenn ich solch einen Mist lese.

Schon mal dran gedacht das man für manche Sachen sowas gar nicht haben will bzw. gebrauchen kann? Das wäre genauso fatal wie ein GC. Dies muss dann der Programmierer entscheiden wann was gelöscht wird bzw. wie die Sicherheit implementiert wird.

Du kommst hier mit Argumenten die weder Hand noch Fuß haben und machst gerade so als ob C++ voll von Sicherheitslücken ist.

Also, bleib bei deinem Rust und verzieh dich ins Mozilla Forum.

[TyRoXx]

Cybertec schrieb:

Rustiger schrieb:

Willst du noch mehr automatische Sicherheit ...

Wenn ich solch einen Mist lese.

Schon mal dran gedacht das man für manche Sachen sowas gar nicht haben will bzw. gebrauchen kann? Das wäre genauso fatal wie ein GC. Dies muss dann der Programmierer entscheiden wann was gelöscht wird bzw. wie die Sicherheit implementiert wird.

Oh man, du hast ja mal gar keine Ahnung, worum es geht.

[ipsec]

großbuchstaben schrieb:

C++ hat die Vorteile und Nachteile jedes mächtigen Werkzeugs - richtig angewandt, ist es effizient, elegant und sicher, in den falschen Händen kann man viel Unsinn mit anstellen.

Eine Kettensäge ist richtig angewandt effizient, elegant und sicher. In den falschen Händen kann man viel Unsinn damit anstellen. Aber du nimmst zum Arbeiten auch lieber eine mit Kettenbremse, oder?

[Marthog]

Rustiger schrieb:

Ownership und Borrowing nachzubauen bringt nichts, es muss Teil des Sprachkerns sein. Beim Nachbauen hängt es wieder beim Entwickler, ob er dieses Feature nutzt oder nicht und das will man nicht.

Schwachsinn. Ownership muss nicht im Sprachkern sein. Auch bei Gc-Sprachen versuche ich nach Moeglichkeit immer meine Programmstruktur auf je einen einzigen Besitzer zuzuschneiden, weil es die Anzahl moeglicher unberechtigter Zugriffe und damit Fehlerquellen minimiert.

Rust und C++ haben das gleiche ownership-modell. Nach Moeglichkeit legt man das Objekt direkt an. Braucht man Zugriff, aber keine Kopie, verwendet man eine Referenz.
Muss man etwas auf dem Heap reservieren, verwendet man fuer dynamische Arrays einen Container (vector oder Vec) und fuer einfache Objekte unique_ptr oder Box.
Hat man mehrere moegliche Besitzer, nimmt man shared_ptr oder Rc.
Erst zur Implementierung von diesen grundlegenden Strukturen oder fuer die Verwendung von C-Libraries greift man zu rohen pointern.

Borrowing schuetzt lediglich vor Fluechtigkeitsfehlern. Normalerweise schaut man in die Referenz und sieht da, dass die pointer von vector beim push_back nicht erhalten bleiben und laesst es dann bleiben.

[Mechanics]

Rustiger schrieb:

Ich bin nur Anwender und glaube da den Profis von Mozilla einfach mal.

Warum glaubst du den Profis von Google nicht und verwendest Go?
Dieses Borrow System funktioniert nur für triviale Fälle, die eh keinen interessieren.

[sprachflüchtling]

Marthog schrieb:

Borrowing schuetzt lediglich vor Fluechtigkeitsfehlern.

Ist nicht der Sinn einer (Hoch-)Sprache, vor Flüchtigkeitsfehlern zu schützen?

[großbuchstaben]

ich warte lieber. Vielleicht wird eine Version von C++2x das haben, was Rust heute hat.

[Cybertec]

TyRoXx schrieb:

Oh man, du hast ja mal gar keine Ahnung, worum es geht.

Was willst du denn?

[krümelkacker]

großbuchstaben schrieb:

krümelkacker schrieb:

großbuchstaben schrieb:

welche Nische ist denn offen, die eine weitere Sprache wie Rust besetzen kann?

[...] Rust will ein besserer C++ Ersatz sein, der es wie C++ auf "zero cost abstraction" aber zusätzlich auch auf Speichersicherheit und Threadsicherheit abgesehen hat.

und wo ist da die offene Nische?

Meinst du, daß sichere Software mit herkömmlichen Sprachen nicht möglich ist?

Nein. Natürlich ist es theoretisch möglich ein Programm in einer anderen Sprache zu schreiben, was keinen Mist baut, auch in C++. Und das klappt sogar meistens in der Praxis. So verdiene ich mir immerhin meine Brötchen seit den letzten 8 Jahren. Ich denke aber, Du verwendest den Sicherheitsbegriff etwas anders als ich. Deswegen habe ich den hier jetzt vermieden.

großbuchstaben schrieb:

In C++ ist das nicht zuletzt eine Frage des Programmierstils bzw der Fähigkeiten des Entwicklers.

Ja, das stimmt. C++ bietet 'ne Werkzeugkiste an, die, wenn man sie effektiv einzusetzen weiß, einem dabei hilft, keinen groben Mist zu bauen … meistens. RAII und Templates sind da in der Hinsicht ganz oben dabei unter den wichtigen C++ Patterns/Features, IMHO.

Bzgl Nische: Rust ist für die Leute, die in erster Linie vom Compiler garantiert haben wollen, dass sie keine Datenrennen und keine „Speicherfehler“ (im Sinne der Speichersicherheit) produziert haben, ohne dabei auf die Performancevorteile zu verzichten, die sie von C++ gewohnt sind und ohne dabei die C-Altlast mitzuschleppen. (Und natürlich gibt es noch diverse andere Unterschiede, die auch nicht alle für Rust sprechen.)

Cybertec schrieb:

TyRoXx schrieb:

Oh man, du hast ja mal gar keine Ahnung, worum es geht.

Was willst du denn?

Ich weiß auch nicht so ganz, was Du mit Deinem Kommentar gemeint hast. Das klang irgendwie so, als würdest Du glauben, Rust erkaufte sich ein gewisses Maß an Sicherheit durch einen Overhead zur Laufzeit. Das trifft jedenfalls nur auf das Bounds-Checking zu — nicht auf das, wobei einem der Borrow Checker zur Übersetzungszeit hilft. Rust lässt dich aber, wenn Du nach entsprechenden Profiling rausgefunden hast, dass irgendwo das Bounds-Checking doch was an der Laufzeit ausmacht (eher unwahrscheinlich), dann kannst du das da selektiv per unsafe auch quasi abschalten. Es vergrößert zwar die „Angriffsfläche“, aber dann gibst Du Dir halt Mühe, da keinen Bug einzubauen. Ggf kann man es in so einem Fall auch ohne unsafe lösen. Das Iterieren über ein Array per Iterator (statt Array Indexing je Element) ist sehr flott.

[Fytch]

Ich lese hier schon eine Weile mit, aber so langsam platzt mir die Hutschnur. Die Rust-Leute klagen, wenn man etwas über Rust sagt, ohne Ahnung zu haben (verständlich), aber tun dann dasselbe bei C++?

Rustiger schrieb:

#include <iostream>
#include <vector>
#include <string>

using namespace std;

int main() {
    vector<string> v;
    v.push_back("Hello");
    string& x = v[0];
    v.push_back("world");
    cout << x;
}

Ersetzte vector durch deque und es kompiliert und läuft fehlerfrei. Und dass dieses Beispiel absolut willkürlich ist (man benutzt Referenzen als Variablen so gut wie nie) lasse ich mal aussen vor.

Als Unwissender: Kann mir jemand erklären, wie ich in Rust println für meine eigenen Structs überladen kann?

[Kopiermann]

Du meinst sowas hier? Ich habe das mal aus der Rust-Doku kopiert.

use std::fmt;
use std::f64;
use std::num::Float;

#[derive(Debug)]
struct Vector2D {
    x: int,
    y: int,
}

impl fmt::Display for Vector2D {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        // The `f` value implements the `Writer` trait, which is what the
        // write! macro is expecting. Note that this formatting ignores the
        // various flags provided to format strings.
        write!(f, "({}, {})", self.x, self.y)
    }
}

// Different traits allow different forms of output of a type. The meaning
// of this format is to print the magnitude of a vector.
impl fmt::Binary for Vector2D {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        let magnitude = (self.x * self.x + self.y * self.y) as f64;
        let magnitude = magnitude.sqrt();

        // Respect the formatting flags by using the helper method
        // `pad_integral` on the Formatter object. See the method documentation
        // for details, and the function `pad` can be used to pad strings.
        let decimals = f.precision().unwrap_or(3);
        let string = f64::to_str_exact(magnitude, decimals);
        f.pad_integral(true, "", string.as_slice())
    }
}

fn main() {
    let myvector = Vector2D { x: 3, y: 4 };

    println!("{}", myvector);       // => "(3, 4)"
    println!("{:?}", myvector);     // => "Vector2D {x: 3i, y:4i}"
    println!("{:10.3b}", myvector); // => "     5.000"
}

[TyRoXx]

asfdlol schrieb:

Die Rust-Leute klagen, wenn man etwas über Rust sagt, ohne Ahnung zu haben (verständlich), aber tun dann dasselbe bei C++? [...] Ersetzte vector durch deque und es kompiliert und läuft fehlerfrei. Und dass dieses Beispiel absolut willkürlich ist (man benutzt Referenzen als Variablen so gut wie nie) lasse ich mal aussen vor.

Ich verstehe nicht, was du meinst.
Referenzen benutzt "man" ständig.
Ein Beispiel, warum das gefährlich ist:

void find_similar_names(std::string const &name, std::vector<std::string> &results);

Ist das hier sicher oder nicht? An der Signatur der Funktion kann ich das jedenfalls nicht erkennen. Und falls es sicher ist, wird möglicherweise innen drin eine unnötige Kopie gemacht.

std::vector<std::string> names{"a"};
find_similar_names(names.front(), names);

In Rust würde etwas Äquivalentes nur kompilieren, wenn es sicher ist. Ohne Mehraufwand oder Laufzeitkosten kann leicht zu übersehendes undefiniertes Verhalten ausgeschlossen werden.

fn find_similar_names(name: &str, results: &mut Vec<String>);

asfdlol schrieb:

Als Unwissender: Kann mir jemand erklären, wie ich in Rust println für meine eigenen Structs überladen kann?

Das entsprechende Trait heißt inzwischen std::fmt::Display.