Transkript: Python Async Teil 2

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast.

Heute die 26.

Episode, wir haben den 1.

Dezember.

Jochen, wir sind heute genau zwei Jahre.

Vor genau zwei Jahren haben wir die erste rausgebracht.

Ja, richtig, das stimmt.

2018, am 1.

Dezember, kam unsere erste Episode raus.

Ja.

Ja, nicht schlecht, oder?

Zweiter Geburtstag.

Ja, aber meine Güte, das ist das schon wieder lange her.

Nicht so schlecht, und wir haben sogar durchschnittlich mehr als eine Folge dann pro Monat aufgenommen.

Und wenn wir die noch zählen, die wir weggeschmissen haben, sind wir sogar bei.

Ja, ich glaube, wir haben uns verzählt ab und zu.

Ich weiß nicht, ob das wirklich genauso viele sind.

Also 27 ist jetzt die Zahl, die aber es kann sein, dass wir irgendwie Dinge unterschlagen haben.

Ja, ich glaube, 26 offiziell jetzt.

Kann auch sein, ich weiß es nicht genau.

Ja, hallo, hallo, schön, dass ihr wieder eingeschaltet habt.

Heute machen wir Async Teil 2.

Ja.

Und wir haben dabei den Johannes.

Hallo.

Hallo.

Ja, wir wollten auch wieder ein bisschen News machen und euch ein bisschen entschädigen für die ganzen Folgen, wo wir das so ein bisschen.

Ja, wir haben uns ja mal so viel vorgenommen, was wir eigentlich machen wollten.

Moodula aus der Stand der Bibliothek vorstellen, Pix und so.

Das machen wir dann nie, weil irgendwie mal zu wenig Zeit ist und wir die ganze Zeit brauchen, um unser Audio-Setup hinzukriegen.

Ja, genau, und dann muss am Ende irgendwie jemand wieder ins Bett und dann müssen wir leider immer aufhören und dann.

Genau, machen wir das diesmal.

Ja, also zum Beispiel eine Geschichte, die ich eigentlich erwähnen wollte, wir hatten ja vorletztem Mal, glaube ich, was zu Python 3.9 erzählt.

Und eine ganz wichtige Geschichte habe ich vergessen.

Und zwar ist ein Python 3.9 Topological Sword schon mit in der Standardbibliothek.

Topological Sword.

Jetzt bin ich natürlich wieder der Blöde, der keine Ahnung hat, was das ist.

Also was ist bitte Topological Sword?

Jochenweise ist es auch nicht.

Bitte ist nur cool.

Nee, das ist einen Graphen, also wenn man zum Beispiel Abhängigkeiten hat und die sortieren möchte, also wenn man sich zum Beispiel anzieht und dann irgendwie dran denken möchte, dass man irgendwie, bevor man, weiß ich nicht, die Schuhe anzieht, die Socken angezogen haben muss, dann ist das Problem sozusagen, das allgemeine Problem dazu ist.

Topological Sort oder topologische Sortierung, keine Ahnung, gibt es auch beim Projektmanagement, glaube ich.

Gibt es überall, wo es Graphen.

Ja.

Zum Beispiel auch ganz wichtiger Anwendungshalt, da habe ich selber zum, da wusste ich noch nicht, dass es das ist und hab selber überlegt, was das für ein Problem sein könnte.

Nach ganz, ganz langem Überlegen bin ich dann drauf gekommen, es könnte irgendwas mit Graphen zu tun haben und dann sortieren.

Und hab dann irgendwann hat mir jemand gesagt, ja, das ist auch Topological Sort.

Dann habe ich mich ziemlich blöd gefühlt, aber zwar beim, wenn man die Abhängigkeiten von Programmen oder Paketen, die man installieren möchte, sortieren möchte, da braucht man das dann auch.

Ist das jetzt mit drin?

Einfach so?

Das ist jetzt in der Standardbibliothek mit drin.

Batteries included, sage ich dir nur.

Ja.

Ja, GraphLib heißt das Modul, oder?

Ja, ja.

Genau.

Heute ist übrigens auch Advent of Code, der Teil 1 rausgekommen.

Macht ihr das noch?

Worum geht es denn dieses Mal beim Advent of Code, Dominik?

Das habe ich noch nicht so ganz rausgefunden.

Ich glaube, irgendjemand möchte in Urlaub fahren auf eine Insel, weil er schon fünf Jahre lang versucht hat, da hinzubekommen und dann muss er irgendwie seine Abrechnung richtig machen, dass er da hinkommt.

Ich finde, die letzten Jahre fand ich auch sehr interessant.

Da ging es ja irgendwie um Weihnachtswittel und die Reise durchs Weltalf mit dem Santa und so.

Ja, genau.

Mit dem Raumschiff, was man Interpreter braucht, den man dann selber programmieren musste.

Ja, genau, da haben wir auch Codes und so, ne?

Ja, also Advent of Code ist eine coole Sache.

Also da kann man in allen möglichen Programmiersprachen machen natürlich.

Hallo.

Das ist auch hauptsächlich so für einen selbst, oder?

Also es ist ja nicht irgendwie gewertet oder

so, sondern es ist ja nur.

Ja.

Oh, ich kann es gar nicht, aber.

Ja, es sind einfach 24 Programmieraufgaben, üblicherweise zweigeteilt in zwei Teile.

Und die sind immer von der Sorte, hier ist ein kleines Beispiel und hier ist eine große Eingabemenge und wenn du die Antwort weißt, dann tippst du hier in dieses Feld ein.

Und dann kannst du quasi überprüfen, ob du die richtige Lösung gefunden hast.

Ah, okay.

Ja.

Und das ist eigentlich immer ganz nett.

Es ist sehr nett

gemacht, es ist sehr aufwendig gestaltet und wir haben immer schöne Story.

Klar, man muss ja mal einen Stern sammeln pro Tag pro Aufgabe, also zwei Sterne am Tag am Anfang.

48, 50 sogar, oder?

24, krieg mal 25 noch ein.

Nö.

Also ja, zweimal 24.

24 oder 25 sind.

Ich glaube 48 dann.

Achso, und das geht auch zurück.

Also man kann auch bis 2015 zurückgucken und sich die ganzen alten Aufgaben ansehen.

Das ist sehr nett.

Also selber ausprobieren und dann halt gucken, ob man die Aufgaben lösen kann.

Die werden am Anfang, sind die noch etwas einfach.

Die gehen aber schnell wirklich in die Zeit.

Also ich habe sogar einen Post gelesen von Peter Norweg, der sagt, das wäre eigentlich schon sehr geil, aber so viel Zeit hat er dann auch nicht.

Aber ja, es ist so.

Ja, das ist auch bei mir immer so das Problem.

Ich mache da gerne mit und dann irgendwann fühlt es sich an wie Arbeit und dann höre ich es dann wieder auf.

Ja, aber es ist auf jeden Fall sehr zu empfehlen.

Für alle Stufen ist was dabei.

Die ersten Aufgaben sind einfacher, die kriegt man schnell durch und die so ab dann fünf oder so oder sechs oder zehn oder zwölf wird es dann schon

richtig happig.

Ja, man muss sich dann wirklich überlegen, wie man da rangeht und nicht einfach so hands-on drauf los.

Dann läuft man meistens gegen eine kleine oder größere Wand.

Und letztes Jahr war es auch so, dass die aufeinander aufgebaut haben.

Das heißt, man hat dann an einem Tag seinen Interpreter gebaut und zwei Tage später hat man wieder abgebaut, weil dann noch ein Feature dazu kam.

Ja, oder man musste halt neue Obcodes handeln oder sowas.

Und wenn man am Anfang schudrig gearbeitet hat und das so hingehotzt hat, dass das einfach so ging, dann hat man sich geärgert, weil man die Implementierung sonst einfach hätte erweitern können und so musste man sie ganz neu bauen.

Naja.

Ich bin gespannt, wie es dieses Jahr draus wird.

Ich habe nicht immer so viel Zeit, aber ich glaube, so eine Stunde morgens oder so will ich mir schon dafür nehmen.

Ich mag das nämlich.

Ja, es lohnt sich auf jeden Fall aus.

Ja, gute Übung.

Ja, ich habe da auch mal sehr viel gelernt.

Also wirklich auch über Konzepte von anderen Lösungen angucken, verschiedene Sprachen.

Ein Kollege von mir macht das in Go, da kann man es immer schon vergleichen.

Sehr gut.

Ja, hat er heute direkt eine rekursive Lösung implementiert.

Ich war direkt da ein bisschen neidisch.

Ich hatte nicht an Binary Search gedacht, ich wusste auch gar nicht, wie das in Python richtig geht.

Und habe einfach IT-Tools genommen.

Was auch funktionierte, aber war halt Brute Force.

Aber ja, wir waren bei News aus der Stiene stehen geblieben.

Das sind ja News.

Ja, genau.

Eine ganz interessante Geschichte, Python läuft jetzt auf.NET, auf der Runtime da.

Das hast du gerade so ein bisschen leise vor dich hin.

Genuschelt, als wäre es eine Meinung.

Das ist mir auch ein peinlich, das ist peinlich, dass es jetzt auf .NET läuft.

Was ist jetzt der Unterschied zu IronPython?

Weil IronPython gab es ja

schon lange.

Ja, aber ich glaube, das war schon lange nicht mehr so richtig aktiv.

Das ist so wie Jython.

Da gibt es sicherlich einen 2.7-Port für.

Ja, es ist irgendwie, es gibt einen PEP, der beschreibt, wie man sich quasi einklinken kann, wenn man jetzt einen JIT-Compiler ist.

Und diese Variante jetzt benutzt es auch.

Das ist irgendwie von Anthony Shaw oder so, hat das gebaut.

Was genau meinst du erst mit Einklinken, wenn man ein JIT Compiler?

Also das ist just ein Time-Compiler, das heißt, sowas wie Python, die halt zur Laufzeit dann irgendwie evaluiert werden oder wie ist das?

Wenn man so ein Interpreting machen.

Naja, dass es halt dann zu Maschinencode runterkompiliert wird, quasi.

Aha.

Ja.

Und genau das.

Zwar während

das Programm läuft.

Also die Teile, die gerade notwendig sind, werden dann während das Programm läuft, zu Maschinencode kompiliert oder zu dem Code der VM, die da drunter liegt, und sind dann natürlich schneller.

Das macht PyPy zum Beispiel auch.

PyPy hat auch so einen JIT-Modus, der dann halt die Sachen, die jetzt gerade in der Schleife sind und hunderttausend Mal durchgeführt werden, die kompiliert er dann halt so vor, dass diese Varianten schneller sind.

Das ist einer der großen Vorteile von PyPy, dass die das machen können.

Das macht CPython, nicht CPython hat keinen JIT drin.

Der hat einfach seine Stack-Maschinen und die arbeitet das alles ab und fertig.

Aber wie ist denn dann die Runtime?

Das ist ja dann nicht CPython, sondern das ist dann irgendeine andere Runtime, die auf .NET läuft, oder wie?

Ja, nee, das ist schon hauptsächlich C-Python.

Es ist nur so, dass man das irgendwie also keine Ahnung.

Okay, also es ist.

Es ist schon C-Python.

Aber es funktioniert jetzt so halbwegs noch nicht schneller, aber Leute könnten jetzt Optimierungen machen, indem sie halt das irgendwie auf die.NET Runtime irgendwie optimieren.

Rüber cheaten.

Ja.

War auf jeden Fall irgendwie so, kann man sich mal angucken, fährt man den Artikel dazu in den Show Notes-Packen.

Ja, was hatten wir noch?

Genau, noch so Dinge wie PEP 621 irgendwie mehr dazu gekommen, was man jetzt alles so in Pipe-Project-Tommel irgendwie reinschreiben kann an Metadaten.

Oh, cool.

Was denn?

Ja, ich glaube, so ziemlich alles, was halt vorher sonst in Setup UI gemacht hat.

Ich glaube, Flag 8 wehrt sich noch so ein bisschen.

Geht fast.

Also Py-Test ist im Moment noch so mit PyTest-Iny-Option, so ein Workaround.

Das wäre cool, wenn das normal wäre.

Und ich glaube, Flag 8 hat es noch nicht so wirklich geschafft.

Und habe ich noch was vergessen, was fehlt?

Ja, ich glaube, das sind eher so Dinge wie, was ist der Autor von dem Ding und was sind die Abhängigkeiten und diese ganzen Geschichten.

Ja, also Black-Konfiguration geht zum Beispiel schon rein.

Ja, ja, gut, aber das ist ja jetzt ein Third-Party-Mand-Kanal.

Aber das ist dann nett, wenn man das alles da in die PiPolate Homel packen kann, weil ich bin ein Freund von monolithischen Configs und nicht so ganz vielen kleinen, die irgendwo rumfliegen.

Ansonsten, was auch noch ganz, was ich ganz witzig fand, ist, da sind ja irgendwie neue Chips aus Apple rausgefallen.

Hat man gehört.

Ja.

Hat man schon so Geräte gesehen?

Ja.

Also du hast schon so einen.

Nee, ich habe jetzt keinen, aber ich habe schon irgendwie Ergebnisse von den Geräten gesehen für Dinge, die ich interessant fand.

Und insofern, ja, wenn ich jetzt schwärme überlegen, ob ich da nicht vielleicht auch mal zuschlagen soll, weil es schon sendet.

So auf dem Papier jedenfalls und so was man hört.

Wenn man in diesem

Ökosystem drin ist, dann ist das, glaube ich, eine Sache.

Das ist ja so eine Sache, die ich gar nicht verstehen kann.

Also sonst finde ich ja alles, was Moch gemacht hat, total bewundert, es wäre dann super.

Aber dieses Mekophilie, wie sagt man?

Ich weiß nicht.

Ja, Mechaniker so.

Fanbeutum, ja.

Naja, also das Schicke daran ist halt, dass da sind jetzt gar keine, also zum Beispiel bei dem MacBook Air, da sind halt keine Lüfter mehr drin.

Ja, juhu, im Sommer, yay.

Ja, aber also die Leute haben das ja schon benutzt und das scheint halt.

iPhones sind ja auch keine Lüfter drin.

Da sind auch keine Lüfter drin.

Sind das die Kinder?

Der schlimmste Hack, den ich gesehen habe, übrigens.

Bitte was?

Der schönste Hack, den ich gesehen habe, der hat eine, die Tesla-App auf seinem Mac installiert.

Und der hat auch Bluetooth und hat damit seinen Mac als Schlüssel für seinen Tesla verwenden können.

Was natürlich sehr praktisch ist, wenn man immer seinen Mac dabei haben muss.

Ja, voll gut.

Und an, also der muss dann auch an sein.

Zum Einkaufen, einmal kurz im Supermarkt.

Ja, er hat mal kurz und dann auch.

Der Akku hält ja jetzt auch länger, da kann man das dann vielleicht irgendwie

aufgekauft werden.

Aber handlicher ist das Gerät?

Aber ja, also.

Wahrscheinlich sieht der Akku den Tester innerhalb von zehn Minuten leer oder so.

Was es da jetzt halt auch gab, ist schon so eine irgendwie Preview-Variante von einer Tensorflow Version, die halt gegen die entsprechenden Bibliotheken gelingt ist und dann halt schnell ist halt auch auf Metal und halt auf der Apple-Hardware.

Und das war tatsächlich auch ganz nett.

Also ich habe das dann auch mal, ich meine, das ist ja immer so ein Problem, man hat halt keine Nvidia-Karten auf Apple.

Und es gibt da einmal so eine Geschichte über Plate ML, das ist so eine Intel-Geschichte, die man sich installieren kann.

Damit wird es dann halt schon mal ein bisschen schneller.

Also da geht dann schon so ein bisschen was GPU-mäßiges, halt auch mit den AMD-Karten, die da halt drin sind.

Aber ist halt nicht so schnell wie Nvidia.

Und ist halt auch nicht so schnell, also die Kuder und diese ganzen Geschichten, das ist damit nicht so richtig vergleichbar, aber so ein bisschen was kriegt man da schon hin.

Also zumindest soweit, dass halt so Machine Learning-Geschichten halt auf der GPU in so einem MacBook sind halt genauso schnell wie halt mit den acht CPUs sonst.

Ja, weil dann hat Nvidia 3090 oder sowas, da ist ja.

Ja, genau, die ist halt schneller.

Die passen in den Mac nicht rein, habe ich gehört.

Ja, nee, das sind halt irgendwie nicht.

Die haben sich irgendwie gemacht.

In diese Mac Bros gehen die nicht da rein?

Nicht?

Ich dachte, die hätten sogar Nvidia-Karten drin, oder?

Das kann sein, dass das da geht, ja, das weiß ich nicht genau.

Ja.

Kostet wahrscheinlich 5000 Euro für eine Karte oder so.

Ja, ist egal.

Ist ja.

Wenn der Standfuß von dem Monitor schon 1000 Euro kostet, dann ist das auch nicht mehr so wichtig.

Aber der ist aus einem massiven Block Aluminium ist der rausgefrät.

Ja, das ist auch, also aus dem Bereich hätte ich auch News.

Habt ihr.

Jochen, was sagst du denn zu dem Durchbruch, was das Proteinfalten angeht?

Ja, das klingt auch sehr gut tatsächlich.

Das wurde so beschrieben als der erste richtige Anwendungsfall für AI.

Der erste richtige Durchbruch von AI-Anwendungen.

Wie mit den Proteinfalten?

Wo eine amerikanische Firma DeepMind.

Die haben einen Algorithmus vorgestellt.

Also Algorithmus kann man ja fast nicht sagen an der Stelle, aber die haben eine Technologie vorgestellt, die aus einer Sequenzbeschreibung, also die Aminosäuren quasi, die aneinander gereiht werden, genau, die zum Beispiel durch Gene kodiert werden können, das fertig gefaltete Protein berechnet.

