Linux: Welche Programmiersprache

[andy_m4]

Es hat hinsichtlich Nachhaltigkeit und Einfachheit eigentlich nur Vorteile.

Welche Nachhaltigkeit? Ressourcenverschwendene Software ist das Gegenteil von nachhaltig. :-)
Oder was meinst Du jetzt?

Streamlining der Technologiestacks

Marketing-Bla ohne Inhalt.

Die Geachwindigkeitseinbussen sind in Zeiten von SSDs und riesigen Mengen an Hauptspeicher wiederum verkraftbar.

Das sagst Du. Nicht jeder kann und will sich aber einen Highend-PC hinstellen. Und das Ressourcenbverbrauchsthema wird insbesondere dann interessant, wenn mehr als einer den Rechner benutzt.

die Anwendung ist praktisch OS agnostisch

Ja. Kann alles aber nix richtig. :-)
OS-unabhängig war auch Java schon. Wir haben ja gesehen, wohin das geführt hat.
Die einzigen echten Vorzeige-Applikationen im Desktop-Bereich sind Java-IDEs :-)

GTK ist unglaublich angestaubt

Echt jetzt? Das ist Dein Punkt den Du machen willlst?

unelegant

Ahja. Aber alles durch nen Webserver und Browser so drücken ist jetzt eleganter?
Zweierlei Maß, mein Lieber.

und ist nur ein UI-Toolkit

Und was ist das Problem dabei? Es soll ja auch gar nicht mehr machen.
Was fehlt denn Deiner Ansicht nach?

Electron ist quasi das Temu in der Softwareentwicklung

So hätte ich es vielleicht nicht gesagt, aber ich musste schmunzeln.

 

[SheepShaver]

@andy_m4 @KitKat::new()
Man merkt, dass ihr Programmierung eher aus einer Hobby-Perspektive betrachtet. In der professionellen Softwareentwicklung steht Nachhaltigkeit nicht in erster Linie für den sparsamen Umgang mit Hardwareressourcen, sondern vor allem für den effizienten Einsatz von Entwicklerressourcen. Entwicklungszeit ist teuer und sie in redundante Technologien zu investieren, ist wirtschaftlich nicht vertretbar. Aus diesem Grund setzt man heute in 90% der Fälle auf Hybrid-Apps oder PWAs, da sie Synergien maximieren und Entwicklungsaufwände minimieren. Alles andere wäre eine Verschwendung von Zeit und Geld.

Daher meine Frage: Inwiefern geht dieser Ansatz konkret zu Lasten der Anwender? Bitte mit belastbaren Fakten belegen und nicht mit subjektivem Blabla. Danke.

Und was GTK angeht:
GTK hat viele Schwächen, die es im Vergleich zu moderneren Frameworks unattraktiv machen. Erstens ist die plattformübergreifende Unterstützung oft holprig. Zweitens ist die Entwicklung mit GTK umständlich, weil es auf C oder spezielle Bindings setzt, was die Einstiegshürde erheblich erhöht. Drittens ist das Ökosystem vergleichsweise klein. Es gibt weniger fertige Libraries und weniger Community-Support. Dazu kommt, dass das Deployment komplizierter ist und sich oft mit Abhängigkeiten herumschlägt. Kurz gesagt: GTK fühlt sich oft altbacken und schwerfällig an.
Electron hat gegenüber GTK einige klare Vorteile: Du schreibst deinen Code einmal und er läuft problemlos auf Windows, macOS und Linux ohne großen Anpassungsaufwand. Electron nutzt Technologien, die fast jeder Entwickler kennt, und das riesige Node.js-Ökosystem bietet unzählige Libraries. Electron-Apps sehen auf allen Plattformen gleich aus, während GTK oft mit Inkonsistenzen kämpft. Dazu kommt ein einfaches Deployment und starke Community-Unterstützung.
Wenn dir schnelle Entwicklung, breite Kompatibilität und ein großer Werkzeugkasten wichtig sind, dann ist Electron klar die bessere Wahl.

 

[pseudopseudonym]

Man merkt, dass ihr Programmierung eher aus einer Hobby-Perspektive betrachtet. In der professionellen Softwareentwicklung steht Nachhaltigkeit nicht in erster Linie für den sparsamen Umgang mit Hardwareressourcen, sondern vor allem für den effizienten Einsatz von Entwicklerressourcen.

Du sprichst meine Gedanken beim stillen Mitlesen dieser komischen und leicht off-topic Diskussion perfekt aus.

 

[andy_m4]

