Von C zu Rust wechseln?

[Nathan]

Rustiger schrieb:

Ich lese gerade die 30-min Intro für Rust und ist es wirklich so einfach in C++ ein SegFault zu bekommen ohne Warnung vom Compiler?

Jup. Aber ist dokumentiert also RTFM oder so.

Edit: Wobei man bestimmt Compiler so verbessern könnte, dass die ähnliche Checks wie Rust machen.

[volkard]

krümelkacker schrieb:

Rustiger schrieb:

Na auf jeden Fall mal einer der da ein wenig am Ball bleiben will. Was die Sprache mir bringt werde ich ja auch erst sehen.

Haha! Wenn Du mehr von der Sorte haben willst, dann bist Du hier aber eher falsch. Schau mal bei reddit vorbei. Ich häng’ da inzwischen öfters rum als hier.

Jo.
Hier gibt es einige Leute, die Rust-Diskussionen gegenüber ablehnend stehen. Weil hier regelmäßig Fanboys reinschneien und alle Leute von irgendwas Neuem missionieren wollen, Rust war da auch recht oft dabei. Da wenig neuer Gehalt ist, wird das Alte halt schlechtgeredet. Woche für Woche, endlos.

[volkard]

Rustiger schrieb:

Ich lese gerade die 30-min Intro für Rust und ist es wirklich so einfach in C++ ein SegFault zu bekommen ohne Warnung vom Compiler?

Sowas nervt einfach nur. An den Haaren herbeigezogener Unfug, der in der Praxis gar nicht vorkommt.

War mir aber schon beim ersten Posting klar, daß "Rustiger" nur eine Werbeveranstaltung ist.
"Tellerrand" "altbacken" und so weiter. => Troll.

[Rustiger]

Ich habe auch nichts anderes in einem C++-Forum erwartet. Aber ist schon geil, wenn trotz Container und Referenzen, mal ganz schnell sein Segfautz entsteht und in der Realität findet man so etwas viel schwieriger, das ist auch nicht besser als die void* Fehler in C. Bei Rust kannst du nun einmal garantieren, dass nur in unsafe Codeblöcken so ein Blödsinn passieren kann. Bei C++ kann das überall sein.

Alles Neue ist böse und früher war alles besser und C++ ist ganz toll blablabla. Rust wird auch seine Achillesfersen haben, aber C++ hat eine ganze Menge davon und die kann man nicht einfach wegdiskutieren. Also man kann schon, deswegen ist C++ aber nicht automatisch sicherer, sondern nur wenn man 1001 Regeln befolgt, was eh kaum einer macht, weil er C++ gar nicht gut genug kennt. Und die neuen Flicken alle paar Jahren machen keine neue Sprache daraus, sie bleibt mit den Altlasten auch per Konzept schon unsafe.

Hier sollte doch jeder wissen, was an C++ toll ist und was totaler Mist. Was spricht dagegen es besser zum machen? Ich denke Rust ist ein Anfang in diese Richtung. Ich kann mich auch irren, aber ich glaube nicht dass C++ oder auch C bis in alle Ewigkeit das Fundament aller Systeme bilden wird.

[Rustiger]

Von mir aus könnte ihr den Thread hier auch dicht machen. Wenn ich jetzt schon die Troll-Keule schwingen hören, nur weil ich was negatives über die Gottheit C++ geschrieben habe. dann macht dies jeder Vergleich mit Rust hinfällig. Rust ist nun einmal mit dem Ziel erstellt worden C und auch C++ ersetzen zu können und da ist ein Vergleich nun mal angebracht. Aber anscheinend nicht in diesem Forum hier.

Also bye bye und C++ ist einfach toll, nicht zu ersetzen und wird ewig bestehen und den Rest kennt hier ja vom Tischgebet, oder was auch immer...

[volkard]

Dir gehts gar nicht um Rust, sondern Du willst nur C++ niedermachen. Viel Spaß.

Hab da auch einen Punk:
Andauernd passieren mir Fehler wie

int main() {
	[](void(*_)()){_();}(0);//segfault
}

und die würden in Prolog nicht passieren. Darum sollten alle jetzt sofort nach Prolog umsteigen.

[Nathan]