Und das Problem ist halt, dass die Proteine zwar linear hergestellt werden, aber sich dann eben zu einer dreidimensionalen Struktur zusammenfalten.

Und weil die eben sehr viele Proteine drin haben, die sich in sehr viele Richtungen falten können, ist die Anzahl der Freiheitsgrade sehr hoch.

Und die haben jetzt eben eine Technik vorgestellt, wie man innerhalb von wenigen Tagen so eine Faltung berechnen kann.

Also quasi an einem Strang aus einer Stadt.

Genau, also RNA.

Was du reinkriegst ist, oder was du gegeben kriegst, ist eine Abfolge von Aminosäuren.

Das ist ja fast wie eine RNA, oder?

Genau, das ist RNA.

Das ist so ein Problem aus der Biologie, was 1973 auf irgendeiner Konferenz vorgestellt wurde.

Also seit 50 Jahren arbeitet man daran im Wesentlichen.

Und die Frage ist halt, wie dieses Protein dann dreidimensional ausschaut, weil das bestimmt ganz viele der Eigenschaften dieses Proteins.

Und das kannst du nicht Blue Force rechnen, weil der Lösungsraum halt irgendwie 10 hoch 1000 ist.

Und die haben jetzt eben so eine Technologie vorgestellt, wo man in, ich glaube, vier Tagen haben sie, vier Tage Rechenzeit haben sie reingesteckt.

Und dann haben sie im Schnitt, also da gibt es dann so einen Benchmark und so einen Wettbewerb, wo sie im Schnitt 92% Übereinstimmung hatten.

Wobei 92% Übereinstimmung, das hört sich niedrig an, aber ist wohl extrem hoch, weil die Messwerte, die man so rauskriegt, sind auch immer nur im Bereich zwischen 90 und 100% Übereinstimmung.

Also es ist im Wesentlichen wie ein Messwert, den man da rauskriegt.

Und das ist eben tatsächlich eine Sache, die man vorher nicht konnte und die es einfach nicht gab.

Und die auch in der Medizin sehr, sehr, sehr, sehr, sehr nützlich ist, weil du dann eben nicht die Moleküle synthetisieren und untersuchen musst, was sehr aufwendig und sehr teuer und sehr schwierig ist, sondern du kannst halt sagen, hier, wir haben so eine Gensequenz gefunden, wie sieht denn das Ding aus?

Und das ist so, also es wurde wie gesagt beschrieben als so einer der ersten richtigen Durchbrüche von AI-Technologie, von Machine Learning-Technologie, wo es, wo jetzt was möglich ist, was vorher einfach nicht möglich war.

Das heißt, man kann tatsächlich irgendwann einen ganzen Körper berechnen, irgendwann mal vielleicht so.

Ja, aber also das wurde halt schon, das wurde halt dann sozusagen so vorgestellt, als, oder das habe ich gesehen, ich habe dann halt so die, den, man hat den Fortschritt gesehen auf so einem als so Graph und dann, das halt die letzten beiden Geschichten waren halt deutlich besser und jetzt halt das letzte so gut wie fast ein Experiment oder quasi genauso gut.

Und jemand hat beschrieb das dann halt so, dass der ImageNet-Moment für Proteinfaltung.

Also wo man halt sieht, so, okay, jetzt ist es so gut, dass man tatsächlich was damit machen kann.

Und wer ImageNet war es ja auch so, also bevor Deep Learning da irgendwie man damit rangegangen ist, waren die Ergebnisse einfach, man konnte es nicht verwenden.

Und das war halt bei diesen Proteinfaltungsgeschichten auch immer so, da war die Genauigkeit, 40%, 50% oder so, ja schon, es geht so ein bisschen was, aber es hat halt nicht, weil man konnte es nicht verwenden.

Und jetzt ist es halt so weit, dass man es tatsächlich verwenden kann.

Und ja, das ist natürlich schon beeindruckend.

Ja, Deep meint, auch interessant, ist von Google gekauft worden.

Die hatten auch auch schon AlphaGo gemacht.

AlphaGo haben die gemacht, genau.

AlphaGo Zero, ja.

Ja, schon eine spannende Sache.

Aber hat nichts mit Python zu tun, also zurück zum Thema.

Hunde wollte ich ewig lieben, ja.

Ja.

Ja, das ist doch gar nicht so schlecht, also so so ein Protein-Fight-Ding, da kann man auch bestimmt einige Sochen und Sachen machen, die den Körper verjüngen oder sowas.

Das ist bestimmt ein gutes Geschäftsmodell, wenn man da relativ weit vorne ist.

Ja, jetzt gerade ist es vor allem spannend, weil das halt, weil man da halt auch mRNA-Sequenzen mitberechnen kann und hat, welche die richtige ist.

Gut, gut, ja.

Ja, da geht einiges.

Genau, ansonsten eine Geschichte und da, das ist ja schon fast eine Überleitung zu Thema, es ist eine neue Release rausgekommen von Phoenix Live View vor kurzem.

Ich gucke da ab und zu auch mal so ein bisschen jetzt rein, weil ich mir dieses ganze Elixier Erlangen-Ding halt auch so ein bisschen angucke.

Und das hat jetzt zum Beispiel auch File-Uploads drin.

Oh, das hört sich.

Entschuldigung, das hört sich total nach Jagni an.

Ah, File-Uploads, das machen wir in Release 12, das braucht kein Mensch.

Ja, ja.

Das hat mich jetzt auch gewundert, ehrlich gesagt, dass das doch nicht drin war.

Ja, jetzt ist es drin und das ist auch tatsächlich sehr schick.

Also ja, aber genau, genau.

Da hat sich auch noch ein bisschen was getan.

Ja, vielleicht musst du nochmal kurz sagen, was Phoenix

überhaupt ist.

Ja, das ist halt sozusagen das Standard oder ich weiß es nicht genau, jetzt bloß nichts Falsches sagen.

Ich kenne mich ja jetzt mit Elixir nicht so aus, aber das ist halt so das Web-Framework, was man halt...

Also Elixir ist halt ein Dialekt oder sagen wir mal so eine etwas anders aufgemachte Sprache, die aber auch auf dieser Erlangen vor allem läuft und zu Erlangen runterkompiliert.

Und Phoenix ist halt sozusagen das Standard-Web-Framework dafür.

Werde, was ist Erlangen?

Kann man das essen?

Ja, Erlangen ist halt auch so eine Sprache.

Ericsson Language.

Werde, was ist Ericsson?

Der Telefonhersteller ist der Schwert.

Der große, der schwierigste Telefonhersteller aus Norwegen, glaube ich.

Woher kommt Ericsson?

Und ich weiß nicht genau, wann das entwickelt.

Ach.

Ja, und ich glaube, das ist irgendwie schon eine ziemlich lange her, Anfang der 80er, weiß ich nicht, warum man dann so erschwinden.

Jetzt ein ganz, ganz, ganz geniales Video aus den 80ern, wo sie das demonstrieren, dieses Erlang-System.

Mit der Ästhetik der 80er, aber mit der Technologie, die heute.

Also wenn ich das programmieren müsste, was die damals zeigen, wüsste ich nicht genau, wie ich es machen würde.

Ja.

Ja, ja, es ist schon mal ein Ort.

Also halt Erlang nehmen.

Ja.

Und das ist halt heute noch immer noch.

Es ist gerade sehr hip im ganzen Web-Umfeld, so für Backend-Geschichten, deswegen, weil es halt, weil man quasi, naja, so sehr, sehr robuste Concurrency-Geschichten halt geschenkt kriegt.

Ja, WhatsApp ist da drauf halt gebaut und so.

Das wurde doch für, also das hat Erlang, äh, das hat Ericsson doch für seine Telefonsystem Backends.

Für die Telefonswitche ist das eigentlich gebaut worden, ja.

Genau, und die dürfen halt nicht abstürzen.

Also ich meine, wenn die abstürzen, dann ist es halt echt blöd.

Deshalb ist das so robust.

Da gibt es auch einige, es gibt auch einige Multiplayer-Gaming-Systeme, wo die Backends in Erlang geschrieben sind, einfach weil die nicht abstürzen und installierbar sein müssen.

Ja, man sieht die ja nicht.

Das sagen immer nur Firmen wieder hier, wir benutzen Erlang, um unsere Backends zu programmieren, aber die siehst du ja nie.

Na gut.

Ja, also ich habe gerade mal bei Wikipedia geschaut und da steht auf der Übersichts-Map, die ziemlich hässlich ist.

Environment Doppelpunkt CCC.

Auch interessant.

Crackers kompilet das Costumers wollten die wohl sagen, aber naja.

Das muss am Rande, kleiner Joke.

Aber Jochen kompiliert es wirklich zu Airlang runter

oder kompiliert es direkt zu Beam?

Weil die VM heißt ja Beam VM.

Ja, ich meine, es meine kompiliert erst nochmal zu Erlang runter.

Und dann, äh, aber ja, genau.

Ich gucke dann immer nur so drauf.

Zu Beam, Beam hier ab, Scotty, was ist denn jetzt wieder Beam?

Ja, das ist die VM, die Erlang ausführt.

Aha, also.

Das ist so wie C-Python.

C-Python, niemand interagiert je mit C-Python, obwohl wir alle immer mit C-Python interagieren, aber das ist das eigentliche Programm, was das ausführt.

Und bei Erlang und Beam ist es genauso.

Bei Erlang heißt es halt nicht CR Lang, sondern es heißt halt Beam.

Und dann laufen Dinge wie Elixir auf Erlang.

Genau.

Aha.

Und Elixir ist das Django für Erlang.

Nee, Phoenix.

Das Phoenix ist ja auch.

Das ist Django sozusagen für Alex.

Das Django für Elixir.

Ja, ja.

Wird auf

Erlang und das läuft dann auf Beam.

Genau.

Und Beam läuft auf?

Ich glaube, da gibt es auch irgendwo OTP oder sowas darunter.

Ja, ich glaube, dass das die Bibliothek ist.

OTP ist die Bibliothek, wenn ich das recht weiß.

Aber ich lasse mich gerne in den Kommentaren.

Genau, das müssen wir uns alle dafür schlagen, dass

wir so abgedrückt haben.

Also ich habe überhaupt keine Ahnung, wofür man ihr gerade redet.

Ich fühle mich etwas abgehängt.

Ja, das macht nichts, dann fühlen wir uns besser.

Ja, ist klar.

Ja, also genau, eigentlich ist auch nur, es ist halt deswegen interessant, weil es halt sozusagen für Async und diese Geschichten halt so, dass, wo man immer sagt, das ist ein Goldstandard, so da funktioniert das richtig gut und alle, die das da machen, sind immer so begeistert und schauen auf die anderen herab.

Dann würden wir auch vielleicht mal gucken, was das eigentlich so kann.

Und ja, deswegen gucke ich mir das auch gerade so ein bisschen an, um das halt ein bisschen miteinander vergleichen zu können, alles.

Und genau dazu vielleicht auch gerade noch eine Überleitung zu so einem Podcast-Software-Thema, weil es gab schon mal einen Versuch, also nochmal eine Ecke ausholen.

So eine der populären Geschichten, wie man Podcasts hostet, ist ja irgendwie der Podlove-Publisher, oder es gibt ja natürlich unterschiedliche Teile, was dieses Hosting betrifft, aber so das Ding, was sozusagen die Feeds generiert und ja, irgendwie auch den ganzen Website-Teil so zum Großteil macht, das ist halt so ein WordPress-Plugin.

Vielleicht habe ich schon mal gehört das von Tütlaff, der mit Cast Radio-Expert hat.

Ja, gut, der hat das jetzt, ja, der hat das Projekt mal initiiert.

Da haben ganz eine Menge Leute dran irgendwie geschrieben.

Und genau, also man kriegt halt so Probleme, wenn man jetzt irgendwie WordPress und da ein Plugin hat und dann, also das, dazu gibt es jetzt auch einen ganz interessanten Podcast.

Puttlovers Podcast heißt er irgendwie.

Und da wurde über die Geschichte auch schon so einiges erzählt.

Und ich habe mir das halt mal angehört, weil ich dachte, für mich ganz interessant, weil ich diesen ganzen Hosting-Teil, den Publisher-Teil ja sozusagen in Django irgendwie gebaut habe.

Halt natürlich nicht das, was das Ding macht, aber halt so rudimentär, dass man damit halt irgendwie für die Anforderungen, die wir haben, das halt so halbwegs hinbekommt.

Und ja, dachte, vielleicht kann ich da so ein paar interessante Anregungen mitnehmen, was man da eigentlich alles noch so tun kann und worauf man aufpassen muss und so.

Und ich fand es sehr unterhaltsam und ich fand es auch interessant, in welche Probleme sie dabei reingelaufen sind.

Zum Beispiel einfach mal so ein bisschen so, ich meine, oder könnt ihr euch das schon vorstellen, was man so für Probleme kriegt, wenn man WordPress als Hosting-Plattform nimmt und dann ein Plugin hat.

Nö, ich glaube, da gibt es keine Sachen.

Auch keine Interabhängigkeiten und auch keine Dependency Hair, gar nichts.

Ich glaube nicht, dass das.

Nö, ist nicht.

Das ist ja Klick, Klick und funktioniert.

Ja, also das ist halt, ich meine, das ist halt so eine super zugänglich und es funktioniert überall.

Und insofern kann ich das natürlich in gewisser Weise verstehen, dass man das macht, weil man halt sozusagen, wenn man nicht benutzt wird, dann hilft einem das ja natürlich auch alles nicht.

Aber wenn man es, wenn es dann benutzt wird, und ist es halt ein WordPress-Plugin, dann hat man halt auch einen Haufen Probleme, die man sonst nicht hätte.

Unter anderem, also der arme Mensch, der das dann erzählt hat, ich hätte jetzt leider den Namen auch gerade nicht parat, der da schon ganz lange dran rum entwickelt, erzählte dann so ein, ja, also wir haben das, also irgendwann wollten Leute dann so Statistik haben auch und dann liefen aber die Statistikjobs irgendwie so ein bisschen länger.

Und naja, normalerweise so WordPress, das läuft dann halt auf Hostern irgendwo und die beenden die Prozesse halt immer so nach einer Minute ungefähr.

Weil normalerweise ist das kein gutes Zeichen, wenn dein Webrequest länger als eine Minute läuft.

Und dann schießt man ihn lieber weg, weil wahrscheinlich ist er eh kaputt.

Und naja, du blockierst ja auch einen Worker komplett sozusagen und das sind ja Shared-Toster, ne?

Und da gibt es ja ganz viele Leute.

Und dann blockierst du ja deren Ressourcen, das heißt, ja, nicht so gut.

Und jetzt musst du halt aber irgendwie um diese Beschränkungen drumherum programmieren.

Weil sowas wie Background-Tasks oder irgendwie Task-Queue-Systeme oder so, hast du halt nicht.

Du hast halt halt auch nicht irgendwelche Maschinen mit Workern, die dann halt Sachen abarbeiten oder so.

Das gibt es halt einfach alles nicht.

Und du musst halt alles in Requests abhandeln.

Das heißt, du musst darauf warten, dass ein Request vorbeikommt und dann guckst du halt in eine Kontakttabelle und guckst halt, ob jetzt gerade irgendwas laufen muss und wenn ja, dann läuft das halt in deinem Request.

Und derjenige, der die Webseite aufgerufen hat, hat halt ein bisschen Pech gehabt und der muss halt länger warten.

Aber du musst halt aufpassen.

Wenn es länger dauert als eine Minute oder wenn du dich diesem Bereich näherst, dann wird es halt knifflig.

Und dann hat er dann irgendwie so ein Katze-und-Maus-Spiel gebaut, wo man dann so einen Prozess wegforgt nach kurz vor 60 Sekunden und dann wieder berechnet, brechnet, berechnet, alles wieder serialisiert, wieder wegforgt und dann sozusagen dem Kill immer wegläuft.

Und das ist natürlich schon, also ich meine, ja, hm.

Ja, das ist eine lustige Übung, würde ich mal sagen.

Ja, kann man natürlich machen.

Oder halt eben auch so Dinge wie, ja, sie wollten irgendwann die Podcast-Logos anzeigen und da gibt es ja die von iTunes geforderten Größen, das sind so 3000 mal 3000 Pixel, das ist ein bisschen groß.

Und sie sagen, okay, das rechnen wir einfach ein bisschen runter und dann, ah, oh, Mist, so einfach kann man das aber nicht machen.

Man muss ja irgendwie berücksichtigen, dass auf unterschiedlichen Monitogrößen die Dinge unterschiedliche viele Pixel haben müssen und so.

Und wie macht man denn das?

Und was sind die Standardlösungen von WordPress?

Und dann haben sie gesehen, oh, es gibt keine.

Und das Problem hat mich ja auch schon, das ist auch etwas, wo ich bei Django etwas überrascht war, dass es da einfach nichts gab.

Und ja, dann mussten sie das halt auch irgendwie selber bauen, wann sie denkt ja, oh ja, das Problem hatte ich halt auch schon, das musste ich dann auch selber bauen.

Aber was das Ganze halt deutlich schwerer macht, ist halt, wenn du nicht selber das alles installiert hast und deine Abhängigkeiten definiert hast, dann hast du halt, äh, machst du das vielleicht mit Image Magic oder so in zehn unterschiedlichen Variationen über alle möglichen Hoster, die halt alle möglichen unterschiedlichen Versionen davon installiert haben.

Und dann musst du halt Code schreiben, der mit zehn unterschiedlichen Versionen von irgendeiner Bildbearbeitungsgeschichte klarkommt, was natürlich totaler, das ist natürlich alles.

Ja.

Na, Dependency Herr.

Ja, und genau, all diese Dinge.

Und ja, ich meine, kann man sich ja auch mal selber anhören, wenn das.

