spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Weder Concept noch Ranges haben es leider in C++17 geschaft.
EDIT:
Module auch nicht.

Die sind btw. allesamt (also modules, concepts & Ranges) in D recht gelungen implementiert.

Zitat von »Architekt«

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.

Der GC wurde in 1.5 neu umgesetzt und ist deutlich schneller geworden (Faktor 7-10 wars glaube ich). Damit ist er für Web- und Business Anwendungen quasi irrelevant. In Spielen hätte man vielleicht das Problem, dass er das ganze Spiel kurz pausiert (Ruckler), aber das teste ich ja gerade mit der Engine. Leaks hatte ich noch überhaupt keine, egal ob in goroutines oder nicht.
Übrigens ist Wissen auf Basis von <= 1.4 auf jeden Fall veraltet. Go ist deutlich stabiler geworden ab 1.5.

Was Features angeht geht es ja gerade darum nicht viele zu haben. Go Code endet fast immer in einem Paradigma, so gibt es selten mehrere sinnvolle Wege ein Problem zu lösen. Das setzt sich dann dank gofmt (automatisierte Formatierung) in Konsistenz fort, so dass fast alles an Go was ich bisher gesehen habe irgendwie gleich aussieht. Machts deutlich verständlicher und sehr sehr angenehm zu lesen und zu warten.
Verglichen mit Java (jaja mein lieblings negativ Beispiel) ist das sehr erfrischend, weil dort seit Jahren, ständig, jedes Jahr nur Features draufgepackt werden. Am lustigsten finde ich den aktuellen Versuch "funktionale" Entwicklung zu ermöglichen. Dann lieber ein kleines Sprach Feature Set, dass sich schnell lernen lässt, als so ein Chaos. Ähnlich sehe ich das bei C++. Einige der Dinge die über die Std eingebaut werden gehören imo eigentlich ins Sprachset. Da ist man konzeptionell in einer Sackgasse. Mehr zu lernen, schwerer zu lesen, fehleranfälligkeit.

Die häufig geringere Entwicklungszeit kommt aber denke ich durch die Sprache an sich und die Standardbilbiothek zu stande, nicht zwingend durch den GC.

Hier gibt es ja einiges zu lernen über diverse Sprachen und Konzepte. Direkt informativ. Da es hier ja streckenweise schon ein wenig weg von der "Grundfrage" bzgl Sinn und Unsinn von GCs hin zu Aspekte von Sprachen i.A. ging, würde ich gerne noch drei Zankäpfel in die Mitte schmeißen:
-Hinkt der Vorwurf das etabilierte Sprachen nicht so "schlank" wie neue Sprachen seien nicht ziemlich? Immerhin fing ja so ziemlich alle Sprachen mal kohärenter an.
-Die jenigen, die an den "Tod" einer Sprache glauben: sicher, dass eine Sprache nur deshalb verschwindet, weil sie "unpraktisch" (geworden) ist? Spielt da nicht Etabiliertheit eine wesentlichere Rolle?
-Wer von euch programmiert (beruflich) an Projekten in denen Performance deutlich wichtiger als Entwicklungsaufwand ist (bzw. sich definitiv nicht durch sowas unperformanten wie z.B. python umsetzen ließe)?

P.S. meiner berufliche Erfahrung ist, dass man ja oft keine Wahl hat bei (größeren) Projekte. Argumente gehen von "das Projekt ist so gewachsen" hin zu "nach dir muss es ja auch jemand pflegen können und wir haben hier nur xyz Entwickler".

Zu 1: doch den Vorwurf kann man machen. Java hätte nicht zwingend erweitert werden müssen. Das ist vor allem Marketing und damit die Sprache "trendy" bleibt. Sinnvoll ist es (meistens) nicht. Für Go ist übrigens genau dieses Sprachset fest gesetzt. Nach Aussagen von Rob Pike wird Go niemals erweitert (also um Sprachfeatures, die Std wächst ständig).
Zu 3: Ich programmiere beruflich hauptsächlich in Java, PHP und Go (dazu noch diverse Scriptsprachen). Performance ist dabei meist weniger das Problem, wobei es hier und da Stellen gibt die soweit optimiert werden müssen, dass sie in "ein paar Stunden" durchlaufen müssen (wenn man 6,5 Mio. Verträge durch einen Prozess schickt, z.B. von 30h auf 8-10h ist ziemlich gut). Aber wirklich Echtzeit und zeitkritisch eher weniger.

Bezüglich Performance vs. Entwicklungsaufwand: Bei mir ist das (zumindest momentan) so, dass Entwicklungsaufwand einiges wichtiger ist als Performance (zumindest abgesehen von ein paar sehr kleinen entscheidenen Stellen).

