spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Tobiking«

Sterben wird es aber wohl so schnell nicht. Außer Facebook etc. möchten ihre Exabyte an Daten auf ein neues System migrieren.

Irgendwelche kleinen bis mittleren Seiten vielleicht. Du kannst dir sicher sein, dass die Großen wie Google, Facebook, etc. kein Java-Backend verwenden. Facebook hat ein Heer an C++ Experten die nichts anderes tun als Tag und Nacht das Backend optimieren. Wie Andrei Alexandrescu selbst gesagt hat: Wenn du es schaffst, aus Facebook auch nur 1% Performance rauszuholen, hast du allein in den gesparten Energiekosten dein Gehalt und das deiner Kollegen für viele Jahre schon wieder reingeholt...über Java wird man da nichtmal für einen Moment auch nur nachdenken...

Zitat von »Tobiking«

Zitat von »dot«

Garbage Collection war vermutlich die dümmste Idee seit Anbeginn der Informatik. Zum Glück haben die Menschen das langsam kapiert, darum gibt es auch keine nennenswerten, neuen Sprachen mehr, die ernsthaft darauf aufbauen...

So wie Go? (https://golang.org/doc/faq#garbage_collection)

Letztendlich kommt es doch wie immer darauf was und wie man entwickelt. Wenn man eine hohe Entwicklungsgeschwindigkeit will und dabei das Risiko für Mem Leaks gering halten will, nimmt man halt eine Sprache mit GC.

Weiß nicht, Python z.B. funktioniert auch ohne GC bestens...

Und Go ist da eher die Ausnahme als die Regel, insbesondere Rust setzt ja im Moment extrem darauf, Ownership als Sprachfeature zu veranken; der GC ist sowohl in Rust als z.B. auch in D optional (in C++ btw auch ) und wirkt eher wie ein Afterthought (meine persönliche Theorie ist ja, dass die Designer beider Sprachen einfach Angst hatten, sonst zu wenig Publikum zu finden, weil ja vor einiger Zeit noch der allgemeine Konsensus war, dass eine Sprache ohne GC keine moderne Sprache sein kann). In den Communities beider Sprachen gibt es nicht umsonst mittlerweile Bewegungen, den GC zumindest zu meiden bzw. ganz aus der Sprache zu entfernen (die Leute kommen halt einfach langsam drauf, was für eine unglaublich dumme Idee GC ist )...

Zitat von »Wirago«

Wie du auf das Sterben von Java und .Net kommst ist mir ein Rätsel...
Gerade im Businessbereich wo stark auf Microsoft gesetzt wird ist .Net ganz vorne dabei.

Genau darum haben sie mit Windows 8 ja den ganzen .Net Kram effektiv weggeschmissen und in Form der Windows RT alles nochmal basierend auf COM neu gemacht...

Anyways, wir werden ja sehen, was die Zukunft bringt...

Zitat von »DeKugelschieber«

@dot: guck dir mal Go an und sag uns was du davon hältst. Würde mich interessieren, da ich die Sprache für fast "perfekt" halte (vor allem erfrischend konsequent). Garbage Collection ist in den älteren Sprachen teils nicht gut umgesetzt (gerade Java hat da ein komisches System, mit mehreren Ebenen, keine Garantien usw.). Aber zu sagen, dass automatische Speicherverwaltung generell keine gute Idee war halte ich für falsch. Schließlich benutzen wir auch in C++ Smartpointer und Co, um eben nicht selbst daran denken zu müssen. Die GC von Go zusammen mit den Pointern sorgt für automatische Speicherverwaltung + das nicht das Java Feeling aufkommt "everything is a reference".

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

Rust hat da imo wesentlich mehr, was man mögen kann. Am Ende haben alle diese Sprachen aber keinen überwiegenden Vorteil gegenüber C++, weshalb sie für die Praxis eher irrelevant bleiben werden. Da würd ich mich vorher eher noch mit Haskell oder sowas beschäftigen, da kann man wenigstens evtl. was Neues lernen...

Zitat von »Schorsch«

Aber es gibt nun mal Projekte bei denen es keinen wirklichen Nachteil bringt. Und dafür vereinfacht es die Entwicklung ungemein. Es hat immer wieder Neuerscheinungen in Sachen Programmiersprachen gegeben und es wurde immer gesagt das neue kann nichts sein. GC war eben ein Ansatz um die Speicherverwaltung zu vereinfachen. Das ist nicht unbedingt immer sinnvoll aber auch nicht immer schlecht.

Und eben dieser Glaube, dass es die Entwicklung so stark vereinfacht, ist imo eine Illusion, an die irgendwie jeder glauben will, von der wir aber langsam loslassen müssen. Hast du schonmal ernsthaft versucht, die selbe Anwendung, die du erst basierend auf GC gebaut hast stattdessen mal mit ordentlichem RAII zu implementieren? Meiner Erfahrung nach relativiert sich der vermeintliche Mehraufwand in der Realität sehr schnell und der resultierende Code ist nicht nur kürzer und sauberer, sondern vor allem auch korrekt...wenn ich nur die Stunden zählen würde, die ich schon damit verbracht hab, irgendwelche obskuren Bugs zu suchen, die mit RAII niemals zustande gekommen wären...

Wie Antiquiert diese Einstellung ist, sieht man ja allein schon daran, dass das Hauptargument für GC immer die bösen Memory Leaks sind, die man ohne GC angeblich ständig hat. In der Realität ist es aber wesentlich schwerer, in modernem C++ ein Memory Leak zu bauen, als in Java oder C# ein Filehandle zu verlieren. Kann mich gerade nicht erinnern, dass ich in den letzten 10 Jahren mal in C++ ernsthaft ein Leak gehabt hätte. Die ganzen Resource Leaks und Out-of-memory Probleme, derer ich mich in C# erfreuen durfte, verfolgen mich dagegen bis heute...

Zitat von »dot«

In der Realität ist es aber wesentlich schwerer, in modernem C++ ein Memory Leak zu bauen, als in Java oder C# ein Filehandle zu verlieren.

Zur Illustration mein Lieblingsbeispiel, direkt aus der Java Doku (Finderlohn geht an CodingCat):


Hier leaked das File wenn das new BufferedReader eine Exception wirft. Die Tatsache, dass selbst die Leute, die die Java Doku schreiben, bereits in so einem trivialen Beispiel – das eigentlich dazu dienen sollte, das zur Vermeidung genau dieser Probleme gedachte Sprachefeature vorzustellen – keinen korrekten Code produzieren können (und dass dieser Code auch nach Jahren immer noch am gewohnten Platz in der Doku unbemerkt sein Dasein fristet), zeigt imo sehr schön, wie sehr Java die Entwicklung doch vereinfacht...

Zitat von »DeKugelschieber«

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

Und was wenn ich die Ressource nicht in der selben Funktion gleich wieder freigeben kann, z.B. weil es sich um eine Texture handelt, die benötigt wird, so lange der Level geladen ist? Oder von mir aus ein Socket, das offen bleiben muss, so lange die Verbindung besteht...

Zitat von »DeKugelschieber«

Typswitch ist nur ein Werkzeug, um etwas komplexere dynamische Casts übersichtlicher zu gestalten. Wirklich oft braucht man das nicht.

Der Punkt ist aber, dass solche Typeswitches in der Regel als Symptom eines Designfehlers anzusehen sind. Statt dem Programmierer also zu helfen, sich möglichst unbemerkt noch weiter im Sumpf zu versenken, würde eine ordentliche Sprache ihm das Leben genau an der Stelle so schwer wie nur irgendwie möglich machen...