Also es war schon interessant und ich fand das auch total cool, was sie da alles irgendwie mit hingekriegt haben und da rausgeholt haben.

Auf der anderen Seite würde ich jetzt sagen, wenn man jetzt nochmal anfängt mit sowas, dann nimmt man doch vielleicht lieber irgendwie ein richtiges Framework zum Entwickeln von Webseiten und nicht irgendwie ein WordPress-Plugin.

Naja, das Problem ist, was du jetzt gerade sagt hast, nimmt man vielleicht lieber, ist natürlich nicht, wenn man denn weiß, wie es geht.

Ich glaube, das ist so die größte Person.

Nee, ich glaube, das war tatsächlich Absicht, dass das so, weil die Frage war, wie kommt man halt zu einer Userbasis.

Und das geht halt nur, wenn man dahin geht, wo die Leute sind und die sind halt bei WordPress oder waren sie auf jeden Fall zumindest damals zu mehr oder weniger 100 Prozent.

Ja, ich weiß nicht, ob sich das groß geändert hat.

Ja, doch, es gibt mittlerweile Hoster.

Es gab, und es gibt zum Beispiel PottiJ als Podcast-Hoster, der inzwischen auch relativ groß ist.

Und einer der Gründer davon war halt auch bei einem von diesen Podcast-Episoden zu Gast und der erzählt dann so, ja, also wir haben das dann auch gemacht, irgendwie so ein Podcast-Hosting irgendwie mal gebaut, aber wir haben dann Ruby und Rails genommen und dachte ich mir so, ja, okay.

Das ist schon mal eine deutlich bessere Wahl.

Also ich würde auch so, also wenn ich so spontan sagen müsste, so Ruby on Rails ist wahrscheinlich eine gute Wahl oder eben Django wahrscheinlich auch, um sowas zu bauen, weil da hat man halt einen Großteil von dem ganzen Kram, den man braucht, der ist da halt schon einfach drin.

Oder nachladbar zumindest.

Ja.

Und man halt halt Wege damit umzugehen.

Und das macht es halt dann natürlich schon mal deutlich einfacher.

Auf der anderen Seite ist es dann halt so, wenn du jetzt das aber eigentlich die ganzen Podcasts, Blogs, die es da draußen gibt, unterstützen möchtest in dem, was sie tun.

Ja, ist halt schwierig.

Da musst du halt dann irgendwas für WordPress entwickeln, was natürlich nicht so nicht so einfach ist.

Also ich weiß es nicht, ich habe keine Antwort darauf.

Aber ich fand es halt interessant, dass es halt, wie sich das da so entwickelt hat.

Und deswegen kam ich eigentlich drauf.

Die haben dann nochmal versucht, das alles komplett neu zu bauen, und zwar in Elixir.

Ja.

Die Katze beißt sich in den Schwand.

Genau, und eigentlich eine ganz gute Idee.

Aber das ist dann irgendwie auch nicht so richtig fertig geworden.

Aber im Prinzip würde ich auch sagen, ja, so Elixir klingt schon mal deutlich besser.

Und das hat nicht gemacht, weil man das mit Asym-Suttor machen kann bei Elixir oder was?

Naja, weil du damit halt auch diese harten Probleme lösen kannst.

Requeste ich mehr Kassel und Maus hinterher spielen.

Ja, nee, das ist gut, aber das ist nochmal eher solche Sachen wie, du willst ja auch zum Beispiel die Files irgendwie distributieren.

Zum Beispiel.

Und du kannst natürlich ein CDN nehmen, aber ich merke das jetzt auch irgendwie.

So, CDN ist halt einmal teuer und ja, also weiß nicht.

Wäre eigentlich schon cooler, das selber machen zu können, aber dann ist halt wieder blöd.

Also das kannst du dann nicht irgendwie mit einem WordPress-Plugin machen, da kannst keine Files haben.

Okay, kann man schon, aber das.

Machst du das mit einem selbstgeholten Minu oder sowas?

Ja, ja, ja, gut.

Aber ist halt auch kein CDN, hast du auch keine.

Wenn du globale Infrastruktur haben willst.

Also du meinst, die Verteilung über mehrere Länder hinweg ist sonst kompliziert.

Ja, oder?

Auch generell die schnelle Anbindung, wenn du halt sehr viele große Dateien hosten willst, ist nicht ganz simpel, das

performant hinzukriegen.

Der Vorteil bei Alexia wäre halt, du kannst halt alles damit machen.

Du kannst halt da dein Pfeil-Verwaltungsdings mitmachen, genauso wie dein Backend für irgendwie dein Frontend.

Und du musst eigentlich nie diese Umgebung verlassen und kannst darin halt alles bauen.

Ja, aber warum

ist das denn so?

Warum ist das denn für alles geil?

Das hört sich alles, was wir den Podcast umbenennen wollen.

Noch nicht, nein.

Lernst du denn Elixier oder ist es nur der, aus der spricht?

Ja, es ist schon Neid auch, ja.

Kann bestehen, das war mir erst.

Ich habe tatsächlich auch hier so Elixir in Action oder sowas, Buch rumliegen.

Ich habe auch schon mal reingeguckt, aber ich habe es noch nicht so.

Das diffundiert jetzt, dass dein Kopfkissen durch in deinen Kopf geht.

Genau, das hoffe ich mir davon.

Mal schauen.

Das ist die beste Methode.

Ich habe auch noch so ein, zwei Bücher unterm Kopfgissen.

Ja, das ist bei Elixir habe ich auch immer das Gefühl, ich hätte gerne die Zeit schon reingesteckt, das mal gelernt zu haben, aber jetzt habe ich doch auch keine Lust, das gerade jetzt zu machen.

Ja.

Ja, aber Jahr, erklär mal, warum ist das, warum ist das so.

Ja, Kriegst ist ein großes Thema.

Also was halt, was halt auch eben, weshalb ich das jetzt auch so betont habe, mit, man kann damit halt alles machen, du kannst damit halt auch Files serven und kriegst halt, also zum Beispiel, irgendwie nehmen wir dieses Problem davon, hatten wir jetzt in dem Django-Channel ja auch schon ein paar Mal, irgendwie private Files serven oder sowas.

Wenn du das jetzt irgendwie, nehme an, du nimmst jetzt mal Django als deine Podcast-Hosting-Plattform.

Und jetzt willst du aber sowas auch haben, wie vielleicht wie private Podcasters, keine Ahnung, irgendwie, wenn es was gibt, keine Ahnung, ich weiß es nicht, aber du willst irgendwie denken.

Deine geheimen Vertragsdaten.

Ja, irgendwie sowas, dann ist das halt nicht mehr so ganz einfach, weil die Files kannst du ja auch nicht mit Django direkt ausliefern, wenn du das jetzt mal so Default-Message betreibst.

Kannst du schon, ist halt aber dann nicht so gut, wenn da tausend Leute gleichzeitig gleichzeitig drauf zugreifen, geht das nicht so gut.

Auf der anderen Seite kann eigentlich nur Django oder beziehungsweise der Applikationsserver entscheiden, ob jetzt.

Privat, viele Leute gleichzeitig hat sich auch irgendwie gerade so ein bisschen, ja.

Ob ein Request autorisiert ist oder nicht.

Der Dominik bezweifelt unseren Erfolg.

Warte, wieso?

Privat viele Leute gleichzeitig.

Natürlich, in unserer coolen Gang laden viele Leute.

Nein, das passiert relativ schnell.

Das passiert möglicherweise mit einem Browser, kriegst du das halt schon hin.

Also wenn du halt irgendwie da, weiß ich nicht, wenn

du mittlere Maustaste, mach der neuen Tab auf und damit

auf einer der

auf deiner Seite hast, dann ist es schon vorbei.

Das heißt, du kriegst das schon mit einem Browser hin.

Also wenn du jetzt, ich weiß nicht, wie viel Worker du normalerweise hast, wenn du jetzt eine billige VM hast auf irgendeinem auf Hetzer oder weiß ich, dann ist es halt, wenn du da nur ein paar Prozesse laufen hast, dann sind die halt schon mit einem Request ausgelastet.

Was ist jetzt mit X-Send-File-Lochen?

Genau, das wäre dann halt sozusagen eine Möglichkeit, das Problem zu lösen.

Dass man halt, dass der Request an den Applikationsserver geht, der überprüft, ob der autorisiert ist oder nicht und schickt dann halt einen Header zurück in der Response.

Ja, also dieser Request sah gut aus und dann geht jetzt irgendwas in der Proxy-Pipeline in Nginx oder so hin, sieht diesen Header in der Response und sagt, ah, das war eigentlich eine File-Response, aber der Applikationsserver kann ja jetzt keine Files zurückschicken, das wäre ja blöd.

Dann bleibt da ja die ganze Zeit die Verbindung offen und es gibt nicht so viele Applikationsserver.

Daher nehme ich jetzt mal diesen Request, diese Response und tausche die aus durch eine File-Response mit dem echten File, auf das ich Zugriff habe und schicke das zurück.

Ja, die Konfiguration dann doch wieder eigentlich relativ blipppalem, weil in den X einen Eintrag macht, der dann dieses V-X-File-Response sennt.

Dings da halt aber auf jeden Fall Nginx benutzt.

Genau.

Geht das nicht mit Kind?

Aber Jochen, warum ist denn das jetzt besser?

Warum ist denn das besser, wenn der Nginx das macht, anstatt dass unser Django, unser GIMP?

Weil bei dem Nginx ist das halt egal, wenn da 1000 Requests reinkommen.

Ja, aber warum?

Warum ist das dem egal und warum ist es uns nicht egal?

Ja, deswegen, weil halt sozusagen eine Verbindung den Nginx nicht blockiert.

Also selbst wenn er da Daten zurücksendet, dann kann der das auf 1000 Verbindungen gleichzeitig tun.

Das geht aber jetzt bei einem normalen Django-Applikations-Server so nicht, sondern da ist der Prozess komplett geblockt, weil der halt synchron Sachen rausschreibt.

Das heißt, das müsste man einen ASCII-Django nehmen.

Der ist quasi, der ist quasi besser parallel als.

Ja, also der macht halt parallel I.O.

Und das geht mit Django erstmal so nicht, das geht jetzt inzwischen auch so ein bisschen, aber erstmal nicht so einfach.

Und das Problem, was ich damit habe, sozusagen aus der Systemperspektive, ist halt, du musst halt einfach nur, um diese Konfiguration dann testen zu können.

Wenn du das jetzt lokal überprüfen willst, funktioniert das denn alles so, wie ich das gedacht habe.

Da musst du dann Nginx hochfahren und eine Datenbank und dann deinen Applikationsserver und einen Caching-Bus.

Du kannst wesentlich nur in einer Staging-Umgebung testen, oder?

Also in einer Developer-Umgebung hast du die ganzen

Bauteile ja normalerweise nicht.

Ja, und das, also kannst du schon und fährst halt einen Haufen Docker-Container hoch, geht schon.

Ja, gut, aber das machst du ja nicht zum Entwickeln.

Das machst du ja wirklich nur zum Überprüfen.

Ja, naja.

Also, aber kann man so gut machen.

Ich mach das nicht.

Ich stelle Dockerkompost ab und dann ist die ganze Liste, die in der Jammel drin ist, die wird dann einfach mal hochgefahren.

Ja, der Punkt ist nur, es ist halt.

Es ist halt ein Haufen.

Wenn da vier so Dinge laufen hat, dann ist schon der Speicher voll.

Naja.

Also es ist halt aufwendig und es ist halt auch irgendwie eine komplizierte Konfiguration und es ist halt fehleranfällig.

Und wenn du jetzt Elixier verwendest, dann ist das halt alles, was dann kannst du das lokal testen.

Du kannst lokal das entwickeln und du kannst, du deployst das so produktiv, natürlich vielleicht mit einer etwas anderen Konfiguration, aber mehr oder weniger genauso, wie du es lokal getestet hast.

Und wenn das dann lokal funktioniert hat, dann funktioniert das halt auch.

Und du brauchst keine komplizierte Architektur mit irgendwie noch drei anderen Teilen, die halt zusammen funktionieren müssen, damit es klappt insgesamt.

Und das hat natürlich einen gewissen Reiz.

Also ich meine, also ich entwickle auch viel mit Docker, weil das halt, ja, ich meine, bei ganz vielen Leuten wahrscheinlich so das Mittel der Wahl ist, um halt Entwicklungsumgebungen zu vereinheitlichen.

Und bei mir ist das so, also das lüftet, also mein Laptop lüftet einfach die ganze Zeit.

Ich dachte,

der hat keinen Lüfter mehr.

Achso, stimmt, das war nochmal.

Und wenn ich das vom Strom abstecke, dann dauert das eine Stunde und dann ist der Akku leer.

Und das ist halt irgendwie eigentlich kein schöner Zustand.

Aber so ist es halt.

Also das ist bei mir nicht so, Jochen.

Ja, wenn man jetzt eine andere Konfiguration, sagen wir, ist eine andere Konfiguration.

Ich versuche auch gerade so ein bisschen wieder von dem Docker-Zeugs runterzukommen, weil das ist halt echt das.

Ach ja, und jetzt bei den neuen, bei den neuen Macs geht das ja auch gar nicht mehr.

Die haben keine Virtualisierungsunterstützung dazu.

Okay, komm.

Wie war der Fortschritt?

Wie bitte?

Es gibt keine Virtualisierungsunstützung, also kein Parallels oder was, oder?

Wood?

Wegen AM?

Warum?

Ja, ich weiß nicht, ob das noch kommt oder so, aber da gibt es das auf jeden Fall nicht.

Ach cool,

da muss man sich ja endlich einen anschaffen.

Wirklich nicht.

Du brauchst dann zwei Macon.

Einen für Windows und einen für MacOps.

Ja gut, aber wir hatten ja jetzt alles nur, also ich meine, wie man seine Entwicklungsumgebung betreibt und warum man das wie macht, das ist ja so ein bisschen freigestellt.

Aber der eigentliche Hintergrund ist doch halt wirklich der, dass man in Python einfach daran gebunden ist, dass jeder Worker einen Request bearbeiten kann, weil die halt nicht parallel arbeiten können.

Und in Lelixia ist es halt nicht so, weil die VM, auf der das läuft, halt super parallel ist, weil die alles gleichzeitig machen können.

Auch hier wieder mit dem Hintergrund halt, dass das aus einem Telekommunikations-Background kommt und wenn die Hardware nur ein Telefonat gleichzeitig machen kann, dann ist das halt ziemlich blöd und es ist besser, wenn man tausend Telefonate

gleichzeitig hat.

Ich erinnere mich an die 90er, wo mein Daten mich die ganze Zeit angeschrien hat, geh aus dem Internet, ich will telefonieren.

Und wenn ihr da halt so einen Knotenpunkt gehabt hättet, dann hättet ihr vielleicht mehrere Sachen.

Aber so Telefonate haben ja auch üblicherweise sehr strenge Real-Time-Anforderungen.

Das heißt, es reicht ja nicht, tausend Sachen gleichzeitig zu machen, sondern du musst ja tausend Real-Time-Sachen gleichzeitig machen.

Und dann ist dieses sowieso schon schwierige Problem nochmal direkt ein kleines bisschen noch viel schwieriger geworden.

Und das ist so ein bisschen für mich das Coole an dieser ganzen Erlangen- und Elixir-Sache, weil die halt einfach eine Basis haben, eine VM haben, die knallhart darauf ausgerichtet ist, tausend Sachen gleichzeitig in Real-Time zu machen.

Und wenn man das braucht, dann ist das eine absolut geniale Sache.

Und das ist, glaube ich, eben in so einem Webumfeld kann das wirklich was sein, wo man das einfach ausnutzen kann, wo du halt wirklich sagen kannst, okay, da kommen Dateien rüber, da kommen Authentifizierungen rüber, da kommt alles drüber.

Und ja, das ist auch so ein bisschen die Faszination, die, das ist der Grund, warum ich das gerne mal gelernt gehabt hätte.

Ja, oder noch ein Beispiel, wo das vielleicht ein bisschen deutlicher wird.

Ich habe jetzt gerade nochmal kurz drüber nachgedacht.

Also wenn man jetzt zum Beispiel etwas, was halt.

Was man häufig nicht hinkriegt, ist, es gibt so eigentlich, was man gerne hätte, eigentlich, ist dieses HLS, so HTTP-Livestreaming.

Sozusagen, also das ist so ein Standard, im Grunde zhakt halt große Dateien in viele kleine und aber du brauchst halt Serverunterstützung dafür.

Wenn du das jetzt gerne anbieten würdest, sodass Podcast-Clients das sozusagen nutzen können, um halt auch auf schlechten Verbindungen und halt auch irgendwie online-Sachen zu streamen, dann hast du halt, wenn du jetzt ein normales System baust, sag ich jetzt mal, so eben mit Ruby und Rails und keine Ahnung, Nginx und so und weißer Teufel, das hinzukriegen, wird ein echter Stunt.

Während wenn du das halt alles in Elixir machst, dann ist das halt bloß Code, den du schreibst.

Du musst auch den Standard unterstützen und du musst es halt irgendwie hinkriegen.

Aber das ist halt auch nur dein Applikationscode und nicht irgendwie ein großes System, was du da irgendwie drumherum konfigurieren musst.

Und du kannst alle diese Anforderungen damit in den Griff kriegen.

Das ist halt halt schon einen gewissen Charme.

Also ist einfach tief in einem Web-Server drin.

Du hast einfach die Fähigkeiten, die du in einem Nginx hättest.

Und ich meine, im Prinzip kannst du das ja alles mit Nginx-Modulen machen.

Kannst du ja Module schreiben.

Nur das Zuhörer haben gerade eben abgeschaltet.

Dann muss man das dann halt mittlerweile auch tun und das wird eigentlich keiner, ja, genau.

Ja, also okay, also wir werden nochmal, das kann man mit Kaddie und Traffic oder sowas nicht einfach machen.

