Energiefresser dynamische Programmiersprache

Lucas Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcasts. Heute wollen wir uns noch mal über das Thema Ruby und Python unterhalten und ob die noch zeitgemäß sind. Aber diesmal nicht aus der Sicht der Performance, sondern aus der Sicht von Green IT. Und dafür habe ich mir den Christoph eingeladen. Hallo, Christoph.

Christoph Hallo!

Lucas Wir haben zu dem Thema einen Teil eins, das ist die Folge 97, wo wir die Frage gestellt haben, Ruby ist schnell genug für GitHub, aber ist es auch schnell genug für uns? Da könnt ihr gerne noch mal reinhören. Da gibt es keine definitiven Antworten, würde ich sagen, aber viele Sachen zum Diskutieren und das, worüber wir jetzt auch reden, spielt auch ein bisschen in das ganze Thema Green IT, wo ich mehrere Folgen mit Daniel und Daphne zu aufgenommen habe. Die sind in den Shownotes verlinkt, für die Leute, die da noch mal reinhören wollen. Aber ja, ich würde sagen, lass uns doch erst mal motivieren, warum wir darüber sprechen, oder?

Christoph Die Idee kam so ein bisschen von mir, dass wir da vielleicht mal einen Nachfolger für unsere Python und Ruby Diskussion machen, wo wir doch schon ein bisschen ein Ergebnis hatten, dass man auf jeden Fall die beiden Sprachen schnell genug machen kann bzw. skalierend genug, um auch solche Dinge zu stemmen, wie GitHub und Instagram als prominente Vertreter für so Webscale Sachen, die hauptsächlich in diesen Programmiersprachen programmiert wurden und dass das aber nicht so out of the box geht, sondern dass da auch ganz viel Arbeit drinsteckt und dass man das nicht so runtermachen kann. Und der heutige Aufhänger ist, ja, wenn das so geht, warum sollte man noch weiter darüber quatschen? Sind jetzt die Anforderungen an Skalierbarkeit noch mal so deutlich gestiegen? Nein, das sind sie eben nicht. Eigentlich müssen wir das schon sehr lange tun, aber wahrscheinlich tun wir es nicht lang genug, uns mit anderen Dingen beschäftigen in der IT. Und das hast du angedeutet mit den Folgen über die Green IT mit Daniel und Daphne, dass wir uns auch so ein bisschen um Energieeffizienz unterhalten müssen. Und da hatte ich gesagt: Ja, Ruby und Python sind jetzt vielleicht skalierbar genug, aber vielleicht sollte man sich auch mal über deren Energieeffizienz unterhalten und schauen, wie es überhaupt mit den Programmiersprachen aussieht, ist das ein Thema für Green IT? Wie effizient sind die und welchen Einfluss können die haben? Müsste man sich vielleicht Gedanken darüber machen, dass man vielleicht nicht alles in Python und Ruby macht, auch wenn es geht, weil wir mit Alternativen vielleicht deutlich weniger Energie verbrauchen können. Das soll das Thema sein.

Lucas Genau, und ich glaube, wir sollten vorher auch noch mal klarstellen, wir reden hier vor allem über den Stromverbrauch, ganz zentral, weil das für uns so einen Proxywert für den CO2 Ausstoß ist. Klar, da gibt es auch noch andere Dinge, die CO2 ausstoßen, aber uns geht es ja vor allem darum, all die Systeme, die wir haben, verbrauchen Energie. Dafür muss Energie zur Verfügung gestellt werden. Die ist aktuell nicht vollständig grün und auch eher zum kleinen Teil grün. Und umso mehr Energie wir brauchen, umso mehr Windkraft und Wasserkraft usw. brauchen wir auch und irgendwo müssen wir uns da einfach einschränken. Das heißt also, Energie zu sparen ist ein Thema für Nachhaltigkeit. Und das heißt, wir diskutieren das so ein bisschen aus dieser Sicht. Wir konzentrieren uns da auf den Stromverbrauch, weil das einfacher zu messen ist als der CO2 Ausstoß direkt. Das ist der eine Caveat, über die wir sprechen und der andere ist, wir sind halt beide Webentwickler und das ist unser Fokus. Das heißt, wir sprechen vor allem über Webanwendungen. Aber einige Dinge, über die wir sprechen, sind auch für andere Arten von Anwendungen durchaus anwendbar. Aber das ist einfach so unser Fokus, oder?

Christoph Absolut. Wenn wir über die Programmiersprachen und deren Effizienz sprechen, dann bleibt das für alle gleich, wo wir die anwenden, alle Anwendungsszenarien. Allerdings sind die Kontexte halt anders und dann kann man sehen, okay, wie ist zum Beispiel dann der Verbrauch anteilig, der wird sich unterscheiden von dem, der irgendwie im embedded System eine Anwendung macht, als wie wir beide, die vielleicht eine Webanwendungen machen. Trotzdem kann das auch für diejenigen Personen, die im anderen Kontext unterwegs sind, ja auch eine wichtige Information sein und ein Entscheidungskriterium, wie sieht es denn mit der Effizienz aus? Die Einordnung davon, die müssen dann die Leute dann halt selber machen, wenn ihr in anderen Kontexten seid. Das können wir beide nur für das Web machen.

Lucas Genau, und manchmal ist es ja tatsächlich auch so, dass es eine Diskussion darüber gibt, implementiert man etwas als eine Webanwendungen oder als eine Desktop-Anwendung? Da kommt mittlerweile in meiner Beobachtung fast immer Webanwendungen bei raus. Aber das ist ja nicht zwangsläufig so, man könnte Dinge ja durchaus auch als eine Swift MacOS Anwendungen schreiben oder so, also das ist ja auch eine Option. Darüber sprechen wir dann später auch.

Christoph Absolut.

Lucas Und einfach, um das noch mal einzuordnen, weil das glaube ich ja vielen auch nicht so klar ist, wo wird da eigentlich Strom verbraucht? Bevor wir dann jetzt auf die Programmiersprache eingehen, einfach noch mal, um den Kontext ein bisschen zu sehen. Wenn wir jetzt also eine Webanwendungen bauen, gibt es ja verschiedene Teile, die Strom verbrauchen. Einmal haben wir den Client, der auf unsere Webanwendungen zugreift, dann haben wir den Server und dazwischen ist aber auch noch jede Menge Leitung. Und eine Sache, die ich auf jeden Fall immer wieder beobachte, ist, dass die Leitung unterschätzt wird, weil die so unsichtbar ist. Also man denkt einfach, Client und Server sind miteinander verbunden, jetzt ist alles gut, aber die Leitung verbraucht signifikant Strom, weil das ist nicht einfach eine Leitung, sondern sehr viele verschiedene Geräte, die Daten hin und her schieben und Router und Switches und was auch immer, die alle Energie verbrauchen. Das heißt also, wir sollten uns immer darüber bewusst sein, dass alles, was wir an Traffic verursachen, auch massiv Energie verbraucht. Und wir sollten uns natürlich auch darüber bewusst sein, dass sowohl Client als auch Server Energie verbrauchen. Das heißt, auch wenn wir zum Beispiel uns entscheiden, bestimmte Prozesse auf den Client auszulagern, dann sind die vielleicht nicht mehr auf unserer Stromrechnung als die Person, die die Webanwendungen schreibt, aber der Client verbraucht die Energie ja trotzdem. Also das hat sich nicht geändert. Das heißt also, das müssen wir auch im Hinterkopf behalten. Wenn wir jetzt ein bisschen den Fokus auf Server setzen, so ein klassischer Server, wo verbraucht der seine Energie? Der Hauptteil der Energie wird von der CPU, dem Motherboard und der Grafikkarte verbraucht. Früher war es so, dass die CPU am meisten verbraucht hat. Mittlerweile, je nachdem was man für eine Grafikkarte hat, ist das nicht mehr so, sondern die Grafikkarte verbraucht mehr Strom, weil die bei den CPUs so ein bisschen der Trend hin geht zu dieser Aufteilung in Performance und Efficiency Cores. Das heißt, wir haben zwei verschiedene Arten von Kernen in unseren Geräten. Die einen sind dafür da, wenn wir jetzt super viel Performance brauchen und die anderen sind wesentlich runter getaktet, brauchen weniger Strom und haben halt weniger Performance, aber sind für die meisten Aufgaben ausreichend. Und dadurch sehen wir so ein bisschen den Trend, dass moderne Computer, egal ob Server, Smartphones oder was auch immer, weniger Energie verbrauchen in der CPU und bei der GPU ist dieser Trend noch gar nicht zu sehen. Also da können wir das nicht sehen. Die verbrauchen eher mehr Energie und dasselbe gilt für irgendwelche ML Co-Prozessoren, die relativ hohen Stromverbrauch haben. Wir haben in den Shownotes eine Seite, die das so ein bisschen aufschlüsselt für so einen typischen Desktop Computer. Interessant dabei ist auch, dass der RAM und die SSD verbrauchen sehr wenig Strom, also ein Bruchteil von dem, was CPU, Motherboard und Grafikkarte verbrauchen. Das heißt, aus dieser Perspektive kann man das fast vernachlässigen. Und wichtig ist auch, ob ich jetzt ein acht Gigabyte RAM Riegel habe oder ein 32 GB RAM Riegel, ist vom Stromverbrauch fast irrelevant. Das ist kaum messbar, was da der Unterschied ist. Das heißt, da aus diesem Aspekt her ist der RAM-Verbrauch nicht so entscheidend im Gegensatz zu dem CPU-Verbrauch. Wichtig dabei festzuhalten ist auch, dass CPUs auch in Ruhe Strom verbrauchen und zwar relativ signifikant. Ungefähr 40 % von ihrem Maximum verbrauchen sie schon in Ruhe die meisten CPUs. Das ändert sich jetzt langsam auch durch diese Efficiency Cores. Da müsste man dann halt noch mal schauen, wie jetzt da die Zahlen sind, aber null ist es auf jeden Fall nicht. Das kann man glaube ich festhalten. Genau, das einfach mal so als Einordnung, das heißt wenn wir unsere Computer betrachten, da geht es, wenn wir über den Stromverbrauch sprechen, viel um die CPU und GPU-Zyklen, die wir verbrauchen, um zu schauen, wie viel braucht unsere Anwendung an Strom. Beim Smartphone ist es dann noch mal ein bisschen anders, da ist es auch das Display, aber wie Christoph in der Vorbesprechung schon sagte, wenn man bei dem Computer den großen Bildschirm, den man hat, mit 85 Zoll noch dazu rechnet, dann ist das da wahrscheinlich ähnlich, weil diese Hintergrundbeleuchtung, die verbraucht signifikant Strom. Beim Smartphone ist die der mit Abstand größte Verbraucher im Smartphone selbst unter Last, gefolgt von WiFi und Modem. Also so ein 3G, 4G, 5G Modem verbraucht noch mal wesentlich mehr als ein WiFi Chip. Aber auch der Wifi Chip verbraucht mehr als die GPU oder CPU. Das mal als Einordnung, wo wir Strom verbrauchen.