In der professionellen Softwareentwicklung steht Nachhaltigkeit nicht in erster Linie für den sparsamen Umgang mit Hardwareressourcen, sondern vor allem für den effizienten Einsatz von Entwicklerressourcen. Entwicklungszeit ist teuer und sie in redundante Technologien zu investieren, ist wirtschaftlich nicht vertretbar.

Das verstehe ich. Ist übrigens nicht mein Versäumnis, das Du(!) Nachhaltigkeit nicht definiert hast.
Du brauchst daher hinterher gar nicht hochnäsig ankommen mit "keine Ahnung". Insbesondere, weil ich diese Dinge als Vorteile ja bereits grob angerissen hab.
Muss Dir aber zugute halten, das Du das in den Sätzen deutlich und gut nachvollziehbar dargelegt hast.

Daher meine Frage: Inwiefern geht dieser Ansatz konkret zu Lasten der Anwender? Bitte mit belastbaren Fakten belegen

Wie gesagt, Electron-Apps fühlen sich fett und träge an. Das geht zu meinen Lasten in meiner Rolle als Anwender.
Meiner Erfahrung nach machen klassische Desktop-Anwendungen weniger Probleme und fühlen sich geschmeidiger an.

Erstens ist die plattformübergreifende Unterstützung oft holprig.

Es geht sicherlich smoother, aber wenn man auf paar Dinge achtet, dann klappt es eigentlich ganz gut.

Zweitens ist die Entwicklung mit GTK umständlich, weil es auf C

Sehe ich als Vorteil. Das trägt im wesentlichen dazu bei, das die Performance gut ist und der Ressourcenverbrauch klein. Und so schwierig ist GTK mit C gar nicht zu benutzen.

oder spezielle Bindings

Seh' ich als Vorteil. Bei Electron ist man im wesentlichen auf Javascript (+CSS +HTML) als Sprache beschränkt.

Drittens ist das Ökosystem vergleichsweise klein. Es gibt weniger fertige Libraries und weniger Community-Support.

Was laberst Du da? Warum sollte GTK Libraries brauchen?
Wenn dann brauche ich welche für C. Und Du willst mir jetzt ernsthaft einreden, für C gibts kaum Libraries und nur ne kleine Community?
Dafür das Du anderen "keine Ahnung" unterstellst, redest Du ziemlich komisches Zeug zusammen.

Du schreibst deinen Code einmal und er läuft problemlos auf Windows, macOS und Linux ohne großen Anpassungsaufwand.

Schön das Du das sagst. Genau das zeichnet häufig GTK-Software aus. Fast alle GTK-Software die ich benutze steht auch unter diesen Systemen zur Verfügung.
Vielleicht solltest Du mal ein bisschen über den Tellerrand schauen. ;-)

Electron-Apps sehen auf allen Plattformen gleich aus

Du meinst, es fühlt sich immer wie ein Fremdkörper an, weil es sich nicht nahtlos ins Look&Feel des Systems integriert. Genau diese Diskussionen hatten wir alle damals schon bei Java.

Ich will trotzdem Electron natürlich nicht seine Daseins-Berechtigung absprechen. Aber so, wie Du es darstellst das es das Beste ist was es gibt und alle anderen können einpacken, das teile ich eben nicht.

Insbesondere wenn da teilweise auch hanebüchene Argumente kommen. Ich bin keiner, der nicht auch anderen Meinungen zugänglich ist. Im Gegenteil. Ich finde das sogar hochspannend. Aber eben nur, wenn die dann auch ordentlich begründet werden. Wenn da so halbe Quatsch-Argumente drunter sind, dann entwertet das Deine Meinung.

 

[SheepShaver]

Was laberst Du da? Warum sollte GTK Libraries brauchen?
Wenn dann brauche ich welche für C. Und Du willst mir jetzt ernsthaft einreden, für C gibts kaum Libraries und nur ne kleine Community?
Dafür das Du anderen "keine Ahnung" unterstellst, redest Du ziemlich komisches Zeug zusammen.

Um dem ganzen mal etwas Perspektive zu geben:
https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/

Zudem schrieb ich "vergleichsweise klein", was unbestreitbarer Fakt ist. C spielt außer bei Low-Level-Programmierung praktisch keine Rolle.
Bzgl. der Libraries. Natürlich nicht für GTK. GTK ist nur ein GUI-Baukasten. Die UI macht aber nur einen Bruchteil der Codebase einer App aus.
Ich bleibe dabei, wer eine App privat in Linux entwickeln will, die dann auch unter Windows etc. läuft und augenscheinlich bzgl. Fachwissen eher juniorig unterwegs ist, der ist mit einem Web-Techstack besser beraten. Will mich da auch garnicht auf Electron festlegen, für den speziellen Use Case reicht eine App im Browser.
Ansonsten Tauri, wenn man gerne Rust nutzen möchte oder Flutter (Desktop), wenn man lieber Dart statt JS/TS nutzen möchte. Das sind ebenfalls Frameworks, die einen relevanten Marktanteil haben.