Was kann man bei alternativen noch?

Nein.

Nein, leider alles nicht.

Nein, nein.

Also kannst du auch, du kannst es auch in Traffic reinbauen.

Musst du dann halt in Go programmieren.

Keddy ist auch Go, oder?

Ja, oder genau, du kannst halt auch in Go schreiben.

Können die beide Module?

Haben die nachladbare Module?

Ja, also Middle-Ware-System.

Das kannst du dann halt direkt über selber kompilieren.

Ja, also ist auf jeden Fall dann nicht mehr so richtig einfach.

Und es ist halt ganz was anderes als die Applikation, die du dann normalerweise so schreibst.

Aber genau, also wie kriegt Erlangen das denn jetzt eigentlich hin?

Es verwendet halt das sogenannte Actor-Model.

Oh, jetzt.

Oh, das ist manchmal.

Ich muss da auch gleich noch, wenn du noch besser klingen willst, musst du sagen, shared nothing concurred programming via message parsing.

Okay.

Schön, haben wir jetzt wissen alle Bescheid, oder?

Kammer?

Fertig für heute.

Nee, ich bin gerade.

Aber das ist so ein, also das ist was, was man sehr schnell.

Ich habe ja mal versucht, Erlang zu lernen.

Hab's dann wieder aufgegeben.

Aber das ist sowas, das ist sowas, so etwas Konzeptuelles, was man sehr schnell lernt, wo man sich aber ungeheuer schwer nur daran gewöhnen kann.

Also in dem Modell, in dem ich üblicherweise so lebe und programmiere in Python, da schreibt man halt ein Programm und das wird von oben nach unten abgearbeitet.

Und wenn ich eine Funktion aufrufe, dann ist es so, wie wenn ich die Funktion da eben an die Stelle hin kopiert hätte.

Im Wesentlichen so bis auf so ein paar Ausnahmen mit Rekursion und Scopes und so, ist das das Modell, was ich im Kopf habe.

Wenn ich eine Funktion aufrufe, dann ist es so, wie wenn die da jetzt steht.

Und in Erlangen ist das aber nicht so.

In Erlangen ist das Modell so ein bisschen anders.

Da schreibt man ein Programm und es besteht aus ganz vielen Prozessen.

Und auch was ein Prozess ist, ist da auch erstmal, es wird so ein bisschen ein Prozess ist.

Stell dir einfach einen Prozess vor.

Und die können sich dann Nachrichten schicken und zwar an ihre Mailboxes.

Also jeder Prozess hat eine Mailbox und da kann man sich Nachrichten hinschicken.

Und das Einzige, was diese Prozesse machen, ist im Wesentlichen Nachrichten aus ihren Mailboxes abrufen und die bearbeiten und anderen Prozessen Nachrichten in ihre Mailbox reinschicken.

Und das ist von der Vorstellung her was total verrücktes, was total Absurdes, weil wie kann man denn daraus ein funktionierendes Programm machen?

Das könnte man ja in Django auch machen, indem man irgendwie so ein Cache oder eine Datenbank nutzt, als diese Mailbox-Layer oder so.

Nee, kannst du da nicht machen, weil das tatsächlich da eine Entsprechung in der Maschine hat, weil diese Sachen alle gleichzeitig laufen.

Und das ist so ein bisschen die Macht davon, ja, das Coole davon.

Und Mailboxes und Processes müssen nicht eins zu eins sein.

Das heißt, du kannst an einem Mailbox viele Prozesse ranmachen oder ein Prozess kann mehrere Mailboxes bearbeiten, je nachdem, wie du es halt, wie dein System halt gerade an der Anforderung ist.

Okay, aber warum ist das jetzt so cool?

Das Coole ist, diese Prozesse heißen Actor.

Dieses System aus Prozess und Mailbox heißt Actor.

Und das hat eine bestimmte, oder so wie ich es mir vorstelle, hat es eine bestimmte Zuständigkeit.

Das System ist zuständig für Dateien ausliefern.

Wenn ich eine Datei ausliefern möchte, dann sage ich, muss ich nicht selber machen, sondern ich schicke nur eine Nachricht an die Dateien ausliefern Mailbox.

Und da ist irgendjemand und der bearbeitet die dann.

Das heißt, wenn ich entschieden habe, ich als Anwendungslogik habe entschieden, da muss jetzt diese Datei ausgeliefert werden, dann ist meine Arbeit beendet, indem ich eine korrekt formatierte Nachricht an die Mailbox-Dateien ausliefern schicke.

Dann bin ich fertig.

Und auf der anderen Seite dieser Mailbox ist halt irgendein weiterer Prozess, der macht nichts anderes als, da kommt eine Nachricht, ich soll eine Datei ausliefern an folgende Verbindung oder an folgende IP oder sonst was.

Also mache ich das.

Und dieser Prozess macht nichts anderes.

Das heißt, es gibt einen Prozess, der ist zuständig für, oder eine Mailbox, ja, einen Actor, der ist zuständig für Dateien ausliefern, es gibt einen Actor, der ist zuständig für Authentifizierung, es gibt einen Actor, der ist zuständig für die Datenbank, es gibt einen Actor, der ist zuständig für was weiß ich, SSL-Termination, was auch immer man haben möchte, ja.

Bühne frei.

Jeder Actor macht eine Sache und ist für eine Sache zuständig.

Und wenn jemand anders was machen soll, dann ist es einfach nur eine Nachricht.

So, jetzt könnte man sagen, okay, das ist ja in einem objektorientierten System nicht anders, ja.

Da schickt man Nachrichten von Klassen zu Klassen.

Der Unterschied ist, dass diese Actors selbst laufende Prozesse sind.

Das heißt, wenn ich eine Nachricht schicke, dann wird die halt gleichzeitig, die wird jetzt sofort bearbeitet.

Ich muss nicht warten, bis die Nachricht abgearbeitet ist von der Klasse und das kann ja sehr lange dauern, ja.

Wenn meine View-Klasse aufgerufen wird und ich eine Datei ausliefern muss, dann dauert es halt so lange, wie das dauert, die Datei auszuliefern und dann ist die Nachricht bearbeitet.

Sondern das sind wirklich einfach nur kurze Nachrichten.

Mach das, mach das, tu das.

Hier ist was passiert.

Also Events, ja.

Das sind einfach nur Dinge, die passieren sollen.

Oder Nachrichten, die in dem System relevant sind und die werden dann sofort weiterbearbeitet.

Und derjenige, der für die Authentifizierung zuständig ist, der kann sich der nächste, der kann sofort den nächsten Request authentifizieren.

So, das ist die eine Sache.

Die andere Sache ist, in Klassen ist es, wenn man eine objektorientierte Architektur, dann ist es sehr leicht, Daten zu verteilen.

Da gibt es diese, wir haben ja schon drüber gesprochen, ja, es gibt diese Sachen, wie man Klassen aufbauen sollte und dass die abgeschlossen sein sollten und dass man, dass die ihre privaten Daten privat halten sollen und dass nur das Interface und so weiter.

Aber im Endeffekt ist es ja doch irgendwie so, dass man schon ungefähr weiß, was diese Klasse wie macht.

Und auch, was die für Daten enthält.

Und dann manchmal ist es halt auch so, dass man auf Daten zugreifen muss, die halt da drin sind und die da draußen sind.

Das geht in diesem Actor-Modell überhaupt nicht.

In dem Actor-Modell gibt es nur eine Möglichkeit, mit einem anderen Actor zu kommunizieren und das ist über eine Nachricht.

Das heißt, alles, was in diesem Aktor-Modell passiert ist, du schickst Nachrichten.

Aber die Actor kann man dann klonen oder was?

Oder dass sie doch gleichzeitig irgendwas machen können?

An der einen Mailbox, weil du sagst was, oder?

Die Mailbox ist der Endpoint.

Du schreibst eine Nachricht und du schreibst die in den, tust die in den Briefkasten rein und dann bist du nicht mehr dafür verantwortlich.

Also die Workup-Programm, dass da zehn Leute gleichzeitig diese Mailbox bearbeiten, das kann dir völlig egal sein.

Weil das ist halt irrelevant.

FIFO oder FIFO oder sowas oder Methode und kannst dann einfach Dinge daraus nehmen aus der Mailbox.

Ja, also davon gibt es dann sehr, sehr viele.

Also das ist halt so, dass ich weiß nicht, also Tausende gar kein Problem, auch Millionen kein Problem.

Und das ist das kannst du quasi beliebig hochskalieren, sagen wir mal so.

Und das funktioniert ja immer.

Auch dynamisch neu starten, die werden auch dynamisch neu gestarten.

Und wenn so einer abbricht, ja, wenn einer kaputt geht, weil er irgendeine Nachricht nicht verstanden hat oder weil irgendwas ist, dann wird er halt gelöscht und einfach ein neuer gestartet.

So, zack, der ist jetzt weg.

Ja.

Was ja kein Problem ist, wenn sozusagen, also was man dazu noch sagen muss, genau, eine schöne Eigenschaft sozusagen für dieses Modell, die halt Erlangen da auch direkt mitbringt, ist, dass da das ja so eine funktionale Programmesprache ist, ist halt sowas wie Daten verändern.

Das geht halt einfach nicht.

Das ist prinzipiell nicht möglich.

Du kannst halt bloß Daten kopieren, aber das heißt, du kannst Sachen auch mal perfekt cachen und so.

Und es ist auch egal, wer da was macht, weil es ja sowieso immer nur das Gleiche.

Es ist halt nie, du kannst, es ist nicht möglich, dass jemand hinterher irgendwie Daten verändert hat und das in einem anderen State ist oder so.

Sondern, ja, wenn der State irgendwie kopiert wird und dann macht das halt eine andere Act, da ist es halt völlig egal, wer das jetzt war.

Ja, oder auch wenn der abstürzt und eine andere übernimmt das.

Ist egal.

Es ist völlig wurscht.

Die sind alle gleich.

Du hast eine Armee von identisch ausschauenden Schauspielern.

Ja, und man kann das halt auch nicht umgehen, weil das verbietet einem die Sprache.

Es gibt ja auch sozusagen eine Aktor-Implementierung in anderen Sprachen, es gibt diverse in C<unk> zum Beispiel, aber Duke.

Gibt es auch?

Acker.

Pi-Acker, ja.

Super Sache übrigens, sollte jeder verwenden.

Okay.

Ich habe nur gehört, dass es das gibt.

Ich weiß aber nicht.

Und dass es sich an der Scala-Acker-Geschichte orientiert.

Ja, genau, das kommt

von Skala her.

Wann, wann, wie, wo benutzt man das dann?

Wobei Skala ist ja

quasi Erlagen für.

Ja, für die Wettkraft, okay.

Wie benutzt man das dann?

Wann, dieses Piaka?

Ja, wenn du halt synchrone Sachen haben willst.

Das Problem an Pi Acker ist halt, dass das immer noch den Gill beachten muss.

Das heißt, du gewinnst nicht so ungeheuer viel.

Weil du immer noch in dieser mehr oder weniger Single-Threaded Python-Welt festhängst.

Aber das macht die Struktur einfacher.

Es löst dich davon ab, alles in einem Ablauf machen zu müssen, sondern du kannst sagen, so, dieses Ding ist jetzt verantwortlich für.

Und das hat folgende Ressourcen fest in der Hand und zack.

Aber was du halt nicht hinkriegen kannst und was das halt so ein bisschen, also ich meine, klar, du kannst natürlich dann sagen, okay, ich weiß, ich darf hier nur Immutable-Datenstrukturen verwenden und so, aber du kannst natürlich Sachen schon ändern, wenn du böse bist.

Und das geht halt erlangen nicht.

Ich habe gerade auch eine andere Bibliothek gefunden, die heißt Tespian.

Habe ich aber nicht reingeguckt, keine Ahnung.

Das ist nur ein Actor.

Das sind die Theaterschauspieler.

Ja, genau.

Also ich meine, man zahlt halt natürlich einen Preis für, also man zahlt den Preis vor allen Dingen in Hauptspeicher.

Also man muss halt alles kopieren, wenn man irgendwas verändern will.

Das ist halt auch das, was einen im Wesentlichen begrenzt, was die Anzahl der Aktor-Dinger halt angeht.

Wenn der Hauptsprecher voll ist, dann ist halt Schluss.

Und es ist halt auch ein bisschen langsamer.

Also wenn man jetzt sagen würde, okay, man macht das Ganze handoptimiert irgendwie mit Threads oder so, dann ist das wahrscheinlich schneller.

Aber sagen wir mal so, es ist halt ein sehr, sehr guter Kompromiss eigentlich, wenn es um Dinge parallel concurrent und in zuverlässig machen geht.

Und so diese letzte letzte Quäntchen Performance brauchen die meisten Leute ja dann eh nicht.

Ja, und dann ist es halt so.

Und selbst dann bist du halt

oft in so einer Situation, wo Stabilität einfach wichtiger ist.

Und die kriegst du da halt für umsonst mit dazu, weil es sehr schwierig ist, da diese VM zu crashen.

Und selbst wenn du irgendwas machst, was crasht, dann hast du halt deinen eigenen, dann hast du halt diesen einen Request gecrashed.

Aber der Rest läuft weiter.

Es ist quasi nicht möglich, diese Maschine abzuschießen.

Und das ist schon, das ist schon was, wo man auch mit Neid draufschauen kann, weil das ja in anderen Systemen relativ leicht ist.

Es ist eher so schwer, das Ding irgendwie am Laufen zu halten.

Da muss man immer irgendwie die ganze Zeit.

Ja, das ist da ganz angenehm.

Aber es ist

natürlich auch ganz klar ausgerichtet auf so Workloads, die parallel sind.

Also, also eben genau aus dem Telefonieumfeld her.

Jedes Telefonat selber braucht halt nicht ungefähr viel.

Also du musst halt dann irgendwie deine, was weiß ich, 16 Kilobit musst du durchkriegen oder deine, wie auch immer sie gerade runter haben.

Aber das ist ja nicht viel.

Aber du hast halt tausend Stück davon gleichzeitig in der Hand.

Und in anderen Workloads hast du ja andere, hast du ja andere Anforderungen.

Jetzt zum Beispiel Machine Learning.

Da hast du halt, da brauchst du halt eine Sache, die du hunderttausend Mal ausführen musst.

Und da ist es besser, Prozessoren zu haben, die das schnell machen können.

Deshalb hat sich das ja auch so ein bisschen anders entwickelt.

Und ich glaube auch, dass da der Hintergrund so ein bisschen anders ist.

Python kommt ja wirklich aus dieser, ja, ein Programm tut eine Sache, Welt, und da ist es dann halt einfacher zu sagen, okay, die Programme werden schneller, weil die Prozessoren schneller werden, weil die Single-Threaded Performance schneller wird.

Aber jetzt sind wir nun mal genau in so einem Umbruch, wo es tatsächlich so ist, dass eben Single-Threaded Performance nicht mehr schneller wird.

Aber dafür kannst du jetzt einen Computer kaufen, der 64 Cores hat.

Oder gibt es nicht von AMD sogar schon die mit 128?

Kann gut sein, ja.

Das ist genau.

Und das jetzt wird es halt, also sagen wir so, also das hat man ja in der ersten Sendung schon und ich würde da tatsächlich ehrlich gesagt beibleiben, also dass man das selten hat, dass man beides braucht.

Also du kannst ja problemlos 128 Python-Interpreter starten.

Also wenn du 128 Cores hast, dann hast du wahrscheinlich auch genug Hauptspeicher, um 128 Prozent zu haben.

Aber da hast du halt nur 128, kannst du 128 gleichzeitig beantworten.

Ja, ja, könnte ich nicht 12.800.

Aber wenn CPU dein Problem ist, und dann brauchst du, ja.

Also wenn I.O.

dein Problem ist, gut, aber dann brauchst du die ganzen Prozessoren eigentlich nicht.

Dann kannst du das auch auf einer CPU.

Also naja, ich weiß es nicht so genau.

Ja, also ich meine, man hat es selten, dass man beides braucht.

Und für beide Extremfälle gibt es halt sehr gute Lösungen.

Also den Data Science CPU-Verbrennen-Ding-Use Case, da gibt es super Lösungen dafür.

Den kann man jetzt nicht zum Webserven verwenden, aber das funktioniert super.

Sehr schöne Computer von Nvidia für mehrere hunderttausend Dollar.

Ja.

Würde ich nicht als Webserver einsetzen.

Nee, genau.

Das macht doch nicht so viel Sinn.

Und auf der anderen Seite ist halt irgendwie, weiß ich nicht, eben Lib, da kriegen wir den Übergang zu Python wieder hin.

Oder halt auch eben Node.js.

LibUV ist halt auch auf einem Prozessor, macht das schon irgendwie ordentlich I.O.

LibU what?

LibUV.

Das ist sozusagen die Event-Loop, die unter Node.js und halt auch bei Python, also normalerweise ein Produktivgeschichten nimmt man halt immer LibUV statt der Async.io Standard-Event-Loop.

Aha, Async IO.

Das ist Async IO.

Würdest du UV-Corn verwenden statt UK?

Also kann man auf jeden Fall, ja.

Und ja, man kann halt, bei Async.io ist es so, du kannst die Implementierung deiner Event-Loop kannst du halt austauschen.

Und du kannst halt entweder die Standard-Implementierung nehmen.

Oder du nimmst halt Lib UV zum Beispiel.

Und LibUV ist dann halt deutlich schneller.

Und ja, also zu der Theorie, ich weiß es jetzt ehrlich gesagt nicht so kurz genau, ich glaube, es gab einmal Lib-EV.

Das Ding ist auch schon ziemlich alt.

Aber das ist doch eine C-Bibliothek, oder?

Ja, ja, Lib-UV auch.

