1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Programmiersprache Go…

Google stopft unwissenden "Programmierern" Golang die Kehle herunter

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: Winny 03.08.20 - 12:50

    Eine Sprache die den Anschein erweckt, als käme sie aus den 80ern (mal abgesehen von Goroutines). Das Fehlen etablierter Features wird Unwissenden auch noch als Feature verkauft.

    Nur um einige zu nennen: keine Generics, keine Immutability, kein map, kein reduce, kein Filter, kein Pattern Matching und ein primitiver Garbage Collector, der sich kaum tweaken lässt. Alles was über eine kleine REST API hinausgeht, endet in einem schrecklichen Durcheinander. Selbst die Performance lässt zu wünschen übrig: In den Techempower Benchmarks performt Golang schlechter als .NET Core und diversen Java Frameworks wie Vert.X oder Quarkus.

    Ich sehe keinen Grund, Golang C# bzw. .NET Core gegenüber zu bevorzugen. C# ist weitaus mächtiger, performt besser, ist Open Source und lässt sich auf allen Betriebssystemen nativ kompillieren. Selbst Java, Scala und andere JVM Sprachen können hier mit GraalVM Native Images mitmischen.

    Man hat den Go "Programmierern" das Fehlen von Generics als Feature verkauft und einige Jährchen später hat man bemerkt, dass es ohne Generics doch ziemlich schlecht läuft. Nun plant man, Generics mit Golang 2.0 doch einzuführen.

  2. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: BlackSuit 03.08.20 - 13:08

    Ich hätte es nicht so drastisch formuliert, aber zweifelos ist Go ein geradezu eine Beleidigung in seiner Simplizität wenn man z.B. modernes Java gewohnt ist. Und der Hauptvorteil von Go - standalone Binaries - werden wie gesagt mit GraalVM auch für JVM Sprachen verfügbar. Allein die Tatsache das Maps ein Sprachfeature und nicht Teil der Std. Libraries ist, sollte eigentlich jeden erfahrenen Entwickler sofort skeptisch machen was die Mächtigkeit der Sprache angeht.

    http://nomad.uk.net/articles/why-gos-design-is-a-disservice-to-intelligent-programmers.html

  3. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: \pub\bash0r 03.08.20 - 13:23

    Schön wie hier haufenweise "Programmierer" beleidigt werden, nur weil der eigene Horizont das maß aller Dinge ist. Toll!

    P.S.: Generics kommen aller Voraussicht nach noch vor Go 2.0, da es dem derzeitigen Entwurf nach abwärtskompatibel sein wird.

  4. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: wasdeeh 03.08.20 - 13:32

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > Schön wie hier haufenweise "Programmierer" beleidigt werden, nur weil der
    > eigene Horizont das maß aller Dinge ist. Toll!

    Naja, lies den Artikel, bzw. die Zitate von Pike. "Möglichst nix einbauen, was n00bs verwirren könnte" ist mehr oder weniger das offizielle Credo der Go-Entwickler selber...

  5. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: schap23 03.08.20 - 13:39

    Und wer die Generics von Java verstanden hat, wird gemerkt haben, daß sie leider verunglückt sind, weil sich die vorher vorhandenen Arrays nicht haben anpassen lassen. Als Pointer für Studien: covariant vs. contravariant.

    Wer Generics liebt, sollte vielleicht besser in Haskell programmieren.

    Aber hier geht es ja nicht um Sprachfeatures sondern darum, daß irgendein Nur-Java-Programmierer seine Felle wegschwimmen sieht, nur weil eine neu zu lernende Sprache auftaucht. Aber wer nur eine Sprache kennt und nutzt, ist eigentlich schon lange nicht mehr konkurrenzfähig. Verschiedene Sprachen haben ihre Stärken und Schwächen und man kommt schneller zum Ziel, wenn man nicht nach dem Motto programmiert: Wenn man nur einen Hammer hat, wird alles zum Nagel.

  6. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: \pub\bash0r 03.08.20 - 13:46

    wasdeeh schrieb:
    --------------------------------------------------------------------------------
    > \pub\bash0r schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Schön wie hier haufenweise "Programmierer" beleidigt werden, nur weil
    > der
    > > eigene Horizont das maß aller Dinge ist. Toll!
    >
    > Naja, lies den Artikel, bzw. die Zitate von Pike. "Möglichst nix einbauen,
    > was n00bs verwirren könnte" ist mehr oder weniger das offizielle Credo der
    > Go-Entwickler selber...

    Nein, genau darum geht es nicht. Es geht darum, dass ein neuer Entwickler (das kann auch einfach ein erfahrener aber im Projekt neuer Entwickler sein) Code verstehen kann, den er zum ersten Mal sieht.

    Das ist signifikant schwerer, wenn die Leute, die seit zwei Jahren in der Sprache und ihrem Code-Stil arbeiten jede erdenkliche Möglichkeit der Sprache ausreizen, um "geilen Code" zu schreiben. Operatoren überladen, DSLs bauen, Abstraktionen über Abstraktionen, ...

    Wenn dir die Sprache gar nicht erst soviele Möglichkeiten lässt, kann auch der geilste Entwickler nicht unnötige eskalieren. Die einheitliche Formatierung tut ihren Rest. In Go kann ich den meisten fremden Code relativ schnell durchsteigen. In C++, C#, Kotlin/Java ist das bei weitem nicht so.

    Was nicht heißt, dass es nicht auch schon Leuten gelungen ist, Go Code absurd kompliziert zu gestalten. Das ist dann aber häufig Code, der mit Java/"Enterprise" Denken geschrieben wurde.

    Go bringt einem bei, sich wieder auf das eigentliche Problem zu konzentrieren, und nicht auf die hippe Sprache.

  7. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: wasdeeh 03.08.20 - 14:02

    schap23 schrieb:
    --------------------------------------------------------------------------------
    > Wer Generics liebt, sollte vielleicht besser in Haskell programmieren.

    Oder schlicht in einer Sprache, die parametrischen Polymorphismus weniger verunglückt implementiert? Also so ziemlich jede moderne statisch typisierte Sprache? (Ok, über C++ templates kann man streiten ;) )

    >Aber hier geht es ja nicht um Sprachfeatures sondern darum, daß irgendein Nur-Java-Programmierer seine Felle wegschwimmen sieht, nur weil eine neu zu lernende Sprache auftaucht.

    Ich würde sagen, das ist eher Projektion deinerseits...



    1 mal bearbeitet, zuletzt am 03.08.20 14:02 durch wasdeeh.

  8. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: Winny 03.08.20 - 14:41

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > In C++, C#, Kotlin/Java ist das bei weitem
    > nicht so.
    Also dass angeblich selbst Kotlin nicht leicht lesbar wäre. Ich zweifle sehr stark daran, dass du wirklich mit den oben genannten Sprachen gearbeitet hast, vor allem Kotlin. Vielleicht könntest du uns ein Beispiel geben?



    1 mal bearbeitet, zuletzt am 03.08.20 14:42 durch Winny.

  9. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: wasdeeh 03.08.20 - 14:42

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------

    > Nein, genau darum geht es nicht. Es geht darum, dass ein neuer Entwickler
    > (das kann auch einfach ein erfahrener aber im Projekt neuer Entwickler
    > sein) Code verstehen kann, den er zum ersten Mal sieht.

    Noch mal: lies die Zitate. Pike spricht *explizit* von unerfahrenen Entwicklern - viel eindeutiger gehts nicht.


    > Das ist signifikant schwerer, wenn die Leute, die seit zwei Jahren in der
    > Sprache und ihrem Code-Stil arbeiten jede erdenkliche Möglichkeit der
    > Sprache ausreizen, um "geilen Code" zu schreiben. Operatoren überladen,
    > DSLs bauen, Abstraktionen über Abstraktionen, ...
    >
    > Wenn dir die Sprache gar nicht erst soviele Möglichkeiten lässt, kann auch
    > der geilste Entwickler nicht unnötige eskalieren. Die einheitliche
    > Formatierung tut ihren Rest. In Go kann ich den meisten fremden Code
    > relativ schnell durchsteigen. In C++, C#, Kotlin/Java ist das bei weitem
    > nicht so.

    Ich stimme dir in der Grundüberlegung durchaus zu. Aufs aktuelle Thema bezogen ists trotzdem ein Strohmann, v.a. das in-einen-Topf-Werfen von C++, C#, Kotlin und Java ggü Go - da hast du ein ganzes Spektrum an verschiedenen Komplexitätsgraden bzw. "shoot-in-foot-ability"-Levels...

    Das Problem, das viele mit Go haben, ist ja nicht, dass die Sprache sich Einfachheit auf die Fahnen geschrieben hat. Sondern dass sie *so* übersimplifiziert ist, dass sie Antipatterns und schlechten Code geradezu fördert (Verletzung von DRY, boilerplate hell etc., aber auch das ganze Thema bzgl fehlender Immutabilität - jaja, "concurrency is not parallelism", was für eine schwache Ausrede...und genau die unerfahrenen Entwickler stehn dann bei ihren ersten race conditions wie die Kuh vorm neuen Tor, race detection hin oder her).

  10. Clojure Async

    Autor: zilti 03.08.20 - 15:25

    Ich bin einfach mal froh um die Go-Routinen, die als Bibliothek nach Clojure portiert wurden :) Mit Sprachen wie Go kann ich nicht mehr allzu viel anfangen...

  11. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: shoggothe 03.08.20 - 15:34

    Kannst du mal erläutern, was die Vorteile einer Map, implementiert als Klassenhierarchie, gegenüber einer direkt in die Sprache integrierten Map sind? Bei den meisten Programmiersprachen ist so eine grundlegende Datenstruktur Teil der Sprache. Da hat man dann Zugriff mit []-Operator, statt mit get, set und es gibt Map-Literale, die Daten syntaktisch ansehnlich strukturieren.

    Und die Daten können im Speicher kompakt und sequenziell abgelegt werden. In Java ist jeder Map-Eintrag ein Objekt. Primitive Datentypen müssen objektifiziert (boxed) werden. Statt dass die Daten cache-freundlich dicht an dicht im Speicher liegen, werden aus einfachen Werten mehrfache Indirektionen (Map->Array->Bucket->MapEntry->Value) auf dem Heap. Und eine Indirektion ist nicht nur ein einfacher Zeiger, sondern ein Zeiger mit Metadaten, immer mindestens 8 bis 16 Bytes groß.

    Das Gleiche mit Arrays. Der erfahrene Java-Programmierer benutzt lieber Boxing und java.util.List. Das einfache Sprachfeature wird ungerne verwendet, da in der Praxis zu unhandlich.

    Und das ist wohl der Punkt. Die Einfachheit von Go ist vielen C++, C# und Java-Programmieren unbequem/lästig. Ohne Klassenhierarchien, Templates sieht man zwar wieder was passiert, aber man muss auch Vieles wieder selbst machen.

  12. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: BlackSuit 03.08.20 - 15:47

    shoggothe schrieb:
    --------------------------------------------------------------------------------
    > Kannst du mal erläutern, was die Vorteile einer Map, implementiert als
    > Klassenhierarchie, gegenüber einer direkt in die Sprache integrierten Map
    > sind? Bei den meisten Programmiersprachen ist so eine grundlegende
    > Datenstruktur Teil der Sprache. Da hat man dann Zugriff mit []-Operator,
    > statt mit get, set und es gibt Map-Literale, die Daten syntaktisch
    > ansehnlich strukturieren.
    >
    > Und die Daten können im Speicher kompakt und sequenziell abgelegt werden.
    > In Java ist jeder Map-Eintrag ein Objekt. Primitive Datentypen müssen
    > objektifiziert (boxed) werden. Statt dass die Daten cache-freundlich dicht
    > an dicht im Speicher liegen, werden aus einfachen Werten mehrfache
    > Indirektionen (Map->Array->Bucket->MapEntry->Value) auf dem Heap. Und eine
    > Indirektion ist nicht nur ein einfacher Zeiger, sondern ein Zeiger mit
    > Metadaten, immer mindestens 8 bis 16 Bytes groß.
    >
    > Das Gleiche mit Arrays. Der erfahrene Java-Programmierer benutzt lieber
    > Boxing und java.util.List. Das einfache Sprachfeature wird ungerne
    > verwendet, da in der Praxis zu unhandlich.
    >
    > Und das ist wohl der Punkt. Die Einfachheit von Go ist vielen C++, C# und
    > Java-Programmieren unbequem/lästig. Ohne Klassenhierarchien, Templates
    > sieht man zwar wieder was passiert, aber man muss auch Vieles wieder selbst
    > machen.
    Nun der Hauptvorteil ist, dass du die Map Implementierung nutzen kannst die für das konkrete Problem die beste ist und nicht eine onesize fits all Implementierung der Sprache. Manchmal möchte man Threadsichere Maps, manchmal mit sortierten Keys, usw. Bei Programmiersprachen mit Operatorüberladung (in der JVM z.B. Groovy) gibt es auch den [] Operator für den Zugriff. Die interne Datenstruktur der Map ist ja letztlich eine Frage der Implementierung und der Möglichkeiten der Sprache und lange nicht so simplistisch wie von dir dargestellt. Das gleiche gilt auch für Collections.
    Und genau man muss vieles Selbermachen in Go. Man verletzt also zumindest Mal DRY. Und damit ist die letztliche Codequalität bestimmt nicht besser als in Java mit seinen abertausenden etablierten und millionenfach getesteten generischen Bibliotheken. Und einer Map Implementierung für jede Anforderung.

  13. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: MarcusK 03.08.20 - 15:55

    shoggothe schrieb:
    --------------------------------------------------------------------------------
    > Bei den meisten Programmiersprachen ist so eine grundlegende
    > Datenstruktur Teil der Sprache. Da hat man dann Zugriff mit []-Operator,
    > statt mit get, set und es gibt Map-Literale, die Daten syntaktisch
    > ansehnlich strukturieren.

    ob es teil der Sprache ist, hat doch wohl wenig mit dem Art des Zugriffes zu tun. Bei C++ wird dafür einfach der Operator[] überladen.

  14. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: shoggothe 03.08.20 - 15:59

    Race Conditions sind wirklich sehr einfach in Go zu finden und zu beheben. Da bekommt man mehrere Stacktraces wo dann drüber steht:
    - hier hat eine Goroutine auf eine Variable zugegriffen (Datei, Zeilennummer)
    - hier hat eine zweite Goroutine unsynchronisiert (muss nicht heißen gleichzeitig) auf die Variable zugegriffen
    - hier wurde Goroutine 1 gestartet
    - hier wurde Goroutine 2 gestartet

    Oft ist es so, dass gar kein wirkliches Problem besteht. Z.B. wenn die Zugriffe durch Benutzereingaben zeitlich immer sehr weit auseinander liegen. Aber man bekommt trotzdem die Meldung. In anderen Sprachen muss es erst wirklich krachen, bevor man sich auf die mühselige Suche nach dem nur sporadisch auftretenden Fehler macht. In Go ist das schon etwas entschärfter.

  15. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: GodsBoss 03.08.20 - 17:28

    > Und das ist wohl der Punkt. Die Einfachheit von Go ist vielen C++, C# und
    > Java-Programmieren unbequem/lästig. Ohne Klassenhierarchien, Templates
    > sieht man zwar wieder was passiert, aber man muss auch Vieles wieder selbst
    > machen.

    Auch im Java-Umfeld gibt es ausreichend Leute, die mit Klassenhierarchien nichts am Hut haben und dem Prinzip "Composition over Inheritance" folgen. Wenn man Dinge nur "selbst machen" müsste, wäre das okay, aber leider muss man die gleichen Dinge immer wieder machen, wenn man typsicher agieren will. Warum eine for-Schleife verständlicher sein soll als ein Aufruf von "filter", entzieht sich ebenfalls meiner Kenntnis.

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  16. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: BlackSuit 03.08.20 - 17:31

    shoggothe schrieb:
    --------------------------------------------------------------------------------
    > Oft ist es so, dass gar kein wirkliches Problem besteht. Z.B. wenn die
    > Zugriffe durch Benutzereingaben zeitlich immer sehr weit auseinander
    > liegen.

    Der letzte Satz schon Brandgefährlich in seiner Geringschätzung des Fehlers.
    Zweitens bieten andere moderne Sprachen wie Rust viel mehr Garantien zur Compilerzeit und sind damit als moderne Sprache wesentlich interessanter.

  17. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: shoggothe 03.08.20 - 19:48

    BlackSuit schrieb:
    --------------------------------------------------------------------------------
    > shoggothe schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Oft ist es so, dass gar kein wirkliches Problem besteht. Z.B. wenn die
    > > Zugriffe durch Benutzereingaben zeitlich immer sehr weit auseinander
    > > liegen.
    >
    > Der letzte Satz schon Brandgefährlich in seiner Geringschätzung des
    > Fehlers.
    > Zweitens bieten andere moderne Sprachen wie Rust viel mehr Garantien zur
    > Compilerzeit und sind damit als moderne Sprache wesentlich interessanter.

    Wurde von dir auch aus dem Zusammenhang gerissen und fehlinterpretiert. Der Race-Detector meldet mögliche Race-Conditions. Man muss nicht darauf warten, dass eine Race-Condition tatsächlich auftritt. Mit den ausgegebenen Informationen ist es einfach, solche Probleme zu beheben. Viel einfacher als in anderen Programmiersprachen, wo man die womöglich sehr selten auftretende tatsächliche Race-Condition als solche identifizieren, nachvollziehen und korrekt beheben muss, die sogenannten Heisenbugs.

    Und wieso ziehst du, als erfahrener Java-Entwickler, immer andere Sprachen heran, um Go obsolet zu reden? Auf die Nicht-Lokalität der Java-Collections und auf den Object-Overhead bist du vorhin auch nicht eingegangen. Java will es dem Programmierer mit viel Voodoo einfach machen. Go ist low-leveliger und dadurch präziser.

  18. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: BlackSuit 03.08.20 - 21:53

    shoggothe schrieb:
    --------------------------------------------------------------------------------
    > BlackSuit schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > shoggothe schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Oft ist es so, dass gar kein wirkliches Problem besteht. Z.B. wenn die
    > > > Zugriffe durch Benutzereingaben zeitlich immer sehr weit auseinander
    > > > liegen.
    > >
    > > Der letzte Satz schon Brandgefährlich in seiner Geringschätzung des
    > > Fehlers.
    > > Zweitens bieten andere moderne Sprachen wie Rust viel mehr Garantien zur
    > > Compilerzeit und sind damit als moderne Sprache wesentlich
    > interessanter.
    >
    > Wurde von dir auch aus dem Zusammenhang gerissen und fehlinterpretiert. Der
    > Race-Detector meldet mögliche Race-Conditions. Man muss nicht darauf
    > warten, dass eine Race-Condition tatsächlich auftritt. Mit den ausgegebenen
    > Informationen ist es einfach, solche Probleme zu beheben. Viel einfacher
    > als in anderen Programmiersprachen, wo man die womöglich sehr selten
    > auftretende tatsächliche Race-Condition als solche identifizieren,
    > nachvollziehen und korrekt beheben muss, die sogenannten Heisenbugs.
    >
    > Und wieso ziehst du, als erfahrener Java-Entwickler, immer andere Sprachen
    > heran, um Go obsolet zu reden? Auf die Nicht-Lokalität der Java-Collections
    > und auf den Object-Overhead bist du vorhin auch nicht eingegangen. Java
    > will es dem Programmierer mit viel Voodoo einfach machen. Go ist
    > low-leveliger und dadurch präziser.

    Um die Vor und Nachteile von Go Arrays und Maps verglichen mit ihren Java Pedants aufzuzeigen müsste man wirklich detailliert die verschiedenen Speichermodelle + Optimierungen des (JIT-) Compilers diskutieren. Dazu kenne ich Go nicht gut genug um das seriös zu machen. Du scheinbar auch nicht, also lass den Strohmann stecken. Und natürlich habe ich klar aufgezeigt, dass es weit flexibler ist ein Interface Map (wie in Java) mit verschiedenen Implementierungen zu haben, statt einer Map als Sprachfeature. Den Teil solltest du also noch Mal lesen. Zu Behaupten eine Sprache mit GC wäre Low-Levellig und präzise ist schon etwas zu mutig.
    Als erfahrener Entwickler lerne ich sowieso verschiedene Sprachen. Und da bietet eben Rust viel mehr interessante Konzepte als Go - der Duplo Kasten der Programmiersprachen.

  19. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: shoggothe 03.08.20 - 23:44

    Wie kommst du zu deinen Schlüssen was ich kenne und was nicht? Ich programmiere Java seit Version 1.0 bis heute. Genauso Go seit einer frühen Beta bis heute. Beides im professionellen Umfeld, dazu noch einige weitere Programmiersprachen, was aber langsam abnimmt (Altcode).

    Go ist in der Hinsicht präziser, weil bekannt ist wie Datenstrukturen im Speicher aussehen. Aus diesem Grund ist es auch einfach, C-Bibliotheken anzubinden. Umgekehrt kann C-Code auf Go-Code zugreifen. Für Java-JNI müssen Datenstrukturen sehr einfach gehalten werden, am besten ohne Vererbung und ohne Assoziationen zwischen Objekten. Man kann Funktionen in einer Art Meta-Assembly schreiben (architektur-übergreifend). Man kann Code optimieren, damit weniger Speicher auf dem Heap reserviert wird. Per Benchmark-Test oder Profiler bekommt man genaue Rückmeldung ob das funktioniert.

    Und da es definierbare Wertetypen und Zeiger gibt, lassen sich Datenstrukturen dicht packen, was wichtig für die CPU-Caches ist. Diesen Punkt hast du bisher geflissentlich ignoriert. In Java gibt es eingebaute Arrays, in denen sich zumindest die primitiven Datentypen dicht packen lassen. Trotzdem wird java.util.List und Boxing bevorzugt, da erweiterbar. Allgemein kennt Java keine dicht gepackten, geschachtelten Datenstrukturen, da definierbare Wertetypen nicht unterstützt werden (soll irgendwann mal kommen, in einer kruden Form, seit 2012). Eine eingebaute Map würde das Problem etwas abmildern.

    Eine eingebaute Map, die auch primitive Datentypen statt nur Objekte unterstützt, ist auch sicherlich effizienter als alle aktuellen Java-Map-Implementationen. Einfach durch das Boxing und die vielen Indirektionen (Cache-Misses).

    Interfaces in Go werden für für APIs/Services verwendet (wie der Name schon sagt). Interfaces für Daten werden vermieden, weil das dem Java-Boxing gleich kommt (Zeiger+Metadata statt Wert und dadurch Allocationen auf dem Heap).

    Du sprichst auch immer so, als wäre vieles an Java für dich kompletter Voodoo. Guck dir mal den Quelltext von java.util.HashMap an. Das ist ein Array von Buckets von Key-Value-Pairs. Der Hash-Wert eines Objekts modulo Array-Size bestimmt in den Index in das Array. Dann wird der Bucket iteriert, bis ein Eintrag mit passendem Hash und key1.equals(key2) gefunden ist oder auch nicht. Im Normalfall gibt es nur einen Eintrag pro Bucket.



    1 mal bearbeitet, zuletzt am 03.08.20 23:45 durch shoggothe.

  20. Re: Google stopft unwissenden "Programmierern" Golang die Kehle herunter

    Autor: Trockenobst 04.08.20 - 00:08

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > Nein, genau darum geht es nicht. Es geht darum, dass ein neuer Entwickler
    > (das kann auch einfach ein erfahrener aber im Projekt neuer Entwickler
    > sein) Code verstehen kann, den er zum ersten Mal sieht.

    Das sehe ich an C++11 mit vollem Syntax-Zucker und bei extremen Codebeispielen von Rust.
    Das ist was für Leute die das jeden Tag machen und einen Sinn darin sehen, bei Gigabytes an Speicher und SSDs noch an solchen "Pointer zu Subroutinen in anderen Threads" zu basteln um 200bytes zu sparen. Ich kam mit 20% der C++99 Features weit und die Software läuft immer noch.

    Das liegt aber auch daran, das C++, Kotlin, Rust etc. eben die Basics des "Intent" umsetzen.
    Das rum schieben von Listen, Maps, Daten lesen und schreiben, etwas Socket Work, vielleicht auch Parallelisiert, ist doch schon 60% des meisten Codes. Die CSV, XML Parser von Go sehen wild aus. Natürlich, weil man dort die Objekttypen aus multipliziert und so muss man auch N x M List/Map Typen simulieren.

    Was ich bei Go Leuten gelernt habe: denen ist alles egal. Wenn es 5 Tage länger dauert als mit X, ist das eben die Entscheidung für die Sprache. Da ist auch der O-Ton bei Reddit. Ich kenne kein Projekt außer Google, Banken und Militär, das diese Einstellung hat. Geld hat man zum Saufuttern, jetzt kann man sich codierte Kunst leisten.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. ING-DiBa AG, Frankfurt am Main
  2. KWS SAAT SE & Co. KGaA, Einbeck
  3. Heinrich-Heine-Universität, Düsseldorf
  4. Radeberger Gruppe KG, Frankfurt am Main

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mobilfunk: UMTS-Versteigerungstaktik wird mit Nobelpreis ausgezeichnet
Mobilfunk
UMTS-Versteigerungstaktik wird mit Nobelpreis ausgezeichnet