Christoph Wichtig als Kontext dazu ist vielleicht, wo wir jetzt gesagt haben, wir machen Webanwendungen, wir schauen jetzt mal, Webanwendungen schreibt man ja typischerweise auch relativ viel auf dem Server auch wenn sie sich mit so einer SPA so verhält, dass man ja einige Teile auch manchmal sogar größere Teile auf den Client verschiebt. Aber dass da zum Beispiel einer der Hauptfaktoren, den Lucas jetzt gerade genannt hat, also die GPU auch eher weniger eine Rolle spielt, also auf den meisten Servern hat man noch, müssen wir jetzt mal sehen, wie sich das mit dem ganzen KI Zeugs so entwickelt, eigentlich wenig Grafik, also wenig GPUs drin, zwar hat man irgendwie einen Grafikkarten Ausgang um vielleicht einen Monitor anzuschließen, um was zu sehen, wenn man nicht so auf die Konsole kommt, aber da ist dann irgendwie so ein embedded Chip, der sowieso vielleicht in dem Intel Prozessor steckt oder in dem ARM Core. Da haben wir relativ wenig. Klar, für die ganze KI-Anwendung braucht man diese Beschleuniger, bekommt man jetzt auch immer in der Cloud, kann man auch extra klicken, kostet auch nochmal extra viel Geld. Aber jetzt so für die normale Webanwendungen haben wir das eher nicht und auch nicht unbedingt auf dem Client. Klar, es gibt Webanwendungen, die irgendwie 3D Visualisierung machen, die verbrauchen das wahrscheinlich auch. Aber wenn wir jetzt so von einer Enterprise Anwendung ausgehen, die ein paar Daten so hin und herschiebt, so typische CRUD-Anwendung, und ich glaube, das ist immer noch ein Großteil der Webanwendungen, die es so gibt, da ist das eher weniger so der Fall, dass die GPU da wirklich dominant ist, sondern das ist dann Netzwerk, wie du gesagt hast und der unsichtbare Teil. Klar, und ihr müsst das für euch, wenn ihr das hört und sagt: Ja, wir machen jetzt aber hier Machine Learning die ganze Zeit, natürlich entsprechend auch einordnen, dann müsstet ihr viel mehr auf die GPUs achten, als wir das jetzt vielleicht innerhalb dieses Podcasts machen.

Lucas Absolut, genau. Klar, das sind jetzt Dinge, das hast du schon angedeutet wie Machine Learning, die das eventuell verändern. Da kommen ja auch zum Beispiel Browser APIs dazu, die das ermöglichen, auf die GPU zuzugreifen wie WebGPU. Das könnte tatsächlich das ein bisschen verändern, aber ich stimme dir in deiner Einschätzung zu, dass es wahrscheinlich eher ein kleiner Prozentsatz der Webanwendungen, die das benötigen. Die meisten zeigen Text, Tabellen, Bilder usw. an und nicht so viele GPU, Canvas oder ML-Dinge im Browser. Aber ob sich das auf dem Server ändert, das steht da glaube ich noch ein bisschen offen, wie viele Leute jetzt da irgendein Machine Learning Modell auf dem Server laufen lassen werden, kann ich jetzt nicht einschätzen. Ich glaube, die Use Cases sind beschränkt, aber das ist dann nochmal ein anderes Thema für eine andere Folge.

Christoph Das ist immer der Unterschied zwischen dem, was wir alle gerne mal machen wollen, was technisch interessant ist und was wir wirklich tun. Alle wollen in Rust programmierte Machine Learning Modelle machen, also neue Programmiersprache und neue interessante Sachen wie KI. Und in Wirklichkeit verschieben wir Versicherungsdaten in Tabellen.

Lucas Exakt. Also wir können festhalten, zumindest zum aktuellen Zeitpunkt ist es so, wenn wir über den Energieverbrauch unserer Webanwendungen sprechen auf dem Server, dann sprechen wir vor allem über CPU-Zyklen und auch auf dem Client ist es hauptsächlich das. Klar, CSS läuft jetzt mittlerweile auch viel auf der GPU, aber da auch vor allem auf CPU-Zyklen. Das heißt, wir können uns jetzt noch mal Programmiersprache anschauen, wie viel CPU verbrauchen wir denn so und was verbraucht das denn an Strom? Was hast du dazu rausgefunden, Christoph?

