spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Architekt«

@DeKugelschieber
Gerade was passendes für dich gefunden: https://github.com/ksimka/go-is-not-good Purer Zufall, aber dachte es passt.

Ja die Liste hatte ich schon mal gesehen Ich finde die Punkte größtenteils zu subjektiv (z.B. "no OOP", "C-style"). Aber wie mit humanen Sprachen (heißt das so?) auch kann man sie mögen oder eben nicht (also z.B. mag ich Französisch nicht, Englisch aber schon usw.). Für das Feld Systemprogrammierung (also z.B. Backend Batch Prozesse mit Service Center Webclient) finde ich sie super.
Für wirklich technische Probleme ist aber C/C++/Rust/... sicher besser. Rust sieht übrigens auch sehr gut aus, vielleicht gucke ich mir das im Detail mal an. Offen für neues bleiben ist sowieso das wichtigste.

GCs gibt's weil Speicherverwaltung und saubere Abhängigkeiten schwierig sind. Entweder man schiebt das Problem zum Entwickler oder man lässt es automatisch machen. Beides hat Vor- und Nachteile.

Der Bedarf an Software ist immens. Die technischen Anforderungen zeichnen sich dabei meist durch Mittelmäßigkeit aus. Das Komplizierte ist die Fachlichkeit nicht die technische Umsetzung. Da macht es doch nur Sinn das technische Modellieren der Fachlichkeit nicht noch durch technische Anforderungen zu verkomplizieren.

Ich weiß echt nicht in welchen Blasen die Leute leben, wenn sie glauben, dass Entwickler, die es gerade so hinbekommen ihre Programme mit GC-Sprachen einigermaßen fehlerfrei zu schreiben, genauso effizient mit Sprachen ohne automatische Speicherverwaltung arbeiten. Der Bedarf an Software ist so groß, die Menge an Problemen so vielfältig, die Anzahl der mittelmäßigen bis schlechten Programmierer so enorm, dass es ökonomisch und gesellschaftspolitisch überhaupt keinen Sinn macht auf irgendeine Elfenbeinturm-Exzellenz zu bestehen. GC-Pausen und ab und zu eine OutOfMemoryException sind das geringste Problem, wenn man irgendwelche historisch gewachsene juristisch verkomplizierte Geschäftsprozesse implementieren muss.

Es ist sehr einfach mit GC-Sprachen einigermaßen funktionierende wartbare Software zu programmieren. Verständlicher sauberer Code ist ebenfalls recht leicht machbar.

Mit Sprachen ohne automatische Speicherverwaltung kommt eine Menge an Problemen hinzu, die es verbieten einfach so ein fachliches Modell nachzuprogrammieren. Die echte Welt ist kein Baum sondern ein ziemlich fieser zyklischer Graph.

Es hat einen Grund warum fast jede Spieleengine eine Scriptsprache mit automatischem Speichermanagement einbindet. Damit kann jeder was hinprogrammieren das irgendwie funktioniert und nicht allzu viel kaputt machen kann. Ob das ein bisschen mehr Speicher und CPU frisst, ist pupsegal.

Zitat von »DeKugelschieber«

Zitat von »dot«

