Go vs. Rust - System Programming languages - Umfrage



  • 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.



  • 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



  • 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.



  • 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.





  • 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++...



  • 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.



  • 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.



  • GetSetWilly schrieb:

    Neue Programmiersprachen bringen heute nur was, wenn da gewaltige Libs mitgeliefert werden, oder halt vorhanden sind, so wie bei Qt oder auch bei Java.

    qt ist keine eigene sprache... nur eine ide/framework... 🙄
    oder gibt es auch eine qt-programmiersprache? 😮

    und diese "gewaltigen libs" müssen auch erstmal entwickelt werden...
    das hat sich ja bei den meisten sprachen mit der zeit mit entwickelt...

    jedes problem stellt andere anforderungen und lösungswege... desweiteren führen mehrere wege nach rom... manchmal ist es evt. auch von vorteil mal was neues zu probieren und sich damit außeinander zusetzten auch wenn man nicht sofort den sinn erkennt...

    zumal meiner meinung nach go nicht schlecht ist...dort ist z.B. Nebenläufigkeit fest in die sprache verankert... ("desweiteren insbesondere im Hinblick auf skalierbare Netzwerkdienste, Cluster- und Cloud-Computing, wurde go entwickelt")...
    schau mal hier sehr interessant:
    http://www.zdnet.de/41552342/google-programmiersprache-go-auf-dem-vormarsch/?PageSpeed

    es gibt auch schon software die in go entwickelt wurde... warum das nur die großenunternehmen machen? vll solltest denen mal verraten das das sinnlos ist 😉 ... (siehe z.B. "Docker" : http://de.wikipedia.org/wiki/Docker_(Software) )

    desweiteren orientiert sich go sytaktisch an c... ist also nix grundlegend neues... außerdem solltest du grundlegte programmiertechniken auch auf andere sprachen übertragen können ohne ein tutorial... 🙄
    meiner meinung nach vereint go "einfachkeit" und c-stärken in sich und ermöglicht so ein komplexes problem schnell, übersichtlich und unkompliziert zulösen... find ich wirklich gut... 🙂

    Marthog schrieb:

    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.

    seh ich auch so...
    ich denke auch das sich go weiter verbreiten wird da diese sprache von google supportet wird... 🙂



  • MfG schrieb:

    seh ich auch so...
    ich denke auch das sich go weiter verbreiten wird da diese sprache von google supportet wird... 🙂

    Ich befuerchte ja, dass Rust wie D ein Schattendasein fuehren wird. Die Entwicklung wird zwar von Mozilla Research gefuehrt, aber es gibt noch keine Einsatzplaene fuer richtige Softwareentwicklung. Zur Zeit gibt es eigentlich nur bindings zu C-libraries und experimentelle Projekte, wie Servo, das zwar eine HTML-Layout engine wird, aber es gibt halt keine Plaene fuer einen Browser damit. Die wichtigste bisher einsatzfaehige Software ist der Rust compiler selbst.



  • Warum nutze ich tolle neue Sprachen wie D, Go, Rust, Ocaml usw. nicht?

    Weil diese zwar schön die Legacy-Nachteile von C++ & Co. auf Sprachebene ausgemerzt haben, aber die Infrastruktur/Ökosysteme dieser neuen Sprachen sind leider dürftig.

    Was nützt mir Rust oder Go, wenn ich z.B. keinen Windows-Compiler, Windows-APIs usw. habe? Und auch sonstige API/Libs und Tools, die woanders selbstverständlich sind? IDE-Unterstützung mit echter Code-Completion, Refactoring usw.?

    Es ist natürlich ein Henne-Ei-Problem. Aber wer produktiv etwas damit erstellen soll/will, der wird sich das genau überlegen.



  • @Marthog: rust ist ja noch im Alpha/Beta-Stadium und bei jedem Release wird die Kompatiblität gebrochen! Produktiv will da niemand drauf setzen. Hinter rust steht nicht nur Mozilla, sondern eine große Community und auch Samsung.
    Go wird, wie schon erwähnt, für docker verwendet. Ich denke, dass rust noch mehr Erfolg haben wird, da rust wirklich eine Systemsprache ist. Der Go-Erfinder meinte hinterher, dass Go eigentlich mehr eine Serversprache sei. rust ist universell einsetzbar: Systemprogrammierung, Serverprogrammierung, theoretisch auch Desktopprogrammierung, wenn es entsprechende libs gibt und die wird es irgendwann geben und: Es hat keinen GC! Das ist für manche bei Go ein No-Go! 🙂
    Ich bin da ehrlich gesagt zuversichtlich und freue mich schon auf Version 1.0!

    L. G.,
    IBV



  • IBV schrieb:

    @Marthog: rust ist ja noch im Alpha/Beta-Stadium und bei jedem Release wird die Kompatiblität gebrochen! Produktiv will da niemand drauf setzen.

    Ich habe mich auf das fertige Rust bezogen. Ich befuerchte, dass die meisten Entwickler hauptsaechlich auf ihre altbekannten Sprachen setzen und deswegen Rust produktiv nicht eingesetzt wird und sich in der Folge deswegen auch wenig neue libs gibt.


Anmelden zum Antworten