Christoph Also selber habe ich dazu gar nicht so viel rausgefunden, sondern ich habe recherchiert und rausgesucht, was es dazu gibt. Und ein Paper, das hatte ich auch noch so im Hinterkopf, das ging mal so vor ein paar Jahren durch die IT-Medien oder durch die Blogs, die ich lese, ob das durch die Medien ging, weiß ich gar nicht, das ist von Forschern aus Portugal, das heißt Energy Efficiency Across Programming Languages, das ist von 2017. Das Verlinken wir auch in den Shownotes. Und da hat man sich verschiedene Programmiersprachen angeschaut, eine ganze Reihe, die man dann auch noch nach verschiedenen Kriterien unterteilt hat, einmal sind es kompilierte Programmiersprachen, die kompilieren zu nativem Code oder interpretierte Programmiersprachen, wie Python und Ruby, die wir im anderen Podcast besprochen haben, und dann auch noch das Paradigma, also imperative Programmiersprachen, objektorientiert, funktional. Dann gibt es noch ein Paradigma, das heißt das Scripting. Das ist ein bisschen verschwommen, weil Programmiersprachen könnten in der Kategorie Scripting Language eingeordnet sein, aber auch in funktional, imperativ oder Objekt orientiert. Ja, ist vielleicht auch gar nicht ganz so wichtig auf jedes Detail und jede Definition kann man da nicht immer mit einverstanden sein. Wichtig sind die Ergebnisse, die dann später geclustert rauskommen und die dann deutlichen Trend zeigen. Und um diese Programmiersprachen ging es. Und wie hat man denn dann versucht, das zu messen? Das hat man dann auf einem standardisierten PC gemacht mit einer Intel CPU, mit einem Intel Programm, was den Energieverbrauch messen kann. Deshalb auf dieser standardisierten Intel CPU und hat dann die Aufgaben aus dem Great Computer Language Shoot Out oder heutzutage heißt das anders, das ist das Computer Benchmark Language Game oder so, das verlinken wir dann auch noch in den Shownotes, ist aber auch in dem Paper selber verlinkt. Die Aufgaben daraus sind hauptsächlich algorithmische Probleme, hat man genommen und dann gemessen, wie die Performance war, also die Laufzeit, wie lange hat das gedauert, das jeweilige Problem zu lösen? Dann wie viel Speicher wurde verbraucht? Und wie viel Energie wurde verbraucht? Und dann versucht der natürlich die Korrelation herzustellen. Die These ist, die auch relativ einleuchtend ist, dass desto performanter das Programm ist, desto weniger Laufzeit, desto weniger Energie wird verbraucht. Das korreliert auch sehr stark. Es gibt da ein paar Ausreißer, wo manchmal Programme doch energieeffizienter sind, obwohl sie langsamer sind. Das kann ganz unterschiedliche Ursachen haben, zum Beispiel das Ausnutzen von irgendwelcher Spezial Hardware oder überhaupt von Teilen der CPU, die vielleicht nicht so Energie lastig sind, aber dann länger brauchen und so, aber insgesamt ist die Korrelation sehr stark und genauso zu der Korrelation, wie viel Speicher verbrauche ich denn und wie viel Energie verbrauche ich? Und da hat sich eins ergeben, also zwei, werden das jetzt mal grob zusammenfassen, jeder kann das Paper nochmal nachlesen, um jedes Detail zu wissen. Also der Energieverbrauch korreliert sehr stark mit der Performance und der Speicherverbrauch korreliert zwar auch mit dem Energieverbrauch, aber in der Gesamtschau ist die CPU-Performance circa 90 % verantwortlich, gibt auch kleine Schwankungen je nach dem Benchmark und der Sprache, und der Speicher verbraucht nur so 10 %. Deshalb ist leider einer meiner Lieblings Programmiersprachen Go, der Platz zwei bei der Speichereffizienz hat, insgesamt nicht ganz so gut, aber naja gut, das ist was anderes die persönlichen Präferenzen. Das hat sich dann ergeben. So und das, was sich auch ergeben hat und was wir jetzt auch ein bisschen besprechen wollen mit der Eingangsfrage, ist Python und Ruby da noch zeitgemäß für Green IT sozusagen, dass die interpretierten Programmiersprachen gegenüber den kompilierten Programmiersprachen einen Unterschied um Faktor 50 haben, schwankt auch immer, je nach Benchmark, aber dass das schon extrem hoch ist, 50 ist ja schon mal eine Hausnummer dafür. Und ganz vorne waren dann C, Rust, Ada, C++ und Java. Ich glaube, C++ ist 3. und dann kommt Ada und dann kommt Java. Was interessant ist, weil Java man nicht 100 % einordnen kann in Sachen, ist das jetzt kompiliert oder interpretiert? Weil es einen Just-in-time-Compiler hat, wird da jetzt nicht näher darauf eingegangen, aber ist schon relativ weit vorne dabei. Genau, das wird da besprochen und das Paper hat relativ viel Kritik auch bekommen, weil diese Benchmarks, die die benutzen jetzt vielleicht nicht so den Workload darstellt, den wir zum Beispiel haben. Für unsere Webanwendungen machen wir da nicht das n-Body Problem lösen, sondern die Tabellensortierung. Was ein bisschen anders ist. Und jetzt, 2021, kam von denselben Forschenden ein neues Paper heraus, das heißt Ranking Programming Languages by Energy Efficiency. Und da machen sie eigentlich eine Wiederholung des Tests, den sie in dem ersten Paper gemacht haben. Aber sie machen noch ein bisschen mehr. Sie gehen einmal nicht nur auf den Peak Memory Verbrauch, sondern über den gesamten Memory Verbrauch über den Benchmark aus. Also da wird noch ein bisschen differenzierter, wobei sich da wenig Veränderung im Ergebnis ergibt, dass das nur 10 % des gesamten Energieverbrauchs beiträgt. Es ergibt sich auch, dass der Peak Memory Verbrauch nicht 100 % ausschlaggebend ist, sondern der Gesamtspeicherverbrauch auch eine Rolle spielt. Aber wie gesagt, insgesamt spielt Speicher nicht ganz so eine große Rolle. Und was ich aber viel interessanter finde, sie haben nicht nur die alten Benchmarks benutzt, sondern jetzt auch neue Sachen benutzt aus dem Rosetta Code Repository. Da drin befinden sich zu verschiedenen Programmierproblemen Lösungen in verschiedenen Programmiersprachen und oft auch für eine Programmiersprache mehrere Lösungen, indem man das verschieden angeht. Also ich kann mir ja für viele Probleme x Lösungen ausdenken, die verschiedene trade-offs haben, die idiomatisch sind oder nicht. Und das haben sie dann auch noch mal damit gemacht und die entsprechenden Messungen für Energie, Performance und Speicherverbrauch gemacht. Und da ergibt sich aber dasselbe Bild. Also es liegt nicht daran, dass sie vorher die falschen Benchmarks hatten. Das gilt auch für jetzt, für die neuen Aufgaben, die deutlich näher an dem dran sind, was man so vielleicht aus seinem Alltag kennt. Und die Ergebnisse bestätigen sich halt und die Reihenfolge hat sich auch nicht wirklich groß geändert. Klar, es gibt so Verschiebungen von Programmiersprachen, vielleicht so um ein, zwei Plätze in der Reihenfolge, aber trotzdem stehen wieder C, Rust, C++, Ada und Java vorne und hinten stehen halt Ruby und Python so auf den letzten Plätzen noch mit Perl und Lua also so reinen Scripting Languages.

Lucas Aber auch so Sprachen wie Erlang zum Beispiel.

Christoph Erlang ist auch sehr weit hinten, ist auch ganz schlecht, auch im Speicherverbrauch noch extra schlecht. Und dann kann man sich jetzt halt überlegen, hat das eine Auswirkung auf unseren Arbeitsalltag? Vielleicht sollten wir, wenn wir jetzt weggehen von der Skalierung das nächste GitHub vielleicht dann doch nicht darin schreiben, weil’s geht, sondern vielleicht, weil wir doch irgendwie so was wie Green IT machen wollen. Energie sparen, Umwelt schonen, ob man sich doch nicht überlegen könnte, ich nehme jetzt eine andere Programmiersprache. Da muss man halt sehen, welche das ist. Und das ist ja auch nicht ohne Trade-offs. Also jetzt nur zu sagen: Ja, jetzt nehmen wir die und verbrauchen weniger Energie, heißt ja nicht, dass ich nicht die ganzen anderen Umstände, die ich habe, da nicht auch ändern können. Sollen wir mal schauen, welche Faktoren eine Rolle spielen bei der Wahl?

Lucas Zwei Dinge, die ich dazu festhalten würde: Das eine ist, was ich auf jeden Fall interessant finde, aus der Ruby Welt war ja eine der Sprachen wo viele Leute irgendwie hin wollten ist irgendwie Elixir, was ja quasi Erlang ist und auch zu JavaScript/Node sind ja relativ viele gewechselt. Und wenn man jetzt auf dieses Ranking allein schaut, ändert das an der Gleichung gar nichts, weil all diese Sprachen sind in dem alleruntersten Segment. Das heißt, ob ich jetzt Erlang mache Ruby, Node, Python ist nicht relevant, weil die sind alle eher in dem letzten Drittel der energieeffizienten Sprachen in dieser Messung. Aber gleichzeitig müssen wir, glaube ich, auch festhalten, dass diese Betrachtung sehr stark auf CPU intensive Tasks schaut. Also auf algorithmische Aufgaben. Und wie wir ja auch schon gesagt haben, bei Webanwendungen ist das nicht unbedingt das, was wir da beobachten. Ich glaube, wenn man dieselbe Betrachtung jetzt gemacht hätte mit einer Aufgabe, die sehr IO intensiv wäre, da würde ein Node.js vermutlich nicht im letzten Drittel sitzen. Das kann ich mir nur schwer vorstellen aus meiner praktischen Erfahrung. Ich habe natürlich jetzt keine wissenschaftliche Arbeit geschrieben, aber so aus meiner praktischen Betrachtung kann ich mir das schwer vorstellen, weil das doch oft Anwendungen sind, die sehr viele Clients mit sehr wenig CPU Ressourcen abhandeln können. Ich glaube, das sollte man auf jeden Fall schon mal so ein bisschen einordnen in diesem Paper. Wie siehst du das?

