Rust vs C/C++ fragen

ZuseZ3

Lt. Commander
Registriert
Jan. 2014
Beiträge
1.660
Kurzfassung.
Wie gut ist Rust in folgenden Bereichen im vgl zu C++. Bonusfrage, was sind vielversprechende Projekte für die Bereiche wo es schlechter ist?

GPGPU (Nutzung anderer HW wie ASIC's, FPGS,..)
High precission Libraries
128 Bit Datentypen
( https://github.com/rust-lang/rust/issues/35118 ) Was genau bedeutet dies?

Ne Suchmaschine kann ich auch benutzen, aber ich habe das Gefühl, das bei Rust extrem viele Projekte nach relativ kurzer Zeit eingestellt werden. Dürfte an dem alter der Sprache liegen, bei C/C++ haben die Leute wohl mehr Erfahrung.
Mir sagen die Entwickler hinter vielen der Rust Projekte nichts, sodass ich sie schlecht einschätzen kann. Weis da jemand mehr?
Oder noch besser, kennt er Rust Projekte mit obigen Elementen im praktischen Eindatz?

Seit ca. 10 Jahren benutze ich C++,
praktisch war dies auch mein erster ernsthafter Einstieg ins programmieren.
Auch wenn das bei Programmiersprachen wohl generell ne gefährliche Sache ist halte ich Rust für eine besder designte Sprache als C/C++.
Noch wird sie natürlich defizite bei den verfügbaren Libraried haben aber ich finde die Sprache spannend und habe ne hohe Meinung von Mozilla.
 
Zuletzt bearbeitet:
Das war tatsächlich der Ausschlag für mich diesen Beitrag zu schreiben. Beobachte Rust schon länger und insbesondere auch wie bisherige Anwendungen zu Rust migriert werden.
 
Ich habe mich mit Rust beschäftigt. Rust garantiert dir ein technisch fehlerfreies Programm. Dafür musst du dem Compiler aber umfangreichreiche Zusicherungen im Code machen. Und genau hier liegt das Problem bei Rust. Rust ist genau dadurch keine besonders produktive Sprache, die Lernkurve durch die neuen Konzepte ist sehr steil und die Syntax zum Teil zum davonlaufen.

Das nächste Problem ist eine komplette IDE zu finden. Mein aktueller Wissenstand ist der, dass aktuell nur CLion (kostenpflichtig) von JetBrains über einen funktionierenden Laufzeitdebugger für Rust verfügt.

Von der Performance / Speicherverbrauch her liegt Rust übrigens auf C/C++ Niveau.
 
Zuletzt bearbeitet von einem Moderator:
rlchampion schrieb:
Und genau hier liegt das Problem bei Rust. Rust ist genau dadurch keine besonders produktive Sprache, die Lernkurve durch die neuen Konzepte ist sehr steil und die Syntax zum Teil zum davonlaufen.
Dann nimmt es sich mit C++ ja nichts ;)
 
  • Gefällt mir
Reaktionen: Schtefanz, Fahrradfahrer und ZuseZ3
Die Zeit die du beim lernen investierst, sparst du halt später weil du deutlich weniger Probleme hast, die du debuggen must.
 
  • Gefällt mir
Reaktionen: Tumbleweed
Naja in erster Linie habe ich Zeit verschwendet die ich für anderes hätte nutzen können, wenn ich am Ende doch wieder bei C++ lande. @Ebrithil Bisher konnte keiner meine Fragen oben beantworten, bei c++ hatte ich in der selben Zeit schon deutlich mehr vorschläge bekommen bzw. das ganze selbst einfach rausgefunden.

@rlchampion keine sorge, ich habe mir vor der Frage schon durchgelesen was das Prinzip von Rust ist und kenne auch den Hintergrund aus der theoretischen Informatik, der Rust überhaupt erst so starke zusagen macht.
Die Syntax ist mir egal, bisher bin ich mit C/C++, Haskell und Python zurecht gekommen.

Und so neu sind die Konzepte denke ich auch nicht, sie haben soweit ich es beobachtet habe in erster Linie ein paar Konzepte aus der Funktionalen Programmierung sauber und stringent weiterverfolgt und mit schon existierenden weiteren Konzepten vereinigt.
Das Wissen um diese Möglichkeit ist im groben und ganzen schon lange bekannt, sie haben es dann halt mal in eine Sprache eingebaut..
Es erfolgreich zu nutzen ist natürlich nicht trivial und gut gelungen, es ändert aber nichts daran, dass Rust jetzt nicht groß neue Konzepte anschleppt.

Zur Entwicklung nehme ich imer Vim, finde es einerseits beeindruckend wie schnell ich im vgl. zu Kollegen damit bin. Anderseits lerne ich trotzdem noch jede Woche nen neuen Trick der mir extrem hilft.
 
Zuletzt bearbeitet:
Du redest komplett an mir vorbei @rlchampion
Ich habe nirgends behauptet, dass es diese Konzepte schon in einer Sprache gäbe.
Ich habe sogar angemerkt, dass sie die ersten waren, die diese Konzepte eingebaut haben.
Was ich angemerkt habe ist dass die Konzepte aus Theoretischer Sicht nen alter Hut sind.

Siehe z.B. P.Wadler: Linear types can change the world! aus 1990!
"In most implementations of a functional language it is essential to recover space that is discarded by the use of reference counting or garbage collection. Values of a linear type avoid this overhead."
So viel zu deinem Ownership. 30 Jahre alt.

Denke da dürfte noch das ein oder andere für dich "neue" Konzept erklärt sein, gerade keine Motivation den Rest rauszusuchen.


Wenn hier noch jemand etwas zu meinen obigen Fragen beizutragen hat wäre ich dankbar, an sonsten versuch ichs halt mal auf SO.


ZuseZ3 schrieb:
Kurzfassung.
Wie gut ist Rust in folgenden Bereichen im vgl zu C++. Bonusfrage, was sind vielversprechende Projekte für die Bereiche wo es schlechter ist?

GPGPU (Nutzung anderer HW wie ASIC's, FPGS,..)
High precission Libraries
128 Bit Datentypen
( https://github.com/rust-lang/rust/issues/35118 ) Was genau bedeutet dies?
 
@ZuseZ3 - meine wenigen Rust-Versuche haben mich zu folgender "Erkenntniss" gebracht:
"Kannst Du voll vergessen"

Warum?

a) Interoperabilität: ich nutze (entweder einzeln oder kombiniert) OpenGL, OpenCV/OpenCL, CUDA, Boost, Qt5 - das funktioniert auf allen meinen Plattformen (Unix, Windows) und ist soweit ausgereift, dass man das(meist) in kurzer Zeit zum Laufen bekommt und das dann auch wunschgemäß funktioniert
b) Tools: ich nutze (inzwischen und wo das geht) auch für die Unix-Programme zunächst Windows/Visual-C++ und portiere/modifiziere parallel für alle Zielplattformen, das geht viel schneller (jedenfalls für mich)
c) Gewohnheit: als alter Sack, der viele Tricks von C++, einschließlich deren Standard-Regex-Implementation mehr oder weniger durchschaut hat, ist es Zeitverschwendung, ein neues Fohlen einzureiten. Wozu?
d) Projektfertigstellung: Wenn Du in Deiner verfügbaren Lebenszeit gezwungen bist, Projekte fertigzustellen bzw. einen Nutzen zu erzeugen, hast Du keine Wahl, als dies mit erprobten und vertrauten Tools zu machen, von denen Du weißt, wo die Probleme liegen und wie Du sie umschiffen kannst.