Sie haben Deutschland zum Mobilfunk-Entwicklungsland gemacht und wurden heute mit dem Nobelpreis ausgezeichnet: die Auktionstheorien von Paul R. Milgrom und Robert B. Wilson.
Ein IMHO von Frank Wunderlich-Pfeiffer

  1. Coronakrise Deutsche Urlaubsregionen verzeichnen starke Mobilfunknutzung
  2. LTE Telekom benennt weitere Gewinner von "Wir jagen Funklöcher"
  3. Mobilfunk Rufnummernportierung darf maximal 7 Euro kosten

Star Trek Discovery: Harte Landung im 32. Jahrhundert
Star Trek Discovery
Harte Landung im 32. Jahrhundert

Die dritte Staffel von Star Trek: Discovery nutzt das offene Ende der Vorgängerstaffel. Sie verspricht Spannung - etwas weniger Pathos dürfte es aber sein.
Eine Rezension von Tobias Költzsch

  1. Star Trek Prodigy Captain Janeway spielt in Star-Trek-Cartoonserie mit
  2. Paramount Zukunft für Star-Trek-Filme ist ungewiss
  3. Streaming Star Trek Discovery kommt am 15. Oktober zurück

Apple: iPhone 12 bekommt Magnetrücken und kleinen Bruder
Apple
iPhone 12 bekommt Magnetrücken und kleinen Bruder

Das iPhone 12 ist mit einem 6,1-Zoll- und das iPhone 12 Mini mit einem 5,4-Zoll-Display ausgerüstet. Ladegerät und Kopfhörer fallen aus Gründen des Umweltschutzes weg.

  1. Apple iPhone 12 Pro und iPhone 12 Pro Max werden größer
  2. Apple iPhone 12 verspätet sich
  3. Back Tap iOS 14 erkennt Trommeln auf der iPhone-Rückseite