Rustiger schrieb:

Ich habe auch nichts anderes in einem C++-Forum erwartet. Aber ist schon geil, wenn trotz Container und Referenzen, mal ganz schnell sein Segfautz entsteht und in der Realität findet man so etwas viel schwieriger, das ist auch nicht besser als die void* Fehler in C. Bei Rust kannst du nun einmal garantieren, dass nur in unsafe Codeblöcken so ein Blödsinn passieren kann. Bei C++ kann das überall sein.

Der beschriebene Fehler tritt aber nicht auf, schließlich sollte jeder wissen, was bei einem Wachstum eines vectors passiert und dementsprechend auch etwaige Pointer oder Referenzen beachten. Ich gebe bspw. in solchen Fällen lediglich die Indicies der Elemente heraus oder sorge dafür, dass der vector nicht wächst. Oder nehme eine andere Datenstruktur.
Der Fehler an sich, ist blöd, aber auftreten tut der extrem selten.

[ipsec]

volkard schrieb:

Sowas nervt einfach nur. An den Haaren herbeigezogener Unfug, der in der Praxis gar nicht vorkommt.

Hierbei handelt es sich offenbar um ein Minimalbeispiel, um das grundlegende Problem zu verdeutlichen. Natürlich ist in diesem Fall der Fehler offensichtlich und so würde das niemand schreiben. Aber ich denke schon, dass es in der Praxis vorkommt, dass zu langlebige Referenzen und Pointer auf Elemente eines Vektors angelegt werden.

Anfängern passiert das sicherlich häufiger, erst recht, wenn sie von Sprachen wie Java kommen, weil sie gar nicht mit dem Problem rechnen. Erfahrene C++-Programmierer sind natürlich für solche Sachen sensibilisiert und vermeiden die meisten Fehler. Aber trotzdem kann es komplexere Fälle geben, z.B. wenn eine Lib unerwartet einen übergebenen Pointer intern speichert. Natürlich kann man sowas schlecht mit einem 5-Zeilen-Beispiel verdeutlichen.

Grundsätzlich ist es in C++ nun mal sehr einfach möglich, dangling Pointer oder Referenzen zu erzeugen. Auch in Anbetracht der Tatsache, dass das sicher jedem schon mal passiert ist, finde ich es überzogen, das als praxisfernen Unfug abzutun. Durch Erfahrung und Disziplin kann man diese Fehler minimieren, aber je komplexer das System wird, desto schwieriger kann man sie ausschließen.

Hinzu kommt noch, dass zusätzliche Sicherheit die Programmierung in der Regel für den Programmierer angenehmer gestaltet, auch wenn tatsächlich im Ergebnis wenig konkrete Fehler verhindert werden. Ähnliche Überlegungen könnte man zum Beispiel zu const anstellen. Wenn C++ kein const hätte, würden deswegen die Programme nicht automatisch fehlerhafter werden. Man müsste sich halt beim Programmieren mehr Gedanken machen, welche Objekte man verändern darf und welche nicht. Für externe Interfaces müsste das zusätzlich dokumentiert werden. Alles in allem aber durchaus machbar und nicht deutlich mehr Aufwand. Wenn jetzt jemand eine Sprache vorstellen würde, in der man Objekte const machen kann und als Motivation ein kurzes C++-Programm angibt, in dem ein Objekt fälschlicherweise manipuliert wird, würdest du das vielleicht auch als praxisfern abtun, weil niemand das so schreiben würde. Aber auf const verzichten möchtest du auch nicht, oder?

[Mechanics]

Rustiger schrieb:

@Mechanics:
Ja, wenn man das "nur" vom beruflichen Aspekt sieht, dann kann ich dich gut verstehen.

Nicht nur aus beruflicher Sicht. Ich interessiere mich auch noch privat für die Programmierung (auch wenn ich nach der Arbeit nicht mehr viel machen kann). Nur wil ich mich daheim erst recht auf die Projekte konzentrieren, die mich interessieren. Und deswegen ist mir die Sprache dabei relativ egal, ich will sie in einer Sprache schreiben, die ich schon kann, für die es Bibliotheken gibt und wo ich weiß, dass Compiler und IDE funktionieren. Ich verschwende doch nicht das bisschen Freizeit, dass ich noch habe, um mich mit einer neuen Programmiersprache rumzuärgern.