Christoph Da hast du recht und das ist jetzt nicht nur dein Bauchgefühl. Dazu gibt es ja auch schon Leute, die Benchmarks gemacht haben, wie viele Clients kann ich denn abhandeln? Und da war Node immer ganz gut, im Gegensatz zu vielen anderen Programmiersprachen auch gegenüber Java, was ja jetzt in diesen Papers deutlich weiter oben steht. Bei Node liegt es daran, weil dieses Non Blocking IO Paradigma und so eine Event Loop für dieses Szenario deutlich besser geeignet ist halt sozusagen die einzige Möglichkeit war, das zu machen. Du musst es nach diesem Paradigma programmieren, während fast alle anderen das halt umgekehrt, also so ein Blocking IO mit Kontext- Wechsel und pro Client ein Thread, der gewissen Overhead hat, das Umschalten Overhead und das verbraucht dann halt auch Energie. Dass das so gegeben war, das würde ich nicht bestreiten, wie gesagt, dazu gibt es auch Benchmarks, wie viele Clients kann ich denn damit abhandeln? Hat sich jetzt so ein bisschen geändert, denn Non Blocking IO steht nun fast in jeder Runtime zur Verfügung. Das ist jetzt nicht ein Feature der Sprache, sondern der Runtime von Node und von JavaScript im Browser auch Event basiert mit einer Event Loop, aber es steht jetzt auch anderen Programmiersprachen zur Verfügung. Python gibt es auch welche, die auf dieser libuv basieren, das auch Basis der Node Runtime ist und mit dem man ähnliche Ergebnisse erzielen kann. In Java gibt es noch Non Blocking IO und es gibt auch einige Server, die das auch nutzen. Erlang hat sowieso Non Blocking gehabt, die konnten auch mal sehr viele Clients bedienen. WhatsApp war ja auch ursprünglich mal in Erlang und hat man mit fünf Maschinen Millionen Leute oder so bedient, ich weiß die Zahl nicht genau, aber die findet man im Netz und das war sehr beeindruckend. Problem dabei ist, das war sozusagen nicht der natürliche Weg, das muss ich sozusagen erst mal einschalten, irgendwie diese Lib einbinden, auf das Programmier Modell ändern. Vorher war es immer ein anderes, deshalb wird das bei anderen Sprachen nicht so oft benutzt. Die Möglichkeit steht offen. Von daher ja, da hast du recht, das ist auch ein Teil, den wir betrachten müssen. Wie gesagt, das kommt jetzt auch auf unseren Kontext an, im Web ist das ein wichtiger Kontext, wie viele Clients muss ich bedienen? Wenn das im Embedded Gerät egal ist, weil da läuft ein Prozess und gut ist, aber sollte man nicht außer Acht lassen. Aber was ich interessant fand, hast du gesagt, die Leute haben gewechselt. Worauf haben sie gewechselt auf Elixir und auf Node. Und jetzt wechseln sie von JavaScript auf Typescript und manche Leute wechseln auf Rust. Aber ich habe noch nie, das ist jetzt natürlich auch wieder anekdotisches Wissen, aber wenn man sich mit Leuten unterhält, die so ein Wechsel hinter sich haben oder man ein Blogpost liest, die so ein Wechsel hinter sich haben, noch nie den Faktor, der den Ausschlag gegeben hat, ich will jetzt sauberer programmieren, ich will weniger Energie verbrauchen. Das habe ich noch nicht als Motivation gelesen, muss ich ehrlich gesagt gestehen. Das war nie die Motivation, dass man sagt: Wir können damit Energie sparen, wie geil ist das denn? Sondern ja, es ist halt viel besser, wir haben jetzt ein Typsystem. Erst hat man zehn Jahre gesagt, Typsystem ist total bescheuert, will ich nicht haben, und dann boah, wer hat das beste Typsystem der Welt? Eine ganz andere Motivation. Das finde ich halt bemerkenswert.

Lucas Das hatten wir auch schon mal besprochen, es gibt ja diese alte Weisheit, dass CPU-Kosten kleiner als Entwicklungskosten sind. Das heißt also, wenn etwas schneller entwickelt werden kann, dann ist es besser auch wenn es dann mehr CPU verbraucht. Wenn ich da doppelt so viel CPU-Ressourcen brauche, ist immer noch günstiger als einen weiteren Entwickler, Entwicklerin einzustellen. Und das spielt da ja auch so ein bisschen rein. Ich glaube bei Node war für viele schon die Motivation, also bestimmt nicht das Typsystem, wenn sie von Ruby zu JavaScript gewechselt haben, hat sich das definitiv nicht verbessert, ist bestimmt nicht der ausschlaggebende Faktor gewesen, sondern da war es tatsächlich, glaube ich, schon eine Überlegung ich brauche weniger Server Ressourcen für eine höhere Anzahl von Clients. Ich glaube, das war für viele die Motivation. Und ich vermute, dass das bei Elixir ähnlich ist, obwohl es da auch Leute gibt, die das glaube ich ästhetisch oder wie auch immer schöner finden als Ruby. Aber ich glaube auch da war es oftmals die Überlegung, man möchte gerne weniger Geld für Server ausgeben. Ich gebe dir total recht, dass die meisten dabei nicht sagen, wie viel Strom es verbraucht, aber es geht da glaube ich eher um diese Kosten Sparmaßnahme, dass man weniger Server Ressourcen braucht.

Christoph Da hast du vollkommen recht und dass man dadurch wahrscheinlich die Umwelt weniger belastet, weil man weniger Energie verbraucht, wenn ich nur noch halb so viele Server benötige für dieselbe Anzahl von Clients, dann ist das offensichtlich. Aber du hast das Richtige genannt. Es ist eigentlich ein Kostenargument gewesen und die Energiekosten sind auch nicht immer unbedingt transparent, wie viel Anteil man jetzt eigentlich für die Energie bezahlt. Das ist auch alles super schwierig zu messen. Darüber habt ihr auch schon in einer anderen Folge gesprochen. Da hast du recht und vielleicht ist das auch der Anreiz zu sagen: Ja, durch steigende Energiekosten werden wahrscheinlich auch Serverkosten höher. In letzter Zeit gab es ja bei verschiedenen Cloud Anbietern auch Preiserhöhungen, wo unter anderem ja auch gesagt wurde, so, Energiekrise und Energie wird teurer. Wäre ein Grund dafür. Nicht nur das, es gab auch andere Gründe, Lieferketten Probleme, insgesamt werden Server teurer und Inflation. Ja, das ist wahrscheinlich so, aber ich finde es auch okay, in meinem Umfeld ist jetzt das Entscheidungskriterium nicht, wir machen moralinsauer alles so super grün, sondern wir sind einfach effizient, weil es uns weniger Geld kostet. Und wenn damit die Umwelt geschont wird, finde ich das auch okay. Ich finde das ist ja dann auch so, solche Mechanismen sollen genutzt werden, indem man ja sagt, dass CO2 auch mehr Geld kostet mit den Zertifikathandel. Das heißt, es wird wahrscheinlich auch so sein, dass die Preise da auch noch steigen werden. Und da werden auch die Cloud Anbieter wahrscheinlich auch mit zu kämpfen haben, auch wenn sie versuchen irgendwie aus regenerativen Energien, mit Solar Dächern ihr Rechenzentrum zu betreiben. Aber die müssen auch CPUs, also Hardware einkaufen, da steckt auch CO2 drin, das wird sich bemerkbar machen. Ich finde natürlich auch super, wenn einer sagt: Ja, weil ich gerne Green IT machen würde, nehme ich jetzt Go.

Lucas Ja, vor allem den zweiten Teil. Ich glaube, dass das wirklich einer der Bereiche ist, wo eben das wirtschaftliche Interesse und der Umwelt Aspekt dieselbe Richtung eindrücken. Weil weniger für Cloud zu bezahlen ist etwas, was viele Leute wollen. Weil die Cloud Rechnungen sind ja doch relativ umfangreich. Interessant dabei finde ich, dass wir auf unserer Rechnung nie irgendwelchen Stromverbrauch sehen. Wir bezahlen meistens für CPUs bzw. vCPUs, wir bezahlen oft auch noch für RAM von den Maschinen, die wir da nehmen und vielleicht auch wenn wir noch eine GPU dran stecken, dann bezahlen wir auch noch mal paar Goldbarren zusätzlich. Aber ob man die CPU auslastet oder nicht, was ja den Stromverbrauch beeinflusst, spielt keine Rolle in der Abrechnung. Das heißt, das ist so ein bisschen indirekt. Wenn der Cloud Anbieter merkt, okay, die Stromkosten unseres Rechenzentrums steigen, dann müssen wir das jetzt auf die Kunden umlegen, dann bekommen wir es indirekt dadurch mit. Zumindest kenne ich jetzt keine Cloud, wo man irgendwie pro Strom bezahlt.

Christoph So direkt den Strom nicht, also wenn dann so nach CPU-Zeit, die verbraucht wird bezahlt und so ein flexibles Modell hat, und sagt, es wird mehr CPUs provisioniert, da merkt man das schon. Also wenn man effizienter ist, dass man Kosten spart und Energie gespart wurde in irgendeiner Form, aber direkt ausweisen kann einem das keiner. Das ist halt Allgemein das Problem in Sachen Green IT, viele Sachen sind halt super schwer zu messen. Aber das soll für mich nicht heißen, dass man nicht sagen kann man tut da nichts. Wir haben im Vorgespräch ein bisschen darüber diskutiert. Du hast es in der Einleitung genannt oder angerissen, was verbraucht überhaupt Energie? Mein Bildschirm verbraucht Energie und das ganze Netzwerk verbraucht Energie und da nützt die Wahl der Programmiersprache nicht so viel, sondern beim Netzwerk nützt vielleicht halt was, wenn wir weniger darüber schicken, wenn wir gut komprimieren oder wenn wir insgesamt Daten sparsam vorgehen, das ist schon klar, aber für mich ist die Sache die, dass man halt was tun kann. Die Wahl der Programmiersprache ist eine Entscheidung, die ich jetzt in meiner Rolle und die du auch in deiner Rolle hast, wenn wir Software entwickeln halt auch in der Hand haben, auch nicht immer. Manchmal gibt der Kunde es vor oder man kommt an einem Projekt dran, was Legacy ist, das halt schon da, dann kann ich auch nicht immer sagen, ich schreibe das mal so um, weil wir sind nicht Energie effizient. Aber im Allgemeinen ist das eine Entscheidung, die man besser in der Hand hat als wie viel Energie wird denn jetzt im Netzwerk verbraucht oder wie viele Bildschirme sind jetzt irgendwo angeschlossen und so was. Und auch wenn es vielleicht nur einen kleineren Teil ist, man hat da eine Wirksamkeit dabei und es muss auch gar nicht so viel kosten. Wenn man dann sagt, wir fangen ein neues Projekt an und wir haben die Wahl zwischen drei Programmiersprachen, weil das können die Leute, es gibt immer externe Faktoren, das können die Leute. Und da gibt es verschiedene trade-offs und dann kann man sagen, okay, der Energieverbrauch ist auch ein trade-off, den wir jetzt betrachten wollen dabei, und nicht nur das Gehalt des Programmierers wiegt halt den Verbrauch auf, sondern vielleicht sagen, das wissen wir gar nicht, vielleicht steigen die Cloud Kosten ja auch jetzt durch Zertifikatehandel auf Dauer. Da können wir auch was machen. Und wenn man das direkt in der Hand hat, finde ich, das ist auch ein wichtiges Thema, weil man kann ja nicht sagen, ja, lassen mal alles weg, sondern überall, wo man handeln kann, sollte man auch versuchen, dann irgendwie zu handeln.