Ganz sicher wäre GTK ganz unten auf meiner Liste. Speziell, wenn man bei dem Unterfangen etwas lernen möchte, was einem in der Zukunft im Berufsleben behilflich sein könnte. Da ist GTK absolut Nische.

 

[JP-M]

@SheepShaver das mit C (bzw. eher allgemein dem "Low-Level") ist je nach Branche aber so eine Sache. Wir hatten nun schon in einigen EU-Ausschreibungen mit konkreten Fragen nach dem CO2-Footprint von Serveranwendungen zu tun. Die Fragen und Diskussionen zu diesen Punkten gingen hier bis runter zur Notwendigkeit von Log-Meldungen und der Möglichkeit zur Optimierung im Bereich von CPU-Zyklen (... oder der Esoterik 🙄). Denn hier wurde Nachhaltigkeit so definiert, dass beim Betrieb der Software möglichst wenig Ressourcen der Hardware und Strom verwendet werden - ohne zu wissen, um welche Hardware es denn geht oder welche Lasten den am Ende zu bewältigen sind. Da waren wir weit weg von "Low-Level", aber ohne C/C++ wäre da nichts zu optimieren gewesen.

Wenn es aber mal nicht um diese Themen geht, ist der Trend, zumindest in meinem Umfeld, aber definitiv Electron und Flutter, sobald es Frontends betrifft, die nicht nur unter unter einem spezifischen OS oder im Browser zum Einsatz kommen sollen und man möglichst viel recyclen können möchte.

 

[andy_m4]

Um dem ganzen mal etwas Perspektive zu geben

Es geht hier aber um Desktop-Applikationen so a-la VIsualStudioCode, Teams und was es da sonst noch so gibt.
In der Statistik werden viele Javascript angeben, die "Webkrams" machen.
Insofern ist die Statistik - gelinde gesagt - ungenau.

Zudem schrieb ich vergleichsweise klein, was unbestreitbarer Fakt ist

Jaja. Von mir aus gebe ich Dir den Punkt. Wir haben uns aber von dem Ursprung der Diskussion eigentlich schon entfernt. Es ging eher am Rande um C. Es ging primär um GTK+ und das ist, wie Du ja selbst(!) eingeräumt hast, von verschiedenen Programmiersprachen aus her ansprechbar.

Und wenn ich selbst GTK+ benutze, dann tue ich das auch eher weniger in Form von C-Programmen. Ganz einfach (wie Du ja auch richtig sagst) C relativ low-level ist. Ich KANN C benutzen und in gewissen Szenarios (z.B. soll mit wenig Ressoucen funktionieren) total hilfreich (und eine Option die ich bei Electron nicht habe). Oftmals benutze ich aber gar kein C.

Von daher gilt, was ich bereits sagte: Irgendwelche verfügbaren Libraries haben eher indirekt was mit GTK+ zu tun.

Was die Anzahl von Libraries und Frameworks angeht: Große Menge ist ja nicht als einzige Kriterium. Es müssen ja auch die Libraries verfügbar sein, die ich brauche. Zudem leiden viele Libraries/Frameworks unter Qualitätsproblemen oder haben nur ne kurze Halbwertszeit, so das gar nicht unbedingt sicher gestellt ist, das die jetzt von mir benutzte Library in ein paar Jahren überhaupt noch supportet wird.

Ich sollte also genau gucken, was ich nehme und was überhaupt infrage kommt und nicht einfach blindlings zu irgendeinem hippen Framework greifen, was gerade aufploppt aber wo kein Mensch weiß, ob sich da nächstes Jahr noch jemand drum kümmern.

Wenn man das alles mit einbezieht, dann reduziert sich die Auswahl schon beträchtlich. Wird sicherlich dennoch von mir aus ein Plus überbleiben. Aber ist doch jetzt nicht so, das GTK und Co deshalb völlig aus dem Rennen ist.

Electron ist eine Option. Aber die anderen Dinge eben auch. Mehr behaupte ich doch auch gar nicht. Und ja. Manchmal fallen die anderen Dinge weg, weil was fehlt. Manchmal aber eben auch Electron. Deshalb ist doch gut, was wir die Wahl haben.

Ganz sicher wäre GTK ganz unten auf meiner Liste.

