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

„Schlanke Syntax, schneller Compiler“, aber…

  1. Thema

Neues Thema Ansicht wechseln


  1. „Schlanke Syntax, schneller Compiler“, aber…

    Autor: oYa3ema5 03.08.20 - 18:39

    …das geht heutzutage scheinbar nicht mehr, ohne für die Inhalte des Basispakets ein halbes Gigabyte Plattenplatz zu brauchen. Plattenplatz ist billig™. Mögen die fertigen Binaries nach dem Linken so klein sein wie sie mögen, das riecht mir doch sehr danach, dass denen schon ihre Standardbibliothek ziemlich aus dem Ruder läuft.

    go-2:1.14.6 = 497 MB

    Als Vergleich GCC 10.1.0 libs + binaries = 297 MB

    (Archlinux-Pakete nach dem Entpacken)

    Wenn das alles benötigte Komplexität ist, weiß ich nicht, was das Attribut „schlank“ in diesem Kontext zu suchen hat. Und wenn sie es nicht brauchen, warum nimmt es dann _meinen_ Plattenplatz weg?

  2. Re: „Schlanke Syntax, schneller Compiler“, aber…

    Autor: garthako 03.08.20 - 19:30

    Interessant, wenn du die die Distribution von golang dot org für Linux ziehst sind das 120mb gepackt und 334mb entpackt.
    KA was arch da noch so reinpumpt

  3. Re: „Schlanke Syntax, schneller Compiler“, aber…

    Autor: \pub\bash0r 03.08.20 - 20:59

    oYa3ema5 schrieb:
    --------------------------------------------------------------------------------
    > …das geht heutzutage scheinbar nicht mehr, ohne für die Inhalte des
    > Basispakets ein halbes Gigabyte Plattenplatz zu brauchen. Plattenplatz ist
    > billig™. Mögen die fertigen Binaries nach dem Linken so klein sein
    > wie sie mögen, das riecht mir doch sehr danach, dass denen schon ihre
    > Standardbibliothek ziemlich aus dem Ruder läuft.
    >
    > go-2:1.14.6 = 497 MB
    >
    > Als Vergleich GCC 10.1.0 libs + binaries = 297 MB
    >
    > (Archlinux-Pakete nach dem Entpacken)
    >
    > Wenn das alles benötigte Komplexität ist, weiß ich nicht, was das Attribut
    > „schlank“ in diesem Kontext zu suchen hat. Und wenn sie es
    > nicht brauchen, warum nimmt es dann _meinen_ Plattenplatz weg?

    Naja dann installiert für einen faireren Vergleich auch noch die cross binutils für alle Kombinationen aus Windows/Linux/Mac/Android/Plan9 und x86/x64/arm/arm64...

    Dann noch die libs die du brauchst für einen HTTP2 Server und Client, JSON, XML und CSV serializer und deserializer, SSL, SMTP, Template Engine, gzip, ZIP, bzip2, hash und crypto etc.etc

    Denn all das bekommst du mit diesen paar hundert MB Go Distribution (inklusive dem Source von all dem).

  4. Re: „Schlanke Syntax, schneller Compiler“, aber…

    Autor: oYa3ema5 03.08.20 - 22:30

    Naja, in das PKGBUILD kann ja jeder einfach reinschauen, da wird der Tarball von dem Google-Server gezogen, entpackt und das Upstream-Buildscript aufgerufen.

    Irgendwie ist auch die Argumentation mit den erweiterten Funktionen der Standardbibliothek nicht ganz schlüssig, weil ich ja auch gcc-go installieren könnte, und damit bin ich immer noch 37 MB unter dem Google-Compiler, und habe ganz nebenbei Unterstützung für C, C++, und alles was GCC noch so mitbringt, mit dabei.

    Meine Kritik richtet sich nicht gegen Go an sich, sondern gegen die offensichtlich ineffiziente und mutmaßlich lieblos/enterprise-ig aufgeblasene Packaging-Praxis von Seiten der offiziellen Referenzimplementierung.

    Mir ist es egal, wenn andere Leute darin kein Problem sehen. Das ist dann aber deren Sache, und sagt wenig über die Software an sich, aber mehr über deren Abstumpfung gegenüber Bloat und Featuritis aus.

  5. Re: „Schlanke Syntax, schneller Compiler“, aber…

    Autor: shoggothe 04.08.20 - 00:31

    Alle Go-Ausführbaren sind riesig, weil statisch gelinkt. Sehr nützlich im Zusammenhang mit dem Cross-Compilieren. Auf einem Baurechner alle Architekturversionen compilieren und verteilen, funktioniert einfach.

    Ein weiterer großer Batzen sind Symbolinformationen. Die machen die Hälfte oder mehr der Dateigröße aus. Wenn man die stripped, verliert man Stacktraces, Reflection und Debugging. Ich glaube mich zu erinnern, dass die Symbolinformationen nicht sonderlich effizient aufgebaut sind. Eher nach dem Prinzip der Potenzmenge, die quadratisch mit der Anzahl der Metadaten wächst.

  6. Re: „Schlanke Syntax, schneller Compiler“, aber…

    Autor: \pub\bash0r 04.08.20 - 09:07

    oYa3ema5 schrieb:
    --------------------------------------------------------------------------------

    > Meine Kritik richtet sich nicht gegen Go an sich, sondern gegen die
    > offensichtlich ineffiziente und mutmaßlich lieblos/enterprise-ig
    > aufgeblasene Packaging-Praxis von Seiten der offiziellen
    > Referenzimplementierung.

    Der Witz bei Go ist doch aber gerade das "Batteries included". Du kannst da nicht einfach einen Teil weglassen. Die stdlib ist nunmal wie sie ist. Quelltext liegt auch immer dabei.

    Ein "Go compiler" ohne irgendwas drum herum bringt dir gar nix. Also macht es auch keinen Sinn, den separat zu verpacken.

  7. Re: „Schlanke Syntax, schneller Compiler“, aber…

    Autor: brainslayer 04.08.20 - 11:07

    shoggothe schrieb:
    --------------------------------------------------------------------------------
    > Alle Go-Ausführbaren sind riesig, weil statisch gelinkt. Sehr nützlich im
    > Zusammenhang mit dem Cross-Compilieren. Auf einem Baurechner alle
    > Architekturversionen compilieren und verteilen, funktioniert einfach.
    >
    > Ein weiterer großer Batzen sind Symbolinformationen. Die machen die Hälfte
    > oder mehr der Dateigröße aus. Wenn man die stripped, verliert man
    > Stacktraces, Reflection und Debugging. Ich glaube mich zu erinnern, dass
    > die Symbolinformationen nicht sonderlich effizient aufgebaut sind. Eher
    > nach dem Prinzip der Potenzmenge, die quadratisch mit der Anzahl der
    > Metadaten wächst.

    es is überhaupt nicht nützlich wenn die klassenbibliothek riesig ist. egal ob statisch oder dynamisch gelinkt. wo verwendet man denn cross kompilieren? auf embedded geräten und dort ist platz heilig. go ist nicht schlank. die sprache ist schlank, aber das resultat ist ein fettsack

  8. Re: „Schlanke Syntax, schneller Compiler“, aber…

    Autor: \pub\bash0r 04.08.20 - 12:50

    brainslayer schrieb:
    --------------------------------------------------------------------------------
    > wo verwendet man denn cross
    > kompilieren? auf embedded geräten und dort ist platz heilig.

    Quatsch. Wenn, dann cross-compile ich FÜR die embedded geräte, nicht auf ihnen. Also ist die Größe des Compilers für das Zielgerät irrelevant.

    Wo sonst noch? Build Maschine -> Target platform.
    Meine CI Pipelines laufen in der Regel auf Linux/Docker. Ich biete aber Binaries für linux/x64, linux/x86, linux/arm, linux/arm64, windows/x86, windows/x64, osx/x64 (bald wohl osx/arm), etc. pp

    Lokal ebenso: ich Entwickle auf OSX und möchte die Binary auf meinen Linux-Server schubsen? Da werd ich bestimmt nicht dort Go installieren. Ich cross-compile das auf meiner Kiste und werf's rüber.

  9. Re: „Schlanke Syntax, schneller Compiler“, aber…

    Autor: Dino13 04.08.20 - 14:07

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > brainslayer schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > wo verwendet man denn cross
    > > kompilieren? auf embedded geräten und dort ist platz heilig.
    >
    > Quatsch. Wenn, dann cross-compile ich FÜR die embedded geräte, nicht auf
    > ihnen. Also ist die Größe des Compilers für das Zielgerät irrelevant.

    Die Größer des Compilers mag egal sein aber nicht die des Kompilats.

  10. Re: „Schlanke Syntax, schneller Compiler“, aber…

    Autor: \pub\bash0r 04.08.20 - 15:30

    Dino13 schrieb:
    --------------------------------------------------------------------------------
    > Die Größe des Compilers mag egal sein aber nicht die des Kompilats.

    So unverschämt groß sind die Binaries ja nun auch nicht. Ein kompletter Service mit HTTP Server, Datenbanktreiber, JSON, etc. pp ist ~12 MB. Und da ist Scheduler (für die Goroutines) und der GC mit an Bord.

    .netcore und java/graal sind da eher bei 80MB.

    C++, wenn du die nötigen Bibliotheken einbindest und statisch linkst, sind auch nicht klein.

    Wenn du mit Embedded natürlich eher den ESP32 meinst, da würdest du wohl auch eher nicht zu einer Sprache mit GC greifen. Falls du dafür trotzdem Go nehmen willst (wäre verständlich), würde TinyGo dir weiterhelfen.

    ... oder man nimmt halt, wofür einem der Hersteller des Boards/Prozessors ein SDK gibt. Und das ist dann am Ende meist C oder C++.

  11. Re: „Schlanke Syntax, schneller Compiler“, aber…

    Autor: kieleich 04.08.20 - 16:34

    oYa3ema5 schrieb:
    --------------------------------------------------------------------------------
    > Mögen die fertigen Binaries nach dem Linken so klein sein wie sie mögen

    Sind die mittlerweile wieder kleiner geworden?

    Also ich bin bei Go vor ein paar Jahren ausgestiegen, damals wurden sie mit jeder neuen Go-Version größer als vorher.

    Bei den Go Binaries ist eben immer die Runtime mit Goroutine-Verwaltung und GC dabei, egal ob du das für dein Programm brauchst oder nicht. "Hallo Welt", ja hallo und tschüß.

    Und alles mit Goroutinen machen (wozu man als Anfänger verleitet wird) schafft eher neue Probleme als welche zu lösen. Der Overhead davon ist auch nicht gerade so ohne.

    Ich bin bei Rust gelandet. Das ist am Anfang komisch sich in dieses Variablen-Verleih-Konzept reinzudenken und wenn das Konzept nicht passt, muss man eben stellenweise unsafe { } einsetzen (so wenig wie möglich so viel wie nötig) aber ansonsten ist das eine richtig tolle Sprache geworden.

    Zu Go werde ich wahrscheinlich nicht mehr zurückfinden, es sei denn ich hätte eine Anwendung wo Go ausgerechnet seine Stärken voll ausspielen kann.

  1. Thema

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. operational services GmbH & Co. KG, Frankfurt am Main
  2. ekom21 - KGRZ Hessen, Darmstadt, Gießen
  3. RENNER GmbH Kompressoren, Güglingen
  4. PTV Group, Karlsruhe

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Apocalypse Now für 6,41€ (Blu-ray), The Fog: Nebel des Grauens für 6,41€ (Blu-ray...
  2. (u. a. Tropico 6 El Prez Edition für 31€, Tropico 5 - Complete Edition 9,99€, The Dark...
  3. 74,90€ (Vergleichspreise ab 91,47€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


MX 10.0 im Test: Cherrys kompakte, flache, tolle RGB-Tastatur
MX 10.0 im Test
Cherrys kompakte, flache, tolle RGB-Tastatur

Die Cherry MX 10.0 kommt mit besonders flachen MX-Schaltern, ist hervorragend verarbeitet und umfangreich programmierbar. Warum Nutzer in Deutschland noch auf sie warten müssen, ist nach unserem Test unverständlich.
Ein Test von Tobias Költzsch

  1. Argand Partners Cherry wird verkauft

IT-Freelancer: Der kürzeste Pfad zum nächsten Projekt
IT-Freelancer
Der kürzeste Pfad zum nächsten Projekt

Die Nachfrage nach IT-Freelancern ist groß - die Konkurrenz aber auch. Der nächste Auftrag kommt meist aus dem eigenen Netzwerk oder von Vermittlern. Doch wie findet man den passenden Mix?
Ein Bericht von Manuel Heckel

  1. Selbstständiger Sysadmin "Jetzt fehlen nur noch die Aufträge"

Verkehrswende: Zaubertechnologie statt Citybahn
Verkehrswende
Zaubertechnologie statt Citybahn

In Wiesbaden wird um den Bau einer Straßenbahn gestritten, eine Bürgerinitiative kämpft mit sehr kuriosen Argumenten dagegen.
Eine Recherche von Hanno Böck

  1. Fernbus Roadjet mit zwei WLANs und Maskenerkennung gegen Flixbus
  2. Mobilität Wie sinnvoll sind synthetische Kraftstoffe?