spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Es geht hier aber nicht nur um Performance.
Garbage Collector basierte Sprachen sind doch wahnsinnig nervig, sobald man nicht RAM Ressourcen hat: Ein File Handle, ein Socket oder ein OpenGL Objekt.

Wo wir uns wohl alle einig sind, ist, dass die Bibliotheken (.Net Framework) und die managed Plattformen wahnsinnig nützlich sind. Aber müssen wir, rein prinzipiell, dazu die Umständlichkeit von Garbage Collection wirklich in Kauf nehmen? Ich denke nicht. Wenn ich schnell eine GUI Anwendung brauche, mache ich das auch in C#. Aber nicht wegen dem GC, sondern trotz GC. Wegen der unproblematischen Sprache, dem einfachen Builds, den guten GUI Libraries.

@BlueCobold
Die Antwort gab es noch nicht, als ich den Beitrag angefangen habe.

Soweit ich weiß, ist Rust im Gegensatz zu Swift aber nicht so Reference Counting zentriert. Das gibt es zwar im Sinne von shared_ptr auch, aber normalerweise ist in Rust erstmal alles ein einfacher Besitz, also unique_ptr. In Rust ist standardmäßig alles move und nicht copy wie in C++. Daher kann man das Ownership schon leicht mal abgeben. Aber das man das versehentlich macht, sollte eigentlich wegen dem Borrow Checker nicht passieren.

Go wurde hier ja oft erwähnt, der GC ist sicher ein großer Streitpunkt. Perönlich ist es nicht gerade ein großes Thema, dass dieser vorhanden ist. Man kann gut lernen mit ihm zu leben, man muss nur etwas umdenken.

Go versucht ganz andere Probleme zu lösen und das macht die Sprache meines Erachtens sehr gut. Am Anfang hab ich echt allergisch reagiert, dass mir die Sprach vorgibt wie ich Benennungen vorgebe und vieles mehr. Ich hab sie immer wieder weggeworfen, gereizt hat sie mich dennoch.

Go versucht einen eher Sozialen Aspekt der Programmierung zu lösen (neben anderen Dingen), Quellcode soll immer vertraut aussehen. Der Code von einem Kollegen oder Fremden soll einem trotzallen sehr schnell vertraut erscheinen. Das hebt deutlich die Code Qualität und vermeidet sehr viele Fehler von sehr komplexen Sprachen wie C++. Ein Problem welches auch Rust hat.

Go hat im Sinn, dass Menschen Programmieren und diese je nach Fähigkeitstand wenig Probleme haben sollten guten Code zu schreiben. Ein Grund warum Go auch so viel wert auf gute und einheitliche Tools und Minimalismuss legt. Akademisch ist sie vielleicht nicht die tollste Sprache, aber sie ermöglicht einer viel größeren Nutzerbasis guten Code mit deutlich geringerem Aufwand zu schreiben. Und deswegen erachte ich auch den GC als gute Entscheidung in Go.

C++ ist eine Zweifelsfrei tolle Sprache, aber es gibt zu viele Möglichkeiten ein Problem zu lösen, und das aufgrund der Sprachmittel nicht verschiedener Algorithmen. Man nutzt 3 verschiedene Bibliotheken und schon schaut der eigene Code aus, als ob 4 verschiedene Personen in ihm rumgepfuscht haben. Zudem muss man, wenn man Fremdcode verstehen will den gesamten Sprachumfang von C++ verstehen da jeder seine eigenen vorlieben hat, was für nicht gerade wenige Entwickler schwer möglich ist da sie nicht den Luxus genießen in einer Sprache langfristig entwickeln zu dürfen um so trainiert zu sein. Auch dies sind alles potentielle Fehlerquellen.

Natürlich bringt ein GC neue Fehlerquellen, aber auch RAII ist davon nicht frei, denn es muss konsequent umgesetzt werden und von jedem teilnehmenden Entwickler.

Ich habe noch nie eine so einheitlich aussehende Codebasis von so vielen unterschiedlichen Entwicklern wie in Go gesehen.

Zitat von »Spiele Programmierer«

Garbage Collector basierte Sprachen sind doch wahnsinnig nervig, sobald man nicht RAM Ressourcen hat: Ein File Handle, ein Socket oder ein OpenGL Objekt.