Lucas Definitiv. Da stimme ich dir absolut zu. Ich hatte in der Folge 114 mit Daniel über nachhaltige Architektur im Web gesprochen. Da waren ja auch andere Sachen, wo wir auch direkten Einfluss darauf haben. Machen wir etwas aus dem CDN, machen wir es aus dem Rechenzentrum, wo wir als Entwickler:innen und Architekt:innen auch Einfluss darauf haben. Es gibt mehrere Bereiche, wo wir Einfluss darauf haben. Was für einen Bildschirm die Leute benutzen, ist kein Teil davon. Und wie lange die Software Patches für iOS eingespielt werden, können wir auch nicht beeinflussen. Da haben wir überhaupt gar keinen Einfluss darauf, obwohl die natürlich sehr große Faktoren sind und vermutlich auch in vielerlei Hinsicht größere Faktoren als das, was wir machen. Aber das sollte uns nicht davon freischreiben, das, was wir beeinflussen können, zu beeinflussen. Da bin ich absolut deiner Meinung. Trotzdem müssen wir das so ein bisschen in der Relation sehen. Ich glaube, viele Webanwendungen sind eben… da schreiben wir einen Code, egal ob Ruby oder Python, aber viele Sachen passieren eben nicht in diesem Code, den wir schreiben. Und das sollten wir schon dabei beachten. Und ich glaube, es gibt ja diesen Begriff der Scripting Language, der wird ja heutzutage nicht mehr so oft benutzt, zumindest in meinem Alltag nicht, dass solche Sprachen wie Ruby, Python, Pearl, TCL und so weiter beschreibt, aber die sind oft ja irgendwie Kleber, um Sachen, die es schon gibt. Wenn wir jetzt an Python denken, warum ist Python die Sprache, wo man super viel mit Machine Learning macht? Nicht weil Python dafür die beste Programmiersprache ist, sondern da ist ein Kern drin, der ist in C/C++ geschrieben und wir haben nur Sachen darum geschrieben. Also da ist der Python Code nicht der ausschlaggebende Faktor für den Energieverbrauch, würde ich behaupten. Und da skripten wir eine Engine, die in einer anderen Sprache geschrieben ist. Man könnte durchaus argumentieren, dass das im Web gar nicht so anders ist, dass wir eigentlich Scripts rund um unsere Datenbank stricken. Unsere Datenbank macht sehr viel von der Arbeit, macht super viel von den Sortierungen und wir ziehen das nur da raus und präsentieren es. Das heißt also, man könnte überlegen, ist dann diese Sprache, in der ich diesen kleinen Teil von dem Code, der da passiert, weil so viel Code wie die Postgres Source Code schreiben wir meistens nicht in einem Projekt, ist dieser kleine Teil ein entscheidender Faktor oder nicht? Das ist ja die Frage, oder?

Christoph Absolut. Erst mal auf Scripting Languages, das wird heutzutage nicht mehr so benutzt und wenn, dann auch so ein bisschen despektierlich: „Du programmierst nicht in einer richtigen, sondern in einer Scripting Language“. Aber das war ja gar nicht gemeint. Wir verlinken dazu auch das Original Paper, von dem Osterhout. Ich glaube, der war der erste, der den Begriff da reingebracht hat, ganz genau, weiß ich es nicht, aber der es beschrieben hat in Sachen mit seiner Programmiersprache tcl und C. Die großen Teilen C geschrieben wird und man den Glue Code, wie man seine Anwendung zusammensetzt, dann halt im tcl schreibt. Damals noch nicht unter dem Aspekt der Energieeffizienz, sondern mehr der Programmierer:innen Effizienz, wie schnell die arbeiten können. Und das haben wir heute noch genauso. Und das ist überhaupt nicht verwerflich, das so zu nutzen als Beispiel genannt in dem ganzen Machine Learning Bereich, ja, da würde ich wahrscheinlich nicht von Python abraten, weil da, wo die Energie verbraten wird, in dem ganzen Zeug, wo Modelle ausgewertet werden oder trainiert werden, das ist alles C/C++, Fortran und nicht Python, sondern man schreibt das Interface dazu. Jetzt hier den prompt entgegennehmen, das schreibt man vielleicht in Python, aber das Modell laufen lassen, das macht man natürlich nicht. Und das sollte auch gar nicht so klingen. Auch wenn ich vorhin gesagt habe, wir machen dann alle Go, weil ich da ein kleines Bias in Sachen Go, dass man jetzt Python und Ruby gar nicht mehr benutzen sollte. Du hast das Beispiel genannt der Datenbank. Da muss man halt sehen, welchen trade-off wollen wir denn da haben? Weil keiner will auch eine Architektur haben, wo die ganze Logik in der Datenbank liegt, also wo man dann Stored Procedures nur noch arbeitet, weil das halt eine Wartbarkeit Hölle ist und nicht gut testbar ist, sondern da muss man halt sehen, was kann ich machen? Zum Beispiel sortieren. Das hatten wir im Vorgespräch gesagt, ist eine super Option, die die Datenbank wahrscheinlich viel besser machen kann als wir, wo man vielleicht auch noch Daten sparen kann, indem man sagt, wir wollen nur die Top Ten und liefern nicht 1000 Ergebnisse, sortieren dann und schneiden dann alles unterhalb der Top Ten ab. Da kann man natürlich ganz viel machen und sagen, ja, wir benutzen das trotzdem noch. Was mir dazu einfällt, ist noch, dass man auch immer sehen muss, was in den Papers nicht so ist, da wurde ja nur die Laufzeit betrachtet, aber nehmen wir mal das Beispiel Rust oder C++, die haben ja unglaublich lange Kompilierzeiten, da wird auch Energie verbraten. Und wenn ich jetzt die Homepage für meinen Fußballverein mache, da kann man vielleicht auch Interaktion machen, sich fürs Turnier anmelden oder sonst was. Das ist nicht rein statisch, sondern wir haben da irgendwie eine Django Python Applikation oder eine Rails Applikation, von mir aus, da gilt ja das Gleiche. Aber die wird dann irgendwie im Monat 100-mal abgerufen, also dreimal am Tag im Schnitt. Da könnte ich mir vorstellen, reines Bauchgefühl nie gemessen, dass vielleicht es sich nicht lohnt, das in Rust zu schreiben, weil die Zeiten für die Kompilation und der Energieverbrauch höher ist als die drei Mal, wie das ausgeführt wird. Gerade wenn man viel daran rumspielt. Wir sind ja heutzutage zum Glück nicht mehr so, dass wir sagen, wir machen Deployment alles halbe Jahr, sondern deployen vielleicht jeden Tag und machen hier was bunt und da mal was schön. Und da muss man halt schauen, brauche ich immer so ein full Rust/C++ Bild oder schicke ich dir einfach hier den Quelltext rüber und das wird dann beim nächsten Aufruf einfach neu interpretiert. Und hier kommt ganz viel dazu: Test Ausführung und was weiß ich was. Und auf dem CI-Server habe ich regelmäßige Durchläufe, jede Nacht und wird neu kompiliert. Das kann man nicht so eindimensional sehen, dass man sagt, wir betrachten nur die Laufzeit. Da muss man schon differenzieren. Aber wenn wir jetzt sagen: Ja, für GitHub war schnell genug und auch für Facebook, also für Instagram, die haben wahrscheinlich so viel Abrufe, dass die Laufzeit total dominiert und nicht die Buildzeit. Da muss man das sehen und es geht in dieselbe Richtung, wie du sagtest, mit den Datenbanken oder kann ich jetzt Non Blocking IO machen oder nicht? Da ist halt, was wir am Anfang gesagt haben, die Zuhörenden müssen den Kontext für sich finden, wir wollen kein Verbot von irgendwelchen Scripting languages machen, auch weil sie vielleicht total ineffizient sind, aber dann 3 % meiner Energiekosten einnehmen.