Genau, das ist, die implementieren das sogenannte Reactor-Pattern irgendwie und benutzen unten drunter Syscreuz.

Da mal ein Podcast dazu gäbe, so Pattern.

Ja, ich glaube, da müssen wir auch noch ein Teil irgendwie machen.

Ja, aber vielleicht, da sage ich nochmal genau was erklären, was halt das Reactor-Pattern vielleicht ist.

Und dann vielleicht auch nochmal, was halt Event-Loops überhaupt sind.

Genau, das haben wir das letzte Mal da aufgehört.

Ja, also Reactor-Patter.

Jetzt seid ihr geneigten Laserzug über das.

Du hast halt so Sys-Calls in Unix.

Da gibt es auch Unterschiedliche, je nachdem, welche Unix-Art man verwendet.

EPOL unter Linux.

Vielleicht machen wir noch ein bisschen nur DM anfangen.

Was ist ein Sys-Call?

Oh nein, oh mein Gott.

Ja, du musst mit Tief einsteigen.

Also sozusagen, das ist die Art, wie User-Space.

Mit dem Betriebssystem kommunizieren.

Also das, was jeder kennt, vielleicht ist sowas wie, du machst einen Pfeil auf.

Muss jetzt irgendwie an die Bits auf der Platte tatsächlich rankommen und tatsächlich bei Unix ist so der Sys-Call für alles, ist halt open.

Also das ist ja auch eigentlich der Trick bei Unix, dass man sagt so, es gibt nur einen Sys-Call.

Es gibt nur ein Sys-Call und es gibt eigentlich eigentlich ist alles ein Pfeil, genau.

Es ist völlig egal, was es wirklich ist.

Pfeil ist unsere Abstraktions für einfach alles.

Und also wenn man das annimmt, dann kommt man bei Unix ziemlich gut raus.

Und ja, genau, das ist halt die Art, wie man dem Kernel sagt, so ich hätte jetzt gern da zum Beispiel irgendwie Zugriff drauf.

Dann sagt man halt open.

Und das kann man eben dann eben nicht nur mit Files machen, sondern auch mit Netzwerkverbindungen, die ja dann in Unix auch nur Files sind oder Hauptsprecher ist auch nur Files oder halt irgendwie Pipes, Kommunikation zu anderen, ist auch alles immer nur ein File.

Man kommt ja sehr weit.

Der Bildschirm ist auch ein Pfeil, oder?

Ja.

Und die Terminals sind auch Files.

Ja.

Jetzt muss

man nur noch wissen, was Files sind.

Das ist abstrakt.

Das können wir in dieser Vorlesung nicht.

Es ist ein sehr, sehr, sehr, sehr, sehr simples Interface.

Es ist einfach unstrukturierte Daten und du kannst darauf zugreifen, indem du halt Sachen rausliest und reinspeichert.

Sortiert.

Und du kannst an einer bestimmten Stelle Abfolge von Bytes.

Ich kann hin und her springen, ja, ich habe so einen Zeiger, der Interface.

Ah, nicht jedes Pfeil kann hin und her springen.

Files können sagen, sie dürfen hin und her springen oder auch nicht.

Okay, dann habe ich jetzt ein Syscode, das macht einen Open, okay.

Genau.

Also insofern noch alles schick.

Das Problem ist jetzt natürlich, was.

Und das ist auch gar kein, das ist doch gar kein Problem, oder Jochen?

Also ich meine, da brauchst du noch keine Lib dafür, sondern du brauchst halt nur wissen, wie du das aufrufst.

Und das ist super nett und easy.

Und wenn du jetzt gegen deine, was weiß ich, Bibliothek, gegen deine Kernel, Bibliothek kompiliert hast, gegen deinen Kernel Header, dann kannst du die Sachen aufrufen.

Genau.

Warum brauchen wir jetzt LibEV?

Warum brauchen wir LibEvent oder Lib?

Ja, das ist sozusagen eine Abstraktionsschicht über den Sys-Calls.

Weil das Problem ist, du hast jetzt unterschiedliche Sys-Calls, je nachdem, welches Betriebssystem du hast, die eben so etwas machen wie, naja, du machst jetzt nicht einfach nur einen Pfeil auf und schickst da irgendwas, das kannst du auch, dann ist es aber blockierend und synchron.

Du willst jetzt aber nicht blockierend irgendwie lesen und schreiben, weil du möchtest ja gleichzeitig parallel irgendwie Datenströme in der Gegend herumschicken.

Weil wenn du blockierst, dann kannst du immer nur eins nach dem anderen machen und das ist ja, wenn du jetzt tausend Leuten gleichzeitig einen Pfeil schicken möchtest, geht das halt nicht so gut.

Und dafür gibt es dann halt andere Interfaces, die das möglich machen.

Und da gibt es dann halt so die uralten Geschichten in Unix sind halt so Select, der Select Syscall und Poll.

Und im Wesentlichen gibt man den, oh Gott.

Jetzt muss ich trotzdem kurz sagen, was Select ist und was Poll ist.

Ja, ja.

Also ich fange mal mit Poll an, du gibst Poll einfach eine Liste von File-Deskriptoren sozusagen, also offenen Files eigentlich mehr oder weniger.

Und dann wirst du irgendwie benachrichtigt, wenn da irgendwas passiert ist vom Kernel.

Und das Problem dabei ist halt, dass, also bei Paul kannst du halt irgendwie, ach Gott, das muss ich aber tief in Erinnerung kraben.

Also der Vorteil ist, du kannst halt beliebig viele Files da reintun, also beliebig viele Netzwerkverbindungen haben.

Der Nachteil ist irgendwie, es ist halt O von N oder sowas.

Also deine Zeit, die das im Kernel verbringt, wird halt immer mehr, je mehr du da reinsteckst.

Und bei Select war es so, dass das schnell ist, dass es irgendwie O von 1, aber du kannst irgendwie nur 1024 File-Deskripturen oder so wie da reinstecken.

Was ist das denn?

Ein Select jetzt, also im Unterschied?

Also im Wesentlichen geht es doch darum, dass du auf Daten wartest.

Das heißt, der Syscall heißt, du kannst sagen, ich möchte jetzt die Datei lesen und dann gibt es einen Syscall, der heißt Read Data oder wie auch immer der heißen mag.

Und der blockiert dann halt, da musst du so lange warten, bis die Daten da sind.

Und das ist bei einer Netzwerkverbindung echt blöd.

Das willst du nicht, genau.

Dann kannst du sagen, okay, wir modifizieren den und sagen, wir machen Read Data aber nicht blockierend.

Das heißt, wenn was da ist, dann kriegen wir das und wenn nichts da ist, dann kriegen wir halt zurück, es gibt gerade nichts.

Und damit kannst du das ja umsetzen.

Dann kannst du Polling machen, dann kannst du sagen, hier alle meine Netzwerkverbindungen, was gibt es denn jetzt, ja?

Aber Polling ist halt schlecht, weil dann ist aktives Warten.

Busy Waiting, genau, das verbraucht halt CPU.

Ja, und vor allem, während

du auf eins wartest, kann ja bei dem anderen was passieren und das bemerkst du dann halt erst, wenn du soweit bist, dass du das nicht so gut.

Bist du schon da, bist du schon da, bist du schon da, bist du schon da, bist du da, bist du schon da, bist du da, bist du schon.

Genau, aber wenn du, wenn du jetzt bei zehn Türen immer anklopft und sagst, bist du schon da, bist du schon da, dann kann es ja sein, dass du bei der zehnten Tür bist und bei der ersten Tür und bei der zehnten Tür passiert jetzt gerade was.

Und du merkst es aber erst, wenn du die anderen neun alle durchgefragt hast.

Das heißt, du hast nicht nur viel CPU verbraucht für was, was eigentlich nichts bringt, sondern du hast auch noch hohe Latenz drin.

Du kriegst die Nachrichten, du kriegst nicht sofort mit, dass irgendwas passiert, sondern du kriegst es erst mit, wenn du dazu kommst, danach zu fragen.

Und das ist natürlich schlecht, ja, weil du dann eben eine unnötige Latenz hast.

Du hast unnötige Wartezeiten, die du nicht verbrauchst.

Und jetzt wird es noch schlimmer, wenn du das nämlich naiv machst, dann kannst du so ein Problem haben, das Starvation heißt.

Wenn du sagst, wenn irgendwas passiert, dann fange ich wieder bei Tür 1 an nachzufragen.

Und dann passiert das nicht.

Und doch, doch, dann hast du nämlich Starvation, weil wenn bei Tür 10 irgendwas ist, da kommst du ja nie hin.

Weil wenn du vor immer irgendwas passiert, dann kommst du nie dazu, Tür 10 nachzufragen.

Das heißt, du musst dann auch noch aufpassen, dass du die in einer gewissen Reihenfolge abfragst, die nicht dazu führt, dass einer hier liegen gelassen wird.

Also Polling ist was ganz Schlechtes, wenn du auf Daten wartest in einer aktiven Verbindung.

Und deshalb gibt es diese Select-Syscall, wo du eben sagst, ich benachrichtige mich, wenn irgendwas von diesen 1024 oder eben jetzt, wie Jochen sagt, beliebig vielen irgendwo was passiert.

Wenn irgendwo was passiert, dann gib mir Bescheid.

Dann kriegst du quasi einen Interrupt.

Ah.

Genau, und also unterstützt.

Das gab's doch früher immer, das war noch so relativ nativ oder schneller ansprechbar.

Das musste man doch früher einmal selber konfigurieren.

Die Interruptor.

Die Soundfarbe gab es das, weil die müssen halt ihre Daten holen und die sagen so, jetzt, ich brauche Daten und dann musst du dich drum kümmern.

Da kannst du nicht sagen, ja, ich bin jetzt gerade beschäftigt mit Knacken.

Der Ton.

Genau, und also der Syscall, den man unter Linux dafür jetzt verwendet hat, nennt sich E-Pall, der halt irgendwie, ja, ist halt irgendwie Anfang der nuller Jahre, ich weiß nicht, seit wann das drin ist im Kernel, pfff, müsste ja irgendwer, aber schon sehr lang.

Und das Ding macht das quasi für beliebig viele Falldeskretoren und halt schnell.

Also das Ding ist richtig, äh, macht Laune, funktioniert dann alles super.

Und FreeBSD, BSD-basierte Unix, die nehmen dann eher sowas wie KQ.

Also FreeBSD, Mac OS, Mac OS und so.

Macht praktisch das gleiche.

Wie was?

Entschuldigung, ich wollte das

nicht nochmal aufschauen.

Der Syscall heißt einfach anders und der heißt KQ.

KQ heißt der.

Oder KQ, ja, genau.

Ja, KQ.

Die Leute mitschreiben, kleiner Schmutzigarritt.

Und genau, aber also es gibt ja subtile Unterschiede.

Bei Solaris hast du dann noch sowas wie DevPoll und so.

Also unterschiedliche Unix-Geschmacksrichtungen machen das halt irgendwie so leicht anders alles.

Und das willst du ja jetzt nicht, wenn du ein Anwendungsprogramm schreibst, alles nochmal machen müssen, damit du halt irgendwie alle Unix-Varianten unterstützen kannst.

Und dann brauchst du halt eine Abstraktionsschicht darüber, die halt dann unten drunter mit den Betriebssystemspezifischen Syscalls oder Interfaces redet, aber mit der du dann reden kannst, ohne das alles wissen zu müssen.

Und genau, das ist halt LibEV.

Und genau.

Das war LibUV, also das, was dann, das Ding ist, glaube ich, gestartet, irgendwann 2011 oder so, das Projekt.

Und hat für Unices, für Unix hat es halt LibEV benutzt einfach.

Das hat es einfach nur gewrappt.

Hat aber auch noch eine Windows-Geschichte mit dazu genommen, weil Windows macht das alles irgendwie anders.

Das implementiert halt nicht dieses Reaktor-Pattern sozusagen, wo du halt benachrichtigt wirst, wenn halt irgendwas passiert, sondern das ist ein Pro-ProRector, Pro Reactor.

Also der Select ist ein Reactor-Pattern?

Das habe ich noch nicht

ganz sagen.

Genau, das sind die alle.

Bei Unix hast du es immer so, das ist überall gleich eigentlich.

Was hast du nochmal ein Reactor-Tool-Mürst nochmal?

Nein, dass du halt, du kriegst halt benachrichtigt, wenn irgendwas passiert und dann kannst du irgendwas machen.

Warum heißt das Reactor-Pattern?

Weil du darauf reagierst, wenn irgendwas passiert.

Also ich bin

in dem Moment nicht der Aktor, der aktiv wartet, sondern du bist der Reaktor.

Du sagst, weck mich auf, wenn irgendwas ist.

Ich hatte irgendwie gerade eine Geräte entdeckt, die Reaktor wie abgeben.

Ja, und Windows macht es halt anders.

Da gibt es diese IO-Completion Ports.

Das ist auch alles nicht eine Datei, sondern ein Handle.

Ja.

Und da ist es halt so, man kriegt halt hinter, da passieren dann Dinge und der Kernel macht dann schon, zum Beispiel, er lest dann schon, also bei dem Reactor-Padern ist es halt so, da musst du dann schon auch selber lesen, du kriegst halt bloß benachrichtigt, also du könntest jetzt, wenn du wolltest, dann könntest du was lesen und kannst es halt machen oder nicht.

Und bei Windows ist es halt so, der Kernel macht das dann halt und dann sagt ihr dir halt, wenn irgendwas completed ist, was damit passiert ist und wo es liegt oder so.

Ich weiß nicht genau, keine Ahnung von Windows.

Wenn du das Handle weißt.

Ja.

Aber es ist halt eine grundsätzlich andere Art, damit umzugehen.

Und da gab es, glaube ich, tatsächlich auch, hat Microsoft selber irgendwie Code beigesteuert zu LibUV, meine ich.

Und hat den Teil halt geschrieben und dann haben sie das halt unter einem Interface sozusagen verfügbar gemacht und halt Lib-IV verwendet für Unix und dann den Microsoft-Teil für Windows.

Und sieht dann aber von der Anwendung, von der Anwendung gleich aus.

Und später haben sie dann aber LibIV wieder rausgeschmissen, glaube ich, und das ist dann selber nochmal alles geschrieben.

Naja, also wie auch immer.

Aber also es funktioniert.

Inzwischen ist es gut getestet, gibt ja genug Node.js da draußen und so.

Und funktioniert gut.

Und ist halt auch richtig, richtig schnell.

Und was diese Event Loop tatsächlich eigentlich macht, ist ja eben diese ganzen I.O.

Zeugs verwalten, aber halt auch Callbacks aufrufen.

Also du kannst zum Beispiel bei der Event Loop jetzt Callbacks registrieren für halt.

Also ein Event-Loop ist ein eigener Prozess, der läuft und der die ganze Zeit guckt, was für Events da registriert sind und die dann aufruft, wenn irgendwas passiert, oder?

Das Ding läuft immer, läuft in kann nur eine Event-Loop pro Thread geben.

Du kannst mehrere haben, aber nur in unterschiedlichen Threads.

Und ja, das Ding läuft halt.

Das ist halt sozusagen die innerste Loop in deinem Programm, wenn du was benutzt.

Das ist das, was mit LibUV interagiert, oder?

Das ist die Event-Loop.

Ja, also über das Lib-UV ist eine Implementation, ja.

Also so eine White-True-Schleife oder sowas.

Ja, ja, letztlich genau.

Das Ding, ja, wobei das nicht busy weightet, sondern das schläft dann halt auch, wenn nichts zu tun ist, aber sobald irgendwas zu tun ist, dann wird es sehr wach und agil und macht irgendwie Dinge.

Und in dem Tutorial, äh, in dieser Einführung in ASIC.io von Lukas Langer gibt es halt auch, da zeigt er die Implementation der Python-Event Loop, glaube ich, aus 3.4 oder 3.5, ich weiß es nicht genau.

Und das waren irgendwie so 20, 20 Zeilen, 30 Zeilen Python und es war tatsächlich eine while True-Schleife.

Und die hat im Wesentlichen nur gemacht, so geguckt, oh, welche Callbacks sollen jetzt gerade laufen?

Dann hat sie aufgerufen, dann noch irgendwie Signal-Handle gemacht und irgendwie, das war es im Wesentlichen.

Und dann noch geguckt, welche sind jetzt beim nächsten Aufruf, beim nächsten, bei der nächsten Iteration dran und das war es eigentlich fast.

Und das war die ganze Event-Loop.

Event-Loop ist tatsächlich dieser Loop und da muss man Signale registrieren oder was?

Die oder die da hinten?

Callbacks sind vor allen Dingen das, was man da rein tut, was dann da drin läuft.

Die stehen dann in irgendeiner Liste, die immer wieder zugegriffen wird.

Also ein gemeinsamer Speicher quasi der.

Also du sagst halt, wenn in Datei X irgendwas passiert, dann ruf damit diese Funktion auf.

Ja, aber also wie sage ich das?

Also das ist.

Da gibt es ein Interface dafür.

Du kannst Crawl zunehmen zum Beispiel für jetzt soll demnächst laufen oder mit einem bestimmten, zu einem bestimmten Zeitpunkt.

Also die Timer kannst dann auch Timer setzen und die werden halt ausgefüllt und dann wird halt überprüft, ist das jetzt dran mit dem Laufen oder noch nicht.

Also je nachdem, was halt so eine Event

Loop anbietet, ja.

Also es gibt ja da viele verschiedene Sorten Events.

Und genau so ein Timer, ja.

Im Wesentlichen sagst du halt, wenn du auf so einen Timer wartest, dein Python-Programm sagt, ruft eine Funktion auf, die sagt, ich möchte um 0 Uhr möchte ich, dass diese Funktion gestartet wird.

Und dann muss diese Event Loop ja im Wesentlichen nichts anderes machen, als zu sagen, ist es schon 0 Uhr?