Das bestreitet auch keiner. In einer normalen Business Anwendung wirst du aber nicht viel damit zu tun haben, weil du da dank Frameworks wie Spring in Java auf einer unglaublich hohen Abstraktionsebene arbeitest. Schau dir mal an wie viel Code du mit Spring brauchst, um eine Datenbank-Tabelle über eine REST-API zu öffnen. Wie viel Aufwand das mit C++ wäre, will ich mir gar nicht erst ausmalen.

Zitat von »H5::«

Go wurde hier ja oft erwähnt, der GC ist sicher ein großer Streitpunkt. Perönlich ist es nicht gerade ein großes Thema, dass dieser vorhanden ist. Man kann gut lernen mit ihm zu leben, man muss nur etwas umdenken.

Go versucht ganz andere Probleme zu lösen und das macht die Sprache meines Erachtens sehr gut. Am Anfang hab ich echt allergisch reagiert, dass mir die Sprach vorgibt wie ich Benennungen vorgebe und vieles mehr. Ich hab sie immer wieder weggeworfen, gereizt hat sie mich dennoch.

Go versucht einen eher Sozialen Aspekt der Programmierung zu lösen (neben anderen Dingen), Quellcode soll immer vertraut aussehen. Der Code von einem Kollegen oder Fremden soll einem trotzallen sehr schnell vertraut erscheinen. Das hebt deutlich die Code Qualität und vermeidet sehr viele Fehler von sehr komplexen Sprachen wie C++. Ein Problem welches auch Rust hat.

Go hat im Sinn, dass Menschen Programmieren und diese je nach Fähigkeitstand wenig Probleme haben sollten guten Code zu schreiben. Ein Grund warum Go auch so viel wert auf gute und einheitliche Tools und Minimalismuss legt. Akademisch ist sie vielleicht nicht die tollste Sprache, aber sie ermöglicht einer viel größeren Nutzerbasis guten Code mit deutlich geringerem Aufwand zu schreiben. Und deswegen erachte ich auch den GC als gute Entscheidung in Go.

C++ ist eine Zweifelsfrei tolle Sprache, aber es gibt zu viele Möglichkeiten ein Problem zu lösen, und das aufgrund der Sprachmittel nicht verschiedener Algorithmen. Man nutzt 3 verschiedene Bibliotheken und schon schaut der eigene Code aus, als ob 4 verschiedene Personen in ihm rumgepfuscht haben. Zudem muss man, wenn man Fremdcode verstehen will den gesamten Sprachumfang von C++ verstehen da jeder seine eigenen vorlieben hat, was für nicht gerade wenige Entwickler schwer möglich ist da sie nicht den Luxus genießen in einer Sprache langfristig entwickeln zu dürfen um so trainiert zu sein. Auch dies sind alles potentielle Fehlerquellen.

Natürlich bringt ein GC neue Fehlerquellen, aber auch RAII ist davon nicht frei, denn es muss konsequent umgesetzt werden und von jedem teilnehmenden Entwickler.

Ich habe noch nie eine so einheitlich aussehende Codebasis von so vielen unterschiedlichen Entwicklern wie in Go gesehen.

Da sprichst du mir aus der Seele und genau so habe ich es heute einem Kollegen in der Mittagspause erzählt. Man lernt Go wirklich zu lieben wenn man fremden Code ließt und dieser genauso aussieht, als hätte man ihn selbst geschrieben. Dazu muss man sich nur mal ein paar Projekte auf GitHub anschauen.
Hätte Google hier manuelles Speichermanagement vorgezogen, wäre die Code Basis die heute existiert sicher nicht so einheitlich. Dann gehts auch wieder los mit Architektur und bla, bis jetzt hat jedes Projekt das ich geschrieben oder gesehen habe eine organische Architektur, also quasi keine. Herrlich.

Zumindest im Vergleich C++ <-> Go betrachten wir hier glaube ich verschiedene Probleme. Interessanter ist eher der Vergleich C++ <-> Java, weil diese historisch doch etwas enger zusammen stehen

Zitat von »Checkmateing«

Du spakst rum, ist alles ok. Der Chat geht auch.

Zitat von »Architekt«

Es lebe Rust.

Und D?

MfG
Check

