Rust vs C/C++ fragen

[blöderidiot]

Ich muss sagen mit C++ und Haskell background ist Rust lernen eigentlich ne Sache von 5 Minuten.
Let (und where, was wohl weniger genutzt wird) kommen aus Haskell, der Rest ist ein aufgeräumtes und vereinfachtes C++.

Ja, das finde ich im Grunde auch, wenn auch der gesamte System-Setup bis zum schmerzfreien Debugging schon ein wenig cumbersome ist. Aber so ist das halt. Aber am Ende bleibt es für mich doch mehr ein Spielzeug unter anderen Spielzeugen, da nun (gerade für mich interessant) der Support von OpenCV (aktuelles C++-Interface) und Qt etwas schwer bis gar nicht benutzbar ist. Aber ansonsten ...

@Ebrithil - danke nochmal für den Tipp mit rust-analyzer. Das, und ein llvm in VS Code ergibt am Ende eine schöne Debugging-Umgebung mit Ctrl-B / F5 (rebuild / debug-run) und schnellen turnaround-Zeiten

 

[ZuseZ3]

Danke für die Errinerungen an die Shortcuts, habe nun bei vim unter f5, f6 und f7 debug-run, release-run und cargo benchmark abgelegt. Wollte mir schon länger angucken wie das geht.
Rust Profiler richte ich heute Nacht noch ein.

OpenCV 4.2 wird ja unter opencv-Rust als default genutzt, da sind sie also bisher nur einen Monat hinterher.
Hast du so schlechte Erfahrungen damit gemacht? Ggf. kann ich es im laufe des Monats mal testen und feedback geben.

 

[ZuseZ3]

Um mal ein bisschen Feedback zu geben.
Nach 2,3 Wochen habe ich mittlerweile ein recht sauberes kleines Android Spiel nach-entwickelt.
(2-Spieler, rundenbasiert auf einem 6x6 Feld, IO übers Terminal).
Gegeneinander spielen können dabei Mensch, zufällig ziehender bot, eine Q-Learning "KI", sowie eine "KI" basierend auf Neuronalen Netzen. Letztere bist aber noch nicht ganz fertig.
Dabei bin ich erstaunt wie kompakt (1k LoC) und schnell das Ergebnis war.
Dazu kommen die auf der vorherigen Seite diskutierten Vorteile von Rust zum tragen, ich denke nicht, dass ich in C++ so eine saubere Lösung so einfach hinbekommen hätte.

Je nachdem wie viel Zeit ich finde schaue ich mal ob ich mittels WebGPU noch eine GUI oder GPU support für das neuronale Netz hinzufüge. Sollte ich mich zu ersterem überwinden könnte ich auch mal testen wie gut das Ergebnis am Ende tatsächlich Plattform übergreifend funktioniert, als Vergleich zu dem o.g. C++ Stack.

Was die bisherige Kritik angeht, auch von meiner Seite:

1) Die Aufteilung von Projekten in files/folder/.. finde ich mittlerweile doch sauber organisiert, bei meiner Kritik auf der letzten Seite hatte ich es mir unnötig kompliziert gemacht.

2) @blöderidiot
WebGPU als Nachfolger von WebGL könnte was für deine GUI Geschichten sein?
Dahinter stehen Google, Apple, Intel, Mozilla und co.
Klar, kein Erfolgsgarant, aber die Ansätze gefallen mir.
Hier nebenbei auch eine Rust Implementation von WebGPU.
Ich persönlich nutze zwar wenig GUIs, aber wenn ich so ohne große Performance-einbußen Systemübergreifend effizient GPGPU nutzen kann bin ich trotzdem dabei.
Dass du nicht vorhast auf deine alten Tage nochmal umzusteigen kam zwar rüber, aber vielleicht findest du es ja trotzdem spannend reinzuschauen?

Mein privates, vorläufiges Fazit nach einem Monat ist, dass ich in C++ noch nicht tief genug drin stecke, um einen Umstieg nicht zumindest zu versuchen.
Die Performance kann imho komplett mit C++ mithalten, die Sprache ist gefühlt (noch) deutlich "aufgeräumter" als C++ und mittels Ownership u.ä. entfallen so viele Fehlermöglichkeiten, dass ich schon als Rust Neuling sicherere Programme schreibe als ich es in C++ machen würde.
Bibliotheken/Bindings für Machine Learning und HPC sind zwar noch nicht stabil verfügbar, aber sie scheinen über die letzten Jahre konstant aufzuschließen ggü anderen Sprachen.
Zuletzt kommt einfach noch mein ganz subjektives Gefühl dazu, es macht deutlich mehr Spaß Rust als C++ zu entwickeln. Die Fehlermeldungen sind deutlich hilfreicher, die Comunity sehr hilfreich und vor allem ist mein Programm kaum gecrasht, eine Eigenschaft die ich über meine C++ Programme während der Entwicklungsphase weniger sagen kann "hüstel".
Entwicklungszeit war, wenn man das lernen der Grundlagen vernachlässigt übrigends nicht länger als für C++.
Der compiler verbietet einem zwar theoretisch etwas mehr als bei C++, praktisch hatte ich aber recht schnell raus was ich durfte und was nicht. Sobald es dann aber compiliert hat, lief es auch (fehlerfrei).