[JustEvo]

Mechanics schrieb:

Rustiger schrieb:

@Mechanics:
Ja, wenn man das "nur" vom beruflichen Aspekt sieht, dann kann ich dich gut verstehen.

Nicht nur aus beruflicher Sicht. Ich interessiere mich auch noch privat für die Programmierung (auch wenn ich nach der Arbeit nicht mehr viel machen kann). Nur wil ich mich daheim erst recht auf die Projekte konzentrieren, die mich interessieren. Und deswegen ist mir die Sprache dabei relativ egal, ich will sie in einer Sprache schreiben, die ich schon kann, für die es Bibliotheken gibt und wo ich weiß, dass Compiler und IDE funktionieren. Ich verschwende doch nicht das bisschen Freizeit, dass ich noch habe, um mich mit einer neuen Programmiersprache rumzuärgern.

So kann man auch die IT-Evolution zum erliegen bringen. Würden das mehr Leute so sehen, dann gäbe es nur noch Programmiersprachen die immer wieder weiteren Flicken bekommen...bähhh!

P.S.: Welche Entwickler kennt denn nur ein oder zwei Programmiersprachen?

[krümelkacker]

JustEvo schrieb:

So kann man auch die IT-Evolution zum erliegen bringen. Würden das mehr Leute so sehen, dann gäbe es nur noch Programmiersprachen die immer wieder weiteren Flicken bekommen...bähhh!

Zu faul zu sein, sich was neues anzugucken, ist ja eigentlich auch normal. Das will ich keinem ankreiden. Ich hüpfe auch nicht auf jeden Zug. Es ist eben eine Kosten-Nutzen-Rechnung mit Ungenauigkeiten, weil man das, was man lernen würde, ja vorher nicht so gut einschätzen kann. Habe neulich erst 'n netten Artikel gelesen, der zu diesem Thema passt: Why your F# evangelism isn't working.

Mechanics schrieb:

Nicht nur aus beruflicher Sicht. Ich interessiere mich auch noch privat für die Programmierung (auch wenn ich nach der Arbeit nicht mehr viel machen kann). Nur wil ich mich daheim erst recht auf die Projekte konzentrieren, die mich interessieren. Und deswegen ist mir die Sprache dabei relativ egal, ich will sie in einer Sprache schreiben, die ich schon kann, für die es Bibliotheken gibt und wo ich weiß, dass Compiler und IDE funktionieren. Ich verschwende doch nicht das bisschen Freizeit, dass ich noch habe, um mich mit einer neuen Programmiersprache rumzuärgern.

Das passt echt zu deinem Namen. Dir ist das Werkzeug egal. Hauptsache, du kannst es bedienen und da kommt was hinten bei raus… Und da ist jetzt auch nichts schlechtes dran. Dem einen oder anderen ist aber vielleicht auch wichtig, wie „effizient“ so ein neues Werkzeug ist, auch wenn er das erst erlernen müsste, wobei das Erlernen ja auch Spaß bringen kann und nicht nur/unbedingt ein Rumärgern bedeuten muss.

volkard schrieb:

Hier gibt es einige Leute, die Rust-Diskussionen gegenüber ablehnend stehen. Weil hier regelmäßig Fanboys reinschneien und alle Leute von irgendwas Neuem missionieren wollen, Rust war da auch recht oft dabei.

Ich finde das nicht schlimm, wenn man in einem allgemeineren Unterforum, was "Rund um die Programmierung" heißt, solche Themen anreißt. Du bist da IMHO nur zu empfindlich und stolz. Es fällt Dir anscheinend schwer, Leute, die sich auch kritisch zu C++ äußern, nicht reflexartig in die Feind-Schublade zu stecken. Das hat auch Fanboi-Züge und ist keine gute Voraussetzung für gehaltsvolle Gespräche.

Aber ich stimme Dir zu, dass es ab einem gewissen Punkt des Meinungsaustauschs, zumindest zwischen denselben Leuten, langweilig wird, weil alles gesagt wurde und man sich nur noch im Kreis dreht.

volkard schrieb:

Andauernd passieren mir Fehler wie

int main() {
	[](void(*_)()){_();}(0);//segfault
}

und die würden in Prolog nicht passieren. Darum sollten alle jetzt sofort nach Prolog umsteigen.

Das ist wieder so ein im-Kreis-dreh-Moment. Ich bin mehrfach auf ähnliche Kommentare (als krümelkacker oder kkaw) eingegangen, habe Beispiele gebracht, die nicht so offensichtlich falsch waren und u.a. auch in freier Wildbahn zu finden sind, habe erklärt, was in realem Code zu Problemen führen kann. Und damit meine ich guten, “modernen” Code, der so aussieht, als ob jemand C++ verstanden hätte, auch für Dich. Ich weiß auch, dass solche Fehler bei 'nem guten C++ Programmierer recht selten sind. Ich habe damit auch so gut wie keinen Ärger in C++! Aber es hat trotzdem etwas befreiendes, in Rust mit Referenzen zu arbeiten, weil man weiß, dass der Compiler einem bzgl potentiell baumelnden Referenzen hilft (im Sinne von "wird zu 100,0% ausgeschlossen"!). Es ist Newbie-freundlich. Und es ist etwas schönes, in der Hinsicht selbstdokumentierende Schnittstellen zu haben. Bei einer Funktion, die eine Referenz zurückgibt, weiß man ganz genau, wie lang sie gültig sein wird, ganz ohne Doku. Das ist auch prima für Bibliotheksentwickler, die eine falsche Benutzung nach Möglichkeit verhindern wollen. Und das ist ja wohl eher die Regel: Du hast überdurchschnittlich gute Programmierer, die Bibliotheken bauen und eher durchschnittliche Programmierer, die solche Bibliotheken benutzen.

[DasNeue]

Zumal es "gute und moderne" C++-Programmierer kaum zu geben scheint. Hier war einmal einer der C++ für einen Job lernen wollte und dort wurde gesagt, dass er ca. ein Jahr braucht, um C++ mit einem guten Buch(was wohl selten ist) und dem Forum hier zu lernen. Aus ihm würde dann, auch durch die Hilfe im Forum hier, mit hoher Wahrscheinlichkeit ein besser c++-Programmierer als die Berufsprogrammierer, die er so kennt.

Man KANN in C++ sicher programmieren. Die Sprache kann dies aber NICHT garantieren, das ist das was zählt. Nur auf die Fehlerfreiheit und auf Top-Kenntnisse der Sprache C++ zu setzen, sehe ich als ziemlich riskant an und viele andere auch, sonst gäbe es heute nicht so viele erfolgreiche Sprachen neben C++.

Sicherheit nur vom Programmierer abhängig zu machen, ist sehr kurzsichtig. Ich finde es gut, dass es immer wieder neue Programmiersprachen gibt. Die IT wird nun einmal immer besser und dazu gehört es Neues zu entwickeln und auszuprobieren.

Wem der Weg zum Ziel keinen Spaß macht, der lässt es halt bleiben. Mir persönlich macht es Spaß neue Sprachen auszuprobieren. Und auch darüber zu diskutieren macht Freude. Die Sprachen in ihren verschiedenen Aspekten zu vergleichen gehört zu diesem Entdecken dazu. Bis auf C++ hat man auch viele Sprachen in einem Monat so weit gelernt um eigene Projekte damit fahren zu können. Ich sehe das bei einigen Blogs in dem Rust z.B ein Path-Raytracer einmal in C++ und einmal in Rust entwickelt wurde und dann wurde zum Schluss verglichen. Der Speed war so ziemlich gleich, beide Sprachen hatten Vor- und Nachteile, aber am Ende hat dem Autor Rust besser gefallen.

SpracheX vs. SpracheY sollte immer ein fester Bestandteil eines Forums sein. Denn dieser Vergleich interessiert mich immer, wenn ich eine neue Sprache sehe. Wenn solche Unterhaltung dann aber gleich als Trollerei und Flamewar runter gebügelt werden, dann ist das echt ein Schlag ins Gesicht für die Meinungsfreiheit.

Wenn hier einer beweisen kann, dass C++ sicherer ist als Rust, dann soll er dies tun. Den anderen mit "Trollerei" zu diskreditieren ist allerdings unterste Schublade.