D benutze ich schon recht lange nicht mehr. Zuviele Bugs und auch wenn oft gesagt wird, in D wäre der GC optional: das ist faktisch nicht wahr. Die ganze Standard-Library basiert auf den GC, die Dynamischen Arrays/Slices & auch Klassen basieren darauf. Klar, man kann durch kleine Eingriffe den GC umgehen (scoped, emplace, Allocator, malloc), aber das fühlt sich oft eher wie ein Hack an und macht für mich dann wieder den Eindruck ich hätte C++ nie verlassen. Außerdem ist der GC von D unglaublich schlecht und der Standard-Compiler optimiert wirklich schlecht. Zudem bin ich auch eher ein Fan von deterministischen Sprache wie C++ & Rust.
Deswegen ist zur Zeit auch Rust mein Mittel der Wahl. Arbeitstechnisch bin ich zu 99% in PHP unterwegs. Ich mag PHP, war meine erste Sprache und auch wenn viele sagen PHP wäre ekelhaft von Syntax und Sprache (womit sie durchaus in einigen/vielen Punkten Recht haben) mag ich PHP wohl schon aus nostalgischen Gründen. Aber PHP basiert intern hauptsächlich auf Referenzcounting, ist somit auch nicht deterministisch und wie in allen nicht deterministischen Sprache leidet darunter das Verständnis von korrekter Architektur - und man hat schnell Zyklen gebaut. Und da hat dann auch PHP wieder einen GC der diese Zyklen wegräumen muss. Ich will nicht sagen das jeder Programmierer der hauptsächlich/lieber in GC/RC Sprachen arbeitet keine Ahnung von Design hat, aber wenn jemand mit diesen Sprachen als Anfänger beginnt, merkt man doch schon eine gewisse Tendenz. Ist mir zumindest so ergangen.

Mit Rust bin ich da zur Zeit wirklich glücklicher. Alles default auf den Stack, alles default const/immutable, kein GC, implizites moving & ownership und wenn man möchte, gibt es RC & ARC in der Library. Das einzige umständliche war zu Anfang die Lifetimes, aber damit findet man sich schnell zurecht.

Und zu Go und seinem GC: Mit 1.4 und deren nebenläufigen GC ist die Performance sowas von in den Keller gegangen und afaik leakt doch beinahe jeder go-Channel trotz GC. Oder haben die das mittlerweile mal in den Griff bekommen?

Zitat von »Nimelrian«

Zitat von »Spiele Programmierer«

Garbage Collector basierte Sprachen sind doch wahnsinnig nervig, sobald man nicht RAM Ressourcen hat: Ein File Handle, ein Socket oder ein OpenGL Objekt.

Das bestreitet auch keiner. In einer normalen Business Anwendung wirst du aber nicht viel damit zu tun haben, weil du da dank Frameworks wie Spring in Java auf einer unglaublich hohen Abstraktionsebene arbeitest. Schau dir mal an wie viel Code du mit Spring brauchst, um eine Datenbank-Tabelle über eine REST-API zu öffnen. Wie viel Aufwand das mit C++ wäre, will ich mir gar nicht erst ausmalen.

Volle Zustimmung,danke! Genau so ist es. In der Regel hat man ja nun auch nicht RAM-Probleme. Und wenn man welche hat, dann hätte man die meiner Meinung nach mit "GC-Freien" ebenso. ich muss auch ehrlich sagen, bei jeder Professionellen Anwendung, an der ich gearbeitet habe, würde ich bezweifeln, dass die in C++ in derselben Zeit mit derselben Qualität hätte erstellt werden können.

Ich glaube, dass wir hier bei einem Spieleprogrammierer-Forum schlecht wegkommen. In der Regel hört man ja tatsächlich eher schlechte Erfahrungen mit allen, die Managed-Sprachen wie C# benutzen: frisst mehr RAM, JIT ist lahm, GC ist lahm.... Ja da muss ja auch alles innerhalb weniger ms erfolgen, da ist es ein Problem, sonst eher weniger.

Ich finde diesen Blickwinkel auf Go sehr interessant. Den mit einem Blick auf die Features der Sprache kann sie einfach nicht überzeugen. Ich habe mich schon häufiger gefragt, was manche Leute an dieser Sprache finden.
Ganz klar ist mir aber noch nicht, was Go jetzt zum Beispiel über C# stellt? Meiner Erfahrung nach ist der Coding Stil dort auch ziemlich einheitlich, es gibt einen GC und vieles mehr.