Mal schauen, vlt. schreibe ich ja mal einen kleinen Leserartikel dazu.

 

[nullPtr]

@new Account() Es gibt mittlerweile eine Implementierung des Sutter-Proposals ("Lifetime profile"). Godbolt hat sogar eine funktionierende Version davon. In Herb Sutters Blog Post (https://herbsutter.com/2018/09/20/lifetime-profile-v1-0-posted/) sind einige Beispiele verlinkt.

 

[Stannis]

Ich pflege ein kleineres Rustprojekt in der Firma und habe seit diesem Jahr den Glauben an die Sprache verloren.
Zu den von Dir angesprochenen Punkten kann Ich nicht wirklich etwas sagen, aber meine Erfahrung ist:

• Rust ist sau kompliziert, für Neulinge schwer zu verstehen und wird immer noch komplexer, genau wie C++ zuvor. Das macht in einer traditionelleren Industrie das Zusammenarbeiten schwerer, weil die anderen Programmierer den Code kaum verstehen.
• Die Rust Toolchain ist extrem internet-affin. Damit meine Ich im Wesentlichen, dass sie erwarten, dass Hinz und Kunz ihren Krempel via rustup direkt von ihren Servern fetchen. Pakete für die in der Entwicklung oft benutzten Linuxes werden eher stiefmütterlich gepflegt.
• Es gibt keinen Sprachstandard, und es gibt nur einen Compiler. Das mag sich in Zukunft ändern, aber aktuell schaut die Situation nicht so rosig aus.

Alle meine Punkte sind aus Sicht eines Programmierers eingebetteter Systeme zu sehen. Wir haben sehr hohe Ansprüche an die Toolchain, wir haben sehr lange Produktlebenszyklen, in denen wir neu bauen können müssen, ggf. auch nach zehn Jahren.
Mit C wird das immer gehen, mit Rust ist gerade eigentlich alles undefined behavior.

 

[ZuseZ3]

Also das Rust sau kompliziert ist kann ich nicht bestätigen, ich hatte aber auch privat schon C++ genutzt und an der Uni grundlegendes Haskell gelernt. Letzteres dürfte mir aber nen Vorteil ggü in der Industrie oft fachfremden Entwicklern geben. Woran machst du das fest?
Auf dem level der Sprache selber, also Borrowing, Crates, traits, Programmstruckturierung?
Da habe ich das Gefühl, dass manche Rust nur deshalb als komplexer als C++ sehen, weil die Leute schon ihre C++ Anfänge vergessen haben.

Oder meinst du den Rust core, wenn du embedded nennst, welcher auch ohne Betriebssysteme läuft?
Der müste ja umständlicher sein, da weniger Befehle nutzbar, aber dafür auch weniger komplex?

Rein von der Zahl her hat Rust 38 keywoards (+13 reserviert), C++ hat mit 93 mehr als doppelt so viel:
https://medium.com/@richardeng/how-to-measure-programming-language-complexity-afe4f7e75786

Das mit der Toolchain sehe ich ähnlich. Aber wie groß seid ihr? Es gibt doch seit einem Jahr die Möglichkeit Programme nur ein eigenes Repo zum ziehen der Pakete zu nutzen.
Für kleinere Unternehmen kann ich mir aber vorstellen, dass der Aspekt unschön ist.

Was den Sprachstandard angeht hast du leider auch recht, hier ist immerhin ein Projekt das eine alternative werden könnte: https://github.com/thepowersgang/mrustc
Aber für diese Supportzeiträume ist Rust wohl nicht bereit.
Ich schätze mal die meisten Sprachen legen am Anfang aber erstmal ein logaritmisches Wachstum hin,

 

[Stannis]

Nun, zum Kontext, Ich habe in meinem Leben zwei Mal C++ angefangen zu lernen und es jedes Mal wieder sein gelassen, weil Ich den Gewinn nicht gesehen habe. Ich bin immer bei C geblieben, später dann auch Python, neuerdings Rust und zuletzt Go.

Rust ist aus mehreren Gründen außerordentlich kompliziert; wobei solche Aussagen immer nur Sinn im Vergleich zu anderen Sprachen Sinn ergeben. Die einzige Programmiersprache der Welt wäre ebensowenig einfach oder kompliziert wie der einzige Mensch der Welt nicht schön oder hässlich wäre.
Die Zahl der Schlüsselworte ist nicht so sehr das Problem wie der aberwitzige Aufbau, den man daraus zusammenschustern kann:

let foo = blubfunction(&bar[..])?.as_mut().clone()?;

// oder
let sock = match try_bind(addr) {
    Ok(s) => s,
    Err(e) => {
        match e.kind() {
            blub => get_default_v6()?,
            blab => get_default_v4()?,
        }
    }
};

Mag sein, dass Ich selbst den Dreh mit idiomatischem Rust noch nicht raus habe – aber das ist genau mein Punkt. Wenn man mal Go mit Rust vergleicht, dann ist das ein himmelweiter Unterschied, idiomatisches Go hat man in ein paar Tagen raus. Mit Rust tue Ich jetzt seit >12 Monaten herum.

Vor einigen Wochen erst habe Ich eine riesige Diskussion im Rust Channel auf Matrix gestartet, bei der sogar sehr langjährige Programmierer erst nach einiger Diskussion wussten, was das Problem war.

if let Ok(sock) = mystruct.condsock {
    sock.do_foo();
}

Dieser Code schien die Operation do_foo einfach nicht auszuführen, d.h. nach dem Ausführen der if-Bedingung war mein Socket unverändert. Wenn Du schnell siehst, woran es liegt, bist du besser als Ich und der ganze Matrix Kanal

Unser Problem im embedded ist nicht das Arbeiten auf dem blanken Eisen (heute hat eh fast jeder ein embedded Linux unten drunter), sondern dass cross compilen für die üblichen Verdächtigen (ARM).
Bei C macht man apt install aarch64-compiler.
Bei Rust kann man sich erstmal mit rustup ein paar hundert Megabyte an Toolchain von deren Servern fetchen.

Der Mechanismus, den es seit letztem Jahr gibt, ist Vendoring. Das betrifft aber nur die Crates, nicht die Cross-Toolchain, die es m.W. nach immer noch nur über rustup gibt.
Dabei installiert das Teil einem den ganzen Krempel ins Homeverzeichnis.
Das hat uns vor extreme Probleme gestellt, weil hier alles mit Containern und automatischen Pipelines läuft, weil viele Projekte sicherheitskritisch sind und nicht am Internet hängen dürfen und und und.
Wir habens am Ende gelöst, indem wir den ganzen Kram auf lokalen Servern ablegen, aber das war unglaublich viel Arbeit und wird auch weiterhin viel Arbeit sein, wenn wir jemals ein Compiler-Update brauchen sollten.

Zu der Zeit, als wir das Programm geschaffen haben, gab es zudem noch kein async, also haben wir Eventloops (mio) gebraucht – und die Typen haben eventede Channel und Timer aus Mio rausgeworfen!
Dadurch wäre das Projekt um ein Haar nicht durchführbar gewesen (der rausgeworfene Teil war dann über ein weiteres Crate wieder einpflegbar)!

Klar sind alle diese Probleme lösbar.
Aber zum Lösen braucht man Personal und Zeit. Das haben wir nicht wirklich.
Eine Programmiersprache ist ein Werkzeug, und das muss auf der typischen Linux Workstation einfach und unkompliziert installierbare oder baubar sein.

Und Ich habe nicht das Gefühl, dass bei den Rust-Leuten da ein Problembewusstsein da ist.
Mit Compiler 1.38 letztes Jahr haben sie das Cross-Bauen für ARM kaputt gemacht, ohne es zu merken. Mein Gefühl ist, dass die meisten Rust-Leute Mozilla-Internetmenschen sind, bei denen die Glasfasern bis an den Schreibtisch reichen und bei denen kein Bewusstsein für die Anforderungen der embedded Industrie oder allgemein der traditionellen Infrastrukturen vorherrscht.

 

[Sparta8]

@Stannis
Warum verwendet ihr im embedded Bereich Rust dann überhaupt? Die Frage ist nicht zynisch gemeint.

 

[Stannis]

@Sparta8
Das war ein Pilotprojekt. Alle reden von Rust und wie geil und fortschrittlich und rasend schnell es sei - und bei uns gab es große Unterstützung dafür, die Sprache mal auszuprobieren.
Also haben wir eine zusätzliche Komponente in Rust geschaffen. Die ist optional, und daher wäre ein Scheitern verschmerzbar gewesen.
Es handelt sich faktisch um eine Art Debugger, der extrem schnell sein soll, um die mit ihm interagierenden Programme nicht auszubremsen, und der sehr sicher sein soll, um nicht auf Dauer mehr Bugs einzuführen, als mit ihm gefunden werden^^ Python und sogar Go scheiden da aus, da sie mit ihrer Runtime zu lahm sind. Bleiben C, Rust und theoretisch C++ oder D.

 

[ZuseZ3]

Kurzes Update, ich habe mittlerweile bald ein Jahr Rust genutzt. C/++ nutze ich eigentlich nur noch, wenn es für Uni Zeug explizit gefordert wird oder ich von Rust code heraus C aufrufe, was ziehmlich trivial ist.
Bin in einer Rust-ML Gruppe aktiv und werde diesen Sommer über sogar an einem GSoC Projekt arbeiten, wo ich Rust nutze.
Ich habe gerade ein wenig um die Ohren, aber werde auf jeden Fall versuchen mal einen Leserartikel über Rust schreiben sobald ich etwas Zeit habe.