Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Software-Entwickler…
  6. T…

Golang [KWT]

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Re: Golang [KWT]

    Autor: grorg 27.09.18 - 04:05

    0110101111010001 schrieb:
    --------------------------------------------------------------------------------
    > Jetzt bin ich neugierig - was gibt es denn moderneres Al's Makefiles?

    Alles ist moderner als ein Makefile.
    Maven z.B.

  2. Re: Golang [KWT]

    Autor: eeg 27.09.18 - 07:40

    grorg schrieb:
    --------------------------------------------------------------------------------
    > 0110101111010001 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Jetzt bin ich neugierig - was gibt es denn moderneres Al's Makefiles?
    >
    > Alles ist moderner als ein Makefile.
    > Maven z.B.

    Jaa genau, weil ich meine Posix CLI Software auch mit einem Java Tool baue...

  3. Re: Golang [KWT]

    Autor: a user 27.09.18 - 09:54

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > TheMasterMaind schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Hä? Seit wann braucht eine Sprache zwingend Generics um kein
    > "Bastelscheiß"
    > > zu sein?
    > Seit jede ernstzunehmende statisch typisierte Sprache dieses Feature
    > beherrscht: C#, Java, OCaml, Typescript, Rust, Swift, Scala, Kotlin, sogar
    > VB.NET und Delphi!
    Also Java hat so etwas, aber beherrschen ist eine echte Übertreibung. Das ist in Java nicht "bad" sondern "totally broken by design".

    > > Oder wie war das noch mit den Generics in Java? stackoverflow.com
    > Den wesentlichen Punkt dort hast Du leider übersehen: „It's better
    > than nothing!“.

    Das stimmt allerdings. Ich wünschte mir aber es wäre nicht so, dann hätte es ne Chance auf Rettung.

  4. Re: Golang [KWT]

    Autor: Hello_World 27.09.18 - 10:20

    eeg schrieb:
    --------------------------------------------------------------------------------
    > Jaa genau, weil ich meine Posix CLI Software auch mit einem Java Tool
    > baue...
    Es spricht für sich, dass Du außer belanglosem Sarkasmus kein einziges _sachliches_ Argument genannt hast.

  5. Re: Golang [KWT]

    Autor: Hello_World 27.09.18 - 10:24

    0110101111010001 schrieb:
    --------------------------------------------------------------------------------
    > Jetzt bin ich neugierig - was gibt es denn moderneres Al's Makefiles?
    Eine Sache, die besser ist als Makefiles, ist zum Beispiel Darmgrippe.

    > (Ehrliche Frage - bin gerne offen für neues)
    Na gut, Spaß beiseite. Bazel ist einen Blick wert: https://bazel.build/

  6. Re: Golang [KWT]

    Autor: Hello_World 27.09.18 - 10:44

    a user schrieb:
    --------------------------------------------------------------------------------
    > Also Java hat so etwas, aber beherrschen ist eine echte Übertreibung. Das
    > ist in Java nicht "bad" sondern "totally broken by design".
    Das sehe ich nicht so. Man hat sich für eine Implementierung mit Erasure entschieden, genau wie es z. B. auch Haskell oder Ocaml tun. Ja, Introspektion und Casts funktionieren dann nicht korrekt – aber die sollte man ohnehin vermeiden. Und ja, use site variance (statt declaration site variance) ist nicht schön, aber es hat Vorteile: vorhandener Code kann nahtlos weiterverwendet werden, und es erlaubt die Verwendung von eigentlich invarianten Typen auf co- oder contravariante Weise. Ich halte das für ein valides Design.

    > Das stimmt allerdings. Ich wünschte mir aber es wäre nicht so, dann hätte
    > es ne Chance auf Rettung.
    Declaration site variance kann man nachrüsten, und die anderen Probleme sind aus meiner Sicht eher weniger gravierend. Ganz sicher besser als das, was Go zu bieten hat: überhaupt nichts.

  7. Re: Golang [KWT]

    Autor: 0110101111010001 27.09.18 - 12:21

    Go hat eine Sache zu bieten: Simplistik
    Das ist oft wertvoller als alles andere, was go nicht hat. Deswegen wird die Sprache auch in einigen großen Firmen eingesetzt.

  8. Re: Golang [KWT]

    Autor: Hello_World 27.09.18 - 13:39

    0110101111010001 schrieb:
    --------------------------------------------------------------------------------
    > Go hat eine Sache zu bieten: Simplistik
    Das ist nur auf den ersten Blick ein Vorteil. Die Komplexität, die man in der Programmiersprache einspart, kriecht erfahrungsgemäß auf anderen Wegen zurück ins Programm, wenn man um die Defizite der Programmiersprache herumhacken muss. Das ist letztlich nicht besser, sondern schlechter. Zumal sich die Komplexität von Generics IMO in Grenzen hält.

  9. Re: Golang [KWT]

    Autor: 0110101111010001 27.09.18 - 14:24

    das witzige ist: das Problem kennt man bei golang eher nicht - selbst ohne Generics kommt man gut zurecht - wobei ich bei den Generics bei dir bin: die hätte man ruhig unterstützen können.

  10. Re: Golang [KWT]

    Autor: Hello_World 27.09.18 - 14:52

    0110101111010001 schrieb:
    --------------------------------------------------------------------------------
    > das witzige ist: das Problem kennt man bei golang eher nicht
    Wenn das so ist, dann nur, weil bei Go-Programmierern nach einer Weile einfach Betriebsblindheit einsetzt. Man nimmt überflüssige Komplexität hin, weil sie eben unvermeidbar ist.

  11. Re: Golang [KWT]

    Autor: eeg 27.09.18 - 15:45

    Erzähl du mir doch nichts von sachlichen Argumenten, wenn du selber nur daher kommst mit: Go steckt wie Automake und Autoconf in den 70ern. Traurig sowas.

    Wo zeigst du denn da überhaupt den Willen für Argumente empfänglich zu sein?

  12. Re: Golang [KWT]

    Autor: Hello_World 27.09.18 - 20:59

    eeg schrieb:
    --------------------------------------------------------------------------------
    > Erzähl du mir doch nichts von sachlichen Argumenten, wenn du selber nur
    > daher kommst mit: Go steckt wie Automake und Autoconf in den 70ern.
    Auch wenn es Dir nicht gefällt, ist das sachlich weitgehend korrekt. Ich habe in meinem ersten (!) Posting in diesem Thread auf zwei Features hingewiesen, die es 1972 in ML schon gab – Generics und Sum Types (aka tagged unions, aka algebraic data types). Diese beiden allein sind schon Killerfeatures, aber ML hatte noch wesentlich mehr zu bieten, beispielsweise globale Typinferenz, eine vernünftige Lambda-Syntax und ein extrem mächtiges Modulsystem. Nicht umsonst ist mit Ocaml einer der Nachfolger nach wie vor in Gebrauch.

    Und Go auf der anderen Seite? Da hält man an seit Jahrzehnten bekannten Designfehlern wie nil fest, oder an der sinnfreien Unterscheidung zwischen Expressions und Statements. Dabei ist schon seit den 50ern dank Lisp klar, dass diese künstliche Trennung überflüssig ist. Ordentliche Fehlerbehandlung gibt es auch nicht, stattdessen soll der Programmierer jeden einzelnen möglichen Fehler von Hand kontrollieren – das ist Steinzeit, nichts anderes.

    > Traurig
    > sowas.
    Ja, ich finde diesen Zustand in der Tat traurig. Hier propagieren Leute mit viel Reputation – Rob Pike und Ken Thompson – Die Rückkehr zu Programmiertechniken aus den 70ern.

    > Wo zeigst du denn da überhaupt den Willen für Argumente empfänglich zu
    > sein?
    Ich bin empfänglich für _gute_ Argumente. Aber die Argumente, die zur Verteidigung von Go üblicherweise vorgebracht werden, sind meiner Einschätzung nach eben leider nicht besonders gut.

  13. Re: Golang [KWT]

    Autor: twiro 28.09.18 - 00:55

    Jo.. "Stay" wäre da wohl ein besserer Name gewesen

  14. Re: Golang [KWT]

    Autor: 0110101111010001 28.09.18 - 13:09

    > Wenn das so ist, dann nur, weil bei Go-Programmierern nach einer Weile einfach Betriebsblindheit einsetzt. Man nimmt überflüssige Komplexität hin, weil sie eben unvermeidbar ist.

    Man nimmt überflüssige Komplexität hin, weil sie eben unvermeidbar ist? Für mich eindeutig ein Widerspruch: unvermeidbar <-> überflüssig.

    Wie gut überflüssige Komplexität ist, sieht man ja bei C++ auf Grund der Abwärtskompatibilität - man kann (ohne Einbezug des Algorithmuses) Probleme in unendlich vielen Variationen lösen.
    Bei Go hat man das normalerweise nicht: Es gibt immer einen wayToGo, der weder 5 mal um die Ecken denken erzwingt, noch besonders ausgefeilt ist. Einfach einfach.
    Go ist so einfach, dass du go nach einer kurzen Einführung ANWENDEN kannst. Quasi C in modern.
    Man könnte hier und da ein Feature, was andere Sprachen haben, manchmal gut gebrauchen, aber unbedingt benötigen tut man es nicht. Andere Sprachen erhöhen durch das Hinzufügen die Komplexität, bei golang hast in der Implementierung an spezifischen Stellen mehr Code.
    Es ist vlt. leicht umständlicher, aber dafür bleibt die allgemeine Komplexität der Sprache auf einem niedrigen Level.

    Die Einfachheit verringert dabei die

  15. Re: Golang [KWT]

    Autor: Hello_World 28.09.18 - 14:42

    0110101111010001 schrieb:
    --------------------------------------------------------------------------------
    > Man nimmt überflüssige Komplexität hin, weil sie eben unvermeidbar ist? Für
    > mich eindeutig ein Widerspruch: unvermeidbar <-> überflüssig.
    Sie ist in Go unvermeidbar, nicht generell.

    > Wie gut überflüssige Komplexität ist,
    Generics sind aber nicht überflüssig, und die Komplexität ist absolut überschaubar. So ziemlich jedes Softwareprojekt bringt Probleme mit sich, die erheblich komplexer sind als Generics. Deswegen ist die Verweigerung der Go-Entwickler ja so albern. Wer Schwierigkeiten damit hat, Generics zu verstehen, sollte sich einfach einen neuen Job suchen.

    > sieht man ja bei C++ auf Grund der
    > Abwärtskompatibilität - man kann (ohne Einbezug des Algorithmuses) Probleme
    > in unendlich vielen Variationen lösen.
    > Bei Go hat man das normalerweise nicht: Es gibt immer einen wayToGo, der
    > weder 5 mal um die Ecken denken erzwingt, noch besonders ausgefeilt ist.
    > Einfach einfach.
    Das ist wieder so eine Behauptung, die ich schlichtweg nicht glaube. Jedes nichttriviale Problem lässt sich auf viele verschiedene Weisen lösen, und jede Programmiersprache, die das nicht zulässt, ist nicht flexibel genug für die Praxis.

    > Go ist so einfach, dass du go nach einer kurzen Einführung ANWENDEN kannst.
    Softwareprojekte laufen nicht selten über viele Jahre, Programmiererkarrieren über Jahrzehnte, und jetzt willst Du mir erzählen, dass Go toll ist, weil man einmal im Leben ein paar Stunden spart, die man braucht, um Generics zu verstehen? Sorry, das nehm ich dir nicht ab.

    Nur mal um zu verdeutlichen, wie zentral dieses Feature ist: Ich arbeite gerade an einer kleinen Codebasis, ein internes Tool mit weniger als 5000 Zeilen Backend-Code. Darin sind 19 generische Methoden- und Klassendefinitionen. Zum Vergleich: der Multiplikationsoperator * wird einmal, der Divisionsoperator / zweimal benutzt. Trotzdem halten die Go-Entwickler es für nötig, für letztere spezielle Syntax bereitzustellen (obwohl man sie problemlos mit einer Funktion abbilden könnte), während Generics als unnötig erachtet werden. Für mich ganz klar eine Fehleinschätzung.

    > Quasi C in modern.
    Also da stimmt ja nun wirklich gar nichts. Go ist _nicht_ modern, und das ist keine Meinung, sondern eine Tatsache, die sich gut belegen lässt. Es fehlen nahezu alle Features, die moderne Programmiersprachen auszeichnen, während andere Sachen eingebaut wurden, die schon vor langer Zeit als Designfehler erkannt wurden (beispielsweise nil). Und es enthält völlig überflüssige Komplexität wie die künstliche Trennung zwischen Statements und Expressions. Lisp hat damit in den 50ern Schluss gemacht, wieso also nicht davon lernen?
    http://cowlark.com/2009-11-15-go/

    Ach, meine zuvor genannte Codebasis enthält übrigens auch keine einzige Schleife. Man braucht sie schlichtweg nicht, wenn man eine Handvoll higher-order-Funktionen wie map, filter, reduce etc. zur Verfügung hat, die natürlich auch generisch sind. Aber offenbar haben die Go-Entwickler mit dieser Komplexität kein Problem.

    Und nein, es ist auch nicht mit C vergleichbar. C ist eine Low-Level-Sprache, die für die Kernel-Entwicklung, für eingebettete Systeme und Echtzeit-Anwendungen taugt. Go ist da schon allein wegen seines Garbage Collectors außen vor. Die moderne Alternative zu C ist Rust, nicht Go. Und Rust hat natürlich auch Generics.

    > Man könnte hier und da ein Feature, was andere Sprachen haben, manchmal gut
    > gebrauchen, aber unbedingt benötigen tut man es nicht.
    Man kann Softwareprojekte auch in C89 erfolgreich zu Ende bringen, ergo benötigt man überhaupt nichts von dem, was in Go enthalten ist. So what? Trotzdem ist Go ein veraltetes Sprachdesign

    > Andere Sprachen
    > erhöhen durch das Hinzufügen die Komplexität, bei golang hast in der
    > Implementierung an spezifischen Stellen mehr Code.
    Mehr Code = mehr Komplexität.
    Mehr Code = weniger wartbare Software.

    > Es ist vlt. leicht umständlicher,
    Umständlicher = mehr Komplexität.

    > aber dafür bleibt die allgemeine
    > Komplexität der Sprache auf einem niedrigen Level.
    Das Problem ist: Wenn Du etwas „einfach” oder „wenig komplex“ nennst, meinst Du in Wirklichkeit Sachen, die dir vertraut sind, an die Du gewöhnt bist. Wie beispielsweise die unnötige Unterscheidung von Expressions und Statements, eingebaute arithmetische Operatoren oder Schleifen. Nichts davon braucht man, wenn die Sprache ordentliche Abstraktionsmöglichkeiten bereitstellt. „Komplex“ heißt bei Dir nicht komplex, sondern mehr oder weniger so etwas wie „Sachen, die es in den Programmiersprachen, mit denen ich groß geworden bin, nicht gibt“. Und die Go-Entwickler scheinen das ähnlich zu sehen, denn anders ist es nicht zu erklären, dass man keinerlei Problem mit Gedöns wie break, continue, breakthrough und ähnlichem hatte, Generics aber für zu komplex hielt.



    1 mal bearbeitet, zuletzt am 28.09.18 15:00 durch Hello_World.

  16. Re: Golang [KWT]

    Autor: 0110101111010001 28.09.18 - 16:35

    Ich bin auch der Meinung, dass Generics noch mit reinhätten sollen.

    Mehr Code ist höhere Komplexität und zugleich schlechtere Wartbarkeit.
    Was aber, wenn dieser Brocken kleiner ist als der Brocken, der durch das hinzufügen von neuen Features kommen würde?
    Gemäß: Das Feature schadet mehr als

    Bzgl C und Go - kann man so sehen wie du, habe ich jedoch anders gemeint: C bietet nicht viele Features (Funktionen, structs, pointer), hat aber gewissen Problemchen, wie z.B. Speicherprobleme, schwieriges multithreading.
    Diese Features wurden nicht groß erweitert, während die Problemchen beseitigt worden sind. Das bezeichne ich als modern.
    Unabhängig vom Einsatzgebiet der Sprachen.

    Modern korreliert mMn nicht mit der Anzahl der Features.

    Bei Problemen gings mir, wie ich vlt. nicht ganz deutlich gemacht habe, darum etwas bestimmtes (ein Algorithmus) mit der Sprache umzusetzen. In C++ kann mans in 100 Varianten machen, in C# in 10 und in go in 2. (Nimm mich bitte jetzt nicht beim Wort)

    Ich rate dir einfach mal: Probier go einfach mal aus. Ich denke es ist etwas dran von dem was ich behaupte. Ich habe bevor ich go angefangen habe mit C, C# und C++ entwickelt. Daher denke ich auch, dass ich das gut vergleichen kann. Vielleicht bin ich einfach zu schlecht im Erklären.

    Generics ist der größte Grund, warum ich von go wieder etwas Abstand genommen habe.

    > So ziemlich jedes Softwareprojekt bringt Probleme mit sich, die erheblich komplexer sind als Generics.
    Umso vorteilhafter, wenn die Sprache hier einem das Leben so einfach wie möglich macht -> Man kann sich auf die komplexen Probleme der Anforderungen kümmern statt sich mit der Sprache rumschlagen zu müssen. Ein Grund, warum C++ so "unbeliebt" ist bei nicht-performance lastigen Anwendungen.

  17. Re: Golang [KWT]

    Autor: Hello_World 28.09.18 - 19:33

    0110101111010001 schrieb:
    --------------------------------------------------------------------------------
    > Ich bin auch der Meinung, dass Generics noch mit reinhätten sollen.
    Na warum argumentierst Du dann die ganze Zeit so komisches Zeugs?

    > Mehr Code ist höhere Komplexität und zugleich schlechtere Wartbarkeit.
    > Was aber, wenn dieser Brocken kleiner ist als der Brocken, der durch das
    > hinzufügen von neuen Features kommen würde?
    Ist er aber nicht, das zeigt die Erfahrung mit Dutzenden anderen Sprachen.

    > Bzgl C und Go - kann man so sehen wie du, habe ich jedoch anders gemeint: C
    > bietet nicht viele Features (Funktionen, structs, pointer), hat aber
    > gewissen Problemchen, wie z.B. Speicherprobleme, schwieriges
    > multithreading.
    Du übersiehst hier die Wurzel des Problems, nämlich dass die Möglichkeiten der Sprache nicht ausreichen, um Abstraktionen zu bauen, mit denen man diese Probleme in den Griff bekommt. Für Nebenläufigkeit braucht man Abstraktionen wie Futures/Promises, um Speichersicherheit ansatzweise zu erreichen braucht man ordentliche Container.
    Die Go-Entwickler meinen nun, dass man des Problems Herr werden könnte, indem man generische Container und Channels direkt in die Sprache einbaut, so dass man – so ihre Logik – darüber hinaus keine Generics braucht. Letztlich ist das ein Ausdruck von schwer zu übertreffender Arroganz: „Generics sind notwendig, aber für Go-Anwender ist das zu kompliziert, deswegen schreiben _wir_ eine Reihe von generischen Datenstrukturen, denn _wir_ wissen ganz genau, was unsere Anwender brauchen“.

    > Diese Features wurden nicht groß erweitert, während die Problemchen
    > beseitigt worden sind. Das bezeichne ich als modern.
    Siehe oben: die eigentlichen Probleme wurden eben _nicht_ beseitigt, Rust ist auf diesem Weg viel weiter.

    > Modern korreliert mMn nicht mit der Anzahl der Features.
    Habe ich auch nicht behauptet. Aber eine Sprache, die es mir nicht erlaubt, elementare Funktionen wie map und filter – oder auch weitergehende Abstraktionen wie Futures, Channels etc. – typsicher und generisch zu implementieren, die ist auch nicht modern. Wenn die Go-Entwickler dafür eine andere Lösung haben als irgendeine Form von Generics – immer her damit. Haben sie aber nicht, und deswegen ist die Sprache auch nicht modern.

    Interessant übrigens auch, dass Du nicht auf das Argument eingegangen ist, dass Go Designfehler wiederholt hat, die seit den 50er Jahren bekannt sind.

    > Bei Problemen gings mir, wie ich vlt. nicht ganz deutlich gemacht habe,
    > darum etwas bestimmtes (ein Algorithmus) mit der Sprache umzusetzen. In C++
    > kann mans in 100 Varianten machen, in C# in 10 und in go in 2. (Nimm mich
    > bitte jetzt nicht beim Wort)
    Ich bin auf diese Behauptung schon in meinem letzten Beitrag eingegangen:
    „Jedes nichttriviale Problem lässt sich auf viele verschiedene Weisen lösen, und jede Programmiersprache, die das nicht zulässt, ist nicht flexibel genug für die Praxis. “

    > Ich rate dir einfach mal: Probier go einfach mal aus.
    Ich habe mittlerweile genug Erfahrung, um einschätzen zu können, ob es sich lohnt, sich mit einer neuen Programmiersprache zu beschäftigen oder nicht. Und meiner Einschätzung nach lohnt sich die Beschäftigung mit Sprachen wie Rust, Haskell oder Idris mehr.

    > Ich denke es ist
    > etwas dran von dem was ich behaupte. Ich habe bevor ich go angefangen habe
    > mit C, C# und C++ entwickelt. Daher denke ich auch, dass ich das gut
    > vergleichen kann. Vielleicht bin ich einfach zu schlecht im Erklären.
    Ich rate dir einfach mal: Probier Haskell einfach mal aus. Da gibt es keine Schleifen, keine Statements, keine eingebauten Channels oder Collections (Ok, ein bisschen Syntax für Listen, aber das ist nicht essentiell), weil man das nämlich alles mit den Mitteln der Sprache selbst implementieren kann, und es funktioniert besser als das eingebaute Zeugs in den von Dir genannten Sprachen.
    http://learnyouahaskell.com/

    > Generics ist der größte Grund, warum ich von go wieder etwas Abstand
    > genommen habe.
    Warum argumentierst Du dann hier noch dafür? Gib doch einfach zu, dass Du mit Go vielleicht irgendwelche neuen Einsichten gewonnen hast und jetzt eben eine Stufe weiter bist.

    > > So ziemlich jedes Softwareprojekt bringt Probleme mit sich, die erheblich
    > komplexer sind als Generics.
    > Umso vorteilhafter, wenn die Sprache hier einem das Leben so einfach wie
    > möglich macht -> Man kann sich auf die komplexen Probleme der Anforderungen
    > kümmern statt sich mit der Sprache rumschlagen zu müssen.
    Generics sind ein Mittel, um genau diese Komplexität einzudämmen. Das ist ungefähr so, als würde man argumentieren, dass eine Axt für einen Holzfäller ein geeigneteres Werkzeug ist, weil man bei der Kettensäge ab und zu mal Benzin nachfüllen muss. Klar muss man das, das ist aber das geringere Übel.

    > Ein Grund, warum
    > C++ so "unbeliebt" ist bei nicht-performance lastigen Anwendungen.
    Klar, es ist ja auch albern, C++ mit modernen high-level-Sprachen zu vergleichen. Die Konkurrenz heißt hier C und Fortran. Und im Bereich Number Crunching und Computergrafik hat sich C++ weitgehend gegen diese beiden durchgesetzt, und zwar weil es die Sprachmittel bietet, sich eigene, nützliche Abstraktionen zu bauen, was mit den anderen beiden nicht vernünftig geht.



    1 mal bearbeitet, zuletzt am 28.09.18 19:37 durch Hello_World.

  18. Re: Golang [KWT]

    Autor: 0110101111010001 28.09.18 - 20:08

    Warum argumentierst Du dann hier noch dafür?

    Tu ich doch garnicht. ?
    Ich argumentiere, dass Komplexitätsreduzierung besser sein kann als jedes kleine Feature (nein, das heißt nicht, dass ich auch keine Generics haben wollen würde!) einzubauen.

    Wenn du das nicht anerkennen willst, und auch nicht einmal einfach ausprobieren willst, kann ich auch nichts machen.

    Und ja, wenn ich zu viel Zeit hätte, würde ich Haskell mal selbst in einem Projekt nutzen, aber bisher hatte ich noch keines, wo ich mir gedacht hätte: Ja, Haskell könnte man hierfür in Erwägung ziehen.

    > Ich bin auf diese Behauptung schon in meinem letzten Beitrag eingegangen:
    Egal, du scheinst nicht zu verstehen, was ich meine, oder ich verstehe deinen Beitrag falsch.

  19. Re: Golang [KWT]

    Autor: Hello_World 28.09.18 - 20:41

    0110101111010001 schrieb:
    --------------------------------------------------------------------------------
    > Warum argumentierst Du dann hier noch dafür?
    >
    > Tu ich doch garnicht. ?
    > Ich argumentiere, dass Komplexitätsreduzierung besser sein kann als jedes
    > kleine Feature (nein, das heißt nicht, dass ich auch keine Generics haben
    > wollen würde!) einzubauen.
    Klar, natürlich kommt nichts gutes dabei heraus, wenn man planlos alles mögliche in die Sprache einbaut. Meine Kritik an Go war doch aber nicht, dass die Anzahl der Features zu gering ist, sondern dass ganz konkrete Features fehlen (wie Generics, die ich für unverzichtbar und Du zumindest für nützlich hältst) und dass andere Features (z. B. Channels oder eingebaute Collections) überflüssig sind, da sie eigentlich in eine Library gehören (nur bräuchte man für so eine Library eben Generics). Es geht nicht um die Anzahl der Features, sondern um die Auswahl, und Go hat eine schlechte Auswahl getroffen.

    > Wenn du das nicht anerkennen willst, und auch nicht einmal einfach
    > ausprobieren willst, kann ich auch nichts machen.
    Nochmal: Ich brauche das nicht auszuprobieren, weil ich mit meiner Erfahrung in der Lage bin, das Ergebnis einzuschätzen. Ich muss auch nicht ausprobieren, in meiner Speiseeismaschine Leber-mit-Zwiebeln-Eiscreme herzustellen.

    > Und ja, wenn ich zu viel Zeit hätte, würde ich Haskell mal selbst in einem
    > Projekt nutzen, aber bisher hatte ich noch keines, wo ich mir gedacht
    > hätte: Ja, Haskell könnte man hierfür in Erwägung ziehen.
    Haskell taugt für alles, wofür Go taugt und mehr. Das einzige leidlich interessante Feature an Go sind Goroutines. Bei näherer Betrachtung sind das aber auch nur Green Threads, und die hat Haskell seit Jahren.

    > Egal, du scheinst nicht zu verstehen, was ich meine, oder ich verstehe
    > deinen Beitrag falsch.
    Die Dritte Möglichkeit ist, dass Du einfach falsch liegst.



    1 mal bearbeitet, zuletzt am 28.09.18 20:42 durch Hello_World.

  20. Re: Golang [KWT]

    Autor: Hello_World 28.09.18 - 20:55

    Ach, und falls dir Haskell zu akademisch ist, würde ich es mal mit Ocaml probieren. Da hast Du dann auch wieder Seiteneffekte, for- und while-Schleifen und strict evaluation – aber trotzdem ein Typsystem, das Go haushoch überlegen ist. Und das in einer Sprache, die Jahrzehnte älter ist als Go…

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. LEW Service & Consulting GmbH, Augsburg
  2. ENERCON GmbH, Aurich
  3. 3Tec automation GmbH u. Co. KG, Herford, Bielefeld
  4. Allianz Versicherungs-AG, Unterföhring

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 119,99€ (Release am 5. Dezember)
  2. 279,00€ (zus. Rabatt von 10 Prozent über Code PINATA3)
  3. (aktuell u. a. Chieftec PC-Gehäuse für 29,99€, Goliath Games Mission Escape für 16,99€)
  4. 243,36€ (zzgl. 4,50€ Versand - Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mobile-Games-Auslese: Magischer Dieb trifft mogelnden Doktor
Mobile-Games-Auslese
Magischer Dieb trifft mogelnden Doktor

Ein Dieb mit Dolch in Daggerhood, dazu ein (historisch verbürgter) Arzt in Astrologaster sowie wunderschön aufbereitetes Free-to-Play-Mittelalter in Marginalia Hero: Golem.de stellt die spannendsten neuen Mobile Games vor.
Von Rainer Sigl

  1. Hyper Casual Games 30 Sekunden spielen, 30 Sekunden Werbung
  2. Mobile-Games-Auslese Rollenspiel-Frühling mit leichten Schusswechseln
  3. Gaming Apple Arcade wird Spiele-Flatrate für iOS und MacOS

WD Blue SN500 ausprobiert: Die flotte günstige Blaue
WD Blue SN500 ausprobiert
Die flotte günstige Blaue

Mit der WD Blue SN500 bietet Western Digital eine spannende NVMe-SSD an: Das M.2-Kärtchen basiert auf einem selbst entwickelten Controller und eigenem Flash-Speicher. Das Resultat ist ein schnelles, vor allem aber günstiges Modell als bessere Alternative zu Sata-SSDs.
Von Marc Sauter

  1. WD Black SN750 ausprobiert Direkt hinter Samsungs SSDs
  2. WD Black SN750 Leicht optimierte NVMe-SSD mit 2 TByte
  3. Ultrastar DC ME200 Western Digital baut PCIe-Arbeitsspeicher mit 4 TByte

Final Fantasy 7 Remake angespielt: Cloud Strife und die (fast) unendliche Geschichte
Final Fantasy 7 Remake angespielt
Cloud Strife und die (fast) unendliche Geschichte

E3 2019 Das Remake von Final Fantasy 7 wird ein Riesenprojekt, allein die erste Episode erscheint auf zwei Blu-ray-Discs. Kurios: In wie viele Folgen das bereits enorm umfangreiche Original von 1997 aufgeteilt wird, kann bislang nicht mal der Producer sagen.

  1. Final Fantasy 14 Online Report Zwischen Cosplay, Kirmes und Kampfsystem
  2. Square Enix Final Fantasy 14 erhält Solo-Inhalte und besonderen Magier
  3. Rollenspiel Square Enix streicht Erweiterungen für Final Fantasy 15

  1. Killerwhale Games: Verdacht auf Betrug beim Kickstarter-Erfolgsspiel Raw
    Killerwhale Games
    Verdacht auf Betrug beim Kickstarter-Erfolgsspiel Raw

    Action in einer offenen Welt mit Elementen aus GTA, Arma Life und Rust - von einem Ministudio? Das wirkt unseriös, trotzdem hat das unbekannte deutsche Unternehmen Killerwhale Games für Raw auf Kickstarter fast 70.000 Euro gesammelt.

  2. BVG: Berlins neue E-Busse sind teuer
    BVG
    Berlins neue E-Busse sind teuer

    Einem Medienbericht zufolge gibt das Land Berlin rund 18 Millionen Euro für die Beschaffung neuer Busse mit Elektroantrieb aus, die von zwei Herstellern kommen. Die Kosten sind damit noch immer sehr hoch. Kritisiert wird zudem die Umweltbilanz.

  3. Elektrische Nutzfahrzeuge: Nicht mehr vom Müllwagen geweckt werden
    Elektrische Nutzfahrzeuge
    Nicht mehr vom Müllwagen geweckt werden

    Keine lokalen CO2-Emissionen und weniger Lärm: Stadtbewohner hätten lieber heute als morgen leise Müllwagen, Bagger und andere elektrische Nutzfahrzeuge. Viele sind schon im Testbetrieb - und einige sogar schon im regulären Einsatz.


  1. 12:35

  2. 12:22

  3. 12:00

  4. 11:50

  5. 11:41

  6. 11:34

  7. 11:25

  8. 11:08