"your milage may vary"
 
  • Gefällt mir
Reaktionen: 0-8-15 User, ZuseZ3 und kuddlmuddl
Danke für die realistische Zusammenfassung ;) Genau solche Punkte hätte ich auch vermutet, ohne Rust jemals angeguckt zu haben.

Für Leute die sagen dürfen "der Weg ist das Ziel", oder die neue Sprachfeatures / Compiler entwickeln ist es sicher sinnvoll über den Tellerrand zu schauen. Aber für SW-Entwickler, die mit begrenztem Zeitbudget ein Ziel erreichen wollen, ist es sehr unwahrscheinlich, dass so ein Wechsel mal lohnt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ZuseZ3
Danke @blöderidiot, genau auf solche Berichte hatte ich gehofft.

Ich habe bisher noch den Vorteil Student zu sein und nicht mehr Vollzeit zu arbeiten.
Daher fordere ich mich auch gelegentlich heraus mal auf neue Sachen umzusteigen, die langfristig wohl etwas effizienter sind (sein können).

Da ich in Richtung Data Science gehe entfällt auch für mich das GUI gebastel (Gott sei Dank), Qt hole ich im Schnitt alle 2 Jahre hervor, openGL gar nicht. Entwickeln tue ich auch nur unter Linux mit VIM, für das es schon gute Plugins gibt.

