Go vs. Rust - System Programming languages - Umfrage



  • Hi,

    ich moechte mal eure Meinung zu folgenden "neuen" Programmiersprachen einholen:

    - Google's Go Programming Language: Taking Cloud Development By Storm:
    http://readwrite.com/2014/03/21/google-go-golang-programming-language-cloud-development

    - Under The Hood Of Mozilla's New Multi-Core Browser And The Open Source Language That Powers It:
    http://www.fastcolabs.com/3027664/under-the-hood-of-mozillas-new-multi-core-browser-and-the-open-source-language-that-powers-i

    wo seht ihr die zukunft für die jeweilige Programmiersprache? Vorteile/Nachteile? Wollt ihr rust/golang verwenden?

    Timmo



  • Seltsam, dass noch keiner geantwortet hat.
    Also, mich interessieren die neuen Sprachen nicht. Keine Zeit und keine Lust, mich damit zu beschäftigen. Wenn ich privat noch etwas entwickeln will, dann gehts nicht um "programmieren" und die Umsetzung kann ich in einer der Sprachen machen, die ich schon kann. Und mit C++ und C# bin ich völlig zufrieden.
    Die letzte neue Sprache, die ich mir angeschaut habe, war Scala. Das ist wahrscheinlich etwa 5 Jahre her. Damals hatte ich beruflich mit Java zu tun und ein Freund der das hauptberuflich gemacht hat, hat mir Scala empfohlen. Das hat gut gepasst, die Sprache hat mir gefallen und die habe ich beruflich dann auch eingesetzt. So in der Art könnte ich mir vorstellen, mir neue Sprachen anzuschauen, ansonsten interessieren die mich nicht.
    Es gibt aber gute Gründe, sich Scala anzuschauen, wenn man Java macht. Bei Sprachen wie Go oder Rust gibts aber schon viel weniger gute Gründe, warum man sie brauchen sollte.



  • go? riecht nach grobem unfug, marketing und separatismus.
    rust? viele konzepte, deren sinn sich mir nicht erschließen mag.

    hab heute wieder einen lua-ausflug machen müssen, und ich muss sagen: lue tut mir jedesmal nicht weh.



  • Seltsam, dass noch keiner geantwortet hat.

    Naja, so'ne Frage kam hier neulich schonmal, wenn ich mich richtig erinnere. Und da kam es mir so vor, als wollte sich jemand die Recherche sparen und einfach andere machen lassen.

    Why Go Is No Good

    Und weil hier vom OP Go im Zusammenhang von "sysmtems programming" genannt wurde: Der Erfinder von Go, Rob Pike, hat hier gesagt, dass er Go nicht als "systems programming language" sondern eher als eine "server programming language" bezeichnen würde. Zum "systems programming" gehört IMHO auch dazu, dass man mal "dreckigere" low-level Sachen schreiben kann und sich damit selbst höhere Abstraktionen bauen kann, wie z.B. Channels.

    Ich habe mal bei dem von Dir verlinkten Go-Artikel einen Link verfolgt und bin auf einen Blogeintrag von Rob Pike gestoßen. Mal vom Titel abgesehen, wo der Autor das Wort "exponentially" falsch verwendet, finde ich da im Text

    Rob Pike schrieb:

    We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care.

    They do care! They just don't like your language! Nur weil Du es besser machen wolltest, heißt das nicht, dass Du es wirklich besser gemacht hast!

    Da das hier ein Umfragenthema ist, gebe ich natürlich auch eine persönliche Empfehlung ab: Schaut Euch Rust an. Das, was ich als C++ Programmierer an Rust cool finde ist:

    • syntaktisch nicht so zumutbar wie C++
    • keine Header-Dateien (und damit weniger Redundanz)
    • bietet Zero-Cost-Abstraktionen (wie auch C++)
    • "stärkeres" Typsystem (im Sinne von strong vs weak typing)
    • bietet Compile-Zeit-Garantien bzgl Speichersicherheit und Threadsicherheit mit Hilfe des "Lifetime"-Systems und dem "Borrow Checker" im Compiler. Das heißt, keine baumelnde Zeiger mehr, keine Iterator/Reference invalidation mehr, keine Buffer overflows mehr, keine Datenrennen mehr)
    • erlaubt generische Programmierung ohne Ad-hoc Templates (=> keine ewig langen Fehlermeldungen vom Compiler)
    • zwingt einem keine Garbage Collection auf (wie auch C++, Yay!)
    • zwingt einem keine Indirektion auf (Man bekommt Referenzen/Zeiger nur, wenn man explizit danach fragt, wie in C++ auch)
    • bietet Summen-Typen ( enum s, Option<T> , Result<T,E> , ...) und Tupel
    • Fokus auf "value types"
    • Schreiben von eigenen Typen, die Ressourcen verwalten ist viel einfacher und weniger fehleranfällig (keine "Rule-of-three" nötig)
    • Move-Semantik ist destruktiv, so dass man nicht künstlich einen Nullzustand zu seinen Invarianten hinzufügen muss
    • All das, was mit höheren Kosten verbunden ist, ist explizit im Code sichtbar (inklusive Kopieren von "nicht-trivialen" Datenstrukturen oder Typunwamdlungen: std::string x = "Hello!"; vs let x = "Hello!".to_string(); )
    • Rust ist mächtig genug, sich (u.a. mit low-leveligem Code) eigene und neue Abstraktionen bauen zu können. Zum Beispiel sind die Channels, über die sich Tasks unterhalten können, komplett in Rust selbst geschrieben und Teil der Standardbibliothek).
    • Für potentiell unsichere Sachen muss man einen unsafe{} -Block aufmachen. So bleiben die kritischen Stellen im Code leicht sichtbar. Mit sowas hat man z.B. viele der nützlichen Dinge der Standardbibliothek gebaut. Für "normale" Anwendungen, braucht man eigene unsafe{} -Blöcke so gut wie gar nicht.

    Rust, obwohl es noch nicht die Version 1.0 erreicht hat, wirkt einfach durchdachter auf mich. Ich denke, es hat sich positiv ausgewirkt, dass da Leute dran saßen, die relativ vertraut mit mehreren Sprachen waren (inklusive C++, OCaml, Lisp, Cyclone, ...). Und Rust lockt nicht nur Pythonianer, Rubianer, Javaianer an (wie es laut Pike bei Go der Fall ist) es lockt auch C++ Programmierer an.

    Nachteile gibt's natürlich auch, aber das hat meist mit dem experimentellem Zustand von Rust und Compiler zu tun. Die Sprache ist ja noch nicht "fertig". Im Moment wird vorranging das abgearbeitet, was unbedingt für Version 1.0 fertig werden soll.



  • kkaw schrieb:

    ...

    Wenn ich damit jemanden neugierig gemacht hab', würd' ich mich über 'n Kommentar freuen. 🙂



  • kkaw schrieb:

    kkaw schrieb:

    ...

    Wenn ich damit jemanden neugierig gemacht hab', würd' ich mich über 'n Kommentar freuen. 🙂

    Mich nicht, wegen den oben genannten Punkten. Es mag an sich theoretisch interessant sein, aber wenn man schon C++ kann und dann auch noch wenig Zeit hat, dann bringt das alles nichts. Da ist nichts dabei, wo ich mir denken würde, das brauch ich jetzt unbedingt, damit ich meine Hobby Projekte daheim noch cooler umsetzen kann. Und da ich C++ schon kann, und nicht nur die Sprache, sondern auch Idiome, Libraries, Frameworks usw. seh ich keinen Grund, mich privat oder beruflich mit etwas neuem zu beschäftigen, wo ich mir erstmal monatelang alles mögliche erst aneignen und zusammensuchen müsste. Was wohl auch nicht so einfach sein wird, weil es für C++ einfach viel mehr gibt.
    Viele Punkte sind auch nicht wirklich relevant. Alles wo "einfacher" dabeisteht ist egal, wenn man C++ eh schon kann. Bei einigen Punkten hast du dazu geschrieben "wie C++ auch", also erst recht kein Grund, sich etwas neues anzuschauen. Und dann die Punkte, die es vielleicht besser kann, z.B. stärkeres Typsystem sind wahrscheinlich in der Praxis erstmal uninteressant. Ich bin mit C++ erstmal zufrieden und müsste mich reindenken, warum das Typsystem von Rust besser ist. Ich vermute, dass es erstmal nur paar konstruierte Beispiele sein werden. Kann sein, dass man bei größeren Projekten irgendwann drüber stolpert, aber ich bin mir ziemlich sicher, dass es nichts weltbewegendes ist, was ich unbedingt brauche und haben will.



  • Mechanics schrieb:

    Mich nicht, wegen den oben genannten Punkten. Es mag an sich theoretisch interessant sein, aber wenn man schon C++ kann und dann auch noch wenig Zeit hat, dann bringt das alles nichts. Da ist nichts dabei, wo ich mir denken würde, das brauch ich jetzt unbedingt, damit ich meine Hobby Projekte daheim noch cooler umsetzen kann. Und da ich C++ schon kann, und nicht nur die Sprache, sondern auch Idiome, Libraries, Frameworks usw. seh ich keinen Grund, mich privat oder beruflich mit etwas neuem zu beschäftigen, wo ich mir erstmal monatelang alles mögliche erst aneignen und zusammensuchen müsste. Was wohl auch nicht so einfach sein wird, weil es für C++ einfach viel mehr gibt.
    Viele Punkte sind auch nicht wirklich relevant. Alles wo "einfacher" dabeisteht ist egal, wenn man C++ eh schon kann. Bei einigen Punkten hast du dazu geschrieben "wie C++ auch", also erst recht kein Grund, sich etwas neues anzuschauen.

    Im Gegenteil. Umso besser ich C++ kann, umso mehr stoeren mich Boilerplate-Code, preprozessorbasierte Modulsystem und schwierige, langsam zu compilende templates mit schlechten Fehlermeldungen. Ausserdem entstehen die meisten Fehler durch dangling pointer, dereferenzieren von Null-pointern oder ungueltige Iteratoren. Das verhindert Rust schon mit statischen Compilerchecks und faengt dadurch auch Sonderfaelle ab.
    Es fehlt in C++ an einem vernuenftigen und fehlersicheren Threading-modell, waehrend Rust mit den grundlegenden Designkonzepten fast alle data-races bereits verhindert.
    Ausserdem sind die filter-, map- und fold-Iteratoren schon dabei.



  • Marthog schrieb:

    Ausserdem entstehen die meisten Fehler durch dangling pointer, dereferenzieren von Null-pointern oder ungueltige Iteratoren.

    Betrifft mich nicht mehr.



  • Das ist für mich erstmal irrelevant. Ich hab ja nicht behauptet, dass C++ perfekt wäre. Nur werde ich mir ohne guten Grund nicht einfach so irgendwelche neuen Sprachen anschauen. Und das sind keine guten Gründe. Man kann mit C++ gut genug arbeiten und sicher programmieren. Man braucht schon irgendwelche Killerfeatures, um auf eine neue Sprache umzusteigen. Und eine experimentelle Sprache, bei der es kaum Libraries, Tools, Beispiele, Best Practices usw. gibt, und die sich mit hoher Wahrscheinlichkeit nie durchsetzen wird interessiert mich eben nicht.
    Das ist aber alles nur meine subjektive Meinung. In der IT entwickelt sich vieles recht schnell und man kann natürlich nicht ewig beim alten bleiben. Ich könnte mir schon vorstellen, dass viele erstmal zumindest privat auf den Rust Zug aufspringen. Nur ist eine Programmiersprache für mich eher ein Werkzeug, dass ich nur sehr ungern wechsle. Für mich ist wichtiger, mich da subjektiv wohler zu fühlen, weil ich mich gut auskenne, als irgendwelche Features, die auf dem Papier Sinn machen.



  • Das kann ich gut nachvollziehen. Es ist nur zur Zeit so, dass neue Prozessoren zunehmend statt auf Taktrate auf Mehrkern setzen und ich vermute, dass der Trend in Zukunft eher zunimmt.
    Die alten Programmiersprachen sind fuer Multithreading aber kaum ausgelegt, Rust hingegen schon. Ich finde die Vorstellung sehr angenehm, Multithreading effizient auszunutzen ohne sich dafuer mit dem Low-Level-Kram herumschlagen zu muessen.



  • Marthog schrieb:

    Die alten Programmiersprachen sind fuer Multithreading aber kaum ausgelegt, Rust hingegen schon. Ich finde die Vorstellung sehr angenehm, Multithreading effizient auszunutzen ohne sich dafuer mit dem Low-Level-Kram herumschlagen zu muessen.

    Ich hatte solche Probleme auch noch nie wirklich. Glaube auch nicht, dass hier die Sprache vorrangig wäre. Wir entwickeln eine sehr große Software im CAD/PDM Bereich, die alles mögliche macht. z.B. 3D Modelle generieren, oder Features in Meshes erkennen, oder Meshes reparieren usw., also durchaus rechenintensiv. Als ich angefangen habe, war praktisch alles noch single threaded. Mittlerweile haben wir vieles umgebaut und können für rechenintensive Aufgaben auch mehrere Threads auslasten. Und das funktioniert auch in C++. War vielleicht nicht ganz einfach, paar komische Probleme haben wir schon etwas länger untersuchen müssen, paar sind erst beim Kunden aufgefallen. Aber erstens glaub ich nicht, dass es mit Rust komplett problemlos gelaufen wäre und sofort perfekt funktioniert hätte. Und zweitens ist die ganze Software einfach viel zu groß und zu komplex, um sie wegen irgendwelcher Sprachfeatures wie "bessere Multithreading Unterstützung" in einer anderen Sprache zu schreiben. Ich mein, auf eine andere Sprache portieren ist sowieso unmöglich, würden wir nie schaffen. Aber ich würd mich auch nicht trauen, sowas großes in einer neuen Sprache anzufangen, die noch nicht so etabliert ist. Kommt natürlich auch wieder der Punkt, dass wir zig 3rdparty Bibliotheken verwenden (Open Source und kommerziell) und da natürlich auch wieder eine Sprache brauchen, die entsprechend verbreitet ist.



  • Es hat keiner behauptet, dass man ein schon existierendes Projekt in Rust übersetzen sollte. Die Mozilla-Entwickler fangen z.B. bei ihrer HTML-Render Engine komplett von vorne an und denken dabei gleich daran, wie man das im Zuge von No-Free-Lunch vernünftig parallelisieren kann. Die Zahl der Leute, die Rust zur Zeit produktiv einsetzen, ist sehr klein. Dazu ist das alles noch zu neu. Bei Mozilla läuft das als "Research Projekt".

    Aber hier nur von "theoretisch interessant" zu sprechen, würdigt die Sache IMHO nicht genug. Rust soll natürlich praktische Probleme lösen. Das Lebenszeitsystem und der Borrow-Checker erlauben nochmal ein ganz anderes Level an Sicherheit, was man Benutzern als Bibliotheksautor bieten kann. Die Standardbibliothek geht da mit gutem Beispiel voran. Ich kann mir aber vorstellen, dass man das nicht zu schätzen weiß, wenn man es nicht kennen gelernt hat. Viele C Programmierer haben ja auch noch nichts von RAII gehört und können sich darin keinen Nutzen vorstellen... 😉

    Und dass man als C++ Programmierer die Syntax ( typename allocator::template rebind<T>::type ), die Adhoc-Templates (Concepts lassen auf sich warten), Headerdateien (Module lassen auf sich warten), die allgemeine Komplexität (siehe z.B. Meyers C++ Talk auf der D Konferenz) und allerlei Fallstricke (z.B. Dreierregel) so gut findet, kannst du mir nicht erzählen. Wir arrangieren uns nur irgendwie damit. Müssen wir. Weil wir noch keinen besseren Ersatz haben. Noch nicht. Das ist aber kein Grund, die Schwächen von C++ wegzufantasieren. Natürlich wird Rust auch nicht perfekt werden. Abes es kommt mir doch aktuell so vor, als sei es weit aus eleganter, einfacher und sicherer.



  • volkard schrieb:

    Marthog schrieb:

    Ausserdem entstehen die meisten Fehler durch dangling pointer, dereferenzieren von Null-pointern oder ungueltige Iteratoren.

    Betrifft mich nicht mehr.

    Das ist schön für Dich. Heißt dann aber wahrscheinlich auch, dass Du Deinen Kram ganz alleine machst. Denn so viele C++ Programmierer, die nie einen Fehler in der Richtung machen, gibt's nicht.



  • Mich nervt's, daß immer Sprachen rumerfunden werden, die dann groben Anfängerfehler adressieren. Nullzeiger dereferenzieren ist so einer. Der passiert in der Praxis wirklich nicht. Und da stehe ich nicht alleine. Sowas als "Die meisten Fehler" kann Anfänger bezeichnen.
    Lustige GCs bauen, weil man in C viel Aufwand hatte, an jedes close() und free() zu denken. Sprachen mit GC schaue ich nicht mehr an, davon gibt es genug.



  • volkard schrieb:

    passiert in der Praxis wirklich nicht.

    Schau mal hier, wieviele von den Sicherheitsproblemen bei Firefox Probleme sind, die in der Praxis "nicht wirklich" auftreten. Das sieht bei Google Chrome im übrigen genauso aus. Ein Großteil dieser Probleme sind Speichersicherheits-Probleme. Und genau das wird bei Rust adressiert. Aber von mir aus kannst du Deinen Kopf weiter im Sand stecken lassen. 😉

    volkard schrieb:

    Lustige GCs bauen, weil man in C viel Aufwand hatte, an jedes close() und free() zu denken. Sprachen mit GC schaue ich nicht mehr an, davon gibt es genug.

    Ich tendiere dazu, es ähnlich zu sehen. Aber ich bilde mir nicht ein, alle Anwendungsdomänen zu überblicken. Das heißt, dass ich nicht davon überzeugt bin, dass Garbage Collection immer eine schlechte Idee ist. Ich bin bisher nur immer ohne in C++ ausgekommen. Das ist auch mit ein Grund dafür, dass ich mir Rust statt D oder Go angeguckt habe. Rust ist im Wesentlichen wie "gezwungenes modernes C++" mit der Extra-Garantie, dass "Sharing" und "Mutation" nicht gleichzeitig auftreten können ( &mut T , der Typ für Referenzen, über die man etwas verändern kann, impliziert quasi restrict , was zur Compilezeit auch gecheckt wird). Das ist ein wichtiges Konzept in Rust. Und so etwas wie new[] / delete[] gibt's da gar nicht. Man muss stattdessen Vec benutzen (oder einen unsafe -Block aufmachen, aber das stellt schon eine gewisse Hürde dar): D.h. alles ist voll von RAII. Und man kann eben nicht ohne einen gewissen Aufwand ( unsafe ) Scheiße bauen. Beispiel:

    fn main() {
        let p: &int;
        {
            let mut v = vec![1,2,3,4i];
            {
                let x = v.get(2); // x ist ein Zeiger auf das 3. Element
                                  // Ist der Index ungültig, bricht der "Task"
                                  // ab, wobei ein ordentliches "stack unwinding"
                                  // statt findet. Oft gibt es aber auch andere
                                  // Funktions-Varianten, die weniger "brutal" sind
                                  // und stattdessen im Fehlerfall etwas anderes
                                  // zurückgeben können.
                println!("Das 3. Element ist {}", *x);
    
                //v.push(5); // könnte zu einer Reallokation führen. Aber der Vektor
                             // gilt wegen x als "ausgeliehen". Deswegen ist diese
                             // modifizierende Operation nicht zugelassen. Der Compiler
                             // bekommt das mit und würde eine Fehlermeldung ausgeben.
                             // Das ist gut so, weil sonst x ein baumelnder Zeiger
                             // werden könnte.
    
                //p = x; // wird auch nicht zugelassen, weil p länger als der Vektor
                         // lebt und p damit ein baumelnder Zeiger werden würde.
            } // <-- Ausleihen des Vektors hier zu Ende
            v.push(5); // Jetzt klappt's wieder!
        } // <-- hier endet die Lebenszeit des Vektors
    } // <-- hier endet die Lebenszeit von p
    

    Der Compiler kann die auskommentierten Fehler abfangen, weil die Lebenszeiten Teil des Typsystems sind und als Compilezeit-Metainformationen bei allen Referenztypen mit dranhängen (und meist deduziert werden) und weil im Compiler ein "Borrow Checker" überprüft, ob das, was an da so hinschreibt überhaupt legal nach den Rust-Regeln ist. Natürlich ist das ein künstliches Beispiel, was keiner so aufschreiben würde. Aber ich wollte hier mal skizzieren, wie Rust die versprochene "Memory-Safety" garantieren kann, ohne auf Garbage Collection zu setzen. Das mit den Lebenszeiten wurde nicht erst für Rust erfunden. Es basiert auf den "region pointers" der Sprache Cyclone.

    Genauso, wie mir C wegen nichtexistierender Unterstützung für RAII oder Templates primitiv vorkommt, kommt mir inzwischen C++ wegen nichtexistierender Lebenszeiten im Typsystem primitiv vor.



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



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



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



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


Log in to reply