Lucas Ich glaube auch, dass wenn man eben seine Anwendung betrachtet, dass das selten die richtige Lösung ist zu sagen, ich baue die jetzt vollständig in Rust oder so. Da wird das nicht seine Vorteile überall ausspielen können, sondern das sind eben gerade die Pfade, wo wir CPU intensive Tasks haben. Ich kann mir gut vorstellen, dass es viele Webanwendungen gibt, die jetzt vielleicht in Ruby oder Python geschrieben sind, da gibt es ein Ding, das macht eine super komplizierte Berechnung. Vielleicht macht das irgendwie ein Pfad finden auf einer Karte oder es macht ein Ranking. Da hatte ich zum Beispiel ein Kundenprojekt, da war eine wichtige Aufgabe, die Suchergebnisse auf dem ganz komplexen Ranking Systemen zu sortieren, die man auch nicht ohne Weiteres immer alle in der Datenbank abbilden konnte. Und da kann man sich dann eben überlegen, wo sollte dann dieser CPU intensive Code stattfinden? Ein Punkt ist eben die Datenbank. Vielleicht ist es dann wirklich okay daraus dann eine Stored Procedure zu machen, weil das ist einfach das Schnellste, weil sonst müssen wir zu viel Daten zwischen unserer Anwendung unserer Datenbank hin und her schaufeln. Und selbst bei Go wäre das dann vielleicht keine gute Idee, weil wir dann einfach zu viel Traffic erzeugen. Oder gibt es vielleicht einen guten Grund zu sagen: Hey, dieses Ding, das sollte jetzt wirklich in Rust geschrieben sein oder in Go oder was auch immer, weil das eben CPU verbraucht. Aber das Ding, was einfach nur ein bisschen Daten aus der Datenbank rausnimmt, daraus ein schönes HTML baut und an den Client schickt oder JSON, das ist vielleicht nicht der Punkt, wo sich das so sehr lohnt, dass wir da so viel CPU-Zyklen sparen, dadurch, dass wir statt Ruby Rust oder Go benutzen. Ich glaube, das ist schon so und ich glaube, das ist eine ähnliche Argumentation wie zu überlegen, welche Sachen können wir an einen Reverse Proxy auslagern, weil der darin vielleicht besser ist? Ganz blödes Beispiel: Wer liefert mit seinem Ruby Code die CSS-Dateien selber aus? Das sollte vielleicht lieber der nginx oder der Apache machen, weil der kann das sehr gut. Das brauche ich jetzt auch nicht in Rust neu zu schreiben, das macht gar keinen Sinn. Dafür gibt es eben schon existierende Komponenten. Und ich glaube, das ist so ein Modell, mit dem ich mich gut anfreunden kann. Zu sagen: Überleg noch mal, in welchem Bereich ist das entscheidend? Und ich finde, dass es gerade auch wenn man sich für JavaScript, also bei JavaScript gibt es ja eigentlich nur Non Blocking Enviroment auf dem Server, egal ob das jetzt Node, Deno oder Bun ist, das ist ja alles Non Blocking IO und die sind ja besonders schlecht darin, wenn man CPU intensive Aufgaben ausführt, weil das eben immer diesen Single Thread blockt. Das hat eben andere Auswirkungen und dort lohnt es sich umso mehr zu überlegen, hey, gibt es hier nicht komplexe CPU-Aufgaben, die vielleicht nicht in meinem JavaScript oder Typescript Code gelöst werden sollten, sondern in irgendwas was in Web Assembly kompiliert oder vielleicht nativen Rust Code oder was auch immer. Und ich glaube, das ist ein Modell da kommen wir, glaube ich hin, dass das sich lohnt aus der Kosten Perspektive und aus einer Energie Perspektive.

Christoph Da hast du schön beschrieben, was eigentlich die Scripting Language ist. Also wir nehmen vorgefertigte Teile, die Dinge gut machen und hauen die damit zusammen. Wenn du sagst, ein Ranking, das ist sehr intensiv und das hat ja nicht nur den Aspekt, dass so ein Ranking vielleicht energieeffizient sein soll, das soll dem Anwender ja auch schnell angezeigt werden. Der soll ja nicht fünfmal Reload klicken, weil er denkt, da kommt nichts und dann hat er mir zum fünften Mal das Ranking Berechnungen angeschlagen, dass man solche Teile auslagert. Dann bei Ruby und Python Sprachen und bei Node bietet sich auch an, Module dann in einer Sprache zu implementieren, die nativ kompiliert sind und dann einfach eine API bereitstellen. Es geht mit Rust bei Python ganz gut, bei Node geht es mit C und C++ auf jeden Fall sehr gut, ob es mit Rust oder mit Go geht, weiß ich ehrlich gesagt nicht. Bei Ruby, kenne mich auch nicht aus, aber da gibt es auch viele Sachen. Und es gibt ja auch schon einige Dinge, die die mitbringen, die auch schon sowieso in C programmiert sind, wo die auch sich in den Benchmarks super schlagen, zum Beispiel Regex. Die Regex Engine von den ganzen ist nicht beschrieben in in der jeweiligen Scripting Sprache, sondern typischerweise diese pcre2 Engine und die ist halt schnell und bietet halt nur ein Interface, dass ich das von Python aus ansprechen kann. Und da haben sie auch kein Problem, mit der Performance mitzuhalten mit nativ kompilierten, das sollte man auf jeden Fall machen und mitnehmen, dass man das machen kann. Ich sehe nur eine gewisse Schwierigkeit darin, dass man sagt, ja, wir nehmen jetzt Ruby und wir kennen am Anfang des Projekts vielleicht auch gar nicht so die Anforderungen an das, und wenn es dann soweit ist, schreiben wir wirklich eine Erweiterung in Rust. Das ist halt nicht so einfach. Das ist dann schon schwierigerer Task. Da muss ich jemand haben, der Rust kann. Und ich muss diese Schnittstelle zwischen Rust und Ruby hinkriegen. Da gibt es zwar auch Bibliotheken, die einem das erleichtern und wo man so ein Foreign Function Interface zu verschiedenen Programmiersprachen hat, aber das ist nicht so leicht. Und ob man da nicht sich dann doch entscheidet, dann kaufen wir halt mehr CPU Power ein, das weiß ich nicht. Hast du schon mal erlebt das in irgendeiner deiner Projekte jemand eine Erweiterung geschrieben hat für Ruby, weil sie zu lahm war? Für Python habe ich das noch nicht erlebt bei mir.

Lucas Ich auch nicht. Ich habe jetzt nur vermehrt das gesehen, dass Leute Client seitig Web Assembly für bestimmte Teile benutzen, aber nicht in unseren Kunden Projekten. Ich glaube, das dauert noch ein bisschen, aber der Trend dazu, dass bestimmte Sachen nicht in JavaScript geschrieben sind. Also wenn ich jetzt an Anwendung denke, die ich als Benutzer einfach habe, zum Beispiel Figma, die benutzen sehr intensiv Web Assembly für bestimmte Teile und das ist garantiert ein Performance Grund. Ich meine, das ist eine komplexe clientseitige Anwendung, die viele Dinge machen muss und da hat es sich wahrscheinlich sehr früh angeboten, Teile auszulagern. Ich würde jetzt sagen, Web Assembly ist ja sehr nah an dem, was wir jetzt mit Go oder so was beschreiben. Es ist jetzt in diesem Benchmark nicht drin, aber es wird sich ähnlich verhalten, also eher in diesem Bereich als in dem unteren Bereich. Und das sehe ich schon. Und ich glaube, das wird sich auch noch ein bisschen mehr verstärken, dass umso anspruchsvoller von dem Interface her die Webanwendungen im Client sind, umso mehr werden da auch Sachen nicht in JavaScript geschrieben sein. Das glaube ich schon.

Christoph Ja, bei Figma weiß ich es auch. Damit, glaube ich, liegt der Fall aber ein bisschen anders, weil a) der Browser als Client kann JavaScript und kann Web Assembly, aber hat keine andere Runtime. Ich kann dem halt nichts anderes geben, da bin ich dazu gezwungen. Das andere ist, es leicht, Web Assembly zu erstellen dabei. Es ist ein Compilation Target. Auch schwieriger als wenn ich jetzt nur JavaScript oder Typescript machen würde, aber es ist schon einfacher als eine native Erweiterung für so eine Scripting Sprache zu schreiben. Dafür gibt es schon das Tuning, da liegt das, ist anders gelagert, hat aber ähnliche Effekte. Und ob Web Assembly so schnell ist, das müssen wir mal schauen. Dazu müssen wir mal eine Folge machen über Web Assembly. Wir schreiben C++ und führen es dann aus, aber in der Hälfte der Geschwindigkeit, die wir vorher hatten, weil wir es auf Web Assembly kompiliert haben, ist das so gut oder nicht? Ganz anderes Thema. Wie gesagt, da würde ich nicht ganz so mitgehen, weil das hat ganz andere Gründe, warum die Erweiterungen dann da gemacht werden, ganz anderer Rahmenbedingung. Aber eins würde ich gerne aufgreifen. Ich glaube, desto leichter wir den Leuten das machen, so was zu tun, ganz verallgemeinert, desto leichter wir den das machen, effizient und damit ressourcenschonender zu programmieren, desto eher machen die das. Bei Web Assembly ist das Tooling da, da geht das. Ich sehe jetzt das andere: High Performance Anwendungen waren immer C++ und auch wenn C auf Platz eins im Paper steht und C++ auf Platz drei, würde ich die natürlich auf keinen Fall empfehlen wegen der fehlenden Memory Safety und den ganzen Bugs, die daraus resultieren und Sicherheitslücken. Da müssen wir dann halt trotzdem sozusagen mehr Energie verbrauchen, um da sicher zu sein. Ich spare beim Auto auch nicht beim Airbag, weil es dann leichter wird und ich dann weniger Spritverbrauch oder weniger Akku, wenn ich ein E-Auto habe. Das macht man halt nicht. C und C++ sind für mich raus. Aber mit dem Aufkommen von Rust hat man zum Beispiel den Leuten es leichter gemacht, so richtig Performance kritische Sachen zu machen, die Low Level Access brauchen auch in der Programmiersprache zu schreiben, die Memory Safe ist, jedenfalls by default. Ich kann da ausbrechen und das muss ich auch manchmal, wenn ich sehr tief in die Hardware gehe. Aber generell ist es erst mal Memory Safe, während es C und C++ halt nicht sind. Und das muss man den leichter machen. Jetzt nutzen Leute Rust dafür für so was. Das hat dann unheimlichen Aufwand und so muss man das auch bei allen machen. Wir müssen diese Entscheidung in den Programmiersprachen leicht machen, dass man das Effiziente nutzen kann. Und ich sehe bei Erweiterung, eher noch nicht, dass das so leicht ist. Das sehe ich bei so Sachen wie Reverse Proxy. Wir liefern die statischen Assets aus mit dem nginx und nicht mit Rails. Das macht man den Leuten leicht. Das ist eine ganz einfache Sache und so muss man das auch bei den anderen Sachen hinbekommen, um energieeffiziente Programme zu haben, dass das einfach leicht wird.

