Von C zu Rust wechseln?

[Rustiger]

Witzig, dass ein C++ler sich über die Syntax ärgert Aber gut, dann haben wir einen Rust-Coder weniger^^

[Mechanics]

Warum ist das witzig? Die C++ ist Syntax ist doch eigentlich die "normalste". Wenn man von irgendwelchen komischen Konstrukten in C++ absieht, ist eine C-artige Syntax am weitesten verbreitet.
Aber ich "ärgere" mich nicht drüber. Mich interessiert Rust aus anderen Gründen nicht, mit der Syntax könnte ich leben.

[Rustiger]

Ah, dann habe ich dich falsch verstanden. Was stört dich dann an Rust? Außer jetzt die Nachteile dass es neu ist und BestPractice, Community und Libs erst wachsen müssen, falls denn Rust gut ankommt, was ja noch keiner weiß. Beta ist ja im Februar und stable Release 1.0 dann im März 2015.

[Nathan]

Mir gefällt die Syntax auch nicht sonderlich. Und die ganzen Abkürzungen sowohl in den Schlüsselwörtern als auch in der Standardbibliothek oder wie die bei Rust heißt nerven mich doch. Aber daran könnte ich mich vermutlich gewöhnen.
Was mich genau an der Sprache stört kann ich schwer beschreiben. Es könnte z.T. daran liegen, dass sie wie eine Skriptsprache wirkt. Konstrukte wie enums als tagged-Unions sind zwar ungeheuer praktisch, aber mir irgendwie suspekt. Das ist zu abstrakt, zu High-Level für eine Systemsprache.
Hauptsächlich ist es aber wohl eine Sache der Gewöhnung. Hätte ich Rust anstatt C++ gelernt, würde ich das nicht sagen und C++ wohl so wie C betrachten. Aber so bleibe ich lieber bei C++.

[Mechanics]

Rustiger schrieb:

Außer jetzt die Nachteile dass es neu ist und BestPractice, Community und Libs erst wachsen müssen

Das ist der Punkt. Ich mache das hauptberuflich. Das alles übt auf mich schon lange nicht mehr so eine Faszination aus, wie früher. Die Sprache mag interessant sein, aber eine interessante Sprache ist mir viel zu wenig. Ohne wirklich extrem gute Gründe werde ich mich nicht mit noch einer neuen Programmiersprache beschäftigen. Und die Wahrscheinlichkeit, dass die Sprache sich durchsetzt ist eben aus diesen Gründen sehr gering.
Außerdem interessieren mich einfach "große" Projekte. Ich mag nicht in kleinen Firmen arbeiten, die an kleinen Projekten basteln. Ich will in sehr großer Software mit sehr vielen Komponenten rumwühlen. Sowas entsteht nicht von heut auf morgen und sowas entsteht selten von Grund auf neu. Das ist meist Software, die schon lang auf dem Markt ist. Und deswegen ist die wahrscheinlich in C++ geschrieben

[krümelkacker]

Rustiger schrieb:

Wie ist eigentlich so die Resonanz auf Rust in Entwicklerkreisen?

Ich kann nur für mich sprechen. Ich find's sehr interessant und ich verfolge das jetzt auch schon seit April 2014. Es gibt viele schöne Eigenschaften der Sprache.

Aber es gibt auch noch genug Macken, die mir im Weg stehen. Z.B. verabschiedet sich der Compiler einfach mal, wenn man ihn bzgl generischer Programmierung zu stark fordert:

trait T { type A: T; }
fn main() {}

lässt den Compiler in eine Endlosrekursion laufen, was kurz vor dem Überlauf zu einem Abbruch führt. Gut, das sind Bugs, die gefixt werden müssen. Also: Einfach ausprobieren und auf GitHub entsprechende Tickets dafür öffnen. Ich bin aber auch öfters an die Grenzen der Sprache selbst gestoßen. Da bin ich von C++ wahrscheinlich schon etwas verwöhnt. Die strengen "Kohärenzregeln" von Rust nerven jedenfalls. Ich finde das etwas peinlich, dass man

x + 3.0

wo der Typ von x benutzerdefiniertert ist, kompiliert bekommt, dagegen

3.0 + x

aber nicht.

Was ich an Rust gut finde:

• Die Move-Semantik macht einiges einfacher (flache Kopie der Bits => klappt immer auch ohne std::move_if_noexcept , moves sind destruktiv => man kommt komplett ohne Zombie-Zustand in der Invariante aus)
• Die eingebauten Tupel- und Summentypen sind sehr praktisch.
• das Pattern-Matching per match , if let , while let
• die Lebenszeitparameter im Typsystem und der Borrow-Checker.
• Der Compiler unterscheided zwischen versch. Typgattungen (Send, Sync) um damit z.B. Datenrennen und baumelnde Zeiger auch im Multithreading-Kontext ausschließen zu können.

Da geht noch was. Ich werde das weiterhin verfolgen.

[Rustiger]

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.

@Mechanics:
Ja, wenn man das "nur" vom beruflichen Aspekt sieht, dann kann ich dich gut verstehen. Meine Zeit als Berufsprogammierer ist vorbei und ich mache das nur noch als Hobby und da sind mit natürlich große Projekte, alter Code etc total egal. Als ich noch so etwas als Job gemacht hatte, da hatte ich aber auch kaum noch Lust privat was zu machen. Der Job hat fast meine ganze Freude an der Programmierung gekillt, was ich sehr schade fand. Alles musste immer Sinn ergeben und so weiter. Das ist jetzt zum Glück wieder anders und ich habe meine kindliche Neugier + viel Zeit wieder gewonnen.

[krümelkacker]

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.

[Rustiger]

Hey, danke für den Tipp. Ich bin schon fleißig am Links sammeln, Notizen machen und natürlich am Lernen und Ausprobieren.

Ich habe dort gerade was von einem 151-byte static Linux binary in Rust gelesen. Es geht also wirklich ziemlich runter bis auf LowLevel in unsafe Blocks und wenn man will mit Assembler.
Aber erst einmal muss ich mich an die neue Syntax gewöhnen, aber der Mensch ist ja ein Gewohnheitstier und meidet große Veränderungen, da muss man bewusst erst einmal gegensteuern und einfach machen, machen, machen. Wenn man flexibel genug ist und es liebt über den Tellerrand zu schauen, dann geht dass irgendwann ins Blut über und C und C++ sind dann fremd, altbacken und unnötig^^

[Rustiger]

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?

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

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

$ g++ hello.cpp -Wall -Werror
$ ./a.out
Segmentation fault (core dumped)

[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?