Ich hab mir Go damals, als es rauskam, kurz angeschaut. Ein kurzer Blick in die Doku genügt mir aber, um recht schnell zu beschließen, dass ich von einer Sprache, die Dinge wie Typeswitches als Feature ansieht und dafür keine Lösung für Ressourcenmanagement anbietet (ja, es gibt defer, aber das ist auch nur die selbe Krücke, auf die sich z.B. auch C# und Java mit Using-Blöcken bzw. Try-With-Resources stützen, weil das Fundament der GC eine ordentliche Lösung unmöglich macht) nicht viel halten kann...allein schon weil sie für das, was ich mache, dadurch völlig unbrauchbar ist...

Könntest du das etwas genauer beschreiben. Ich sehe nicht wirklich das Problem ein

	Quellcode
1 2 3 4 5	resource, err := os.Open("irgendwas") defer resource.Close() // edit: äh das gehört natürlich hier hin if err != nil { // behandel mal }

zu machen oder eben das Equivalent in C++.
Mag sein das Go nicht das richtige für deinen Anwendungsfall ist, vor allem wenn man auf niedriger Ebene mit Daten arbeiten muss, aber allgemein ist das doch recht elegant?

Ich verwende mal ein Java Beispiel:


Wann kann someVar denn bereinigt werden? Man müsste dazu später prüfen, ob alle Tasks abgearbeitet wurden. Dazu einen eigenen Thread zu erstellen oder nach der for Schleife darauf zu warten würde die Vorteile von Multi Threading eher sinnlos erscheinen lassen. Irgendwas muss sich darum kümmern, dass die Variable, wenn sie nicht mehr benötigt wird, wieder freigegeben wird, entweder ein GC, oder man implementiert genau das selbst.

Zitat von »BlueCobold«

Zitat von »Spiele Programmierer«

Einen GC gibt es in Rust übrigens nicht mehr.

Sagte ich doch schon, es setzt auf Reference-Counting auf. Ohne gewissenhafte Verwendung von weak/unowned references baut man sich in Rust allerdings sehr schnell den Speicher voll. Die Mittel sind da und sind zum Glück einfach zu verwenden, nur ist es gewöhnungsbedürftig, wenn auch wesentlich weniger gewöhnungsbedürftig (weil gefühlt unnötig [das Gefühl trügt aber eben]) als in C# oder Java. Reference-Count auf 0 heißt auch automatisch Freigabe des Objekts zu diesem Zeitpunkt und nicht erst irgendwann. In C++ ist eine Ownership bei einer Referenz wesentlich schwerer "versehentlich" zu übertragen als dass man bei Rust das weak/unowned vergisst und dann plötzlich eine ungewollte Ownership bekommt. Da ist C++ schon deutlich ausdrucksstärker, wenn auch ulkigerweise impliziter zur gleichen Zeit.

Der GC in Java schaut sich an, welche Klassen / Instanzen welche Referenzen auf was setzen und wenn keine Referenz besteht, wird die Variable freigegeben. Im Grunde genommen ist das so ähnlich wie Reference Counting, wenn auch etwas komplizierter. Um das ganze noch etwas performanter zu machen, unterteilt Java Instanzen in 3 Bereiche, einen für kurzzeitige Variablen, die schnell bereinigt werden können, einen für langlebige Variablen und einen für Variablen, die nie bereinigt werden können, z.B. statische Variablen.

Zitat von »JuKu«

Der GC in Java schaut sich an, welche Klassen / Instanzen welche Referenzen auf was setzen und wenn keine Referenz besteht, wird die Variable freigegeben.

Jein. Der GC tut das zwar, aber wann er das tut, ist völlig undefiniert. Und genau das ist das Problem, was wir hier lang und breit diskutieren und wo ich (und andere) ein (aus Sicht des Entwicklers) deterministisches Verhalten bevorzugen.

Zyklische Graphen in Geschäftsprozessen haben übrigens nichts mit zyklischen Abhängigkeiten von Code zu tun. Das eine kann wunderbar ohne das andere existieren - und bei schlechten Entwicklern leider auch andersrum.

Zitat von »BlueCobold«

Zyklische Graphen in Geschäftsprozessen haben übrigens nichts mit zyklischen Abhängigkeiten von Code zu tun. Das eine kann wunderbar ohne das andere existieren - und bei schlechten Entwicklern leider auch andersrum.

Natürlich. Aber mit manueller Speicherverwaltung ist es schwerer zyklische Graphen abzubilden. Übrigens meine ich nicht zyklische Abhängigkeiten von Code sondern von Daten.

Das einfachste Beispiel ist wohl eine Ringliste:


Da wird's dann mit Referenzen zählen schwierig. Klar gibt's noch andere Mechanismen sowas aufzuräumen, aber die stoßen eben oft an ihre Grenzen, wenn es kompliziert wird. Und genau dann will man das nicht auch noch an den Hacken haben.

Reden wir denn jetzt über Daten oder über Geschäftsprozesse? Wie ich schon sagte, zyklische Abhängigkeiten in Geschäftsprozessen haben nichts mit zyklischen Abhängigkeiten in Code zu tun. Also über was reden wir jetzt? Über Daten oder über Geschäftsprozesse?

Zitat von »Chromanoid«

Das einfachste Beispiel ist wohl eine Ringliste: (...)
Da wird's dann mit Referenzen zählen schwierig.

Wenn man sie so implementiert, dass jedes Element der Besitzer des Nachfolgers ist, dann schon, klar. (das ist übrigens kein Geschäftsprozess, das ist ein Datenmodell) Das Problem ist dennoch sauber lösbar, indem ganz klar geregelt wird, ob man ein Element nur referenzieren will oder die Ownership eines ListElements an ein anderes ListElement übergibt. Dazu benötigt man natürlich intern zwei Pointer - einen strong und einen weak, die gekapselt nach außen transparent nur als einer erscheinen. Und dann ist das Ganze absolut kein Problem. Weder mit "manueller" Speicherverwaltung wie in C++ über uniue_ptr und raw-pointer, noch in Rust/Swift über Strong Reference und Weak/Unowned Reference. Und das ist keineswegs "schwierig". Über unique_ptr in C++ ist es bei so einer Implementierung nicht mal möglich "aus Versehen" etwas mit Ownership zu übertragen, obwohl man nur eine schwache Referenz übergeben wollte. Und damit ist man wesentlich sicherer als in GC-Sprachen, wo ich selbst schon oft genug Memory-Leaks suchen durfte, weil sich die Entwickler darauf verlassen, dass ja irgendwann eh alles freigegeben wird und man nie irgendwas auf null setzen muss. Explizites null-setzen ist sogar noch viel übler als in C++ sauber über unique_ptr zu arbeiten.

Zitat von »BlueCobold«

Wie ich schon sagte, zyklische Abhängigkeiten in Geschäftsprozessen haben nichts mit zyklischen Abhängigkeiten in Code zu tun. Also über was reden wir jetzt? Über Daten oder über Geschäftsprozesse?

Wir reden über Geschäftsprozesse und andere fachliche Vorgänge und Strukturen, die durch Daten technisch repräsentiert werden. Also über das, was als Code und zur Laufzeit dabei herauskommt, wenn man eine Anwendung gemäß fachlichen Anforderungen programmiert hat.

Zitat von »BlueCobold«

Das Problem ist dennoch sauber lösbar, indem ganz klar geregelt wird, ob man ein Element nur referenzieren will oder die Ownership eines ListElements an ein anderes ListElement übergibt. Dazu benötigt man natürlich intern zwei Pointer - einen strong und einen weak, die gekapselt nach außen transparent nur als einer erscheinen. Und dann ist das Ganze absolut kein Problem. [...] Und das ist keineswegs "schwierig".

Doch das finde ich schon. Das war ja nur ein kleines Beispiel. Stell Dir die Problematik mal in einer riesigen Anwendung vor, mit zig Entwicklern unterschiedlichstem Kenntnisstand. Darüber Gedanken machen, muss man sich ja die ganze Zeit, bei jeder Code Review, bei jedem Fitzel der Anwendung. In einer GC-Sprache kann ich das ganze genauso, wie es die Pfeile zeigen, nachbauen, ohne mir Gedanken über Besitz und Speicher machen zu müssen.

Zitat von »BlueCobold«

Und damit ist man wesentlich sicherer als in GC-Sprachen, wo ich selbst schon oft genug Memory-Leaks suchen durfte, weil sich die Entwickler darauf verlassen, dass ja irgendwann eh alles freigegeben wird und man nie irgendwas auf null setzen muss.

In GC-Sprachen gibt es streng genommen keine Memory-Leaks. Also jedenfalls nicht im eigentlichen Sinne des Wortes, dass man Speicher nicht freigibt, den man eigentlich freigeben muss und so nicht mehr referenzierbaren Speicher erzeugt. Das was Du meinst, sind versehentlich hergestellte Referenzen von Objekten die aus irgendeinem Grund langfristig existieren sollen, zu Objekten, die nicht mehr existieren sollen. Wenn man Null-setzen muss, hat man mMn etwas falsch gemacht. Meinetwegen können wir das aber auch Memory Leak nennen. Das schöne ist halt , dass man buchstäblich die Wurzel des Übels bei GC-Sprachen i.d.R. sehr leicht finden kann, in dem man den Heap automatisch analysieren lässt (und zwar geht das auch im Nachhinein mit einem Heap-Dump vom Produktiv-System). Sicher muss man in diesem Sinne bei GC-Sprachen auch mal an Speicher denken, aber die Problemfläche ist eben viel viel kleiner. Bei manueller Speicherverwaltung trifft man auf das Problem eher selten, weil es vorher mit einem Crash wegen Verweis auf bereits freigegebenen Speicher wegfliegt o.Ä.

Ich sage ja gar nicht, dass GC-Sprachen immer besser sind einem Problem zu begegnen, aber sehr viele Probleme sind damit einfacher und sorgenfreier zu lösen. Ich glaube schon, dass man von der Popularität von GC-Sprachen auf die Häufigkeit dieser mit GC-Sprachen besser lösbaren Probleme schließen kann. Wie erklärst Du Dir die ungemein hohe Popularität von GC-Sprachen? Python, Javascript, .Net-Sprachen, JVM-Sprachen und zig andere Sprachen setzen doch darauf. Basieren die alle auf der falschen Grundannahme? Ich glaube es gibt einfach unterschiedliche Probleme, die unterschiedliche Lösungen sinnvoll machen. Der Einsatz einer Nicht-GC-Sprache ist aus meiner Sicht allerdings schnell mal "premature Optimization": Wenn es eine aussichtsreiche leicht zu bedienende Holzhammer-Methode gibt, dann sollte man die solange benutzen, bis sie wirklich Probleme macht.

Zitat von »Chromanoid«

In einer GC-Sprache kann ich das ganze genauso, wie es die Pfeile zeigen, nachbauen, ohne mir Gedanken über Besitz und Speicher machen zu müssen.

Genau das sehe ich als schlecht an. Denn man muss das auch in einer GC-Sprache sehr wohl, sonst muss ein armes Schwein wie ich wieder irgendwann tagelang Memory-Leaks suchen gehen. Die Vorstellung, dass man sich darüber in GC-Sprachen keine Gedanken machen muss, ist de fakto falsch.

Zitat von »Chromanoid«

In GC-Sprachen gibt es streng genommen keine Memory-Leaks. Also jedenfalls nicht im eigentlichen Sinne des Wortes, dass man Speicher nicht freigibt, den man eigentlich freigeben muss

Doch, die gibt es. Nämlich immer dann, wenn irgendwo irgendwelche Dinge weiterhin Kram referenzieren, der schon lange hätte freigegeben werden sollen. Diese "das macht der GC alles"-Vorstellung ist nicht korrekt. Ich muss auch als Entwickler eben hier und da gewisse Referenzen auf null setzen in GC-Sprachen. Das macht aber fast nie jemand. Das Ergebnis sind OutOfMemory-Probleme. Solches null-Setzen ist aber an sich auch kein schöner Stil. Nur leider in der Praxis unvermeidbar. Genauso, wie ein GC.collect/flush eben auch in gewissen Situationen unbedingt notwendig ist, so grauenvoll das auch weh tut solchen Code zu sehen oder selbst schreiben zu müssen.

Zitat von »Chromanoid«

dass man buchstäblich die Wurzel des Übels bei GC-Sprachen i.d.R. sehr leicht finden kann

Nein, eben nicht. Schön wär's.

Zitat von »Chromanoid«

Wie erklärst Du Dir die ungemein hohe Popularität von GC-Sprachen?

Die Popularität liegt mMn in der selben falschen Grundannahme begründet, die auch du hier aufführst. Nämlich, dass man sich um das Speichermanagement keine Gedanken machen müsste. Mal davon abgesehen, dass C++ vor dem 11er Standard wirklich saumäßig hässlich war und Swift/Rust auch erst sehr junge Konzepte sind. Dazu kommt noch, dass diese GC-Sprachen "zufällig" eine saugeile Standard-Bibliothek mitbringen, die quasi schon alles hat, während non-GC-Sprachen irgendwie (Gott weiß warum, ich vermute begründet durch ihr Alter) diese eben nicht bieten und man sich mit furchtbarem Bibliotheks-Mist herum ärgert, wie selbst in C++ heute noch.
Ich finde es im Gegenteil sogar sehr erhellend, dass solche neuen Sprachen eben nicht mehr einen GC nutzen wollen, weil sie offensichtlich aus den Fehlern gelernt haben. Einfacheres Speicher-Management? Ja gern! Aber bitte doch auch deterministisch und verständlich. Man kann Dinge nämlich auch kaputt-simplifizieren und das so weit, dass für den Entwickler nicht mehr entscheidbar ist, ob und wann etwas überhaupt freigegeben wird.
Ich sage hier keinesfalls, dass Java und C# nicht nutzbar sind. Gott bewahre, ich nutze beide oft und durchaus auch gern. Genauso nutze ich aber auch Swift und C++ gern und sehe eindeutig, wo welche Sprache einen Schwachpunkt hat. Der GC ist für mich der schlimmste Nachteil an C# und (gleich nach den schlecht umgesetzten Generics) der zweit schlimmste Nachteil an Java. Die Bibliotheks-Auswahl und Einfachheit sie zu integrieren wiederum sind die absoluten Stärken von Java und C# (C# bietet seit C#6 hier auch noch weitere Features der Sprache an sich). Die neuesten Features aus C# (.? und ?? z.B.) und Swift sind die Dinge, die in anderen Sprachen fehlen. Jede hat Stärken. Der GC ist aus meiner Sicht aber eindeutig keine.

Zitat von »BlueCobold«

Genau das sehe ich als schlecht an. Denn man muss das auch in einer GC-Sprache sehr wohl, sonst muss ein armes Schwein wie ich wieder irgendwann tagelang Memory-Leaks suchen gehen. Die Vorstellung, dass man sich darüber in GC-Sprachen keine Gedanken machen muss, ist de fakto falsch.

Zitat von »Chromanoid«

Sicher muss man in diesem Sinne bei GC-Sprachen auch mal an Speicher denken, aber die Problemfläche ist eben viel viel kleiner.

Zitat von »BlueCobold«

Nein, eben nicht. Schön wär's.

So mache ich das in Java, wenn es mal passiert. Das musste ich in über zehn Jahren Berufserfahrung vielleicht vier Mal oder so machen: http://blog.rejeev.com/2009/04/analyzing…ak-in-java.html Das schlimmste sind ClassLoader-Leaks aber auch die kann man so nachvollziehen.

Zitat von »BlueCobold«

Das Ergebnis sind OutOfMemory-Probleme. Solches null-Setzen ist aber an sich auch kein schöner Stil. Nur leider in der Praxis unvermeidbar. Genauso, wie ein GC.collect/flush eben auch in gewissen Situationen unbedingt notwendig ist, so grauenvoll das auch weh tut solchen Code zu sehen oder selbst schreiben zu müssen.

Ich kenne dieses Vorgehen so aus der Praxis nicht.

Zitat von »BlueCobold«

Doch, die gibt es. Nämlich immer dann, wenn irgendwo irgendwelche Dinge weiterhin Kram referenzieren, der schon lange hätte freigegeben werden sollen.

Zitat von »Chromanoid«

Das was Du meinst, sind versehentlich hergestellte Referenzen von Objekten die aus irgendeinem Grund langfristig existieren sollen, zu Objekten, die nicht mehr existieren sollen. [...] Meinetwegen können wir das aber auch Memory Leak nennen.

Zitat von »BlueCobold«

Dazu kommt noch, dass diese GC-Sprachen "zufällig" eine saugeile Standard-Bibliothek mitbringen, die quasi schon alles hat, während non-GC-Sprachen irgendwie (Gott weiß warum, ich vermute begründet durch ihr Alter) diese eben nicht bieten und man sich mit furchtbarem Bibliotheks-Mist herum ärgert, wie selbst in C++ heute noch.

Das liegt daran, dass es wesentlich leichter ist tolle Standardbibliotheken mit GC-Sprachen zu schreiben.

Zitat von »BlueCobold«

Ich finde es im Gegenteil sogar sehr erhellend, dass solche neuen Sprachen eben nicht mehr einen GC nutzen wollen, weil sie offensichtlich aus den Fehlern gelernt haben.

Rust ist eine Sprache zur Systementwicklung - nicht zur Anwendungswentwicklung:

Zitat von »https://doc.rust-lang.org/book/«

Rust is a systems programming language focused on three goals: safety, speed, and concurrency. It maintains these goals without having a garbage collector, making it a useful language for a number of use cases other languages aren’t good at: embedding in other languages, programs with specific space and time requirements, and writing low-level code, like device drivers and operating systems.

Swift hat als Zielplattform iOS und ist eine neue Alternative zu Objective-C, das auch schon ARC verwendet. Das sehe ich jetzt nicht als Konkurrenz für Sprachen in denen man richtig fette Anwendungen entwickelt.