Lucas Ich sehe das ein bisschen anders. Also ich glaube, das wird schon leichter. Da ist es auf jeden Fall auch interessant, den Kontrast zwischen Rust und Go zu sehen. Ich habe ja eher die Ruby und Node Perspektive. In Ruby und Node ist es viel einfacher jetzt Rust Code zu integrieren als Go Code. Da kenne ich jetzt nicht so Lösungen, wo man einfach den Code reinschreibt und zack können die miteinander kommunizieren und fertig. Das ist aber bei Rust so, also da gibt es eben fertiges Framework oder wie auch immer man das nennen möchte, um diese Kommunikation sicherzustellen, um auch daraus ein Paket zu bauen, in dem beides drin ist usw. Das ist einfach fertig. Die Integration gab es vorher auch mit C und C++. Aber wenn ich jetzt zum Beispiel meine Webanwendungen betrachte und dort gibt es jetzt einen Application Server in Ruby, ein Puma oder ein Thin, bei all denen ist es so, dass der HTTP Parser in C geschrieben ist. Den hat irgendwann mal jemand geschrieben, der wird einfach von Webserver zu Webserver weitergetragen in der Ruby Welt. Und ich persönlich käme nie auf die Idee zu diesem C Teil irgendwie Code beizutragen, weil ich mir nicht zutraue den Memory Safe zu bauen. Ich traue mir das selber nicht zu, obwohl ich natürlich C in der Uni mal gemacht habe, aber wesentlich mehr nicht, würde ich mir das nicht zutrauen. Wenn es aber jetzt Rust Code wäre, dieser Code, der den HTTP Server macht, dann ist die Barriere für mich niedriger als die, wo es in C oder C++ war, weil ich da eben ein höheres Vertrauen drin habe, das bestimmte Fehler mir nicht passieren können. Und ich glaube, dass das schon sich ändert gerade, dass eben solche Sachen, wo es früher wirklich nur war, entweder du bist jetzt C oder C++ Guru oder du kannst halt in diesem Teil nichts beitragen, das ändert sich schon, weil die Barriere von Rust ist nicht so hoch wie die Barriere von C und C++, meiner Meinung nach.

Christoph Absolut. Ich glaube, du hast mir gar nicht widersprochen, sondern das sehe ich auch so alles. Was ich sagen wollte, sollte der einfachste Weg sein, die effizienteste Lösung zu nehmen. Und das ist es noch nicht. Also, wenn ich halt die Programmiersprache wechseln muss, ist schon mal eine Hürde da, ich muss diese Glue Bibliothek zwischen Ruby und Rust ja auch kennen. Das ist jetzt Wunschdenken: Wäre halt cool, wenn das sozusagen der default wäre, dass man das nehmen kann, weil es einfach die einfachste Möglichkeit wäre. Da müsste man hinkommen. Das wird im Endeffekt eigentlich bedeuten, man hätte eine Programmiersprache, die so dynamisch und wahrscheinlich so high level und komfortabel ist wie Ruby oder Python mit der Performance von Rust oder C++. Das wäre jetzt das Wunschdenken, aber das wäre das Ziel, wo man mal irgendwo hinkommen möchte. Wahrscheinlich wird man das nicht erreichen, aber in die Richtung, das wollte ich nur so sagen. Nicht, dass es nicht leichter geworden ist, ist es auf jeden Fall.

Lucas Okay, dann sind wir uns wahrscheinlich doch einig. Es gibt ja so eine Sprache, die heißt Crystal. Die sieht aus wie Ruby, aber ist kompiliert und die ist auf jeden Fall wesentlich schneller. Aber die kommt in solchen Benchmarks selten vor, weil die nicht genug Verbreitung hat, um das da wirklich zu betrachten. Und ich hatte jetzt auch noch nicht genug Vertrauen in diese sehr kleine Programmiersprache, um die jetzt in einem ernsthaften Kunden Projekt einzusetzen. Dafür ist es mir dann doch ein bisschen zu wenig verbreitet. Aber ich glaube, da passieren noch Dinge, das dreht sich jetzt noch so ein bisschen. Ich habe einen letzten Aspekt, den wir vielleicht noch aufgreifen sollten, ist vielleicht auch die Frage von mobilen Anwendungen oder auch Anwendungen, die jetzt mit Web Technologien gebaut sind, die man früher als Desktop Anwendung geschrieben hat. Weil da sehe ich durchaus mehrere Aspekte. Ich nehme jetzt noch mal ein Figma als Anwendung, mit der ich UIs entwerfe. Das könnte ja eine native Anwendung sein, aber es ist eine Webanwendungen und das hat aus meiner Sicht erstmal zwei Konsequenzen. Die eine ist, es wird wahrscheinlich weniger effizient sein, als wenn Figma in Swift geschrieben wäre. Das ist jetzt eben in Web Technologien geschrieben ist und ein Wrapper drumgewickelt ist. Und das andere und das finde ich auch eine Sache, die ist so selbstverständlich geworden, dass wir das manchmal vergessen, es ist viel mehr auf dem Netzwerk, was da passiert. Wenn ich statt einer nativen Anwendung eine Anwendung habe, die jede einzelne Sache, die ich mache, an den Server schickt, auch wenn da jetzt viel lokal passiert, aber trotzdem ist es ja ein Konzept bei Figma oder auch bei Pitch, diesem Präsentations Programmen oder bei Google Docs, da ist es ja so, dass alles was ich schreibe, wird an den Server geschickt. Das basiert ja auf dieser Idee, dass wir kollaborativ an allem arbeiten und dafür ist das ja auch klasse. Aber in der Realität schreiben die meisten Leute ihr Word Dokument doch alleine. Und da ist es gar nicht so notwendig, dass jetzt wirklich quasi jede Sekunde auf dem Server landet. Klar, man möchte ein Backup haben und man möchte dafür sorgen, dass wenn jetzt mein Computer kaputt geht oder den See fällt, dass es dann alles auf dem Server ist, verständlich. Aber dieses blinde wir bauen alles als Server Anwendungen, die einfach nur so ein Kostüm angezogen bekommt, das sehe ich schon kritisch und das sehe ich jetzt auch mehr in den Developer Tools, wo man jetzt so was wie GitHub Code Spaces hat, wo dann eben das VS Code nicht auf dem eigenen Computer läuft, sondern auf dem Server. Das sind alles Sachen, die erzeugen erst mal wesentlich mehr Netzwerk Traffic und auch das verbraucht Energie und diese Energie ist einfach sehr unsichtbar. Und ich weiß, das hat jetzt nicht direkt was mit der Programmiersprache zu tun, aber die spielt eben auch dort rein. Wenn ich jetzt mich stattdessen dafür entscheiden würde, in GNOME eine Rust GTK Anwendung zu schreiben oder auf MacOS eine Swift Anwendung, dann hätte ich ein anderen Energieverbrauch als ich es jetzt habe. Und da ist eben die Motivation ganz stark die Kosten zu sparen. Und da läuft es eben nicht wie bei diesen anderen Themen, die wir jetzt besprochen haben, nicht gleich das Business Interesse und das Energieverbrauchs Interesse, weil das Business Interesse drei Clients zu bauen gegenüber einem Client zu bauen ist ganz klar: Ich baue ein Client und den wrappe ich nur in verschiedenen Plattformen.