Und obwohl ich C++ und die ganzen Systeme sehr interessant und spannend finde, bin ich um jegliche Abnahme von Arbeit froh. Das endet dann ja nicht bei der Sprache, sondern bei all den Tools und Libraries, die man benutzen kann. Zum Teil kann man Heute durch enorme Abstraktionen und Modularitäten komplexe Features von Idee über Backend, zur App und Distribution in ein paar Stunden locker machen. Und das ganze läuft dann mit grosser Wahrscheinlichkeit ziemlich performant, skalierend, verteilt und paralell.

Eigentlich wollen wir uns ja am Ende darauf konzentrieren die Features zu entwickeln, die dem Nutzer etwas bringen. Alles andere ist nur Mittel zum Zweck. Wenn mir eine Sprache mühsame Sachen abnimmt und ich da nicht daran denken muss, dann ist das eine super Sache. Wenn ich dann in kritischen Fällen doch noch ein wenig mehr eingreifen und optimieren kann, dann ist das perfekt.

Ob das jetzt pro GC, Kontra GC, pro C++ oder Kontra Java ist weiss ich jetzt gar nicht, spielt aber auch keine Rolle und kommt wohl sehr auf den Fall drauf an, aber um den Thread generell zu beantworten:



//
Üblicherweise sind weitere Faktoren bei der Auswahl der Sprache/Platform, etc. viel wichtiger (wie auch schon von Nox und LetsGo erwähnt) wie irgendwelche Performance/Aufwand Fragen. Im Zweifelsfall nimmt man am besten das, was oft benutzt wird. Nicht zuletzt weil man so sicher gehen kann, dass viele andere die gleichen Probleme bereits hatten wie man haben wird und es bereits eine Lösung auf Stackoverflow gibt. Support und Community ist dann auch eher vorhanden und aktiv.

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

Naja die meisten Kritikpunkte in diesen Aufzählungen sind sehr subjektiv und nicht selten werden Punkte als Schwäche genannt, die andere gerade als Stärke sehen. Sachliche Argumente fand ich beim Überfliegen wenige.

Zitat von »Nox«

Naja die meisten Kritikpunkte in diesen Aufzählungen sind sehr subjektiv und nicht selten werden Punkte als Schwäche genannt, die andere gerade als Stärke sehen. Sachliche Argumente fand ich beim Überfliegen wenige.

Sehe ich absolut genau so. Alles in allem ist das hier ja wieder so eine Diskussion bei der jeder seine Lieblingssprache verteidigen möchte. Ob man Go oder Java oder C++ oder was auch immer jetzt mag oder nicht. Ich denke fest steht dass man mit einer Sprache allein nicht weit im Leben kommt. Sei es weil von oben eine andere Sprache als die selbst gewollte vorgegeben wird oder weil die Sprache eben absolut ungeeignet für ein Problem ist. Ungeeignet heißt nicht dass es nicht machbar ist, es geht eher darum dass es mit anderen Sprachen viel schneller, schöner, simpler geht. Der Rest bleibt am Ende Vorliebe. Ich gucke mir gern neue Sprachen an, aktuell ists Kotlin von Jetbrains da ich zur Zeit beruflich für Android entwickeln darf/muss. Für das was wir da machen wäre C++ ziemlich unbrauchbar. Und genau so gibt es eben Projekte bei denen Java/JVM-Sprache nicht zu gebrauchen ist und ich dann lieber zu C++/Go/Python/was auch immer greife.
Ich denke wichtig ist dass man sich als Entwickler nicht selbst zu sehr einschränkt. Man sollte offen für vieles und vor allem für neues sein. So kann man sich selbst am besten weiter entwickeln.
Um zurück zum Thema GC zu kommen. Ich arbeite in den meisten Fällen auch lieber ohne. Zumindest wenn es um komplexere/technischere Projekte geht. Wie vorher schon gesagt stört er mich aber nicht immer. In Go oder C# hat es mich an sich noch nie gestört dass es einen GC gibt, mag aber auch an den Projekten liegen die ich damit umsetze. Von daher weiß ich nicht ob ich sagen würde GC ist immer schlecht. Ob ich GC vermissen würde wenn es das Konzept nicht geben würde weiß ich auch nicht. An sich ist es mir aber auch relativ egal. Ich versuche die Sprache vorher sinnvoll auszuwählen und ich denke solange man das macht macht man sich das Leben nicht all zu schwer.

@Architekt:
In deinem Link wird genannt dass man zu Go sehr schlecht suchen kann. Wenn man nach "Go xyz..." sucht findet man tatsächlich oft anderes Zeug. Der Trick ist nach Golang zu suchen. Und siehe da, alles kein Problem mehr

Gleiches Problem tritt bei D oder Rust auf. Lösung ist genauso: dlang / rustlang. Und der verlinkte Artikel spiegelt nicht meine Sicht auf go wieder, ich hab ihn nur zufällig heute morgen entdeckt und dachte ich zeige ihn passenderweise zur Diskussion über go.