Nein, ist es schon 0 Uhr?

Und wenn es 0 Uhr ist, dann sagt sie, ja, und dann startet

eben dieses registrierten Callback.

Diese Funktion und genau.

Also ein Callback ist einfach eine Funktion, ja.

Du sagst, ich möchte, dass eine Funktion aufgerufen wird.

Und die muss auch normalerweise schon fertig parametrisiert sein.

Also du kannst dann nicht sagen, mit folgenden Parameter, sondern du musst dann halt die so, ja, oder du gibst dir halt irgendwie mit, ja, aber im Wesentlichen sagst du nur, da soll dann ein Funktionsaufruf passieren.

Also im Prinzip iteriert quasi dieser ganze Loop immer durch diese gleiche Liste und guck, was da drin steht und versucht das dann auszuführen, was da halt irgendwie angeht.

Ja, nur halt schlau, ja.

Er iteriert da nicht die ganze Zeit durch, sondern er sagt zum Beispiel, wann ist denn der nächste Timer fällig?

Das kann ja, das ist um 0 Uhr, das sind jetzt noch, äh, sind jetzt noch eine Stunde 55.

Also kann ich eine Stunde 55, ich schlafe mal eine Stunde 54, ja, und dann kannst du dich da so rantasten.

Aber für die eine Stunde 54 musst du ja nicht immer gucken, ah, ist schon soweit, ist schon soweit.

Sondern die machen das halt schlauer.

Und das ist eben genau der Trick daran, dass du dich nicht drum kümmern musst, wie der das macht, sondern dass diese Event-Loop schlau genug ist, das für dich auf eine schlaue Art und Weise zu machen.

Ja.

Genau, richtig, da war noch ein Spezialdings dabei.

LPUV hat auch noch ein Threadpool irgendwie für, wo, glaube ich, Kommunikation mit Files und so.

Aber, also im Grunde, es abstrahiert alles weg, was man halt so, was Low Level unten drunter passieren muss, damit es halt funktioniert und man hat dann halt ein sehr schönes Interface nach außen.

Und wenn man jetzt Async.io zum Beispiel verwendet, dann kann man einfach das Async.io Interface verwenden und dem und Async.io sagen, verwende doch LibUV als Event Loop und dann benutzt es das Ding unten drunter.

Ja, und ein weiterer Trick, den es dann halt noch gibt, ist, das sind sogenannte Trampoline, also Callbacks.

Wenn man das genau wissen kann.

Wie das alles funktioniert, diese Videoserie von Lukas Lange angucken, der erklärt das alles sehr ausführlich.

Ich kann das jetzt nur so anreißen.

Aber im Grunde ist es so, Callbacks, die sich halt selbst wieder registrieren, sozusagen, weil man ja, also ich meine, wenn jetzt eine Funktion aufgerufen worden ist und gelaufen ist, dann ist ja dann eigentlich ja Schluss.

Aber du hast ja oft so Tasks, die irgendwie die ganze Zeit irgendetwas machen und ab und zu malen und dann wieder schlafen.

Also wie kann das zum Beispiel sein, dass die sich dann schlafen legen und wieder aufwachen und dann nochmal was anderes machen?

Das ginge ja eigentlich nicht.

Die Reaktivität anpassen, ja.

Wenn du gemerkt hast, da ist jetzt nichts zu tun, dann schlafen die länger oder kürzer.

Ja, und der Mechanismus, mit dem das geht, ist, die schedulen sich selbst wieder auf die Event-Loop.

Und ja, genau, man ist.

Das hat jeder von uns schon mal gemacht.

Ohne das Wort Trampolin zu kennen.

Ja, wahrscheinlich.

Genau.

Und noch, wenn man jetzt guckt, wie ist der Mechanismus eigentlich dafür, der das macht, dann sind das halt tatsächlich einfach nur Generatoren eigentlich unten drunter.

Ja, das ist doch der generelle Trick von Ace und Gaio, oder?

Das sind alles einfach immer nur Generatoren.

Ja, also man nennt es halt anders und es hat einen anderen Typ, aber es ist tatsächlich die fast das gleiche, ja.

Und man, also die Step-Funktion in dem Generator ist halt eigentlich das, was du dann halt wieder immer wieder in die Event-Loop reintust.

Und Await ist halt nur ein anderes Wort für Yield-From und Yield From ist halt genau das Ding, was halt die Generaturgeschichte da macht an der Stelle.

So hat noch Async.io auch angefangen, oder?

Dass man einfach gesagt hat: hey, wenn ich eine Menge von Generatoren habe, dann könnte ich die alle nacheinander mal ausführen lassen und die geben mir die Kontrolle zurück.

Die haben genau diese Eigenschaft schon.

Generatoren haben genau das, was man braucht, was man sagen kann, beim Generator kommen ja auch.

Beim Generator kann man ja sagen, okay, alles klar, jetzt gib mir nochmal das Link, es gibt mir das Ding so.

Ah, und jetzt stopp mal, bleib mal kurz stehen.

Du bist jetzt erstmal, machst jetzt erstmal nichts mehr und dann später kann man dem sagen, okay, und jetzt gibt nochmal wieder was.

Das heißt, es sind schon Funktionen, die man irgendwie so anhalten und weiterlaufen lassen kann.

Und wenn man das jetzt nicht nur aus der Ich kann ja jetzt Sachen rausnehmen, Perspektive sieht, sondern auch man kann ja Sachen reintun, dann hat man eigentlich schon alles zusammen, was man braucht, um das zu implementieren, ja.

Und tatsächlich, die werden alle gefährgescheduled.

Das heißt, also wenn man sich jetzt, naja, so wäre jetzt ein Schaubild ganz nett.

So als Klassenbildung.

Wenn man sich jetzt sozusagen als, also so ein, wie ist die Vererbungshierarchie an der Stelle?

Also was halt eine, also wenn man jetzt zum Beispiel Async Dev schreibt, ja, also Async Dev-Funktion ist was sehr ähnliches wie eine normale Funktion, die jetzt irgendwie Yield statt Return sagt.

Die wird nämlich intern in Python auch anders behandelt als normale Funktion.

Und auch dieser Was auch sehr überraschend ist für

Anfänger, oder wenn man das erklärt, dass ja vielleicht müsste man statt Dev einen Name irgendwie Gen-Name machen oder sowas.

Nein, nein.

Das schreibst du schon so hin, aber wenn du sagst Yield im Body der Funktion, dann wird das Ding anders behandelt und nicht mehr als normale Funktion.

Wenn man die Deklaration dann anders machen würde, vielleicht mit einem Gen, da statt einem Define, dann könnten sie einfach sein.

Ja, aber also dann halt an einer anderen Stelle und dann musst du aufpassen, dass die, dass das zusammenpasst.

Es ist schon okay so, wie es ist.

Es ist nur einmal am Anfang, wenn man es erklärt zum ersten Mal, dann ist es echt weird.

Ja, also im Grunde sind halt nur andere Schlüsselwörter, aber was man tatsächlich macht, ist halt ein Generator oder eine Funktion zu definieren, die halt ein halt irgendwelche Dinger, also einen Generator erzeugt.

Und wenn man jetzt die Worte ändert, dann hat man fast das schon, was Async.io macht, nämlich Async Dev, damit definiert man halt eine Funktion, die man anhalten kann und die man weiterlaufen lassen kann.

Und wenn man die aufruft, kriegt man nicht das Ergebnis der Funktion zurück, sondern eine Koroutine oder einen Generator.

Eine Routine, die man dann halt starten kann.

Genau diese Runde, bis er wieder Yield sagt, hat oder genau.

Und das Ganze ist verpackt.

Also wenn man jetzt, man hat diese Ansinnfunktion und dann hat man diese Koroutinen und diese Koroutinen verpackt in ein Future, sozusagen das Interface von einem Future sind ein Task.

Und dann sind wir eigentlich komplett, weil das, was tatsächlich, was man haben will, sind eigentlich Tasks.

Das ist halt so das, was eigentlich die Low-Level-Async.io-Geschichte ist.

Also Future hat man ein erwartbares Ergebnis, oder?

Ja, ein Future ist sozusagen auch nur ein Interface für, also einem Future kann man halt fragen, so bist du fertig?

Und dann sagt das halt ja oder nein.

Also dann.

Oder man kann ein Result für ein Future setzen.

Dann kann man sagen, so Future.z-Result, irgendwas.

Und dann, wenn man sagt future.don, dann sagt das, ja, ich bin fertig, ich habe ja einen Result und dann kann man das Result auch holen.

Und man kann auch sagen, sogar verketten.

Man kann die verketten beliebig, genau.

Man kann auch solche Sachen sagen wie, wenn du fertig bist, dann ruf folgende Funktionen auf.

Folgendes Future.

Ja, und das kann man mit beliebig vielen wieder machen.

Und die gehen auch alle wieder auf die Event-Loop.

Das ist auch ein interessanter Unterschied, habe ich jetzt, als ich da so ein bisschen was drüber gelesen habe, habe ich das dann gesehen.

Es gibt ein Node.js macht das anders und dann, es gab da auch einen Vortrag von dem Ryan Dahl, also der Node.js mal irgendwann entwickelt hat.

Ist jetzt auch schon wieder was her, 2018 hat er den gehalten und meinte, so, ah, Designfehler in Node.js früher haben.

Also einer der Fehler ist halt, dass es eben nicht so, dass auch diese Promise-Geschichte in JavaScript nicht, dass Node.js da nicht so wirklich drauf basiert, sondern dass sie halt auch viele Callbacks haben, die dann direkt ausgeführt werden.

Und dann haben sie das Problem, dass Netzwerk dann doch nicht so gut funktioniert, weil sie teilweise nicht kontrollieren können, wann welche Callbacks ausgeführt werden und sie dann irgendwie, keine Ahnung, kann kompliziert Backpressure kriegen an, Probleme kriegen an diversen Stellen und das dann alles irgendwie wie ein Kartenhaus in sich zusammenfällt.

An der Stelle bräuchten wir vielleicht mal, was wir reden, dass wir Callback aus Candle.

Genau.

Und in Python ist es halt so, da wird das alles wieder, also die ganzen Callbacks der Future, sie gehen auch alle wieder zurück in die Event Loop und werden ganz normal gescheduled und das ist alles fair, sozusagen.

Also kein Callback, das ist ein Callback, das ist ein Callback, das ist ein Backcallback.

Im Wesentlichen ist dann jeder Funktionsaufruf eben so ein Yield-Punkt, oder?

Ja.

Beziehungsweise, genau, an der Stelle findet dieser Übergang statt.

An der Stelle geht es zurück in die Event Loop und dann halt in den nächsten Callback.

Ja genau, aber das ist ja eben genau wichtig, sonst.

Also damit dieses kooperative Multitasking hier funktioniert, dass die Prozesse einfach regelmäßig oder in möglichst kurzen Abständen hielten, damit eben die Event Loop andere Sachen

machen kann.

Genau, wenn man das nicht macht, hat man ein Problem.

Ja gut, dann ist halt, dann hältst du halt im Wesentlichen die Event Loop an.

Also wenn einer von denen hängen bleibt, sag ich mal, dann hat auch die Event Loop wenig Möglichkeiten, da was zu tun dagegen, weil die halt nie wieder dran ist.

Und das ist zum Beispiel in der Airlage-Welt anders.

Wenn da ein Aktor, die haben auch natürlich Monitoring eingebaut, automatisch.

Das heißt, man kann da Timeout setzen und wenn der Timeout erreicht ist, dann wird halt der Aktor abgeschossen.

Ja, ja, also ist das.

Das ist halt da nochmal nochmal anders, ja.

Ja, und dann habe ich auch noch so ein bisschen Benchmarks gemacht.

Ich wollte einfach mal gucken, wie schnell ist das denn alles so ungefähr und das war, das war auch teilweise ganz interessant.

Also bei Node.js kommt man ungefähr so bei, also ich bietet einem dann, ich habe Nuxt, glaube ich, irgendwo mal deployed und dann, also wenn man das startet, man kriegt nicht mal die Option, das auf mehreren Prozessen laufen zu lassen oder so, sondern man kriegt halt irgendwie einen Prozess mit der Event-Loop, das war's.

Aber der macht halt dann auch schon so irgendwie 7000 Requests pro Sekunde oder so.

Wenn man jetzt einfach nur ein Stückchen Hello World JSON zurückgibt.

Und das ist respektabel.

Das ist schon sehr schnell.

Und wenn man das konfigurieren könnte, das was ich nicht konnte, aber dann kann man das bestimmt auf mehreren Prozessoren auch laufen lassen.

Und das wird dann wahrscheinlich in einer ähnlichen Richtung, weil es die gleiche Event-Loop ist, liegen wie wenn man jetzt irgendwie einfach nur Starlet nimmt oder so, halt Async-Web-Server und dann Lib UV drunter und auch wieder so Hello World JSON zurückgibt, dann kommt man so auf 35.000 Requests pro Sekunde bei einer 8-Core-Maschine.

Irgendwie meine 8, also bei meinem.

Es ist etwas weniger als 7000.

Nee, mehr.

Aber es ist ja auch auf.

Es ist etwas weniger als 7000 pro Core.

Ja, das kann sein, genau.

Es ist ein bisschen weniger, genau.

Du brauchst auch ein bisschen.

Aber es ist, es ist, es ist, auf einem Prozess ist es aber ähnlich.

Auf einem Prozess ist es fast gleich.

Also es machte echt kaum einen Unterschied.

Ja, okay.

Sie werden

halt auch im Wesentlichen nicht viel anderes machen.

Das sind ja kurze Funktionen, die ausgeführt werden, wenn so ein Deb kommt.

Ja, und die Latenz war auch fast gleich.

Tatsächlich bei Node.js ein bisschen konstanter als bei Python.

Aber auch so, also tatsächlich die Netzwerk-Latenz zwischen den beiden Rechnern, auf denen ich das probiert habe, war so 2-3 Millisekunden.

Und die gemessene Latenz war dann so 12, 13 Millisekunden immer.

Sowohl bei Node.js wie auch bei Python.

Auch wahrscheinlich eben die Latenz von LibUV halt.

Aber das ist auch schon ziemlich gut, also kann man nicht merken.

Wenn man jetzt Django nimmt und nicht irgendwie so einen rohen Async-Server, also wie Juvicorn habe ich verwendet halt als Applikationsserver.

Wenn man jetzt Jubicorn nimmt und Django, dann sieht das halt ein bisschen anders aus.

Dann ist halt leider, also da gehen insgesamt nur so 3000 Requests pro Sekunde durch ungefähr.

Wahrscheinlich liegt das irgendwie an diesem ganzen Middleware-Stack oder ich weiß nicht genau, woran es liegt, aber das ist.

Ja, der macht halt sehr viel.

Macht halt sehr viel Pro View.

Ja, also das ist deutlich weniger und es ist halt auch, die Latenz ist halt deutlich höher.

Die ist irgendwie direkt bei so 30 Millisekunden oder sowas.

Ich meine, das ist immer noch nicht viel, aber es ist halt dann schon mal so, puh, ui, das ist schon, ich meine, es ist alles völlig irrelevant, ja, also nicht, dass sich jemals irgendwie so klar.

Die Zahlen sind halt schon deutlich unterschiedlich.

Ja.

Und was ich dann krass fand, ist, wenn man Django nimmt mit Junicorn und zum Beispiel G-Event-Workern, dann ist das auf einer CPU auch so bei 8000 Requests pro Sekunde.

Also sogar noch ein bisschen schneller als CPU.

Wie kann das denn sein?

Auch mit relativ wenig Latenz.

Also, das ist, hat mich auch gewundert, dass ich so, wow, krass, wusste ich, hätte ich jetzt nicht gedacht.

Also, das war, das fand ich ganz beachtlich.

Und auch Latenz besser.

Aber du musst kannst es nicht als ASCI laufen lassen, sondern dann als über Whisky-Interface.

Und dann kannst du natürlich viele Dinge so nicht mehr machen.

Ja.

Aber da ist das dann gar nicht mehr so langsam.

Ich glaube, irgendwie momentan ist es halt noch so, dass die ASGI-Geschichten nehmen irgendwie einen Sonderweg in Django und dieser Sonderweg ist irgendwie ein Stückchen langsamer.

Ja, aber keine Ahnung.

Aber da würdest du jetzt dann natürlich auch nicht deinen File-Server bauen.

Also würdest du dich trauen, einen File-Server mit Django, ASCII, Yubicorn zu machen?

Ich glaube, das ginge wahrscheinlich sogar tatsächlich.

Also wahrscheinlich wäre das schon.

Dann würdest du

den raus tun in den Starlet reintun.

Ja, das wäre eben auch so eine Sache.

Wahrscheinlich würde ich es eher mit sowas wie Starlet probieren oder FastAPI oder so.

Genau.

Einfach deswegen, weil das da so seamless ist quasi.

Das ist halt irgendwie dafür schon gebaut und das funktioniert einfach so.

Und was ja auch toll ist, du kannst ja auch über ASCII halt mehrere Applikationen haben.

Du nimmst halt einen Applikations-Server und sagst dem halt unter der URL ist es halt irgendwie, deine ASCII-Applikation ist halt jetzt irgendwie Fast API oder sonst irgendwas.

Ja, klar.

Und unter der URL ist es halt Django.

Gar kein Problem.

Und gibst denen halt unterschiedliche Funktionen mit und dann ist das halt so.

Sodass du halt auch sowas machen.

Wenn du es jetzt schaffst, irgendwie zum Beispiel Sachen zu authentifizieren, du kriegst ja das gleiche Cookie, Session-Cookie zum Beispiel, und dann kannst du natürlich auch die Autorisierung in irgendwas anderem machen und nicht unbedingt in Dango-Django.

Wenn das geht und das geht bestimmt irgendwie, dann kannst du auch das Ding dazu verwenden, die Files auszuliefern.