Vor allem macht es doch einen Riesenspaß was Neues zu lernen. Das Interesse an Programmierung im Jahre 2015 vor rausgesetzt.

[DasNeue]

Nachtrag:
Die Sprache ist nun einmal als Ersatz für C und C++ direkt so entwickelt worden und deswegen MUSS man sie auch damit immer wieder vergleichen können dürfen. Ob Rust erfolgreich wird oder nicht weiß keiner, es ist ja auch nichtmal Version 1.0 wirklich draussen. Ich finde es gut mal wieder einen Schritt in Richtung kompilierbare Sprache zu gehen und moderne Anforderungen einer heutigen nativen Sprache umzusetzen. Eine neue Sprache ohne VM und ohne GC, sondern mit RAII und unsafe-Blocks ist doch toll. Das Buildtool cargo finde ich auch spitze, ganz einfach libs veröffentlichen und Abhängigkeiten automatisch auflösen usw. Keine Header und Source-Dateien mehr. Gut der Syntax ist auch für mich sehr gewöhnungsbedürftig, aber nichts was man nicht lernen kann, so man denn will.

Ich finde Rust ist ein Weg in die richtige Richtung und so lohnt sich so etwas zu unterstützen. Gerade heute ist es wichtig wenn Software sicherer wird.

[großbuchstaben]

DasNeue schrieb:

Eine neue Sprache ohne VM und ohne GC, sondern mit RAII und unsafe-Blocks ist doch toll.

absolut - ohne VM und GC, das muß man sich mal vorstellen!

Aber gibt es da nicht eine Sprache mit RAII, mit ohne VM und ohne GC, die seit über 3 Jahrzehnten weit verbreitet ist, eine riesige Code- und Benutzerbasis hat, und gerade in den letzten Jahren stürmisch weiterenwickelt wird - die heißt irgendwas mit "C" und "plus" oder "11", komm' jetzt gerade nicht drauf

[DasNeue]

Ist ja richtig, C++11 bietet eine ganze Menge und da wurde viel Nützliches mit angebaut. Die Sprache ist aber nach wie vor unnötig kompliziert und per Standard unsafe. Die große Codebase wird auf lange Sicht der einzige Vorteil der Sprache bleiben. In andere Sprachen lassen sich aber auch sehr leicht C- Libs einbinden, was einen Übergang, bis genügend eigenen Libs vorhanden sind, leichter macht.

Rust ist halt ein erster Versuch C und C++ komplett abzulösen. In wie weit das gelingt werden so die nächsten fünf Jahre zeigen. Neue Sprachen brauchen immer eine ganze Weile um akzeptiert zu werden. Die Leute die sich jetzt damit beschäftigen sind wie Forscher auf einem neuen Planeten. Das ist anstrengend aber auch aufregend. Wenn man allerdings gleich von Vornherein alles Neue abschmettert, dann wird nie was Neues kommen und die Evolution bleibt stehen. C++ kann man nun einmal nicht mehr sicher bekommen, sonst wäre es nicht abwärtskompatibel. Alles hat seinen Preis, das All-in-One-Wunder gibt es nicht. Aber man kann so etwas ja versuchen zu bauen und vielleicht kommt man dem ja mit jeder neuen Sprache etwas näher.

Ich versuche jedenfalls alles um die Sprache bekannt zu machen, denn ich finde sie geht einen Schritt in die richtige Richtung.

[Ethon]

Keinen GC zu haben ist doch ein Nachteil.
Da ist D toll. Kombiniert beides.

[dot]

Ethon schrieb:

Keinen GC zu haben ist doch ein Nachteil.

Hab noch kein Beispiel gesehen, wo das ein Nachteil gewesen wäre, im Gegenteil. Zumindest meiner Erfahrung nach macht die Abwesenheit eines GC fundamentale Dinge wie Ressourcenverwaltung wesentlich einfacher und führt zu wesentlich beserer Softwarequalität, z.B. weil man von Anfang an gezwungen wird, gewisse Eigenschaften des zu lösenden Problems im Design zu addressieren (z.B. solche, die sich in Besitzfragen äußern), die durch die Anwesenheit des GC so lange verschleiert würden, bis sie still und heimlich zu einem ausreichend großen Monster herangewachsen sind.