Weh tut mir aber vor allem der Punkt das es noch keine numpy Alternative gibt und darauf aufbauend natürlich keine richtigen Mathe/Machine Learning Libraries. Einen stabilen OpenCL parser konnte ich lediglich finden.

Da ich mit keinen weiteren Beiträgen gerechnet hatte, habe ich gestern daher angefangen mit den ersten Schritten in Rust. So habe ich zumindest einen Überblick und sobald sich das Problem mit den Libraries dann etwas bessert bin ich schneller drin.

Da ich nicht denke, dass C++ innerhalb von 10, 20 Jahren die Position von Pascal einnimmt (komplexer Legacy Code ohne Maintainer => besondere Gehälter), erscheint mir das aktuell am sinnvollsten
 
Zuletzt bearbeitet:
@Ebrithil - schade, dass sehr viele schöne crates nicht unter Windows funktionieren.
nalgebra.jpg
 
@blöderidiot Cargo install tut nicht was du denkst, dass es tut.
Das installiert fertig compilierte binaries, wenn du nalgebra als dependency einbinden willst, musst du das in der cargo.toml hinzufügen.

Wenn du dependencies mittels cli adden willst brauchst du sowas wie https://github.com/killercup/cargo-edit (welches zb per cargo install installiert wird)
 
  • Gefällt mir
Reaktionen: blöderidiot
@Ebrithil - Danke! Geht auch unter Windows. Seit meinen letzten Versuchen hat sich einiges geändert. Ich hatte diesmal keine ernsthaften Probleme, unter VSCode/Windows Debugging zum laufen zu bekommen.

Apropos nalgebra: rust benötigt auf der target-Maschine einen funktionierenden und erreichbaren C-Compiler?! Jedenfalls sah das vorhin so aus.

Rust-Debugging in Windows:
nalgebra2.jpg
 
@Ebrithil Danke, schaut gut aus.
Ist zwar immer noch zu grundlegend im vgl. zu Sachen die ich in C++ nutze, aber zumindest könnte es andere Leute dazu animieren das zu implementieren was ich dann wiederrum nutze (ML Libraries, arbitray precision/ 128Bit float math).
Aber zumindest kann ich es schonmal nutzen einzelne Layer eines Neuronalen Netzes testweise selbst zu prototypen.
Bestärkt mich darin es für kleinere Projekte zu nutzen und einfach mal abzuwarten bis die richtigen libraries da sind.
 
Zuletzt bearbeitet:
rlchampion schrieb:
Lifetime, Ownership / Borrowing! Welche (gängige) Sprache nutzt dies schon? @ZuseZ3
C++:
Ownership klar durch Smart Pointers, LifeTime und Borrowing hat man zwar nicht explizit als syntaktische Features, gibt es aber auch in C++ - wie in jeder Sprache.
Aber es gibt ein paar Tools und Compilerflags dafür (v.a. für Visual Studio - ich glaube da hat Herb Sutter vor ein paar Jahren ein Projekt losgetreten).