Du könntest es über einen geteilten Cache oder irgendwelche anderen Messages machen, dass du quasi.

Dass man das andere Ding dann halt irgendwie fragt, ja, das könnte man wahrscheinlich auch machen.

Sogar über dieses AGI-Interface könnte man auch machen.

Ja, also wie auch immer, das kriegt man auf jeden Fall hin, denke ich.

Und dann bräuchte man vielleicht diese ganze Nginx-Geschichte schon nicht mehr und kann es einfach auch alles direkt in Python machen.

Ja, gut, irgendwas brauchst du davor, um es zu terminieren.

Also SSL-Termination.

Genau, das willst du nicht.

Also da ist man eine aktuelle Geschichte, ja Traffic.

Und ich, also ich fand es haklich zu kontrollieren.

Dreifig für die Leute, die mitgoogeln wollen.

Und ja, das ist so ein Load Balancer, TCP, HTTP und mit eingebautem SSL.

Es ist hauptsächlich ein Load Balancer, oder?

Habe ich so verstanden.

Ja, ja, ja.

Die machen gar keinen Webserver-Kram.

Also da gibt es auch diverse SSL-Termination und Load Balancer.

Ja, genau.

Und das Ding ist in Go geschrieben und performt auch.

Es ist auch so, wenn man SSL anschaltet, habe ich dann natürlich auch getestet.

Wie ist das eigentlich, wenn man jetzt SSL anmacht?

Ja, es verbrennt gut CPU und es wird dann alles nur noch halb so schnell.

Aber okay, das ist ja gut, klar, dass das was kostet.

Das ist ja irgendwie logisch.

Ja, gut, aber das sind ja Kosten, die man, die, also da kommt es halt nicht drum, oder?

Ja.

Die hast du halt irgendwo.

Genau, und ja, also das war eigentlich, also insofern würde ich sagen, also Django ist halt momentan noch im Vergleich zu Node.js und reinem Ubicorn irgendwie ein Stück langsamer.

Woran es genau liegt, weiß ich nicht.

Aber es ist auch schnell genug wahrscheinlich für alles, was man irgendwie so damit machen möchte.

Insofern eigentlich kein großes Problem.

Und dann habe ich auch nochmal Erlang getestet.

Und Erlang war Erlang war quasi genauso schnell wie Juvicorn auf allen CPUs.

Hat auch irgendwie alle CPUs komplett ausgelastet und hat halt auch so 35.000 Requests pro Sekunde ungefähr gemacht.

Und aber was ich total überraschend fand, und das hat mich auch beeindruckt, ehrlich gesagt, war, dass die Latenz, also du hast ja dann immer so, also die meisten Requests liegen halt alle in so einem engen Korridor von Zeit, äh, Latenz.

Und dann du hast halt so ein paar Ausreißer irgendwie so.

Und eigentlich schon eher fies viele, weil manchmal dauern Dinge ja dann länger und das sind wir eigentlich auch nicht.

Und bei Erlang hat man das praktisch gar nicht.

Die brauchen alle genau gleich lang.

Und alle nur so drei Millisekunden.

Die Latenz zwischen den beiden Rechnern, wenn man Ping macht, sind halt irgendwie 2,47 Millisekunden oder sowas.

Und die Latenz bei den Erlang-Dingern ist halt drei Millisekunden.

Also, wow, krass.

Okay.

Das ist ja.

Ja, das ist eben diese Telefonie, ja.

Das ist einfach ein Real-Time-System.

Und das merkt man eben an so einer Stelle ziemlich deutlich.

Also da waren halt eben, also ja, das fand ich durchaus auch beeindruckend.

Ja.

Aber wie kann man jetzt diese beiden Welten verheiraten, Johan?

Wie würdest du jetzt?

Kann man ja auch machen.

Man könnte ja auch sagen, okay, man lässt das über den gleichen Loadbalancer gehen.

Und wenn man einen Loadbalancer hat, ja.

Ja, okay.

Man braucht irgendwas in der Richtung und dann könnte ja auch zum Beispiel Erlangen die Sessioncookies von Django kriegen, weil es ja die gleiche Domain.

Ja, wobei Session Cookies reichen ja alleine nicht aus.

Du hast ja oft bei Authentifizierung hast du dann irgendwelche Datenbankaufrufe, ob du welche Dateien du sehen darfst oder welche Bilder oder was weiß ich.

Ja, ja, klar, okay.

Aber du kannst ja, du kannst ja ja auf die gleiche Datenbank gehen.

Das könntest du ja machen.

Ja, nee, aber klar, eine Lösung, die ich mal gesehen habe, ist, dass du das über S3-Buckets machst und dann solche Tickets mitschickst, weil da kannst du so Authentifizierungstickets machen.

Du machst über welche Tickets auf welche Buckets.

Ist egal jetzt, das Wichtige ist, du hast zwei Systeme und das eine System sagt dem anderen, ja, du darfst die Datei ausliefern oder nein, du darfst sie

nicht ausliefern.

Und das eine ist ein Erlangen und das andere ist Dunglo zum Beispiel.

Und sowas könnte man da ja prinzipiell auch machen, dass du sagst, du hast irgendwie so eine interne Schnittstelle, die dir aufruft und sagt, darf dieser Session-Cookie diese Datei abrufen.

Ja, das gibt es.

So was könnte man machen, dass du quasi da eine interne Schnittstelle hast.

Weil das brauchst du auf jeden Fall.

Wenn du das alles in ASCII hast, hast du auch eine interne Schnittstelle.

Auch wenn du eben Starlet und Django zusammenverwendest, brauchst du auch eine Schnittstelle.

Das ist dann halt eine Python-Funktion.

Wenn du zwei VMs quasi in einem Load Balancer zusammentust, hättest du auch eine Schnittstelle, die dann halt aber eine HTTPstelle.

Was ja okay ist, ja.

Was ja prinzipiell möglich ist.

Und dann hast du ja wieder so eine Situation, ich meine, Extend-File ist ja auch nichts anderes als so eine Schnittstelle, ja, die sagt, liefere diese Datei aus.

Der haltiert ein kleines bisschen anders.

Aber ich wüsste jetzt nicht, dass es da was gibt, was vorbereitet ist.

Nee, da muss man dann selber, also ich habe tatsächlich auch jemanden schon irgendwo einen Blog, ich habe dann nur so ganz kurz danach gegoogelt und dann habe ich jemanden gefunden, der einen Blogpost dazu geschrieben hat, wie man Django Sessions von Erlang aus authentifizieren kann.

Und der Matter, also der Fazit von dem Blogpost war irgendwie so, ja, ja, das geht.

Aber es war.

Das ist ja im Wesentlichen eine Datenbanktabelle, da steht der Session-Kookie drin und ein serialisiertes, ein Base 64-serialisiertes JSON.

War das, ja, ja, das geht, aber lass es lieber oder war das ja geht, aber.

Nö, der brauchte das für irgendwas.

Hab es halt halt mal so gebaut.

Und es war jetzt natürlich schon fummelig und es ist nicht so, dass das irgendwie, dass man das irgendwo keine Konfigurationsoption oder so, dass man jetzt sagt, Django ja, aber man muss das halt.

Aber es geht schon.

Also insofern, ja.

Ja, und das ist auch nicht super kompliziert schlimm.

Also es ist nicht, du musst jetzt hier den internen Code von Django lesen und verstehen und da ändert sich alle meine Release, sondern es ist halt schon, du musst auf die Datenbanktabelle zugreifen und Base 64 dekodieren und JSON lesen und fertig.

PPX install L.

Ja, genau.

Oder halt keine Ahnung, wie es bei Airline heißt.

Beam install Python.

Django.

Ja, ja.

Ja, aber ja, fand ich, fand ich, fand ich ganz halt überhaupt.

Fast API habe ich ja nicht jetzt so ein bisschen mit beschäftigt, mal.

Zuerst, ich habe das immer mal schon verfolgt, so dass es dachte, oh, ist eigentlich ganz interessant.

Und jetzt habe ich es ein bisschen intensiver mir angeguckt und das ist wirklich eigentlich ziemlich cool, muss man sagen.

Auf der anderen Seite, also auf der einen Seite, sehr cool, auf der anderen Seite, ich vermisse Django, bei Django eben schon solche Sachen, dass es halt, da ist halt Registrierung, Authentifizierung, also wobei, ehrlich gesagt, ich finde es fast noch ein bisschen zu wenig.

Also Registrierung muss man ja auch immer dann schon überlegen bei Django.

Aber das halt zumindest Authentifizierung und so halbwegs eigentlich alles schon drin hat.

Und bei FastAPR, das macht man schon mehr oder weniger so roh selber.

Und das ist halt ein bisschen so, okay, ich muss ja wirklich, man hat die Hash-Funktion auswählen und ja.

Hat ja auch einen gewissen Security Impact.

Ja, ja.

Die Verantwortung

will ich gar nicht haben.

Don't do it yourself, ja.

Try.

Ja.

Und also insofern, da muss man halt dann eine ganze Menge Dinge tun, die, die man vielleicht gar nicht machen will, aber auf der anderen Seite ist es halt so, man sitzt halt auch wirklich mit dem Hinternroh auf der Performance und kann halt auch, wenn man jetzt müsste.

Man muss zwar nie, aber man könnte.

Man muss doch eigentlich gar nie richtig.

Wir lösen es durch mehr Prozessoren.

Ja, auf jeden Fall, genau.

Fast.PI eigentlich auch eine sehr, sehr schöne Geschichte und macht diverse Dinge richtig.

Also zum Beispiel, dass das API-Interface, dass das Webinterface halt so komplett integriert ist und alles ist halt, das macht Dinge schon deutlich einfacher.

Und ja, also ich bin mal gespannt, wie sich das noch entwickelt, aber das sieht schon, also ich Flask habe ich mir auch so ein bisschen angeguckt.

Flask ist schon so ein bisschen schwieriger mit Async, also da gibt es dann auch so Geschichten, ich weiß nicht, wie hieß denn das?

Quart oder ich weiß es nicht mehr genau, wo man das irgendwie so miteinander verheiraten kann, aber ehrlich gesagt, ich glaube nicht, dass ich Flasks noch wirklich verwende.

Also jetzt so, weil eben Starlet oder Rest.

Oder ist halt, du hast und es ist halt irgendwie deutlich moderner.

Ja, den Eindruck hatte ich auch.

Es gibt Leute, die verwenden es noch.

Ich meine, wir kennen ja beide Leute, die noch Pyramid verwenden oder BFG

oder im Webverwender.

Ich meine, das ist natürlich auch so eine Sache, wenn man sich da einmal dran gewöhnt hat und da viel drin gemacht hat, dann ja, bevor man den

eigenen Vendor-Login.

Ja, ja, hat man sich dann selber eingeschlossen.

Genau.

Ja, letztens habe ich auch noch so einen Podcast gehört mit einem, jetzt habe ich leider den Namen, nicht mehr parat, auch ein Python-Urgestein, der Arbeit bei Instagram und erzählte so und plauderte so ein bisschen aus dem Nähkästchen, was sie da so alles machen.

Und da waren auch so ein paar Aspekte noch dabei, die ich noch nicht so kannte.

Wie zum Beispiel, das war mir nicht klar, dass Instagram schon seit Jahren auf ASGI, so, nicht ASGI, also die hatten den Standard gab es nicht, aber auf irgendeinem Async-Interface zwischen Applikationsserver und Anwendung umgestiegen ist, obwohl sie ja eigentlich Django verwenden.

Aber den Teil haben sie halt tatsächlich umgebaut.

Und das war, weil das für sie dann wohl doch schon sehr wichtig war, dass das halt geht.

Ja, ja, gut.

Wenn du viel Rechenlast hast und wenn du viele Dateien auslieferst.

Ja.

Und also das auf der anderen Seite war, sie waren lange auf Django 1.3.

Sind dann jetzt umgestiegen.

Und das war auch irgendwie wohl der Treiber hinter dem Umstieg auf Python 3, weil dann Async alles sehr viel fluffiger wird.

Und sind jetzt auf Django 1.8 und das hieß halt so, das wird sich wohl auch nicht mehr ändern.

Das ist jetzt die letzte Django-Version, die sie halt irgendwie nehmen.

Wie es gibt die letzte Version, die sie haben.

Und ja, das war es dann da irgendwie.

Sie haben halt einige Teile komplett, die quasi identisch geblieben sind.

Also irgendwie das ganze Request, Response-Handling ist irgendwie, auch die Mittelwehr-Geschichten ist alles gleich geblieben.

Auch der View-Layer ist mehr oder weniger komplett intakt.

Aber also bis auf dass sie halt da eine ASI-Schnittstelle dazwischen haben.

Aber was sie komplett ausgetauscht haben, ist irgendwie, also alles, was man irgendwie Pluggable austauschen kann, ist ausgetauscht.

Und den OR haben sie auch ausgetauscht.

Weil sie irgendwann Schaden mussten.

Da brauchst du mehr der Kontrolle dann irgendwann.

Ja, und Schaden zu der Zeit ging das.

Es geht ja inzwischen in Django auch so halbwegs, aber damals ging das halt nicht.

Aufteilen von Atemangfragen bei verschiedenen.

Ja, also der Königsweg bei Datenbanken, die zu skalieren, ist ja einfach immer mehr Hauptsprecher reinstecken oder mehr Prozessoren, so lange wie halt geht.

Und wenn man denkt, ja, jetzt geht nicht mehr, dann halt einfach nochmal.

Eine zweite Datenbank.

Dann musst du halt aufpassen, wo du deine Daten nicht falsch ist.

Wisst ihr, wo das Wort herkommt?

Das ist ein sehr schönes

Ultima Online.

Genau.

Das Wort Shard heißt ja eigentlich so ein Bruchstück.

Und es kommt tatsächlich aus der Ultima Online-Welt.

Die Geschichte von Ultima Online ist, dass der Weltstein in viele kleine Steine zerbrochen ist.

Und jeder von diesen Shards ist jetzt eine Welt für sich.

Und das heißt, wenn du eben in Ultima Online dich mit einem Server verbindest, dann heißt er nicht Server, sondern Shard.

Und das war deren Trick, wie sie so eine große Benutzerschar handeln konnten, indem die die einfach auf verschiedene Bruchstücke von diesem Weltstein verteilt haben.

Und da kommt dieses Wort Sharding her.

Weil das ist ja schon ein sehr spezifisches Wort, dass du eben einfach sagst, das ist eine eigene, abgeschlossene Welt und du kannst nicht aus dieser Welt raus.

Ja, genau, und das musste Instagram mit denen, musste halt auch die User dann irgendwann aufteilen auf unterschiedliche Datenbanken.

Und dann hatten sie das zuerst so gemacht, dass quasi alle deine Daten, wenn du jetzt als User auf irgendeiner Datenbank lagst, dann alles, was du, also dein kompletter Feed und der ganze Content von denen, den du folgst, der lag dann halt auf deiner Datenbank.

Was ja auch irgendwie Sinn macht, weil dann die ganzen Quellies gehen halt nur zu einer Datenbank und dann ist eigentlich schön.

Und dann war irgendwie Justin Bieber oder sowas.

Ich weiß es nicht genau.

Irgendwie hieß es halt so, jeder kannte die User-ID von dem und wenn die irgendwo aufgetaucht ist, dann war immer irgendwie All hands on deck-Zeit und man musste halt, weil immer wenn der gepostet hat, hast du natürlich das Problem, der hatte halt irgendwie Zillionen Follower und der Content, den er da irgendwo in seiner, der musste dann halt auf alle Datenbanken repliziert werden.

Das hat dann einen riesen Update-Strom ausgelöst, weil also sobald der irgendwas abgerittet hat, wurde da dann halt in quasi jede Datenbank reinrepliziert.

Und das ist natürlich dann nicht so gut.

Das ist doch eine generelle Eigenschaft von so Netzwerk,

von so Social Graphs, dass wir so eine exponentielle Verteilung haben.

Dass es ein paar Knoten gibt, die mit allen verbunden sind und alle anderen haben nur ein paar Verbindungen.

Also ein zentrales Webding.

Die Spinne.

Ja, nee, dass du eben so eine Verteilung hast, wo es beide Extreme gibt.

Du hast ganz, du hast viele Knoten oder einige Knoten, die ganz viele Verbindungen haben und du hast aber auf der anderen Seite auch ganz, ganz viele Knoten, die ganz wenige Verbindungen haben.

Also die, das ist irgendwie irgendwie.

Ja, irgendwo im Zentrum der Gap ist irgendwie so eine große Graswolke, wo ganz viele der Edges gerne sitzen, die gleich

verteilt und so ähnlich.

Ist es nicht sogar so, wenn du so einen random Graph baust, wenn du in so einen Graph random Edges reintust, dass du dann immer so einkriegst?

Das kann sein, das war nicht.

Meine Graphentheorie-Vorlesungen sind lange her.

Naja, also jedenfalls fand ich das ganz auch witzig, fand ich, dass dann wurde irgendwann gefragt, so ja, wie lange dauert das eigentlich, wenn man die Tests?

Oder wie viel, wie viel Code ist das eigentlich so?

Naja, keine Ahnung.

Wie viele Millionen Zeilen irgendwie.

Und wie lange dauert das eigentlich, die Tests durchlaufen zu lassen?

Ja, also auf einer Maschine hat das schon ganz lange keiner mehr probiert.

Sie haben sich halt auch so ein eigenes Ding gebaut, was dann halt die Tests irgendwie an diverse Maschinen.

Night leaves.

Auf dem Teststart lief es, auf dem anderen nicht.

Ja, aber das dauert wohl tatsächlich nur 15 Minuten.

Also und das machen sie auch nur, also normalerweise reicht es irgendwie die Lokaltests, um dich herumlaufen zu lassen, um zu sehen, ob das irgendwie alles noch funktioniert oder nicht.