Der einzige mir bewusste "Nachteil" ist, dass man tatsächlich fähige Programmierer braucht. Ohne die wird man aber früher oder später Probleme haben, die Dimensionen annehmen, die die zunächst vermeintlich gesparte Zeit relativieren. Freut mich zu sehen, dass die Welt langsam aber doch aufzuwachen scheint...

[Ethon]

Och, wenn man beide Seiten der Medaille kennt, zb weil man lange C++ programmiert hat, dann weiß man auch wie man einen gc richtig nutzt.
Ich programmiere gerne mit gc.

[dot]

Ethon schrieb:

Och, wenn man beide Seiten der Medaille kennt, zb weil man lange C++ programmiert hat, dann weiß man auch wie man einen gc richtig nutzt.
Ich programmiere gerne mit gc.

Einer meiner größeren Fehler bisher, aus denen ich sehr viel lernen durfte, war, ein bestimmtes Projekt auf Wunsch des Kunden in C# zu schreiben. Ich hatte keine Ahnung wie vielfältig die Welt der Probleme, die GC in einem komplexeren Projekt (in dem Fall eine kleine CAD Anwendung) verursachen kann, doch ist. Jetzt weiß ich es allerdings besser und bastel bestenfalls ein sehr komplexes GUI (aus praktischen Gründen, auch wenn dieses eventbasierte zusammenpappen von Dingens einfach nur furchtbar ist) aber niemals die Business Logic dahinter in Sprachen mit GC. Hätte ich das damals schon so gemacht, wäre die resultierende Anwendung nicht nur performanter (die Performance von C# hat sich in dem Fall sogar als gerade noch ausreichend herausgestellt, wobei es dank GC massive Speicherprobleme gibt), sondern vor allem auch wesentlich einfacher (im Sinne von weniger und vor allem weniger komplizierter Code) und als indirekte Folge davon viel stabiler...

Diese Erfahrung bescherte mir auch meinen ersten Kontakt mit C++/CLI und der Illusion vom wunderbaren Universum der Sprachen in denen die Welt mit und die Welt ohne GC friedlich koexistieren. Ich hab mich mit D nicht wirklich beschäftigt, aber zumindest auf den ersten Blick sehe ich auch dort weder etwas Neues noch irgendwelche Anzeichen einer sinnvollen Antwort auf die Frage, wie man diese beiden Dinge auf produktive Art kombinieren könnte. Meine Theorie: Die beiden Dinge sind wie Tag und Nacht und schließen sich rein prinzipiell gegenseitig aus. Die Entwickler von Rust und Swift haben das offenbar auch verstanden...

[Mechanics]

krümelkacker schrieb:

Das passt echt zu deinem Namen. Dir ist das Werkzeug egal. Hauptsache, du kannst es bedienen und da kommt was hinten bei raus… Und da ist jetzt auch nichts schlechtes dran. Dem einen oder anderen ist aber vielleicht auch wichtig, wie „effizient“ so ein neues Werkzeug ist, auch wenn er das erst erlernen müsste, wobei das Erlernen ja auch Spaß bringen kann und nicht nur/unbedingt ein Rumärgern bedeuten muss.

Hmm, ein bisschen weit hergeholt Es ist auch nicht unbedingt so, dass mir egal wäre, wie "effizient" ein Werkzeug ist. Sagen wir mal so, ich hätt überhaupt kein Lust, Visual Basic zu programmieren, auch wenn ich es wahrscheinlich könnte, ohne es explizit zu lernen (hab schon sehr oft gesehen und was angepasst). Ich hab auch gern Scala gelernt und benutzt, als ich Java programmiert habe. Da habe ich aber die entscheidenden Vorteile gesehen, die mir Scala gegenüber Java bietet. Und es hatte kaum Nachteile, ich konnte das in bestehenden Java Projekten verwenden, nur die IDE Unterstützung war nicht ganz ausgereift. Bei Rust habe ich einfach keine wirklich relevanten Vorteile, dafür habe ich etliche Nachteile. Das reicht einfach nicht, um mein Interesse zu wecken.