Christoph Die Programmiersprache könnte da eine Rolle spielen. Tut es aber aus dem genannten Grund von dir jetzt nicht, weil ich muss anstatt drei Anwendungen oder vier Anwendungen, wenn ich noch mobile Plattformen nehme, kann nur noch eine schreiben. Ich würde das aber gerne trennen von diesem kollaborativen Aspekt. Das wird immer auf dem Server gemacht und erzeugt Netzwerk Traffic, ja, kann man haben, aber das werde ich vielleicht auch gerne bei einer nativen Anwendung, dass ich so ein Online Modus einschalte und sage, ich mach jetzt gerade mit dem Lucas das Vorbereitungdokument für den Podcast und wir editieren das zusammen oder ich bin in dem Offlinemodus und genauso kann ich bei so einer Anwendung, wie Figma und Miro, die eigentlich ja nur ein verkappter Browser sind, typischerweise Elektron, das kann ich auch offline machen. Ich muss das nicht online machen. Trotzdem habe ich damit eine Runtime gewählt und eine Programmiersprache, die jetzt wahrscheinlich um Faktor zehn oder Faktor fünf weniger effizient ist, als wenn ich auf Mac OS Swift benutzen würde oder ich weiß nicht, auf Windows C#, auf Linux weiß ich nicht, welches man nutzen würde, wenn es nicht immer C oder C++ sein muss. Die wollen wir vermeiden wegen der Memory Safety. Aber ich bekomme wahrscheinlich eine effektivere Runtime, weil der Browser geht dann ja zu meiner Runtime, um dann zum Beispiel für die GUI, alles darzustellen und man hat dann immer noch diese Zwischenschicht dazwischen, was meine Runtime theoretischer Weise nativ könnte. Und ja, ich würde mir wünschen, das wäre anders. Ich sehe aber den Kosten Aspekt für die Firmen. Also drei oder vier Anwendungen zu pflegen kostet halt deutlich mehr Geld. Und die Kosten in Sachen Energieverbrauch, die verlagere ich ja weg von mir. Das ist auf dem PC des Endanwenders, der Endanwenderin. Die brauchen halt mehr Speicher und eine bessere CPU, damit Figma oder Miro vernünftig läuft in Elektron und Co programmiert ist und auch der Netzwerk Traffic wird nicht bezahlt von denen. Nicht unbedingt, je nachdem wenn ich es in der Cloud gehostet habe vielleicht schon manchmal, aber den Großteil des Energieverbrauchs wird wahrscheinlich auch nicht von denen bezahlt, die das Programm herstellen. Von daher, ich weiß, warum das so ist. Ich würde mir das aber anders wünschen. Du hast VS Code genannt. Auch lokal das laufen zu lassen, verbraucht halt unglaublich viel Ressourcen, wenn man sich das mal anschaut. Aber ich glaube, das ist eine generelle Limitierung drin, weil man startet halt den Browser, um Editor zu machen, anstatt den Editor zu nehmen. Ich weiß nicht, was man da machen kann, wahrscheinlich eher wenig, weil das ist dann ökonomisch echt schwierig. Wir bräuchten wahrscheinlich die Elektrom Steuer, um die externen Kosten wieder in die, die so was verbocken zurück zu verlagern, aber das ist natürlich völlig utopisch. Das funktioniert nicht. Und wo du das sagst, ist mir auch noch eins eingefallen in Sachen Ressourcenverbrauch. Wo wir beide jetzt gesagt haben, das ist nicht so wichtig, der Speicherverbrauch macht nur 10 % aus. Aber ein Aspekt der in den Papers nicht behandelt wird, ist ja vom Energieverbrauch, den ich jetzt zur Laufzeit habe, aber wenn ich jetzt meinen Rechner mit 32 Gigabyte ausstatten muss, weil ich VS Code und Figma gleichzeitig laufen lassen will und nicht nur eins, weil die so viel Speicher verbrauchen, dann wurden dafür auch doppelt so viele RAM Chips hergestellt. Und die sind jetzt ja auch nicht ohne Energie aus der Luft entstanden, sondern da floss viel rein. Und wenn man da das sparen kann, schon die ganze Herstellung, weil wir insgesamt viel weniger Speicher verbrauchen, sollte man das nicht außer Acht lassen. Du hast so ein schönes Beispiel genannt und auch ein Fachbegriff, den ich so vorher nicht kannte für Mobiltelefone, wo das gleiche Prinzip gilt.

Lucas Embodied carbon meinst du, oder?

Christoph Du hattest auch eine Zahl, wie hoch der ist bei so einem Handy, weil man nach zwei Jahren typischerweise ein Neues hat, typischerweise weil die Verträge so lange dauern und da irgendwie eins inkludiert ist und man will schon das Neueste haben. Und auch weil die Hersteller vielleicht keine Updates mehr liefern oder wie Apple zwar Updates liefert, aber Funktionen immer nur für die neusten Geräte Generation freischaltet, auch wenn es wahrscheinlich nicht immer nötig ist. Und ja, das muss man auch differenziert sehen. Handys werden dann weitergegeben oder vielleicht auch gebraucht verkauft, aber trotzdem, ich weiß nicht, ob du die Prozentzahl parat hast, alle zwei Jahre? Das war unglaublich hoch.

Lucas Genau. Der embodied carbon Anteil liegt zwischen 85 und 95 % des CO2 Ausstoßes. Das ist schon wirklich eine Hausnummer.

Christoph Das gilt jetzt für Mobiltelefone und ich glaube aber auch für Elektronik, Mikroelektronik, Chips, Speicher und so, den wir nicht erstellen, gibt es auch große Potenzial, was wir dann sparen. Und deshalb sollte man, auch wenn es jetzt wieder zur Laufzeit den Energieverbrauch nicht so signifikant beeinflusst, zu schauen, dass wir halt nicht so viel Speicher verbrauchen, weil dann kann halt mehr auf dem Desktop passieren, mehr als VS-Code, aber genauso gilt das natürlich auf dem Server. Wenn ich jetzt so ein Deployment habe und ich kann doppelt so viele Container auf meinem Kubernetes Knoten laufen lassen, dann brauche ich halt vielleicht ein Knoten weniger, da ist dann der Speicher drin, CPU oder sonstiges drin, das Gehäuse, alles was so verbaut wird, was embodied carbon alles beinhaltet. Da sollte man auch drauf schauen. Und da finde ich ganz interessant, ich habe das mal in einer anderen Folge den Blauen Engel für Softwareprodukte angesprochen, da ist dieser Effizienz Anteil gar nicht so groß, aber da ging es darum, wie lange soll so eine Software halten? Auch auf einem fünf Jahre alten PC, dass das vernünftig funktioniert. Die haben andere Nachhaltigkeitskriterien. Aber dass das so ein Thema da ist und das wird halt, wenn wir ressourcenschonend arbeiten, muss halt die Hardware sowohl bei den Servern als auch bei den Clients nicht so schnell ausgetauscht werden. Da freuen sich die Leute auch, wenn sie sich nur noch alle fünf Jahre ein neues Notebook kaufen müssen und nicht alle zwei, weil Angular und React 5000 neue Features mitbringen.

Lucas Das stimmt, obwohl es natürlich auch andere Gründe gibt, warum Leute sich neue Telefone kaufen, als dass die Sachen langsam werden.

Christoph Wie gesagt, die Verträge klar, aber beim Notebook ist es glaube ich nicht so, dass du unbedingt…

Lucas Nein, das stimmt. Aber es gibt ja auch durchaus Leute, die wollen die neuere Kamera oder was auch immer.

Christoph Und die Firmen schreiben nach drei Jahren ab. Aber trotzdem muss das nicht sein. Und du sagtest mir, dein MacBook ist jetzt auch schon etwas älter.

Lucas Fünf Jahre.

Christoph Und funktioniert halt trotzdem.

Lucas Einwandfrei.

Christoph Gut.

Lucas Da wäre es auf jeden Fall auch noch besser gewesen, wenn ich meinen Akku selber hätte austauschen können, dann wäre es sogar noch einfacher gewesen, weil der war ein bisschen schwach auf der Brust mittlerweile. Und besser nur den Akku austauschen als das ganze Gerät, wenn der Rest noch funktioniert.

Christoph Das auf jeden Fall. Aber deine Software, die du benutzt, soll halt auch noch laufen. Wie gesagt, wenn man die mit Programmiersprachen macht, die auch effizient sind, dann wird man da wahrscheinlich vielleicht auch noch ein Jahr oder zwei rausholen.

Lucas Definitiv. Ich glaube, wir sind jetzt am Ende. Aber wir sind auf jeden Fall auch interessiert an anderen Meinungen. Wir freuen uns, wenn ihr uns sagt, an welchen Stellen, da unsere Argumentation vielleicht nicht so ganz passt. Aber ich glaube, wir zwei sind einer ähnlichen Meinung, auch wenn du natürlich alles in Go neu schreiben willst und ich nicht. Aber sonst kommen wir da in eine ähnliche Richtung.

Christoph Wir beide sind jetzt für heute am Ende, aber eigentlich sind wir am Anfang. Das Thema haben wir jetzt angerissen, anhand von zwei Papers und 5000 neue Aspekte da reingebracht, wo viel noch im Unklaren ist, weil wir keine guten Zahlen liefern können, sondern wo man klar, das ist nicht Bauchgefühl, sondern manches ergibt sich einfach auch logisch. Daher sind wir da am Anfang und wir sind gespannt, ob Reaktionen darauf kommen. Und sagt mal, wie das bei euch ist, ob das ein Thema ist bei der Wahl der Programmiersprache oder welche Faktoren noch eine Rolle spielen oder welche Faktoren wir komplett vergessen haben. Wir würden das alles gerne mal hören, was ihr dazu denkt.

Lucas Definitiv. Gut Christoph, dann wünsche ich dir noch einen schönen Tag und den Hörerinnen und Hörern bis zum nächsten Mal!

Christoph Bis bald.