Und sobald es dann halt in Produktion geht, muss es halt einmal komplett durchlaufen und das dauert dann halt auf X-Rechnern, 15 Minuten ungefähr.

Ja gut, aber das ist doch trotzdem noch cool.

Also, die release

in 15 Minuten durchzutesten, das ist ja der Hammer, da könnten sich ja viele Firmen, das dauert ja bei vielen anderen Projekten Monate.

Ja, genau.

Und in diese ganzen Teile fand ich das auch, da dachte ich mir so, oh, das ist aber auch respektabel.

Und was ich auch gut fand, ist, dann hieß so, ja, wie macht ihr das eigentlich als Entwicklungsmodell mit Branches oder wie auch immer.

Und dann hieß es so, naja, Branches, das können wir schon ganz lange nicht mehr machen, weil es sind einfach zu viele Entwickler.

Die haben halt tausende Entwickler, die da drum rumschreiben.

Und sobald du einen Branch irgendwie weggehst, dann kriegst du nie wieder zurück, weil du gehst einfach in den Konflikten unter.

Das ist zu schnell.

Das ist einfach zu schnell.

Das heißt, alle entwickeln immer auf dem gleichen Branch, aber verstecken alles.

Subversion.

Subversion und File-Locking.

Und packen halt alles hinter Feature Flags.

Und das geht dann wohl.

Ja, aber das ist generell so eine Technik, wenn du größere Deployments auch hast, dass du Feature Flags machst.

Was ist ein Feature Flag?

Rolling Releases haben kannst und trotzdem sicher bist, dass du ein Rollback machen kannst.

Dass du halt sozusagen ein Feature, an dem du jetzt irgendwie schreibst, das ist das machst du halt ein- und ausschaltbar sozusagen.

Und quasi die Commits kann man dann abschalten, alle die Atomiten.

Nein, nein, nein,

nein, dein Code.

Nur die Funktionalität.

Der Code kommt immer mit, aber der wird halt nicht immer angesprochen.

Du hast eine große Tabelle, wo drin steht, was jetzt gerade für Features aktiv sind.

Okay, dann muss ich halt quasi jede Zeile quasi flaggen.

Nö, nur die.

Nur die Einstiegspunkte.

Genau.

Und du würdest auch nie ein neues Feature auf allen gleichzeitig anschalten oder so, sondern du schaltest das immer erstmal auf so eine Promille an und guckst, was passiert.

Und dann nimmst du ein bisschen mehr und dann guckst du halt.

Und dann kannst du messen und dann guckst du deine Graphen an und denkst, okay, sieht gut aus, dann ja.

Kennt ihr, kennt ihr, könnt ihr euch noch damals ganz, ganz früher, als das Internet noch jung war, könnt ihr euch an Audio Galaxy erinnern.

Ja.

Das war das bessere Napster.

Ja, das war super.

Und einer von den Autoren, die das geschrieben haben, also die hatten auch, die sind dann geschlossen worden, ja, von der Musikindustrie relativ schnell.

Die haben sehr viele, der hat sehr viele interessante Artikel veröffentlicht und er hat halt gesagt, die sind irgendwann von Java auf C umgestiegen aus Geschwindigkeitsproblemen.

Und natürlich waren diese Server erstmal nicht kompatibel.

Und die haben das einfach so gemacht, die haben einen, die haben diesen C-Server halt geschrieben und der war dann halb fertig und dann haben sie ihn einfach laufen lassen, in den Pool reingetan, der ist nach einer halben Sekunde gecrasht und dann haben sie diesen Crash behoben.

Und dann haben sie das so lange gemacht, bis der halt stabil genug lief, dass sie den, dass sie quasi die Hälfte ihres Pools ersetzen konnten.

Das ist so eine Technik.

Wenn du viel Traffic hast, dann kannst du so statistische Sachen machen.

Kannst du sagen, okay, wir sampeln jetzt einfach mal einen Teil des Traffics raus und tun den auf einen anderen Server und schauen mal, ob der kompatibel ist.

Oder du sampelst eben die, wie du sagst, Feature Flags raus.

Und sagst, wir aktivieren jetzt dieses Feature mal für 10.000 Benutzer.

Und dann denkst du so, 10.000 Benutzer, so viele!

Aber es sind halt nur 0,001 Promille der aktiven Benutzer.

Und wenn irgendwas schief geht, dann ist das schade für die, aber dann müssen die halt die Seite neu laden und du hast aber statistisch valide Daten.

Also auch das ist ja was, was da, was du nur kannst, wenn du viel Paralleles, viele parallele Anfragen hast.

Ja.

Das fand ich eigentlich alles sehr fluffig und dann hat er noch was gesagt und dann dachte ich so, oh shit.

Das ist auch, hatte ich ja vorher schon so ein bisschen gehört bei auch einem Podcast mit Andrew, wo Andrew Godwin zu Gast war, der irgendwie bei Eventbrite, glaube ich, arbeitet.

Weil er auch meinte, so, ah, also die Eventbrite Junkware-Applikation hat ja so um eine Million Zeilen irgendwie Code.

Und es dauert halt schon relativ lang, die zu starten.

Und der Grund, warum es so lange dauert, sind halt die Imports, weil die Imports laufen halt 20 Sekunden.

Und da kann man nicht viel optimieren.

Und er meinte so, sie haben halt tatsächlich das Problem, dass wenn die jetzt irgendwo schnell hochskalieren müssen, dann sind halt diese 20 Sekunden, die fehlen ihnen einfach.

Und es gibt tatsächlich Überlegungen, überhaupt sie das Ganze nicht in einer anderen Sprache neu schreiben, weil es halt unoptimierbar ist.

Kann man die Imports cachen oder so?

Nee, leider kann man da nicht viel machen.

Du kannst so einen Grafen aufbauen, der die dann in einer anderen Reihenfolge macht.

Das habe ich schon mal wohl gelesen.

Aber das hilft halt auch nur.

Ja, das grundsätzliche Problem ist halt wohl irgendwie, dass auch, sobald ein neues Modul dazu kommt, kann es halt die Reihenfolge ändern.

Und das heißt, du kannst nicht, du müsstest irgendwie das restrieren.

Ich habe das mal gesehen, ich habe mal so einen Artikel gelesen, wo sie gesagt haben, sie mussten, also aber auch irgendein Internetanbieter aus den 2010ern oder was weiß ich, die halt das Importsystem so anpassen mussten, dass sie die Importreihenfolge selber optimieren können.

Ja.

Um genau das zu umgehen.

Ja, und genau das sagte der dann halt auch.

Der meinte so, naja, also sehr große, also sie haben das schon so ein bisschen zerlegt irgendwie oder versucht, aber trotzdem ist es so, wenn die, wenn du daran, wenn du an Instagram entwickelst, was er da auch deinen Entwicklungsserver, deinen Django-Entwicklungsserver so quasi, ganz normal, wie man das so kennt.

Und jetzt änderst du da halt irgendeine triviale Geschichte und dann lädt er automatisch neu.

Und dann willst du ja gucken auf deiner Seite, okay, hat das jetzt so funktioniert, wie ich mir das gedacht habe.

Und das dauert dann halt eine Minute.

Und du kannst nicht viel dran machen.

Das ist halt, äh, so ist das dann halt.

Und das ist natürlich extrem frustrierend.

Also das macht dann nicht mehr so richtig viel Spaß, damit zu entwickeln.

Und da hieß dann also, ja, also was man sich eventuell vorstellen könnte, was man da macht, ist halt eben über Type Hinting oder so, vielleicht irgendwie auch in dem Modulsystem zu sagen, es gibt nicht mehr, es gibt Module, die nicht mehr alles dürfen und dann kannst du irgendwie einschränken in welche Reihenfolge, dass die zum Beispiel nicht mehr die Reihenfolge der Module, die importiert werden, ändern dürfen.

Und dann könntest du sowas machen wie du kannst es eben cachen.

Du kannst halt sagen, okay, wenn ich jetzt, ich mache einen Reload, aber nur von dem Modul und sonst nichts.

Und das geht aber momentan noch nicht so richtig und da sind sie halt aber auch irgendwie dran.

Aber da kann man doch bestimmt den Python-Interpreter irgendwelche Memory-Snapshots machen, wo du alles importiert hast, was du einfach einmal komplett in den Hauptspeicher reinstreamst.

Ja, ich weiß nicht, aber es scheint nicht so ein etwas Problem zu sein.

Das sind irgendwie wohl.

Ja, aber das klingt natürlich, wenn schon mehrere Leute sagen, dass sie damit Probleme haben, das klingt natürlich nicht so richtig gut.

Aber ja.

Ja, tatsächlich ist mir das auch schon in eigenen Projekten aufgefallen.

Wenn die größer werden, dann ist halt die Start-up-Time langsamer.

Und das ist nervig beim Entwickeln, weil du halt deine Sekunden warten musst, bis du deine Änderungen testen kannst.

Das ist schon so.

Ja, aber du hast irgendwas interessantes gesagt, und zwar Typens.

Ich glaube, das bringt uns jetzt quasi zum Ende dieser Folge.

Ja.

Und zwar hatte ich da einen Pick der Woche in der Standard, äh, nicht Standard Library, wo wir ein bisschen Standard Library machen, aber ich hätte heute gepickt Typer.

Und Typer macht nämlich genau das, das macht nämlich aus Typends Kommandos, die man sehr schön benutzen kann.

Man kann sich seine eigene Clee zusammenklicken oder seine eigenen Kommandos, die man aufrufen kann.

Ah, das ist für eine Kommandozeile.

Ist das da also tatsächlich so, dass du dann Command-Line-Dinger hast?

Ja, es gibt sogar Autocompletion, die mitgeliefert wird und so, das hast du eigentlich ganz, ganz cool gemacht.

Da gibt es ja ganz viele Bibliotheken, die das machen.

Liegt, glaube ich, früher

gab es ja immer nur eine, die ganz schlecht war und inzwischen gibt es ganz viele.

Ja, ich glaube, also Klick klickt runter, weil man kann halt tatsächlich mit so Type-Annotations sagen, was für gültige Argumente man irgendwie mitparsen kann.

Irgendwie, dann kannst du halt einfach einen Boolean flecken und dann kannst du halt einfach die auf Tun setzen, dann kommt halt ein True davor rein und kannst halt dann gucken, was du machen willst.

Und das ist irgendwie sehr convenient irgendwie für Projekte und kleine Abstraktionen.

Ja, das ist spannend.

Das ist tatsächlich ein Problem, an dem ich auch schon vor langer Zeit mal gearbeitet habe.

Ah, weil es nämlich auch genervt hat.

2012 habe ich meine eigene Bibliothek veröffentlicht.

Kommandier heißt die, die im Wesentlichen genau das gleiche macht.

Die nimmt Funktionen mit ihren Types und Type hints und baut ja daraus eine Kommandozeile.

Gibt es inzwischen tatsächlich einige Google Fire, heißt die, glaube ich.

Die ist nicht quasi auf Google nicht zu finden.

Ah, hier, Python Fire heißt es.

Macht auch sowas ähnliches.

Simple way to create Command-Line Interface in Python.

Ich bin ja sehr froh, dass ich lange vor Google auf die Idee gekommen bin.

Also ich kann mir selber schreibe mir selber zu, dass ich die bessere Idee hatte.

Ja, sehr gut.

Du hast auch irgendwie

noch eben was gesagt in unserem Vorgeplinkel, dass du Commander interessant fandest.

Nee, also wie gesagt, meine Bibliothek heißt Kommandier.

Kommandier.

Das ist ein englisches Wort, das heißt so viel wie übernehmen.

Und deshalb habe ich das gemacht.

Aber es gibt in der Stadionbibliothek noch was anderes, das heißt CMD, also CMD.

Das macht ein bisschen was anderes, das macht nicht ein Command-Line-Interface, sondern

ein Shell-Interface.

Das heißt, so etwas wie das, was man in Python hat, der Python-Interpreter ist ja, wenn man den startet, ist er ja ein Shell-Interface.

Das heißt, ich habe eine Eingabezeile und wenn ich da was eingebe, dann passiert irgendwas.

Und mit dieser Bibliothek CMD aus der Standardbibliothek kann man solche Shells sich selber bauen.

Das heißt, es ist quasi nicht auf der Kommandozeile die Befehle eingegeben, sondern in dem Programm dann drin.

Auch mit voller Autocompletion und mit bestimmten Optionen, die direkt angezeigt werden und sowas alles.

Genau, also im Wesentlichen schreibt man eine Klasse, die von dieser Command-Klasse ableitet, also von der CMD-Klasse ableitet und tut dann da Funktionen rein.

Und der Rest, also der nimmt die Dokumentation daraus, der nimmt die Parameter daraus.

Das muss man dann im Wesentlichen nicht machen.

Wenn man nicht die Standardlibry braucht, gibt es auch CMD2.

Das kann dann auch Farben und sowas alles machen.

Ah, Farben.

Spielerei.

Ja, nein, nein, nein, das kann, glaube ich, noch ein, zwei, andere nette Sachen.

Ich muss aber mal ausprobieren.

Das Beispiel, was bei CMD in der Command, in der Standardbibliothek drin ist, ist direkt Turtle, also wenn man sich eine Turtle, interaktive Turtle baut.

Ich weiß nicht, ob ihr damals schon alt oder schrägstrich jung genug wart, um die Turtle zu benutzen im

bisschen an wie ist das Logo?

Informatikunterricht.

Ja, ja, Turtle Graphics, das war sehr schön damals.

In Pascal hatten wir das.

Da gab es, kennt ihr, wisst ihr, was Lead ist?

Guckt ihr meinen Spiegel.

Der, der, oh, ich weiß nicht mehr, was das heißt.

Loye Informatik-Editor oder irgendwie sowas.

Es war so ein System, was wir in der Schule hatten.

Als ich in der 8.

Klasse war, hatten wir das in Schulen.

Das war so eine Art Pascal mit einem Turtle-Interface und das Beste ist, es hat einen Editor mit dabei und es hat auch sehr schöne Grafiken gemacht.

Der konnte aber nicht scrollen, dieser Editor.

Das heißt, alle Programme waren maximal eine Seite lang.

Sehr schön.

Und das musste halt ausreichen in der 8.

Klasse.

Aber mit Turtle und allem, also sehr, sehr gut.

Wir hatten damals tatsächlich Tupopascal 5-0, glaube ich.

Das hat tatsächlich Spaß gemacht.

Ist auch sowas, was man nicht mehr, also ich

meine, diese ganzen Dinge findet man nicht mehr im Internet.

Ich habe es gerade probiert und es geht nicht.

Ja, ist alles irgendwie weg.

Ja.

Gone, gone, gone.

Ja, aber Rechter vergessen das ja auch nicht schlecht.

Ja.

Kommt alles in die Shownotes.

Genau, ja gut.

Hast du noch was, Pick, Jochen?

Ja, also ich würde jetzt einfach mal so auch, was so Asyn-Geschichten angeht, also man braucht ja nicht nur den Serverteil, sondern halt auch einen, ähm, der Kleine ist ja manchmal auch nicht so schlecht, wenn man den hat.

Ansonsten, ja, wie will man jetzt eigentlich gucken, ob das funktioniert hat, was man da auf der Serverseite gebaut hat.

Und ja, so üblicherweise wird man jetzt unter Python zum Web-Requests machen, ja, verwenden die meisten wahrscheinlich Requests.

Aber das Ding ist halt leider nicht async gar nicht.

Und sondern halt komplett synchron und kann man auch nicht viel machen.

Und sozusagen der asynchrone Nachfolger irgendwie von Requests, oder vielleicht wird ja Requests auch nochmal irgendwann async, ist HTTPX, auch von einem der Namen, so, die hinter ganz vielen Dingen stehen, von Tom Christie, der halt Django Rest Framework gebaut hat und dann Starlet und viele andere Dinge.

Und genau, der hat dann jetzt irgendwann quasi auch halt auch jetzt einen Async-fähigen HTTP-Client geschrieben, der sich am Request-Interface halt orientiert.

Aber halt auch, mit dem man dann Async-Geschichten machen kann.

Und genau, den verwende ich jetzt auch eigentlich meistens, wenn ich irgendwie HTTP-Geschichten mache.

Und funktioniert eigentlich ganz gut.

Und warum nicht jetzt nicht mehr Requests?

Was ist jetzt besser als Requests?

Es kann mehr als Requests.

Ne, wie gesagt, Requests ist Sync.

Kann kein Async request sein.

Ja, okay.

Also es

ist jetzt quasi Async-Requests.

Okay.

Ja, also ich erinnere mich auch noch.

Früher habe ich immer sowas verwendet wie AEO, HTTP-Client und so, aber das war immer ziemlich, da muss man viel selber machen.

Ja, da muss man selber frickeln.

Ich würde sagen, Come to the Dark Side, we have Cookies.

Und du hast auch noch ein nettes Video gemacht zum Cookies.

Oh ja, das können wir ja auch mal verlinken.

Das kommt auch in die Show Notes.

Perfekt.

Aus aktuellem Anlass.

Ja.

Ja, vielen Dank, dass ihr uns heute wieder zugehört habt, dass ihr eingeschaltet habt.

Feedback, Kritik, Anregung, was auch immer, hallo.pythsonpodcast.de.

Schreibt uns, hört uns, wann auch immer ihr wollt, morgens, mittags, abends, nachts, zum Aufstehen, zum Schlafen gehen, zum Zähneputzen, zum Autofahren, zum, was auch immer euch ja gerade einfällt.

Zum auf der Decke im Park liegen.

Bei den Temperaturen bestimmt wundervoll.

Ja, es ist ja auch beim Autofahren.

Optionen sind eingestrengt, wir müssen asynchron machen können.

Wir sind immer noch Corona behindert, irgendwie in allem, was wir tun.

Aber E-Mails schreiben geht.