Immerhin ists auf Deiner Liste. ;-)

Speziell, wenn man bei dem Unterfangen etwas lernen möchte, was einem in der Zukunft im Berufsleben behilflich sein könnte.

Ja. Aus der Perspektive macht man da sicherlich nichts falsch, wenn man zu sowas wie Electron greift. Aber es ist halt nicht die einzige Perspektive. Wenn man beispielsweise schon Kenntnisse in Sprachen hat die eben nicht Javascript sind und die man nutzen will, dann sieht die Sache anders aus.

Das Du zu vielen von mir angesprochenen Punkten nichts gesagt hast, werte ich mal als Zustimmung. Du kannst es sicherlich nur nicht so zeigen. ;-)

 

[nullPtr]

Man merkt, dass ihr Programmierung eher aus einer Hobby-Perspektive betrachtet. In der professionellen Softwareentwicklung steht Nachhaltigkeit nicht in erster Linie für den sparsamen Umgang mit Hardwareressourcen, sondern vor allem für den effizienten Einsatz von Entwicklerressourcen.

Klar ist die Frage der Wirtschaftlichkeit immer gegeben. Aber es gibt große Bereiche, in denen deine Aussage in der absoluten Form keinen Bestand hat. U.a. Embedded (Automotive, Maschinenbau, etc.) und wissenschaftliches Rechnen.

Dass C eine "Low-Level"-Sprache ist, ist bei genauerem Betrachten fraglich. Klar ist es relativ zu vielen anderen Sprachen (z.B. Java Script) "lower" level; aber ein moderner Computer ist keine PDP8.

 

[SheepShaver]

Ja, ja, und geschweifte Klammern gehören in eine neue Zeile.
Nee im Ernst. Embedded ist Low-Level-Programmierung und natürlich hat dort C sicherlich seinen Platz. Hier ging es ja vornehmlich um Frontend bzw. Fat Clients, da der Threaderöffner vom Client aus direkt mit der DB kommunizieren will und nicht an einer Serverkomponente interessiert ist.

 

[andy_m4]

Hier ging es ja vornehmlich um Frontend bzw. Fat Clients

Eben.
Und Du stehst ja so auf FAKTEN, FAKTEN, FAKTEN. :-)

Nehmen wir einfach mal ne Linux-Distribution. Arch Linux. Ist bekannt und verbreitet und halt auch viele Pakete, so das es (zumindest die Open-Source-)Landschaft ganz gut abbildet. Ist jetzt vielleicht (dadurch) nicht ganz repräsentativ, aber genaue Zahlen bringst ja auch Du nicht und soll ja auch nur mal ein Eindruck vermitteln.

Und dann schauen wir uns einfach mal nut GTK3 an:
https://archlinux.org/packages/extra/x86_64/gtk3/

Und da gibts ein Eintrag Required by. Und der hat 653 Einträge. Gut, da sind auch teilweise Bibliotheken bei und auch Plugins zu Programmen, testing-Versionen und anderer Kram, die würde ich jetzt nicht mitzählen. Streichen wir da mal großzügig zu Ungunsten von GTK raus und lassen nur 100 Packages tatsächlich gelten.

Und da sind noch nicht mal die drin, die GTK4 benutzen. Oder auch Programme, bei denen es weitergehende Abhängigkeiten gibt (also im Abhängigkeitsgraph ein Schritt weiter), weil GTK nicht direkt benutzt wird, sondern über Bindings/Libs).

Jetzt gucken wir mal im Vergleich, wer so alles electron benutzt:
https://archlinux.org/packages/extra/x86_64/electron34/

8 Einträge. :-) Und da ist sogar noch das Metapaket electron mit drin. Ok. Ist ja auch nur die Version 34
Gibt ja noch die Version 33: https://archlinux.org/packages/extra/x86_64/electron33/ weitere 3
Dann die Version 32: https://archlinux.org/packages/extra/x86_64/electron32/ weitere 2
Version 31: https://archlinux.org/packages/extra/x86_64/electron31/ noch einer
Version 27: https://archlinux.org/packages/extra/x86_64/electron27/ noch einer

Da fehlen zugegebenermaßen noch ein paar Applikationen wie Signal-Desktop, WhatsApp-Desktop, Teams oder der Quba-Viewer.

Sind nicht mal 19 Applikationen (und da hab ich schon hoch gegriffen, weil auch da wie gesagt das Metapaket mit drin ist und auch Sachen doppelt, die testing-Version von deltachat-desktop und drawio-desktop). Spielt aber keine Rolle, weil der Abstand so derartig groß ist.
Und sicher hab ich da noch Sachen vergessen oder weiß sie schlicht nicht. Da kannst Du ja vielleicht auch noch Sachen ergänzen.