ZuseZ3 schrieb:
Aber zumindest kann ich es schonmal nutzen einzelne Layer eines Neuronalen Netzes testweise selbst zu prototypen.
Bestärkt mich darin es für kleinere Projekte zu nutzen und einfach mal abzuwarten bis die richtigen libraries da sind.
So ergings mir letztes mal genauso.
Wenn alles essentielle da ist, gerne Rust - ansonsten eben weiter C++.
Für langfristige kommerzielle Projekte mag das anders aussehen, aber persönlich nehme ich es nicht in Kauf dannn entsprechende Libraries selbst zu entwickeln oder C++ libraries reinzufrickeln.
 
  • Gefällt mir
Reaktionen: ZuseZ3
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: 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++. Die Techniken a la Borrowing und co hatte ich schon an der Uni und sind auch sonst gut erklärt.

Schlecht finde ich bisher die Erstellung von geschachtelten Arrays. Dafür will ich nicht extra crates runterladen und nutzen, vor allem wenn die auch wieder ihre Limitierungen haben. Besonders kompliziert wirds bei mir, da ich mehr als 32 Vektoren drin habe, da somit die Default initialisierung nicht mehr funktioniert o.0.
Code:
let mut foo = [vec![],vec![], vec![], vec![], vec![],vec![], vec![], vec![], vec![],vec![], vec![], vec![], vec![],vec![], vec![], vec![], vec![],vec![], vec![], vec![], vec![],vec![], vec![], vec![], vec![],vec![], vec![], vec![], vec![],vec![], vec![], vec![], vec![],vec![], vec![], vec![]];

Mangelhaft finde ich auch die Erklärung der Aufteilung in verschiedene Crates.
Einfaches Beispiel: Ich habe zwei Boards für das Spiel entwickelt, einmal mit guter Spieler/Engine unterstützung (Bereitstellung möglicher Züge, bereitstellung des aktuellen Punktestandes), einmal mit minimaler Unterstützung (Falsche Züge werden einfach abgelehnt, Punktzahl wird nur am Ende berechnet, lediglich das Brett und der aktuelle Spieler werden jede Runde bereitgestellt).
Zusätzlich habe ich mehrere Engines/Bots/KIs: Einmal eine random ziehende (wahlweise nutzt sie mögliche Züge oder berechnet sie selber), einmal eine welchen menschlichen Input weiterreicht, dazu dann die intelligenteren.
Ich habe zugegeben selbst nicht so viel Ahnung von Softwaretechnik, bei den Crates bin ich mir aber noch nicht ganz sicher. Ich tendiere dazu ein Crate mit allen Boards und ein Crate mit allen Engines zu erstellen?
Dann jeweils eine Engine pro File und die in ne Lib bündeln?

Gut finde ich dagegen, wie einfach ich mittels Criterion Benchmarks durchführen konnte, da sollten sie sich aber wohl mal entscheiden ob sie ihre eigene schwebende Implementierung fallen lassen und Criterion als Standard einbauen.

Sehr schön finde ich auch, dass es nicht so auf Objektorientierung versteift ist, ich mag es einfach generell nicht wenn das Konzept zu weit getrieben wird. Da finde ich Rusts Lösung persönlich deutlich schöner.
Vielleicht ist Linus Torvalds ja aus dem Grund auch bereit Rust statt C einzusetzen, wenn seine Ablehnung von OOP im C++ für ihn schon Grund genug war bei C zu bleiben. :D :D

Sehr beeindruckend finde ich auch die Performance.
Bin gerade an einem kleinen Spiel für Reinforcement Learning auf der CPU.
Mit den üblichen leichten Performancegedanken im Hintergrund habe ich direkt einen Durchsatz von 1000 Spielen pro Sekunde (beide Spieler ziehen Random). Denke nicht, dass ich mit C++ so schnell so eine Performance bekommen hätte. Wenn ich am Ende Zeit habe entwickel ich mal was in C++ zum vergleichen.
 
Zuletzt bearbeitet:
Zurück
Oben