Go vs. Rust - System Programming languages - Umfrage

Ethon

Was exakt ist eigentlich der Grund dass hier so gegen GCs gehetzt wird? Der Performance ist gleich gut bis besser, die Vorteile liegen auf der Hand.

Irgendwie geht es immer nur um die deterministische Freigabe von Resourcen (die ich fast nie benötige und wenn dann lässt sich das auch in GC-Sprachen mit minimalem Aufwand machen, zb. try with resources) oder um die Echtzeit-Tauglichkeit die einerseits bei den meisten Applikationen uninteressant ist (und wofür vermutlich auch C++ eher ungeeignet ist) und andererseits nichtmal stark beeinträchtigt ist. Wenn zb. der Java GC anspringt sieht man keinen signifikanten Einbruch - wenn man nicht gerade für Android & Dalvik entwickelt.

Perfekt ist in meinen Augen das Modell von C#: GC und trotzdem zusammengesetzte Werttypen.

Nathan

Ethon schrieb:

die ich fast nie benötige und wenn dann lässt sich das auch in GC-Sprachen mit minimalem Aufwand machen, zb. try with resources

Da haben wirs.
Wieso möglichen Laufzeitoverhead und minimalen Aufwand, wenn man dasselbe für minimalen Aufwand ohne möglichen Laufzeitoverhead* haben kann?

*gut, exception handling kann da evtl. auch Overhead reinmachen

Kellerautomat

Ethon schrieb:

Der Performance ist gleich gut bis besser, die Vorteile liegen auf der Hand.

Nein und nein.

Ethon schrieb:

Was exakt ist eigentlich der Grund dass hier so gegen GCs gehetzt wird? Der Performance ist gleich gut bis besser, die Vorteile liegen auf der Hand.

Ich fühl mich dabei jetzt nich so richtig angesprochen. Habe während des Studiums und ein bisschen danach, viel Java gemacht. Aber seit dem ich zu C++ gewechselt habe, habe ich nie einen GC vermisst. Und da frag ich mich schon, warum ich mir so etwas ans Bein binden soll, wenn ich es doch nicht brauche. Mag ja sein, dass Du ganz andere Anwendungsfälle hast ... Dagegen sag' ich ja auch nichts ...

Als D Fan interessiert dich vielleicht, dass jemand D für einen JavaScript JIT Compiler verwendet hat und neulich bemerkte, dass 75% der Laufzeit für Allokation/Garbage Collection drauf gehen, weil die aktuelle Implementierung quadratisch viel Zeit in der Zahl kleiner Objekte "verbrät". Ist also zumindest verbesserungswürdig. Garbage Collection bedeutet bewiesenermaßen ein Zielkonflikt zwischen Speicheraufwand und Zeitaufwand. Meist wird sowas zugunsten der Performance implementiert, was dann 2-5fachen Speicheroverhead bedeuten kann.

hustbaer

Ethon schrieb:

Was exakt ist eigentlich der Grund dass hier so gegen GCs gehetzt wird? Der Performance ist gleich gut bis besser, die Vorteile liegen auf der Hand.

GCs ohne Generations (oder ähnliche Konstrukte) sind langsam, weil sie bei jeder Collection alle Objekte durchackern müssen. Bei Programmen mit einem grossem Working-Set welches sich aus vielen kleinen Objekten zusammensetzt braucht das viel Zeit.

GCs mit Generations sind schneller, dafür müssen sie über das Ändern von Referenzen Buch führen. Was auch nicht gratis ist - alle Schreibzugriffe auf Referenzen werden dadurch langsamer.

GCs die kompaktieren verbraten beim Kompaktieren Zeit. Umso mehr je mehr Objekte es gibt, weil alle Referenzen auf verschobene Objekte umgeschrieben werden müssen. (Und natürlich müssen die Objekte auch verschoben werden, was aber wenn ich mich richtig erinnere eher weniger ins Gewicht fällt.)

Und GCs die nicht kompaktieren brauchen erst wieder eine Freelist und müssen diese warten und bei Allokationen darin suchen. Was einen wichtigen Punkt wo der GC aufholen kann wieder zunichte macht.

In Summe kann sich das vermutlich je nach Programm so oder so auswirken. Pauschal zu sagen der GC wäre "gleich schnell oder schneller" halte ich aber für falsch.

hustbaer

ps:

Ethon schrieb:

Irgendwie geht es immer nur um die deterministische Freigabe von Resourcen (die ich fast nie benötige

Also ich brauch' das dauernd. Wirklich, dauernd.
Und wenn ich mir C# Code von anderen Programmierern so ansehe (z.B. Code von Kollegen, Zeugs was im Internet rumflattert etc.), dann finde ich da auch haufenweise fehlende "using" Blöcke (using=das C# "Original" zu try-with-resources).

ps: Was passiert wenn man nach dem Motto "muss nicht deterministisch freigegeben werden, ist ja im Endeffekt eh nur Speicher" arbeitet, das sieht man bei WPF. WPF + D3DImage + öfter mal die Direct3D Surface wechseln = OutOfMemoryException. Suba, danke ihr tollen "GC is voll kuhl und wir sind voll schlau" Entwickler!!1elf
Und natürlich hatte ich auch noch niiiiiemals ein Java oder C# Programm das mir ein File offen gehalten hat nachdem ich das entsprechende Dokument im Programm bereits geschlossen hatte. Nein, ehrlich, niiiiiie.

volkard

Ich füchte, wenn dem C++-Compiler erlaubt wäre, optimierend bei der letzten Verwendung einer Variablen das move automatisch einzufügen, bräuchte ich kein rust.
Zur Zeit nervt es mich unendlich, daß ich nachdenken muss, wann ich eine Variable wegmoven sollte und wann nicht.

Damit wäre ich satt. Noch sind mir auch 256 Prozessorkerne recht egal.

Denke, rust ist der maßgebliche Wegbereiter für eine kommende Messias-Sprache, die dann für sehr sehr lange Zeit was taugt.

volkard schrieb:

Ich füchte, wenn dem C++-Compiler erlaubt wäre, optimierend bei der letzten Verwendung einer Variablen das move automatisch einzufügen, bräuchte ich kein rust.

Das wurde sogar mal vorgeschlagen. Aber dann sind Code-Beispiele aufgetaucht, die mit so einer Regel nicht mehr das tun würden, was sie sollen. Du brichst also ggf alten Code damit. Das ist noch gar nicht lange her. Findest Du bestimmt irgendwo in 'nem Mailarchiv von isocpp.org oder so. Nachdem derjenige, der das vorgeschlagen hatte, die Beispiele gesehen hatte, zog er seinen Vorschlag wieder zurück.

volkard schrieb:

Zur Zeit nervt es mich unendlich, daß ich nachdenken muss, wann ich eine Variable wegmoven sollte und wann nicht.

Echt? Wie kommt's? Kannst du das eingrenzen? Beschränkt sich das auf generischem Code, den Du schreibst? Denn da könnte std::forward auch nicht ganz unpraktisch in einigen Fällen sein. Zum Beispiel wird im Move-Constructor von std::tuple std::forward verwendet, weil so ein T auch eine Referenz sein könnte und andernfalls unbeabsichtigt etwas gemovet werden könnte:

string x = "hello";
string y;
tie(y) = tie(x); // dies sollte x NICHT verändern obwohl tie(x)
                 // ja ein Rvalue vom Typ tuple<string&> ist.

Ich kann mich jedenfalls nicht an Situationen erinnern, wo die Frage, ob ich std::move oder std::forward benutzen sollte oder nicht, schwierig zu beantworten gewesen wäre. Allerdings habe ich bestimmt auch ein Jahr vorher gebraucht, um die Details von Rvalue-Referenzen komplett zu verstehen.

volkard schrieb:

Denke, rust ist der maßgebliche Wegbereiter für eine kommende Messias-Sprache, die dann für sehr sehr lange Zeit was taugt.

Ahja.

Hab noch schöne C++ Beispiele bzgl Speichersicherheit gesehen:
https://www.reddit.com/r/programming/comments/2ghl3o/the_road_to_rust_10/ckjpd7p

neue infos zu rust:

We plan to ship the 1.0 beta around the end of the year. If all goes well, this will go on to become the 1.0 release after the beta period:
http://blog.rust-lang.org/2014/09/15/Rust-1.0.html

volkard schrieb:

Lustige GCs bauen, weil man in C viel Aufwand hatte, an jedes close() und free() zu denken.

Das ist sehr stark vereinfacht! Mehrfache frees sind auch ein Problem. Klar, das Problem kannst du umgehen, wenn du eine Variable nach einem free auf NULL setzt, aber das ist Symptombehandlung und bläht den Code auf.
Gerade wenn du geteilte Ressourcen hast und auch noch multithreaded, wird das mit der Speicherverwaltung zunehmend komplizierter.
Oder du machst

int *x = malloc(...);
...
x = malloc(...);
...
free(x);

Den Memoryleak übersehen viele gerade bei längerem Code. Nee, gerade du solltest es wissen, dass Memoryleaks nicht nur dadurch entstehen, in dem man am Funktionsende ein free() oder close() vergessen hat und die Changelogs von bekannten größeren Projekten wo Profis programmieren, verdeutlichen auch, dass das kein Problem von gestern oder von Anfängern ist. Das geht vom Linux-Kernel bis zum Google Chrome Browser!

L. G.,
IBV

hustbaer

Also erstmal ist es auch in C nicht wirklich so schwer Resourcen korrekt zu verwalten. Es ist bloss aufwendig und man benötigt dafür recht viel Disziplin.

Ich glaube aber dass volkard darauf nicht hinauswollte.
Sondern eher darauf dass wir ja jetzt C++ haben, wo man Dinge wie RAII wunderhübsch einfach machen kann.

Ethon

hustbaer schrieb:

Ethon schrieb:

Was exakt ist eigentlich der Grund dass hier so gegen GCs gehetzt wird? Der Performance ist gleich gut bis besser, die Vorteile liegen auf der Hand.

GCs ohne Generations (oder ähnliche Konstrukte) sind langsam, weil sie bei jeder Collection alle Objekte durchackern müssen. Bei Programmen mit einem grossem Working-Set welches sich aus vielen kleinen Objekten zusammensetzt braucht das viel Zeit.

GCs mit Generations sind schneller, dafür müssen sie über das Ändern von Referenzen Buch führen. Was auch nicht gratis ist - alle Schreibzugriffe auf Referenzen werden dadurch langsamer.

GCs die kompaktieren verbraten beim Kompaktieren Zeit. Umso mehr je mehr Objekte es gibt, weil alle Referenzen auf verschobene Objekte umgeschrieben werden müssen. (Und natürlich müssen die Objekte auch verschoben werden, was aber wenn ich mich richtig erinnere eher weniger ins Gewicht fällt.)

Und GCs die nicht kompaktieren brauchen erst wieder eine Freelist und müssen diese warten und bei Allokationen darin suchen. Was einen wichtigen Punkt wo der GC aufholen kann wieder zunichte macht.

In Summe kann sich das vermutlich je nach Programm so oder so auswirken. Pauschal zu sagen der GC wäre "gleich schnell oder schneller" halte ich aber für falsch.

Ist halt immer schwer zu vergleichen. Ich erinnere mich aber an ein paar Benchmarks in denen der Boehm GC ( http://www.hboehm.info/gc/ ) keine Probleme hatte mit manueller Speicherverwaltung mitzuhalten.

vortrag zu rust:
http://media.ccc.de/browse/conferences/hackover/2014/hackover14_-_6496_-_de_-_raum_1_7_-_201410251345_-_programmiersprache_rust_und_ihre_sicherheitsgarantien_-_esgeh.html#video

was meint ihr?

ich hatte neulich mal einen interessanten beitrag gelesen... in der jemand ein problem in "Go" umsetzt und das in 10-20 zeilen anstatt 50-100 (C,C++) ...

ich muss nochmal schauen ob ich dazu den link finde...

aber da fand ich die sprache "Go" eigentlich gar nicht soooo schlecht... also relativ kompakt und übersichtlich... dafür relativ abstrakt wie ich finde... aber wenn man sich da einmal eingearbeitet hat geht das bestimmt auch...

ich fand es halt interessant... weil wenn man mal "schnell" ein programm bauen will dann coded man schnell 10 go zeilen zusammen und fertig ...
vll stelle ich mir das auch zu einfach vor...

was haltet ihr von "go"?

selbst hab ich aber noch nix produktiv mit go gemacht außer spaßens halber mal nen "hallo welt" ...
aber ansonsten finde ich die semantische größe / umfang von c++ einfach unschlagbar...
auch wenn es manchmal evt. bedeutet nicht einfach klasse xyz zunehmen und alles reinzuwerfen sonder mal selber zudenken.. das finde ich gerade bei c++ gut auch wenn es nicht alles dem programmierer überlässt wie C...

deswegen gibt es für mich nicht wirklich eine alternative zu c++ ist einfach für mich genau der richtige mix aus theorie und anwendung ...
dann ist der semantische umfang von c++ kaum zutoppen... und wenn ich diese kombination betrachte kommen sicherheitsrelevante aspekte hinzu und "bequemlichkeit" desweiteren noch effektivität ... lässt mir c++ keine wünsche offen ...
falls doch kann /sollte man eh ne andere sprache nehmen wenn diese zur problemlösung besser geeignet ist... ( grundsätzlich wie ich finde... )

ich find go cool! schreibe gerade einen compiler in go in c++ waere das wesentlich aufwendiger.

go bietet eine umfangreiche standard bibliothek and andere nette sachen... ich sehe go zwischen python um c++...

Mechanics

xyzxyz schrieb:

ich hatte neulich mal einen interessanten beitrag gelesen... in der jemand ein problem in "Go" umsetzt und das in 10-20 zeilen anstatt 50-100 (C,C++) ...)

Find ich völlig uninteressant. Es gibt sehr viele Sprachen, in denen du viele kleinere Programme viel kompakter als in C++ oder anderen Sprachen schreiben kannst. Das sagt überhaupt nichts aus. Wenn ich ein 20 Zeilen Script brauche, dann nehm ich Python oder etwas ähnliches. Wenn ich etwas größeres schreiben will (schon ab tausend Zeilen nicht mehr), würd ich persönlich schon keine dynamisch typisierte Scriptsprache mehr in Erwägung ziehen. Außer vielleicht bei Webanwendungen, wo die einzelnen Teile relativ unabhägig sind. Aber zum Glück schreib ich keine Webanwendungen

Dynamisch typisiert ist wirklich Kacke.
Wenn man eine ähnliche Ausdrucksfähigkeit und Flexibilität haben will wie in Ruby o. ä., dann ist Scala eine Option. Hat Typeinferenz, funktionale Features, und auch so etwas ähnliches wie Ducktyping, nur eben wirklich typsicher! Aber: Scala ist deutlich komplexer als Ruby und andere imperative Sprachen (ausgenommen C++ vielleicht).

L. G.,
IBV

Neue Programmiersprachen bringen heute nur was, wenn da gewaltige Libs mitgeliefert werden, oder halt vorhanden sind, so wie bei Qt oder auch bei Java. Einer der wichtigsten Gründe C oder auch C++ zu nutzen sind ja auch die Verfügbarkeit von viel Code. Was auch nicht zu verachten ist, ist die Community die hinter einer Sprache steht. Was nutzt mir eine top designte Sprache, wenn kaum jemand sie spricht und ich ewig lange brauche, um schon die trivialsten Fehler am Anfang zu finden? Wenn dann noch Best-Practice-Tipps fehlen macht das nochmal weniger Freude. Ist es dann noch schwach mit Fachliteratur/Tuts etc bestellt geht der Sinn in solch eine Sprache viel Zeit zu investieren gegen null.

Der einzige Sinn, solche Sprachen aus zu probieren, sehe ich als Test oder weil man sich im allgemeinen für neue Ansätze/Paradigmen etc. interessiert.

Da ich Handwerker bin, kann ich das auch gerne mit Werkzeug vergleichen. Eine Handsäge oder ein Schlitz/Kreuz-Schraubendreher hat sich bewährt, lieber diese eine Art verbessern, als was völlig Neues zu erfinden. Das ist jetzt nicht die beste Analogie, aber der Kern der Aussage ist halt: Lieber Bewährtes ausbauen und verbessern, als komplett neues mit Gewalt versuchen zu etablieren. Gibt es mal komplett neue Technologien, dann machen vielleicht auch neue Sprachen mehr Sinn.

Marthog

GetSetWilly schrieb:

Der einzige Sinn, solche Sprachen aus zu probieren, sehe ich als Test oder weil man sich im allgemeinen für neue Ansätze/Paradigmen etc. interessiert.

Die Zukunft wird aber wohl andere Probleme haben als die Vergangenheit. Es wird wohl weniger die reine Rechenleistung sondern viel eher Energieverbrauch (wegen mobile), Sicherheit (Geraete bieten attraktivere Ziele als frueher) und Multithreading (wegen nicht unendlich lang ansteigender Taktrate) sein.
Rust und Go sind entwickelt, um dabei mitzuhelfen. Beide sind auf geringen Overhead, wenig Fehler und Multithreading bereits im Sprachdesign ausgelegt.