Und klar wird sich das in Zukunft sicher verschieben. Aber Stand hier und heute ist eben so, das das mit deiner Aussage so a-la "GTK nimmt keiner" ganz derbe kollidiert.

 

[SheepShaver]

Das sind aber Äpfel mit Birnen verglichen. Wenn ich jetzt eine Applikation schreiben wollte, die nur unter Linux laufen soll und sich gut in den Rest der Desktop-Landschaft integriert, dann würde man je nach Ziel Desktop-Umgebung so wählen:
GNOME/Xfce/Cinnamon etc. -> GTK
KDE -> Qt

War aber nicht die Fragestellung.

 

[andy_m4]

Das sind aber Äpfel mit Birnen verglichen.

Wenn Du das mal bei dir selbst einräumen würdest. Das tust Du dann aber nicht, selbst wenn man Dir die Unzulänglichkeiten aufzeigt.
Mal davon abgesehen hab ich von vornherein gesagt, das das nicht repräsentativ ist, sondern nur einen Eindruck vermitteln soll. Die Zahlen darf man natürlich nicht zu genau nehmen. Aber man kann sie auch schlecht völlig wegignorieren.

Außerdem so sehr Äpfel-Birnen ist das nicht, weil - wie bereits gesagt - sich GTK-Programme auch gut auf andere Systeme portieren lassen. Und viele der dortigen gelisten GTK-Programme sind auch unter anderen Betriebssystemen verfügbar. Man denke nur an bekannte Programme wie LibreOffice, Audacity, Chromium, ClawsMail, filezilla, firefox, Thunderbird, gajim, Inkscape, GIMP, ZIM, ScummVM, Pinta, MyPaint, FreeCIV, gnumeric, emacs, RawTherapee und und und.

Und wie gesagt, da sind noch gar nicht die Programme dabei, die GTK über Bande benutzen. Wenn ich zum Beispiel zu Python mit GTK benutze. Dann habe ich sowohl die einfache Sprache (ich muss mich also nicht mit C herumschlagen), hab plattformunabhängigkeit und ich habe die zahlreichen Frameworks und Bibliotheken (u.a. auch für die geforderte Datenbankanbindung an mariadb).

Und angesichts dessen finde ich das durchaus eine Option. Ob es nun die beste Option ist, das will ich hier gar nicht behaupten. Aber so furchtbar, wie Du es hier dargestellt hast (insbesondere durch die teilweise sehr schwachen bis sogar unrichtigen Argumente) ist es meiner Ansicht nach nicht.

 

[JP-M]

Man denke nur an bekannte Programme wie LibreOffice, Audacity, Chromium, ClawsMail, filezilla, firefox, Thunderbird, gajim, Inkscape, GIMP, ZIM, ScummVM, Pinta, MyPaint, FreeCIV, gnumeric, emacs, RawTherapee und und und.

Das sind alles Programme, die schon lange existierten, bevor Stacks wie Electron in Mode gekommen sind (mit dem Sonderfall Chromium ). Ich würde vermuten, dass viele dieser Applikationen würden heute - wenn das Ziel Multi-OS-Support ist - nicht mit GTK implementiert werden.

 

[andy_m4]

Das sind alles Programme, die schon lange existierten, bevor Stacks wie Electron in Mode gekommen sind

Mag ja alles sein. Aber dafür, das man heute (angeblich) bevorzugt zu electron greift: Wo sind sie denn, die ganzen electron-Programme? Die müssten ja wie Pilze aus dem Boden schießen.
Ich kam auf nicht mal 20 Programme. Wenn ihr mehr Beispiele habt, gerne her damit.

Ich würde vermuten, dass viele dieser Applikationen würden heute - wenn das Ziel Multi-OS-Support ist - nicht mit GTK implementiert werden.

Kann gut sein.
Mein Eindruck ist aber häufig, das solche Entscheidungen oftmals Mode-getrieben sind. So nach dem Motto: electron (oder was auch immer) ist angesagt. Also nimmt man das.
Wenn man dann aber mal nach ganz konkreten Gründen fragt, dann kommt da oftmals nicht viel (kann man hier im Thread ja sehr schön bestaunen).
Wie gesagt, mir gehts nicht darum electron schlecht zu reden oder so. Es mag von mir aus auch seine Vorteile haben. Das will ich gar nicht in Abrede stellen.
Aber das es klar und deutlich überlegen ist (wie hier teilweise suggeriert), das sehe ich bisher irgendwie nicht.