Für mich persönlich ist die Sprache trotzdem nichts. Das jeder Code anders aussieht ist meiner Meinung nach hauptsächlich ein Problem von C++, weil es dort so viele (zu viele?) Wege gibt alles zu erreichen. Viele alte Features, alter Code und viele Programmierer mit unterschiedliche Blickwinkeln.

@Architekt
Referenzzählung ist doch auch deterministisch?
Gibt es einen GC in Rust? Ich dachte irgendwie, man hätte den mal entfernt? Ich kann allerdings gerade nix konkretes dazu finden.

Zitat von »Spiele Programmierer«

@Architekt
Referenzzählung ist doch auch deterministisch?

Hab' ich dem widersprochen? Es ist lediglich ein Problem, wenn man Zyklen hat die (z.B. in PHP) dann doch durch einen GC irgendwann weggeräumt werden.

Zitat von »Spiele Programmierer«

Gibt es einen GC in Rust? Ich dachte irgendwie, man hätte den mal entfernt? Ich kann allerdings gerade nix konkretes dazu finden.

Ich meine mich zu erinnern, dass es ein std::Gc gab, aber den finde ich jetzt auch nicht mehr. Dann korrigiere ich mich auf RC und ARC.

Zitat von »Architekt«

Und zu Go und seinem GC: Mit 1.4 und deren nebenläufigen GC ist die Performance sowas von in den Keller gegangen und afaik leakt doch beinahe jeder go-Channel trotz GC. Oder haben die das mittlerweile mal in den Griff bekommen?

Also ich kann mich jetzt an keinen GC Bug erinnern im Zusammenhang mit den channels oder meinst du damit, dass der GC sagt "RAM ist zum nutze da". Ansonsten hat sich der GC durchaus weiter entwickelt. Go GC: Prioritizing low latency and simplicity

Ansonsten ist Go nicht besonders langsam, aber für Zeitkritisches würde ich Go nicht einsetzen. Außer es geht um Entwicklungszeit da würde ich sogar sagen, dass ein Produkt in Go deutlich schneller sein kann als in vielen anderen Sprachen. Man hat einfach mehr Zeit zum Optimieren der Algorithmen. Aber Performance ist nicht gleich Performance.

Go hat noch ein paar andere Vorteile, Go ist deutlich simpler als C# was besonders Programmierer von Scriptsprachen anlockt. Die Sprache ist schnell zu lernen, die tools sind schlank aber sehr mächtig. Für mich fühlt sich die Sprache sehr erfrischend schlank an. Und ich glaube die cross platform Entwicklung ist eine der Besten zur Zeit (Ohne wirklich lange warten zu müssen kann sogar mein BeagleBone mal eben ein größeres Go Project für Windows bauen, man muss nur 2 Umgebungsvariablen anpassen sonst nichts).

Zitat von »H5::«

Zitat von »Architekt«

Und zu Go und seinem GC: Mit 1.4 und deren nebenläufigen GC ist die Performance sowas von in den Keller gegangen und afaik leakt doch beinahe jeder go-Channel trotz GC. Oder haben die das mittlerweile mal in den Griff bekommen?

Also ich kann mich jetzt an keinen GC Bug erinnern im Zusammenhang mit den channels oder meinst du damit, dass der GC sagt "RAM ist zum nutze da". Ansonsten hat sich der GC durchaus weiter entwickelt. Go GC: Prioritizing low latency and simplicity

Meines letztens Wissens nach war es recht einfach mittels der go-Channels ein Memory-Leak herzustellen. Ich weiß aber nicht mehr wie, ich guck mal ob ich nachher noch eine Quelle finde. Aber es gibt ja immer ein paar Wege auch in GC Sprachen Memory-Leaks herzustellen.
Ich bin bei Go 1.1 raus, ein paar Kollegen berichteten mit 1.4 aber eine rapide Senkung der Performance und meinten, dies liege am neuen GC. Kannst du dazu was sagen? Würde mich mal interessieren. Ich konnte Go leider nicht viel abgewinnen - es stimmt die Sprache lernt man innerhalb eines Tages aber ich fand sie nie sonderlich ansprechend, sie bringt einfach nicht genug neues mit, dass sich der Umstieg für mich gelohnt hätte.