Von C zu Rust wechseln?
-
:p
-
Hey Leute, ich habe eben angefangen, programmieren zu Lernen. Als Sprache habe ich mir dafür C++ ausgesucht, weil es so schön neu und hip ist. Gibt es irgendeinen Grund von C++ auf C umzusteigen?
-
Nochmal schrieb:
Hey Leute, ich habe eben angefangen, programmieren zu Lernen. Als Sprache habe ich mir dafür C++ ausgesucht, weil es so schön neu und hip ist. Gibt es irgendeinen Grund von C++ auf C umzusteigen?
Ja. C ist automatisch einfacher, weil der Sprachkern viel kleiner ist. Dinge wie RAII braucht kein Mensch; denn man kann auch leckfrei in C programmieren.
-
ich lecke aber gerne ... ähm. nein. vergesst den letzten Satz bitte wieder ...
-
Also wenn man sich diesen Benchmarkvergleich ansieht, dann ist Rust nicht besonders schnell.
C++ ist hier immer noch eine der schnellsten Sprache, aber an der Spitze steht mit einem Geschwindigkeitsvorteil von > 16 % gegenüber C++ D und das auch noch bei den wenigsten Zeilen Code, was für eine starke Ausdrucksstärke und auch wenig Arbeit für den Coder bedeutet.Obwohl D hier also rein von den Zahlen am besten abschneidet wird es in der Praxis immer noch kaum benutzt, wie soll da Rust überhaupt nur eine Chance haben, wenn Rust von den drei Sprachen am langsamsten ist und der SLOC Wert auch kein großer Sprung gegenüber C++ ist?
https://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/
-
Hier gibt's mal eine Debatte zu C++, D, Rust und Go von den Profis (ihr kennt sie sicher alle, wenn ihr euch die Leute anschaut):
-
Also wenn man sich diesen Benchmarkvergleich ansieht, dann ist Rust nicht besonders schnell.
Verwechsle nicht Sprachen mit deren Implementierungen. Vom Sprachdesign her gibt es keine Gründe für Deine Beobachtung.
Obwohl D hier also rein von den Zahlen am besten abschneidet wird es in der Praxis immer noch kaum benutzt, wie soll da Rust überhaupt nur eine Chance haben, wenn Rust von den drei Sprachen am langsamsten ist und der SLOC Wert auch kein großer Sprung gegenüber C++ ist?
Ich kenne keine andere Sprache, die Speichersicherheit erreicht, ohne dabei auf Garbage Collection oder ausbremsende Checks zu setzen. Das ist es, was Rust für mich interessant macht. Du tickst da anscheinend anders. Und das ist ja auch okay.
Wenn man als D Programmierer wirklich über den Tellerrand guckt, dann kann da u.a. so etwas bei heraus kommen:
http://blog.dicebot.lv/2015/01/thoughts-about-rust-from-d-programmer.htmlIch hoffe, ich konnte Dir mit dieser Antwort helfen.
-
Ich hoffe, dass viel Software in Rust Stück für Stück neu geschrieben wird. Java hatte seine Sicherheitslücken auch nur C++ zu verdanken, wird Zeit dass man solche Sprachen nicht mehr bei sicherheitsrelevanten Programme einsetzt. Auch wenn der Umstieg viele Jahre oder Jahrzehnte dauert, er MUSS kommen.
-
Ich finde es interessant dass Rust trotz llvm backend so abkackt. LLVM ist ja doch schon sehr ausgereift was Optimierungen etc angeht. Hätte C-gleich Performance erwartet.
SecurityFirst schrieb:
Ich hoffe, dass viel Software in Rust Stück für Stück neu geschrieben wird. Java hatte seine Sicherheitslücken auch nur C++ zu verdanken, wird Zeit dass man solche Sprachen nicht mehr bei sicherheitsrelevanten Programme einsetzt. Auch wenn der Umstieg viele Jahre oder Jahrzehnte dauert, er MUSS kommen.
blablabla.
-
Ethon schrieb:
Ich finde es interessant dass Rust trotz llvm backend so abkackt. LLVM ist ja doch schon sehr ausgereift was Optimierungen etc angeht. Hätte C-gleich Performance erwartet.
Der Artikel ist von August 2013 und bis zur Implementierung von unboxed Closures war Rust total langsam.
Es entspricht auch fast keine Zeile noch gueltigem Rust.EDIT: Hier gibt es z.B. was neues.
-
krümelkacker schrieb:
Ich kenne keine andere Sprache, die Speichersicherheit erreicht, ohne dabei auf Garbage Collection oder ausbremsende Checks zu setzen.
Was ist mit funktionalen Programmiersprachen wie Haskell & Co?
In der Luftfahrt und im Militärbereich setzt man AFAIK oft Ada ein und das wurde so weit ich weiß darauf optimiert, dass der erzeugte Code stabil läuft.
Wie wird bei Ada Speichersicherheit erreicht?Wenn man als D Programmierer wirklich über den Tellerrand guckt, dann kann da u.a. so etwas bei heraus kommen:
http://blog.dicebot.lv/2015/01/thoughts-about-rust-from-d-programmer.htmlIch werde es mir noch durchlesen.
-
Irgendwann wird auch mal C++ in Rente geschickt. Rust ist ein erster guter Kandidat. Die IT muss nicht auf ewig zwischen Performance und Sicherheit wählen, das sollte wirklich jeder Entwickler begrüßen und unterstützen. Wenn nicht ist das Gelaber hier gegen C und C++ reine Unsinn, denn das gleiche kann man jetzt mit C++ und Rust machen.
-
-
welche Nische ist denn offen, die eine weitere Sprache wie Rust besetzen kann?
wenn eine neue Sprache eine der wohletablierten C, java, C++ verdrängen könnte, dann würde das wohl kaum von heute auf morgen geschehen.
Gibt es mehrere Sprachen für ähnliche Zwecke, dann koexistieren die oft nebeneinander her, die älteren verlieren nach und nach an Zuspruch, die neuen gewinnen allmählich an Zuspruch. Das kann Jahrzehnte dauern, man denke mal an cobol und fortran, beide mit Wurzeln in den 1950er Jahren, und beide immer noch im Einsatz, obwohl für beide Einsatzbereiche seit langem C, java, C++ (neben zahlreichen Spezialsprachen) bereitstehen.
angesichts der riesigen Codebasis von C, java, C++, die sich in Jahrzehnten angehäuft hat, und angesichts der großen Menge an Libraries, Literatur und Entwicklern würde ich vermuten, daß die Ablösung einer dieser Sprachen ein eher langsamer Prozess sein würde.
vielleicht kommt die Ablösung von C, java, C++ erst mit dem Durchbruch von anderen Paradigmen als OOP, etwa dem funktionalen und dem logischen.
Erlang gibt es heute schon (eigentlich schon länger). Funktional, entwicklungsgeschichtlich eine gewisse Nähe zu Prolog, und passenderweise für nebenläufige Systeme der nach-Moore-Ära geeignet, würde gut zu meiner Vermutung passen.
-
Ethon schrieb:
Ich finde es interessant dass Rust trotz llvm backend so abkackt. LLVM ist ja doch schon sehr ausgereift was Optimierungen etc angeht. Hätte C-gleich Performance erwartet.
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp
-
Über Tellerrand geschaut schrieb:
Was ist mit funktionalen Programmiersprachen wie Haskell & Co?
Hau rein. Nur zu. Das ist jetzt nichts, was ich zu den "low overhead"-Sprachen (C, C++, Rust) zählen würde.
Über Tellerrand geschaut schrieb:
In der Luftfahrt und im Militärbereich setzt man AFAIK oft Ada ein und das wurde so weit ich weiß darauf optimiert, dass der erzeugte Code stabil läuft.
Wie wird bei Ada Speichersicherheit erreicht?Wird sie denn erreicht? Gibt's da Zeiger? Schließen sich diese beiden Dinge in Ada aus? Ich weiß es nicht. Mir ist jedenfalls nicht bekannt, dass Ada das Konzept der Lebenszeiten kennt und dass Zeiger solche Lebenszeitparameter als Teil des Typs haben, wie es in Rust der Fall ist, womit zur Übersetzungszeit ausgeschlossen werden kann, dass ein Zeiger ungültig wird. Viele andere Möglichkeiten, das zu gewährleisten kenne ich nicht: (1) Garbage Collection (nur der GC räumt das weg, was wirklich nicht mehr erreicht werden kann) oder auch (2) Runtime Checking à la Clang's Address Sanatizer. Und beides bedeutet einen Overhead.
Ada 2012 soll sich wie C++11 auch „gemausert“ haben. Aber ich finde zum Thema Speichersicherheit nichts überzeugendes, zumindest nicht ohne die Sprache jetzt zu lernen. Ich habe nicht den Eindruck, dass die Sprache zur Übersetzungszeit ausschließen kann, dass es keine baumelnden Zeiger im Programm geben wird.
großbuchstaben schrieb:
welche Nische ist denn offen, die eine weitere Sprache wie Rust besetzen kann?
Also, dafür, dass dieser Thread hier schon 10 Seiten überschritten hat und dass es so Dinge wie Suchmaschinen gibt, finde ich die Frage ein bisschen ignorant. Ist doch ganz einfach: 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 warum will es das sein? Weil es immer noch viel zu viele Sicherheitslücken in C und C++ Software gibt, die es mit Speichersicherheit nicht gegeben hätte. Und wie es sich für einen C++ Ersatz gehört, will man den Leuten Garbage-Collection ersparen ohne dabei Zeiger zu verbieten. Weder Performance noch Speichersicherheit sind in Isolation ein Alleinstellungsmerkmal. Aber die Kombination dieser Eigenschaften in einer Sprache ist, soweit ich das beurteilen kann, einzigartig (wobei Rust in der Hinsicht von Cyclone's „region pointers“ inspiriert ist).
-
Besser kann man das gar nicht beschreiben
Von der Sprache her, ist Rust jetzt schon vollwertiger C++ Ersatz. Jetzt liegt es "nur" noch an der Community. Ab der Finalversion ab März/April wird sich zeigen wie viel den Leuten die Sicherheit wirklich wert ist und ob sie Sicherheit gegen ihr gewohntes, aber unsicheres C++ eintauschen werden. Die IT würde ein gutes Stück sicherer dadurch werden.
Lasst den Compiler für euch arbeiten, das sind doch immer einer der großen C++-Sprüche hier. Mal schauen was dran ist wenn eine andere Sprache da weit mehr drauf hat.
Also schreibt Bindings, IDEs etc. und dann nach und nach Libs ersetzen.
https://crates.io/
-
C++ wird wegen dem benutzt was schon da ist und nicht weil es eine tolle Sprache wäre. Bei Rust ist noch nichts da und die Sprache hat absolut nicht das Potential irgendwo Java oder C# zu ersetzen.
Wer soll damit bitte etwas anfangen, realistisch betrachtet?
Ich weiß nur sehr sicher dass bei uns niemand anfangen wird Linux Treiber in Rust zu schreiben.Und diese "C++ ist unsicher"-Jammerei geht mir auch auf den Keks. Das stammt aus Zeiten, in dem man Software in C++ geschrieben hat, die heute zurecht in Java geschrieben wird. C++ taugt sowieso nur noch in Expertendomänen wirklich und die wissen wie man sicheres C++ schreibt.
-
Ethon schrieb:
C++ wird wegen dem benutzt was schon da ist und nicht weil es eine tolle Sprache wäre.
Was ist denn großartig da außer Boost?
Entwicklungsumgebungen sind auch eher mies. Da ginge bei der viel einfacheren Sprache Rust besser.
Meiner Erfahrung nach sind 99% aller C++-Bibliotheken Müll, weil die Macher irgendwelche Grundprinzipien der Sprache noch nicht verstanden haben. Und wenn man etwas wirklich wichtiges schreibt, macht man es in C oder mit C-APIs.Ethon schrieb:
Bei Rust ist noch nichts da und die Sprache hat absolut nicht das Potential irgendwo Java oder C# zu ersetzen.
Wer soll damit bitte etwas anfangen, realistisch betrachtet?Rust möchte gar nicht Java oder C# ersetzen, sondern C++ und damit auch C.
Ein guter C++-Programmierer erkennt, dass Rust nicht viel mehr macht als die vielen ungeschriebenen Gesetze von C++ in eine neue Sprache zu gießen, wo die Tools diese Gesetze kennen. Die strikte Befolgung der Gesetze führt auch in C++ zu sicherem Code, aber der Compiler hilft einem dabei nicht und lässt ganz viel Mist durchgehen.Ethon schrieb:
Ich weiß nur sehr sicher dass bei uns niemand anfangen wird Linux Treiber in Rust zu schreiben.
Warum nicht? An fehlenden Bibliotheken kann es ja nicht liegen, denn die verwendet man bei Linux kaum.
Ethon schrieb:
Und diese "C++ ist unsicher"-Jammerei geht mir auch auf den Keks. Das stammt aus Zeiten, in dem man Software in C++ geschrieben hat, die heute zurecht in Java geschrieben wird. C++ taugt sowieso nur noch in Expertendomänen wirklich und die wissen wie man sicheres C++ schreibt.
Es ist schön, wenn in deinem Umfeld nur Experten arbeiten, die wissen, was sie tun. Das ist aber eher ungewöhnlich.
-
Was ist denn großartig da außer Boost?
Entwicklungsumgebungen sind auch eher mies. Da ginge bei der viel einfacheren Sprache Rust besser.
Meiner Erfahrung nach sind 99% aller C++-Bibliotheken Müll, weil die Macher irgendwelche Grundprinzipien der Sprache noch nicht verstanden haben. Und wenn man etwas wirklich wichtiges schreibt, macht man es in C oder mit C-APIs.Wegen der Software, die in C oder C++ angefangen wurde, und jetzt halt da ist und gerne erweitert und gewartet werden möchte.
Warum nicht? An fehlenden Bibliotheken kann es ja nicht liegen, denn die verwendet man bei Linux kaum.
Weil es sich im in C geschriebenen Kernel fremdartig anfühlt und man auch einiges an Bindings zu Kernel APIs und vor allem Makros pflegen müsste.
Es ist schön, wenn in deinem Umfeld nur Experten arbeiten, die wissen, was sie tun. Das ist aber eher ungewöhnlich.
Vor schlechten Programmieren schützt auch Rust nicht.
