WEBVTT 00:00:00.880 --> 00:00:03.640 Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast. 00:00:03.980 --> 00:00:07.320 Heute ist die 23. Episode, also für uns wieder eine ganz besondere Zahl. 00:00:08.100 --> 00:00:12.240 Was machen wir heute? Heute machen wir wieder Async und Multispelling und sowas. 00:00:12.680 --> 00:00:16.080 Und zwar Django Async kommt bald raus und darüber haben wir eine eigene Folge aufgenommen. 00:00:16.500 --> 00:00:19.080 Und zwar in dem schönen Wintergarten von Jochen. Ich bin der Dominik. 00:00:19.460 --> 00:00:22.920 Und diesmal haben wir natürlich wieder einen Gast. Den kennt ihr vielleicht schon. 00:00:24.020 --> 00:00:24.760 Hallo Johannes. 00:00:25.780 --> 00:00:27.020 Hallo Dominik. Hallo Jochen. 00:00:27.020 --> 00:00:27.780 Und hallo Jochen. 00:00:28.100 --> 00:00:29.580 Hallo, genau. Auch wieder dabei. 00:00:30.000 --> 00:00:32.300 Falls euch irgendwas gefällt oder nicht gefällt, 00:00:32.380 --> 00:00:34.520 dann schreibt uns doch wie immer gerne eine E-Mail an 00:00:34.520 --> 00:00:35.580 hallo.python.gc 00:00:35.580 --> 00:00:38.480 Und wir möchten uns auch gerne noch für ein paar Abonnenten bedanken. 00:00:38.580 --> 00:00:39.960 Und zwar haben wir allein auf Spotify 00:00:39.960 --> 00:00:42.060 mittlerweile über 1111 Abonnenten. 00:00:42.380 --> 00:00:44.040 Herzlichen Dank dafür und wuhu! 00:00:44.640 --> 00:00:45.600 Sehr cool, wir freuen uns. 00:00:45.600 --> 00:00:46.120 Ich finde es toll. 00:00:46.240 --> 00:00:46.560 Naja. 00:00:48.380 --> 00:00:50.040 Dir reicht es noch nicht, du bist die Weltforscherin. 00:00:50.880 --> 00:00:52.700 Du guckst zu viele YouTube-Channels. 00:00:53.040 --> 00:00:53.880 Ich weiß nicht genau. 00:00:55.060 --> 00:00:56.320 Ist das da so üblich? 00:00:56.520 --> 00:00:58.080 Ich weiß nicht, ob das auf dem Podcast auch so üblich ist. 00:00:58.080 --> 00:00:59.980 Ach was denn, ich habe mich einfach gefreut 00:00:59.980 --> 00:01:01.880 Ja, ist schon toll, aber 00:01:01.880 --> 00:01:02.700 keine Ahnung 00:01:02.700 --> 00:01:05.520 Ja, wo wir gerade schon bei so anderen Sachen sind 00:01:05.520 --> 00:01:07.840 Ihr habt ja vielleicht den Thomas gehört, der mit uns eine 00:01:07.840 --> 00:01:09.920 schöne Folge gemacht hat und der hat 00:01:09.920 --> 00:01:11.820 jetzt seinen Podcast umgenannt, also wir hatten ihn das letzte Mal 00:01:11.820 --> 00:01:13.800 zu wenig erwähnt, deswegen müssen wir es auch einmal extra erwähnen 00:01:13.800 --> 00:01:15.880 Der ist ein ziemlich cooler Podcast, den er da 00:01:15.880 --> 00:01:17.520 hat, wie heißt der jetzt, Jochen? 00:01:18.600 --> 00:01:19.300 Dads instead 00:01:19.300 --> 00:01:21.800 Dads instead, und Kevin ist schon dabei 00:01:21.800 --> 00:01:24.040 in einem letzten Talk und redet über PyMC3 00:01:24.040 --> 00:01:25.400 Ich glaube, das ist sehr hörenswert 00:01:25.400 --> 00:01:28.000 Ja, ich habe es gestern schon gehört, fand es sehr gut 00:01:28.000 --> 00:01:28.880 Also, ja. 00:01:30.020 --> 00:01:31.680 Ja, vielen Dank. 00:01:31.780 --> 00:01:35.940 Und ich hätte jetzt gar nicht gedacht, ich meine, dass Instagram 00:01:35.940 --> 00:01:38.120 Python macht, aber dass sich halt deren Gründer 00:01:38.120 --> 00:01:39.520 und Ex-CEO irgendwie so viel mit 00:01:39.520 --> 00:01:41.960 Statistik und Machine Learning Kram 00:01:41.960 --> 00:01:43.440 so beschäftigt ist und Data Science. 00:01:44.120 --> 00:01:46.040 Oder naja, gut, das hat er ja vorher nicht so gemacht, aber das macht er jetzt halt. 00:01:46.440 --> 00:01:47.780 Das fand ich schon sehr interessant und 00:01:47.780 --> 00:01:49.740 war auf jeden Fall eine 00:01:49.740 --> 00:01:52.220 interessante Geschichte. Ja, hört doch da mal rein, wenn ihr möchtet. 00:01:52.780 --> 00:01:54.080 Ja, wir machen 00:01:54.080 --> 00:01:55.720 heute wieder Dango, vor allen Dingen halt, weil 00:01:55.720 --> 00:01:57.660 Dango 3.1 jetzt im August 00:01:57.660 --> 00:01:59.700 erscheint und tatsächlich jetzt mehr 00:01:59.700 --> 00:02:02.260 Async-Features unterstützt als in der 3.0-Version, 00:02:02.420 --> 00:02:03.480 die seit Dezember draußen ist. 00:02:03.820 --> 00:02:05.440 Und wir möchten ein bisschen mit euch 00:02:05.440 --> 00:02:07.720 darüber reden oder untereinander darüber 00:02:07.720 --> 00:02:09.740 reden, was das überhaupt heißt, was das alles so ist. 00:02:10.940 --> 00:02:11.600 Was ist überhaupt dieses 00:02:11.600 --> 00:02:13.660 Multispring? Wir hatten das in irgendeiner Episode schon mal so ein bisschen 00:02:13.660 --> 00:02:15.540 angerissen, vielleicht auch so ein bisschen kurz 00:02:15.540 --> 00:02:17.560 verbrochen, aber uns sind noch so ein paar andere Erkenntnisse 00:02:17.560 --> 00:02:19.620 gekommen und darüber wollten wir 00:02:19.620 --> 00:02:20.640 halt so sprechen. Warum 00:02:20.640 --> 00:02:23.580 macht man so ein Spread und warum macht man so ein Multiprocess 00:02:23.580 --> 00:02:25.540 und warum macht man das dann irgendwie Async und 00:02:25.540 --> 00:02:27.520 warum macht man das mit Async.io und was gibt es da noch 00:02:27.520 --> 00:02:29.520 für Alternativen, wann braucht man das überhaupt 00:02:29.520 --> 00:02:31.620 und warum und warum vielleicht auch überhaupt nicht 00:02:31.620 --> 00:02:33.180 und irgendwie so. 00:02:34.000 --> 00:02:35.580 Ja, wollten wir vielleicht erst mal 00:02:35.580 --> 00:02:36.520 so ein bisschen News machen? 00:02:37.040 --> 00:02:38.880 Oh, News, ja, du hast natürlich recht. 00:02:39.540 --> 00:02:40.840 Neuigkeiten aus der Szene. 00:02:41.540 --> 00:02:43.640 Ja, wobei so wahnsinnig viel gab es nicht. 00:02:43.980 --> 00:02:45.300 Ich habe mir nur so ein paar Dinge aufgeschrieben. 00:02:46.160 --> 00:02:47.300 Ich weiß nicht, ob du das verwendest. 00:02:47.840 --> 00:02:48.740 Insofern kannst du vielleicht... 00:02:48.740 --> 00:02:49.080 Pylance. 00:02:49.580 --> 00:02:53.320 Ja, sehr gut. Ja, also Pylance ist ein neues Plugin, 00:02:53.440 --> 00:02:55.580 was für VS Code rausgekommen ist, also ein neuer Language-Server, 00:02:55.740 --> 00:02:57.120 wenn ich das richtig verstehe. 00:02:57.120 --> 00:02:59.600 der ziemlich coole Sachen macht, also mit der Auto-Import-Sätze 00:02:59.600 --> 00:03:01.440 in VS Code und so und fast alle 00:03:01.440 --> 00:03:03.540 Features, die man sonst so auf PyCharm eher hatte 00:03:03.540 --> 00:03:05.540 und also ich mag ihn sehr gerne. Hast du ihn auch schon 00:03:05.540 --> 00:03:07.620 aktiv im Einsatz? Ich hab das auch schon 00:03:07.620 --> 00:03:09.420 aktiviert und finde es auch ziemlich gut. 00:03:09.860 --> 00:03:11.660 Also ich mache ja jetzt gar nicht so viel 00:03:11.660 --> 00:03:13.400 mit Type-Annotationen, aber 00:03:13.400 --> 00:03:14.920 die Verlockung wird stärker. 00:03:15.940 --> 00:03:17.380 Und das Ding kann da 00:03:17.380 --> 00:03:18.600 irgendwie einiges rausholen, ja. 00:03:19.860 --> 00:03:21.460 Tja, Johannes, da bist du raus, denn du nutzt PyCharm, ne? 00:03:22.000 --> 00:03:23.660 Ja, tut mir leid, ich hab die Features alle schon. 00:03:23.880 --> 00:03:25.600 Ja, ich meine, ich benutze 00:03:25.600 --> 00:03:26.360 ja auch PyCharm. 00:03:27.120 --> 00:03:29.740 also insofern, also ich finde das auch gar nicht schlecht. 00:03:30.020 --> 00:03:31.980 Du wurdest dazu gezwungen, habe ich gehört, Jochen. 00:03:32.700 --> 00:03:33.660 Naja, mehr oder weniger. 00:03:34.520 --> 00:03:35.820 Ich meine, ich finde es ja auch interessant. 00:03:36.140 --> 00:03:37.800 Also ab und zu mal andere Dinge verwenden, ist vielleicht gar nicht so wichtig. 00:03:37.820 --> 00:03:39.360 Bei uns nutzen uns alle VS Code. 00:03:40.920 --> 00:03:42.380 Achso, wer übrigens auch VS Code 00:03:42.380 --> 00:03:43.780 natürlich nutzt, ist Daniel Feldtroy, 00:03:43.860 --> 00:03:45.980 falls ihn kennt, der Autor von Two Scrooge of Django, 00:03:46.380 --> 00:03:48.640 der ja bald das 3X-Version-Buch 00:03:48.640 --> 00:03:50.000 rausnimmt. Und ich war letztens bei ihm 00:03:50.000 --> 00:03:52.020 ein, zwei Mal in seinem Twitch-Stream, weil er irgendwie 00:03:52.020 --> 00:03:54.060 streamt irgendwie Twitch und er hat mir versprochen, 00:03:54.200 --> 00:03:55.820 dass er in Düsseldorf zum Essen vorbeikommt. 00:03:55.820 --> 00:03:58.800 Ich bin natürlich ganz gespannt, ob das irgendwie nicht nur blöd ist. 00:03:58.880 --> 00:04:03.100 Ja, das kann man leicht versprechen, solange keine Flugzeuge fliegen. 00:04:04.780 --> 00:04:08.540 Ich glaube, ein zweites Mal, als ich da war, hat er gedacht, oh, warst du nicht der aus Istanbul? 00:04:08.780 --> 00:04:10.240 Ich so, nee, das war aus Düsseldorf. 00:04:10.920 --> 00:04:13.920 Das ist ja relativ gesehen nach Düsseldorf. 00:04:14.700 --> 00:04:16.240 Kann man sich dann da Bücher signieren lassen? 00:04:16.580 --> 00:04:19.000 Ja, also wenn die Altenbühne auf dem Ball, ja, das hat er ja auch gesagt. 00:04:19.460 --> 00:04:21.820 Vielleicht verliege ich dann sogar dahin und dann quatschen wir ein bisschen. 00:04:22.040 --> 00:04:24.000 Nein, das fand ich super, wollte ich nur mal kurz erwähnen haben. 00:04:24.000 --> 00:04:35.540 Ja, aber es stimmt, ich gucke in letzter Zeit auch gerade in Vorbereitung auf diese Episode, habe ich relativ viele YouTube-Channels und so geguckt und da verwenden doch sehr viele VS Code. 00:04:36.140 --> 00:04:37.680 Du hast dich vorbereitet? 00:04:38.020 --> 00:04:44.880 Ja, ausnahmsweise mache ich das eigentlich nicht, aber ich fand es auch sehr unangenehm, ehrlich gesagt, wenn ich das nochmal machen möchte. 00:04:46.280 --> 00:04:53.060 Aber gerade zum Beispiel, da gab es eine Serie von Lukas Langer, der hat auch VS Code verwendet. 00:04:54.000 --> 00:04:55.900 zu Async.io und so. 00:04:56.820 --> 00:04:58.440 Auch sehr empfehlenswert, kommt auch noch in die Show. 00:04:59.620 --> 00:05:00.740 Ansonsten war ich glaube ich 00:05:00.740 --> 00:05:02.200 irgendwie für 3.7 00:05:02.200 --> 00:05:03.360 ist die letzte 00:05:03.360 --> 00:05:06.240 Bugfix-Release irgendwie 00:05:06.240 --> 00:05:08.380 gerade erschienen. Für 3.6 00:05:08.380 --> 00:05:10.700 noch irgendeine Security-Geschichte 00:05:10.700 --> 00:05:12.440 Python und das 00:05:12.440 --> 00:05:14.480 war es dann so ziemlich irgendwie mit... 00:05:14.480 --> 00:05:15.840 Ja, bald ist 3.9 durch. 00:05:16.060 --> 00:05:17.600 Ja, bald kommt dann 3.9, genau. 00:05:18.220 --> 00:05:19.480 Was ist denn das Tolle an 3.9? 00:05:21.480 --> 00:05:22.840 Wie hast du das jetzt mal gefragt? 00:05:22.840 --> 00:05:24.360 aus dem falschen Fuß erwischt. 00:05:25.400 --> 00:05:26.960 Also ich meine, das Tolle an 3.8 00:05:26.960 --> 00:05:28.920 ist ja der Walrus Operator und den wir auch 00:05:28.920 --> 00:05:30.700 alle ständig immer benutzen. 00:05:31.020 --> 00:05:32.840 Ich wüsste nicht, was in 3.9 neues drin ist. 00:05:33.140 --> 00:05:34.180 Doch, also ich habe gehört, 00:05:34.400 --> 00:05:36.720 dass zum Beispiel diese 00:05:36.720 --> 00:05:39.080 Subinterpreter-Geschichte da irgendwie 00:05:39.080 --> 00:05:40.640 mit drin sein soll. 00:05:41.320 --> 00:05:43.080 Also das war fraglich eine Zeit lang 00:05:43.080 --> 00:05:43.900 und dann gab es... 00:05:43.900 --> 00:05:46.600 Was ist ein Subinterpreter? 00:05:47.540 --> 00:05:49.160 Ja, das ist im Grunde auch so eine Methode, 00:05:49.280 --> 00:05:50.460 um dann halt eventuell... 00:05:50.460 --> 00:05:55.920 Also, ja, um halt in Gil so ein bisschen loszuwerden oder halt das so ein bisschen... 00:05:55.920 --> 00:05:57.480 Gil ist der Global Interpreter-Log, ja? 00:05:57.600 --> 00:05:59.240 Ja, um das so... 00:05:59.240 --> 00:06:00.540 Da werden wir sicherlich gleich noch ganz viel drüber sprechen. 00:06:00.540 --> 00:06:02.700 Genau, die Konsequenzen so ein bisschen zu mitigieren. 00:06:03.500 --> 00:06:05.540 Und das sollte... 00:06:05.540 --> 00:06:07.100 Obwohl, ich weiß es nicht, was ich da erzählen soll. 00:06:07.140 --> 00:06:07.940 Ich habe keine Ahnung. 00:06:08.120 --> 00:06:11.820 Also, ich habe gehört, Python 3.9 unterstützt einen neuen Parser und der macht ganz viel anders. 00:06:11.960 --> 00:06:15.460 Und deswegen kann man jetzt auf einmal ganz viele andere Code-Analyse-Tools oder irgendwas benutzen. 00:06:15.760 --> 00:06:15.980 Ja. 00:06:17.500 --> 00:06:17.860 Aber... 00:06:17.860 --> 00:06:19.300 Ja, diese Back-Parser-Geschichte, ja. 00:06:20.460 --> 00:06:22.460 Ja, weiß ich aber auch nicht so viel zu. 00:06:23.020 --> 00:06:24.720 Also für den normalen 00:06:24.720 --> 00:06:26.460 Programmierer erstmal keine Unterschiede. 00:06:27.480 --> 00:06:28.740 Ja, nicht so richtig viel. 00:06:29.120 --> 00:06:30.540 Also muss man sich mal mit 00:06:30.540 --> 00:06:32.320 beschäftigen, vielleicht gibt es auch irgendwelche total coolen Sachen. 00:06:32.620 --> 00:06:32.900 Na gut. 00:06:34.320 --> 00:06:36.080 Ansonsten Django, genau, war auch 00:06:36.080 --> 00:06:38.160 2.2.14 und 3.0.18 00:06:38.160 --> 00:06:39.260 sind irgendwie vor kurzem raus. 00:06:40.700 --> 00:06:42.140 Ja. Ja, also Django ist 00:06:42.140 --> 00:06:43.880 hart an der Entwicklung zu 3.1 00:06:43.880 --> 00:06:46.320 und das ist ja das, worüber wir heute reden wollen, 00:06:46.400 --> 00:06:48.500 weil es halt tatsächlich diese Async-Features jetzt gibt. 00:06:48.500 --> 00:06:50.420 Oder hast du noch mehr News aus der Szene? 00:06:50.460 --> 00:06:56.300 Ja, ich habe welche aus dem Hintergrat, beziehungsweise aus dem persönlichen Setup. 00:06:56.900 --> 00:07:04.200 Und zwar, genau, ich weiß nicht, ob man es hören kann, aber wir haben eine große Bohrmaschine genommen 00:07:04.200 --> 00:07:10.900 und dann irgendwie immer die Außenmauer durchlöchert und jetzt ist hier tatsächlich kabelbasiertes Netz. 00:07:11.820 --> 00:07:12.040 Oh! 00:07:13.040 --> 00:07:15.040 Es könnte sein, dass es jetzt deutlich weniger knackst als vorher. 00:07:15.520 --> 00:07:18.700 Also du meinst nicht, weil es weniger WiFi gibt und jetzt mehr konstantes LAN? 00:07:18.700 --> 00:07:21.040 und es gibt halt richtig ordentliches... 00:07:21.040 --> 00:07:23.060 Stimmt, ich sehe sogar da hinten das Kabel, das durch die Wand 00:07:23.060 --> 00:07:23.920 in den Raum geht. 00:07:24.400 --> 00:07:27.020 Und eine zweite 00:07:27.020 --> 00:07:29.160 Geschichte, die auch neu ist 00:07:29.160 --> 00:07:30.820 und die ich eigentlich ganz cool finde, 00:07:31.240 --> 00:07:32.460 weil ich nicht wusste, 00:07:32.720 --> 00:07:34.800 also ich habe das Ding einfach mal so auf Verdacht gekauft 00:07:34.800 --> 00:07:36.520 und wusste nicht, ob es geht, aber es ging tatsächlich, 00:07:37.320 --> 00:07:38.560 war, ich habe mir so eine 00:07:38.560 --> 00:07:40.800 Caldigit Docking Station 00:07:40.800 --> 00:07:42.100 besorgt. Eine was? 00:07:43.100 --> 00:07:43.460 Caldigit. 00:07:43.460 --> 00:07:44.100 Ja, ja, ja. 00:07:45.440 --> 00:07:46.100 Das Ding 00:07:46.100 --> 00:07:49.020 versorgt gleichzeitig 00:07:49.020 --> 00:07:50.880 einen Rechner mit Strom, macht irgendwie 00:07:50.880 --> 00:07:53.040 Thunderbolt und du kannst 00:07:53.040 --> 00:07:54.780 Monitore dran anschließen und was ich halt da drin habe, 00:07:54.900 --> 00:07:56.920 also ich habe sozusagen nur noch ein Kabel, das ich 00:07:56.920 --> 00:07:58.700 halt immer an den Rechner stecke, weil ich hatte 00:07:58.700 --> 00:08:00.840 nämlich jetzt, weil ich jetzt Netzwerkkabel habe, 00:08:00.900 --> 00:08:02.320 das Problem, okay, wie mache ich denn das 00:08:02.320 --> 00:08:05.040 Netzwerkkabel an meinem Rechner fest, der hat ja nur OSWC, 00:08:05.820 --> 00:08:06.920 da so irgendwie 00:08:06.920 --> 00:08:08.840 so ein Dongle dran zu hängen, der dann so rumbaumelt, 00:08:08.900 --> 00:08:10.360 ist auch irgendwie etwas unschön, 00:08:10.640 --> 00:08:12.600 zusätzlich zu den ganzen anderen Adaptern 00:08:12.600 --> 00:08:14.580 und Dongle, die da sowieso schon rumbaumeln. 00:08:16.100 --> 00:08:22.860 und das geht damit halt ganz gut, weil da steckt man einfach Ethernet hinten rein plus irgendwie das, was zum Monitor geht 00:08:22.860 --> 00:08:28.480 und hat halt nur ein einziges Kabel, was zum Laptop geht und alles andere geht dann über die Dockingstation 00:08:28.480 --> 00:08:32.320 und was tatsächlich funktioniert ist, ich habe da hinten halt dann noch Storage dran 00:08:32.320 --> 00:08:42.300 und das ist schnell, also so eine externe SSD und das ist ordentlich schnell, der Monitor ist so ein ultrafein LG 5K 00:08:42.300 --> 00:08:44.120 und da dachte ich auch so, oh, ob das funktioniert, 00:08:44.240 --> 00:08:46.020 aber es funktioniert tatsächlich und es kommt auch noch Strom durch. 00:08:47.100 --> 00:08:48.060 Also ich suche auch schon was ähnliches. 00:08:48.120 --> 00:08:50.180 Ich möchte gerne meine Monitore umschalten 00:08:50.180 --> 00:08:51.880 mit so einem Switch und zwar einmal auf 00:08:51.880 --> 00:08:53.920 eine Workstation und einmal auf meinen 00:08:53.920 --> 00:08:55.220 normalen Rechner. 00:08:55.840 --> 00:08:58.180 Eine KVM-Switch. Ja, genau, eine KVM-Switch und ich habe mich 00:08:58.180 --> 00:09:00.180 dann gefragt, ob es da was Vernünftiges für gibt, weil ich hätte gerne 00:09:00.180 --> 00:09:02.260 auch die Auflösung der Monitore 00:09:02.260 --> 00:09:04.120 und mit Switch immer hin und her 00:09:04.120 --> 00:09:05.700 geschaltet zwischen allen Setups. 00:09:06.660 --> 00:09:08.220 Das finde ich cool, aber ich habe noch keine Ahnung, 00:09:08.320 --> 00:09:09.920 was es da gibt. Also falls ihr da irgendjemanden kennt oder 00:09:09.920 --> 00:09:12.140 einen guten Tipp habt, her damit. Ich freue mich drüber. 00:09:12.300 --> 00:09:14.180 und schaue ich mir an und probiere das mal aus. 00:09:17.560 --> 00:09:18.820 Ansonsten, nö, sonst habe ich nichts mehr. 00:09:18.840 --> 00:09:20.700 Johannes, hast du eine News, eine Neuigkeit? 00:09:20.820 --> 00:09:22.640 Nee, ich bin immer noch im WLAN, ich habe kein Kabel. 00:09:23.320 --> 00:09:24.880 Du bist tatsächlich im WLAN bei dir im Haus? 00:09:25.820 --> 00:09:27.460 Ja, das geht ja nicht anders. 00:09:28.220 --> 00:09:29.080 Das ist zu weit weg. 00:09:29.600 --> 00:09:29.920 Vormaschine? 00:09:30.600 --> 00:09:32.100 Ja, nicht in den Meters. 00:09:33.960 --> 00:09:39.180 Und ich habe schon lange so ein relativ altes Lenovo-Dock. 00:09:39.180 --> 00:09:40.620 Das gehört auch gar nicht zu meinem Rechner, 00:09:40.620 --> 00:09:43.500 sondern das habe ich einfach mal irgendwo gekriegt für, keine Ahnung, 50 Euro oder so. 00:09:45.000 --> 00:09:45.600 Und das ist super. 00:09:45.820 --> 00:09:47.100 Ein Dock ist total gut. 00:09:47.180 --> 00:09:48.300 Da ist einfach alles eingesteckt. 00:09:48.480 --> 00:09:52.740 Tastatur eingesteckt, Maus eingesteckt, Monitore eingesteckt, Storage ist auch dran. 00:09:53.460 --> 00:09:54.100 Das ist total gut. 00:09:54.180 --> 00:09:57.280 Und du sitzt diesmal auf einem anderen Stuhl und auf einem anderen Schreibtisch, 00:09:57.340 --> 00:09:58.540 also vor einem anderen Schreibtisch in deinem Büro. 00:09:59.940 --> 00:10:02.580 Naja, nee, ich habe ja zwei Arbeitsplätze in meinem Büro. 00:10:02.720 --> 00:10:03.040 Ja, genau. 00:10:03.060 --> 00:10:04.200 Und nicht auf einem anderen Arbeitsplatz. 00:10:04.500 --> 00:10:05.840 Er ist ja Vatikan nicht zu Hause, na gut. 00:10:05.840 --> 00:10:09.360 Es gibt den 00:10:09.360 --> 00:10:11.180 mobilen Arbeitsplatz und den immobilen 00:10:11.180 --> 00:10:13.500 Arbeitsplatz und das ist jetzt der fest installierte 00:10:13.500 --> 00:10:14.880 mit den großen Monitoren 00:10:14.880 --> 00:10:19.140 Ja, cool, okay, dann würde ich sagen 00:10:19.140 --> 00:10:19.640 von mir aus 00:10:19.640 --> 00:10:22.120 tatsächlich das Thema 00:10:22.120 --> 00:10:25.640 Ich bin absolut begeistert, das ist eine Weltpremiere 00:10:25.640 --> 00:10:27.400 ja heute, liebe Hörerinnen und Hörer 00:10:27.400 --> 00:10:29.460 hört zu, ihr wisst genau, was euch jetzt erwartet 00:10:29.460 --> 00:10:31.800 Weltpremiere Dango Async 3.1 00:10:31.800 --> 00:10:33.640 Ja, also 00:10:33.640 --> 00:10:34.760 genau, ich habe mich da 00:10:34.760 --> 00:10:35.680 Ich habe direkt mal eine Frage. 00:10:36.000 --> 00:10:37.020 Was ist denn der Async? 00:10:38.740 --> 00:10:40.720 Muss ich irgendwas beachten, wenn ich jetzt von 3.0 00:10:40.720 --> 00:10:42.740 auf 3.1 upgrade, muss ich dann irgendwas 00:10:42.740 --> 00:10:44.340 machen oder geht es dann auch noch alles? 00:10:44.520 --> 00:10:46.460 Das geht alles genauso wie vorher auch. 00:10:47.400 --> 00:10:48.640 Wichtigste Frage direkt geklärt. 00:10:49.620 --> 00:10:50.540 Also erstmal nochmal 00:10:50.540 --> 00:10:52.640 ganz kurz zum Frame, zum Rahmen, 00:10:52.820 --> 00:10:53.420 worum es eigentlich geht. 00:10:54.300 --> 00:10:56.600 Was Async dann überhaupt bedeutet 00:10:56.600 --> 00:10:58.620 und was man jetzt damit machen kann, was vorher 00:10:58.620 --> 00:10:59.940 schon so ging, so diese Geschichte 00:10:59.940 --> 00:11:02.240 und wofür man das eigentlich braucht. 00:11:03.140 --> 00:11:04.120 Womit wollt ihr denn anfangen? 00:11:04.120 --> 00:11:14.440 vielleicht, was das ist, Async überhaupt und ja, dann kommt man vielleicht darauf, warum man das vielleicht haben wollen möchte oder vielleicht auch gar nicht braucht. 00:11:16.140 --> 00:11:17.680 Das ist gleich eine schwierige Frage am Anfang. 00:11:18.460 --> 00:11:33.860 Also ich glaube, ich würde tatsächlich mit der Motivation starten, weil sonst wird das direkt so trocken und alle Leute schalten sofort auf Durchzug und wenn man so zumindest weiß, dass es irgendwie vielleicht nicht so super unwichtig ist und dass tatsächlich irgendwie interessante Dinge damit gehen, 00:11:34.120 --> 00:11:36.180 Dann vielleicht hält man ein bisschen 00:11:36.180 --> 00:11:37.700 länger durch. Also du weißt schon, dass da 00:11:37.700 --> 00:11:40.000 EVE Online steht und das ist ja gleich sonst ein Exkurs 00:11:40.000 --> 00:11:40.900 von mir zu EVE Online. 00:11:41.560 --> 00:11:44.080 Ja, genau, das wäre interessant. 00:11:45.100 --> 00:11:46.080 Aber die sind doch noch auf 00:11:46.080 --> 00:11:48.180 2.7, die kriegen da ja doch die ganzen 00:11:48.180 --> 00:11:48.980 Sachen gar nicht mit alle. 00:11:49.780 --> 00:11:52.020 Aber es gibt wahrscheinlich Gründe, warum das so ist. 00:11:53.120 --> 00:11:55.220 Also okay, ich fange einfach mal so an. 00:11:55.300 --> 00:11:55.840 Das ist der Grund. 00:11:57.260 --> 00:11:58.200 EVE Online hat 00:11:58.200 --> 00:11:59.840 von Anfang an gesagt, wir haben, keine Ahnung, 00:11:59.940 --> 00:12:02.080 15 Millionen Codezeilen in unserem Server, wir fangen 00:12:02.080 --> 00:12:03.260 jetzt nicht an, die auf Python 3. 00:12:03.260 --> 00:12:05.220 Genau, EVE Online basiert 00:12:05.220 --> 00:12:07.140 viel auf Python, falls ihr das noch nicht gehört habt. 00:12:07.320 --> 00:12:09.120 Ja, genau. Und soweit ich weiß, 00:12:09.160 --> 00:12:11.400 ich weiß nicht, ob das immer noch so ist, aber soweit ich 00:12:11.400 --> 00:12:12.620 das gehört habe, 00:12:12.820 --> 00:12:14.880 auch auf Slackless Python. 00:12:16.120 --> 00:12:17.080 Oh ja, das ist interessant. 00:12:17.340 --> 00:12:19.080 Da umgehen sie ja gleich viele von den Dingen, was 00:12:19.080 --> 00:12:20.260 halt mein Async überhaupt braucht. 00:12:21.860 --> 00:12:22.580 Genau, also 00:12:22.580 --> 00:12:24.700 beziehungsweise zu der Zeit, wo sie das 00:12:24.700 --> 00:12:26.740 gemacht haben, gab es das halt einfach noch nicht. 00:12:27.180 --> 00:12:28.780 Und Slackless Python war halt eine Lösung für die 00:12:28.780 --> 00:12:30.800 Probleme, die sich da gegeben haben. Und ich meine, gut, wir können 00:12:30.800 --> 00:12:32.620 auch einfach direkt so einsteigen, weil das ist ja auch eine gute 00:12:32.620 --> 00:12:35.160 Motivation, warum braucht man sowas überhaupt 00:12:35.160 --> 00:12:36.620 und was die wohl können. 00:12:37.220 --> 00:12:38.140 Also hieß es jedenfalls, 00:12:38.780 --> 00:12:40.200 ist, dass 00:12:40.200 --> 00:12:43.100 da das alles in Stackless Python 00:12:43.100 --> 00:12:43.860 halt auch so 00:12:43.860 --> 00:12:47.220 Userland Threads oder Green Threads 00:12:47.220 --> 00:12:49.160 oder wie auch immer man die nennt, sind 00:12:49.160 --> 00:12:51.300 Stackless Python 00:12:51.300 --> 00:12:52.180 halt im Grunde braucht es keinen 00:12:52.180 --> 00:12:54.400 Execution Stack dafür im Betriebssystem. 00:12:55.600 --> 00:12:56.840 Kennst du die, was 00:12:56.840 --> 00:12:58.880 Stackless Python kann, ist, du kannst diese Threads 00:12:58.880 --> 00:12:59.340 picklen. 00:12:59.340 --> 00:13:02.040 Ja, vor allem kannst du 00:13:02.040 --> 00:13:03.460 mehr als einen ausführen, oder? 00:13:03.940 --> 00:13:05.500 Ja, das auch, du kannst ganz gerne ausführen 00:13:05.500 --> 00:13:08.080 Das hat auch keinen Global Interpreter-Log, das heißt, du kannst einfach 00:13:08.080 --> 00:13:10.320 Also ihr erkennt jetzt gerade 00:13:10.320 --> 00:13:11.920 wieder die ganze Bagage 00:13:11.920 --> 00:13:14.440 mit dem Graphics-Collector in den Müll 00:13:14.440 --> 00:13:16.220 Moment, stopp, stopp, stopp 00:13:16.220 --> 00:13:16.800 da sind wir doch noch nicht 00:13:16.800 --> 00:13:20.260 Also, ich wollte eigentlich 00:13:20.260 --> 00:13:21.920 nur mal kurz, warum man das eigentlich machen will 00:13:21.920 --> 00:13:23.640 was das Coole daran ist, also 00:13:23.640 --> 00:13:25.900 dadurch, dass diese Threads, also wenn ich jetzt zum Beispiel 00:13:25.900 --> 00:13:27.960 halt ein Ding, ich habe keine Ahnung, wie die 00:13:27.960 --> 00:13:29.920 funktioniert. Ja, ich kenne das nicht gar nicht. 00:13:30.180 --> 00:13:31.700 Aber ich glaube, es geht irgendwie um Raumschiffe und so, die da 00:13:31.700 --> 00:13:32.800 in den Weltraum rumfliegen. 00:13:32.880 --> 00:13:34.000 Excellent Space. 00:13:35.040 --> 00:13:37.460 Gut, wenn es Spaß macht, aber naja. 00:13:38.920 --> 00:13:39.920 Und du hast jetzt irgendwie 00:13:39.920 --> 00:13:41.820 einen Thread, der jetzt so ein Raumschiff simuliert, 00:13:41.880 --> 00:13:44.100 das da so durch die Gegend fliegt, dann kannst du halt 00:13:44.100 --> 00:13:46.280 das Ding pickeln, in eine Datenbank 00:13:46.280 --> 00:13:48.520 schreiben, irgendwo anders 00:13:48.520 --> 00:13:49.540 wieder auspacken 00:13:49.540 --> 00:13:51.280 und weiter ausführen. 00:13:52.500 --> 00:13:53.960 Ja, das ist eine sogenannte Continuation, 00:13:54.160 --> 00:13:55.940 wäre mal die akademische 00:13:55.940 --> 00:13:56.660 Fachliteratur. 00:13:56.660 --> 00:13:57.840 Ah, okay, gut 00:13:57.840 --> 00:14:01.040 Und das ist natürlich, wenn man ein riesen 00:14:01.040 --> 00:14:02.860 Universum hat, vielleicht eine ganz gute Sache 00:14:02.860 --> 00:14:05.000 wenn man das machen kann, weil eventuell 00:14:05.000 --> 00:14:07.020 will man halt nicht alles immer laufen haben 00:14:07.020 --> 00:14:08.520 sondern möchte halt auch 00:14:08.520 --> 00:14:10.980 Teile von dem Universum, das man simuliert 00:14:10.980 --> 00:14:12.360 da irgendwie auch einfach mal 00:14:12.360 --> 00:14:14.860 einfrieren und in die Datenbank 00:14:14.860 --> 00:14:16.860 schreiben und erst dann wieder auftauen, wenn man es 00:14:16.860 --> 00:14:18.880 tatsächlich benötigt, damit man nicht immer alles 00:14:18.880 --> 00:14:20.340 gleichzeitig ausführen muss oder so 00:14:20.340 --> 00:14:22.260 Wäre eine gute Idee für Zeitreisen 00:14:22.260 --> 00:14:24.920 Aber wir wollten über die Motivationen nochmal 00:14:24.920 --> 00:14:26.880 dann doch vielleicht kurz, lass das doch mal kurz, heute 00:14:26.880 --> 00:14:28.800 ausnahmsweise strukturierter angehen. 00:14:29.200 --> 00:14:30.980 Und dann, wir gehen auch versprochen wieder zu EVE Online 00:14:30.980 --> 00:14:32.540 zurück. Ja, also 00:14:32.540 --> 00:14:34.880 genau, die Frage ist halt 00:14:34.880 --> 00:14:36.920 sozusagen, ob 00:14:36.920 --> 00:14:38.660 nicht es 00:14:38.660 --> 00:14:40.420 valide Use Cases gibt für 00:14:40.420 --> 00:14:42.140 so sehr, 00:14:43.340 --> 00:14:45.000 das deutsche Wort ist so ein bisschen 00:14:45.000 --> 00:14:46.320 doof, aber ich 00:14:46.320 --> 00:14:48.000 weiß auch nicht, 00:14:48.940 --> 00:14:50.220 ob man da ein besseres finden kann, 00:14:50.300 --> 00:14:52.720 massiv nebenläufige Programme. 00:14:52.720 --> 00:14:54.500 Also man braucht halt viel Concurrency. 00:14:54.500 --> 00:15:24.480 und die Programmiersprache Python. 00:15:24.500 --> 00:15:26.700 in Go, es gibt diverse Geschichten in Node.js 00:15:26.700 --> 00:15:28.120 oder Rust 00:15:28.120 --> 00:15:30.640 oder Erlang. Erlang ist 00:15:30.640 --> 00:15:32.520 auch ziemlich en vogue gerade und die Frage 00:15:32.520 --> 00:15:33.920 wäre halt, wenn man jetzt so einen Use Case hat, 00:15:34.520 --> 00:15:36.460 bedeutet das, dass man die Programmiersprache wechseln muss 00:15:36.460 --> 00:15:38.440 und dann halt Erlang machen muss oder 00:15:38.440 --> 00:15:40.220 kann man das auch in Python machen? 00:15:40.600 --> 00:15:42.020 Eigentlich kann man das auch in Python machen, 00:15:43.020 --> 00:15:44.940 ist jetzt sozusagen dafür die Infrastruktur 00:15:44.940 --> 00:15:46.740 noch nicht so ausgeprägt 00:15:46.740 --> 00:15:48.800 wie in anderen Sprachen, aber so prinzipiell 00:15:48.800 --> 00:15:50.580 geht das schon 00:15:50.580 --> 00:15:52.520 und man könnte jetzt sagen, na gut, das hat 00:15:52.520 --> 00:15:54.260 ein bisschen lange gedauert, also die Geschichte von 00:15:54.260 --> 00:15:56.120 von Async in Python ist wahnsinnig lang. 00:15:57.060 --> 00:15:58.340 Aber in letzter Zeit wird es halt 00:15:58.340 --> 00:16:00.400 sehr interessant. Zum Beispiel, wenn man jetzt Django als Beispiel 00:16:00.400 --> 00:16:02.220 nimmt, dann geht das jetzt gerade erst 00:16:02.220 --> 00:16:03.940 so richtig. Und der Grund dafür ist, 00:16:04.540 --> 00:16:06.160 dass eigentlich will man 00:16:06.160 --> 00:16:07.500 die Syntax dafür haben, 00:16:07.820 --> 00:16:09.360 für Kuroutinen. 00:16:10.500 --> 00:16:12.100 Und die ist erst seit 3.5 so richtig 00:16:12.100 --> 00:16:14.120 in der Sprache. Das heißt, vor 3.5 ist 00:16:14.120 --> 00:16:14.800 sowieso schwierig. 00:16:15.900 --> 00:16:17.480 Und Django hat mit 00:16:17.480 --> 00:16:19.720 Version 1.11 noch Python 2 00:16:19.720 --> 00:16:22.060 supported. Dann geht es auch nicht. 00:16:22.060 --> 00:16:23.120 Das kann man einfach vergessen. 00:16:23.120 --> 00:16:28.060 und mit Django, glaube ich, 2.1, 2.2 weiß ich gar nicht mehr, 00:16:28.180 --> 00:16:30.960 aber noch Python 3.4 und mit 3.4 geht es auch nicht. 00:16:31.600 --> 00:16:36.640 Das heißt sozusagen, also bis vor kurzem konnte Django das gar nicht mit der nativen Syntax machen, 00:16:36.640 --> 00:16:41.040 weil Python-Versionen supportet wurden, bei denen das einfach nicht geht. 00:16:42.000 --> 00:16:44.260 Und jetzt ist es halt sozusagen alt und abgehangen genug, 00:16:44.540 --> 00:16:48.940 dass sozusagen nur noch Python-Versionen unterstützt werden, 00:16:49.380 --> 00:16:51.300 mit denen man das dann tatsächlich nativ machen kann. 00:16:51.300 --> 00:16:53.980 und jetzt kann man halt anfangen, das umzustellen. 00:16:54.080 --> 00:16:56.300 Beziehungsweise die Arbeiten daran sind ja jetzt auch schon was älter, 00:16:56.440 --> 00:16:58.600 aber jetzt ist es halt so weit, dass es tatsächlich mal in einer 00:16:58.600 --> 00:17:03.280 für User verwendbaren Form halt tatsächlich in Django ankommt. 00:17:05.280 --> 00:17:08.320 Und wenn man sich sowas überlegt, also was ich zum Beispiel mir angeguckt habe, 00:17:10.860 --> 00:17:14.320 Erlang ist ja relativ irgendwo gerade, beziehungsweise halt so ein Dialekt, 00:17:15.220 --> 00:17:17.700 der oft dann so für Webentwicklungsgeschichten benutzt wird, Elixir. 00:17:18.800 --> 00:17:20.880 Und da gibt es auch so ein Webframework Phoenix zum Beispiel 00:17:20.880 --> 00:17:23.420 und da kann man auch mal sich angucken, so Phoenix Elixier, 00:17:24.780 --> 00:17:25.420 LiveView, 00:17:25.740 --> 00:17:27.020 solche Sachen und das 00:17:27.020 --> 00:17:28.900 sieht alles schon sehr beeindruckend aus und 00:17:28.900 --> 00:17:31.000 ist auch sehr nett. Und die Frage 00:17:31.000 --> 00:17:33.040 wäre halt, kann man sowas in Django und Python 00:17:33.040 --> 00:17:34.880 auch machen? Und die Antwort ist eigentlich ja. 00:17:35.080 --> 00:17:37.120 Eigentlich gibt es nichts, was einen davon prinzipiell abhält. 00:17:38.320 --> 00:17:38.980 Außer, dass es 00:17:38.980 --> 00:17:41.000 halt nicht, dass man nicht so unterstützt wird 00:17:41.000 --> 00:17:43.060 in den Frameworks und so, aber prinzipiell 00:17:43.060 --> 00:17:44.900 geht das schon. Was macht das denn jetzt so 00:17:44.900 --> 00:17:45.680 bei dir so schön? 00:17:49.700 --> 00:17:50.060 Ja, 00:17:50.060 --> 00:17:53.960 Keine Ahnung, habt ihr noch was? 00:17:54.180 --> 00:17:55.820 Oder wegen Motivation oder was? 00:17:55.880 --> 00:17:58.280 Ich überlege gerade, ob ich jetzt schon ausreichend motiviert habe 00:17:58.280 --> 00:18:02.100 Ja, da fehlt noch 00:18:02.100 --> 00:18:03.820 ein kleines bisschen vielleicht, warum 00:18:03.820 --> 00:18:06.160 man das vielleicht macht, könnte man bei der Motivation 00:18:06.160 --> 00:18:08.260 direkt sagen, oder? Also was für Problemfälle 00:18:08.260 --> 00:18:09.760 gibt es denn, die man jetzt 00:18:09.760 --> 00:18:12.140 Ja, es gibt ja schon immer, also ich meine, es gibt ja schon 00:18:12.140 --> 00:18:14.240 immer Anstrengungen 00:18:14.240 --> 00:18:15.660 Sachen zu parallelisieren 00:18:15.660 --> 00:18:18.180 und da gibt es auch schon ganz 00:18:18.180 --> 00:18:18.780 alte Sachen 00:18:18.780 --> 00:18:21.460 nur damals war es halt 00:18:21.460 --> 00:18:23.660 damals, also vor 10 Jahren war es halt noch so 00:18:23.660 --> 00:18:26.000 dass Computer 2 Cores hatten oder 4 Cores 00:18:26.000 --> 00:18:27.680 und da ist es nicht so wild 00:18:27.680 --> 00:18:29.520 wenn du nur einen benutzt 00:18:29.520 --> 00:18:31.860 aber heutzutage ist es ja relativ leicht 00:18:31.860 --> 00:18:34.020 gerade im Serverbereich Sachen zu kriegen 00:18:34.020 --> 00:18:36.080 die 64 oder 128 Cores haben 00:18:36.080 --> 00:18:37.980 oder noch mehr wenn man das unbedingt 00:18:37.980 --> 00:18:39.740 haben möchte oder wenn man auf Grafikkarten geht 00:18:39.740 --> 00:18:41.400 kriegt man direkt in die Tausenden von Cores 00:18:41.400 --> 00:18:43.820 deshalb ist das 00:18:43.820 --> 00:18:45.940 man darf da nicht so viel Python verdammen 00:18:45.940 --> 00:18:48.440 weil das einfach vor 10 Jahren noch kein Problem war 00:18:48.440 --> 00:18:51.540 Moment, aber das ist jetzt glaube ich ein anderes Problem, oder? 00:18:51.880 --> 00:18:53.300 Also aus meiner Perspektive ist es ein anderes Problem 00:18:53.300 --> 00:18:54.980 Generell die 00:18:54.980 --> 00:18:57.640 Nebenläufigkeit, die man da jetzt braucht 00:18:57.640 --> 00:18:59.640 Aber das braucht man 00:18:59.640 --> 00:19:01.460 Das haben die anderen auch nicht 00:19:01.460 --> 00:19:03.300 Das kriegst du auch auf Node.js nicht hin 00:19:03.300 --> 00:19:07.500 Das mag sein, dass 00:19:07.500 --> 00:19:09.380 das mit Node.js nicht unbedingt hinkriegst 00:19:09.380 --> 00:19:11.500 Aber mit C und Erlang und Rust 00:19:11.500 --> 00:19:13.000 und so weiter kriegst du die Sachen schon hin 00:19:13.000 --> 00:19:13.600 Und Go auch 00:19:13.600 --> 00:19:17.880 Die nutzen schon alle Cores aus 00:19:17.880 --> 00:19:22.020 Ja, aber da weiß ich gar nicht, ob man das unbedingt braucht. 00:19:22.260 --> 00:19:24.520 Also da würde ich jetzt denken, warum? 00:19:25.340 --> 00:19:30.700 Doch, also ich glaube, für mich ist das schon eine Motivation, mehr Core ausnutzen zu können. 00:19:31.600 --> 00:19:40.660 Geht zwar nicht mit Async, das weiß ich, aber generell, der Trend geht dazu, mehr Sachen gleichzeitig zu machen, um es mal so auszudrücken. 00:19:40.800 --> 00:19:42.320 Und dafür braucht man halt irgendeine Syntax. 00:19:42.620 --> 00:19:45.660 Und klar, es gibt die ganzen Sachen, die man früher machen konnte. 00:19:45.660 --> 00:19:47.740 da gibt es die coolen 00:19:47.740 --> 00:19:49.740 Message Passing Interfaces und die coolen 00:19:50.680 --> 00:19:51.200 was weiß ich 00:19:51.200 --> 00:19:53.740 verteiltes Rechnen Ansätze und dann 00:19:53.740 --> 00:19:55.740 gibt es Threads und Multiprocessing und so weiter 00:19:55.740 --> 00:19:57.780 aber die haben halt alle ihre 00:19:57.780 --> 00:19:59.620 Nachteile und die haben halt alle ihre 00:19:59.620 --> 00:20:01.100 sagen wir mal 00:20:01.100 --> 00:20:02.500 Schwierigkeiten 00:20:02.500 --> 00:20:05.780 und gerade wenn man anfängt mit Threads 00:20:05.780 --> 00:20:07.680 zu arbeiten in Python merkt man halt sehr schnell 00:20:07.680 --> 00:20:09.700 dass das von der Geschwindigkeit her überhaupt gar nichts bringt 00:20:09.700 --> 00:20:11.920 also 00:20:11.920 --> 00:20:13.880 ist die Frage was man mit Geschwindigkeit meint 00:20:13.880 --> 00:20:15.640 ja wenn es um 00:20:15.660 --> 00:20:19.220 quasi, wie schnell kann man Dinge machen, 00:20:20.440 --> 00:20:21.540 geht, dann bringt einem das nichts, sondern 00:20:21.540 --> 00:20:23.320 macht die Sachen langsam. 00:20:25.440 --> 00:20:27.500 Nicht viele Sachen gleichzeitig kann ich machen. 00:20:29.020 --> 00:20:29.800 Wir helfen einem 00:20:29.800 --> 00:20:31.240 im Verhältnis in Python ja erstmal gar nichts. 00:20:31.740 --> 00:20:33.700 Ja, wobei, da würde ich direkt 00:20:33.700 --> 00:20:35.180 unterscheiden zwischen Sachen 00:20:35.180 --> 00:20:37.060 parallel machen, das heißt 00:20:37.060 --> 00:20:39.180 und Sachen concurrent 00:20:39.180 --> 00:20:41.380 und danebenläufig, ja, weiß nicht, ob das eine gute Übersetzung 00:20:41.380 --> 00:20:42.540 ist, könnte man nicht. 00:20:43.360 --> 00:20:44.880 Die deutschen Worte sind da total blöd. 00:20:45.660 --> 00:20:47.820 weil parallel geht halt 00:20:47.820 --> 00:20:49.620 in Python nicht, aber ich glaube auch nicht, dass das 00:20:49.620 --> 00:20:50.380 das Problem ist. 00:20:52.120 --> 00:20:52.900 Oder geht noch nicht. 00:20:52.920 --> 00:20:55.580 Da gibt es verschiedene Workloads, glaube ich, die du da 00:20:55.580 --> 00:20:57.120 bedenken musst. 00:20:58.420 --> 00:20:59.560 Also multiprocessing parallel? 00:20:59.840 --> 00:21:01.780 Dann hast du ja schon Parallelität. Mit NumPy kriegst 00:21:01.780 --> 00:21:02.720 du die Cores schon alle voll. 00:21:03.140 --> 00:21:04.640 Ja, klar, genau. Insofern würde ich sagen, das ist auch ein Problem. 00:21:04.640 --> 00:21:07.700 Vielleicht müssen wir erst noch erklären, was Parallelität und Nebenläufigkeit sind. 00:21:07.720 --> 00:21:09.440 Ja, bitte, bitte. Einmal kurz da einschalten. 00:21:10.700 --> 00:21:11.480 Ja, aber ist 00:21:11.480 --> 00:21:13.560 Multiprocessing nicht sowas wie 00:21:13.560 --> 00:21:13.840 parallel? 00:21:13.840 --> 00:21:15.460 oder... 00:21:15.460 --> 00:21:17.780 Ja, Multiprocessing ist parallel, aber auch das 00:21:17.780 --> 00:21:19.800 kannst du nur machen, wenn du 00:21:19.800 --> 00:21:21.100 wenig Kommunikation hast, weil 00:21:21.100 --> 00:21:23.340 du da eben zwischen Prozessen kommunizieren musst 00:21:23.340 --> 00:21:24.400 und das ist langsam. 00:21:25.100 --> 00:21:27.500 Das ist generell die Krankheit, die du hast, 00:21:27.680 --> 00:21:29.800 wenn du solche Message-Parsing-Sachen 00:21:29.800 --> 00:21:30.080 machst. 00:21:31.180 --> 00:21:32.580 Das hatten wir ja früher auch schon gehabt. 00:21:33.640 --> 00:21:36.180 Als ich studiert habe, hatten wir einen großen 00:21:36.180 --> 00:21:37.980 Cluster, der hatte 16 Prozessoren 00:21:37.980 --> 00:21:38.840 an der Universität. 00:21:39.900 --> 00:21:41.640 Und das waren halt unterschiedlich, es waren halt 16 00:21:41.640 --> 00:21:42.080 Computer. 00:21:43.840 --> 00:21:45.520 die mit einem schnellen Netzwerk verbunden waren. 00:21:45.640 --> 00:21:48.360 Aber je weniger Nachrichten du schicken musstest, 00:21:48.420 --> 00:21:49.680 umso schneller war das dann halt. 00:21:50.120 --> 00:21:51.740 Das heißt, im Wesentlichen warst du da gar nicht 00:21:51.740 --> 00:21:53.940 durch die CPU gedrosselt, 00:21:54.000 --> 00:21:55.160 sondern eben durchs Netzwerk. 00:21:55.520 --> 00:21:55.980 Ja, ja, gut. 00:21:57.400 --> 00:21:59.440 So ein bisschen ist es bei Multiprocessing ja auch. 00:21:59.580 --> 00:22:01.300 Je weniger Nachrichten du schicken musst, umso 00:22:01.300 --> 00:22:02.040 besser. 00:22:04.680 --> 00:22:05.640 Irgendwie, dass man sagt, man hat 00:22:05.640 --> 00:22:06.640 so eine gemeinsame Verwaltung. 00:22:06.640 --> 00:22:09.700 Genau, es gibt Chat-Memory, kannst du einfach wenden, musst du gar keine Nachrichten schicken. 00:22:09.740 --> 00:22:10.500 Cool, sowas gibt es schon? 00:22:10.500 --> 00:22:12.900 Ja, ja, das ist auch eingebaut. Seit Python 3.8 ist das drin. 00:22:13.840 --> 00:22:15.280 Also du kannst sagen, hier irgendwie... 00:22:15.280 --> 00:22:15.760 Ja, umso besser. 00:22:18.160 --> 00:22:19.440 Aber dann hast du trotzdem noch 00:22:19.440 --> 00:22:21.300 irgendwelche Locking-Mechanismen, die dir da 00:22:21.300 --> 00:22:22.640 gut erraten mussten. 00:22:23.080 --> 00:22:25.620 Aber wenn du CPU-bound bist, ist das alles nicht mehr schlimm. 00:22:26.120 --> 00:22:27.040 Also das ist alles... 00:22:27.040 --> 00:22:29.440 Ich würde sagen, wenn du Dinge einfach... 00:22:29.440 --> 00:22:31.680 Wenn du jetzt irgendwie Number-Crunch-Geschichten machst, 00:22:32.560 --> 00:22:33.760 da alle Cores zu verwenden, 00:22:33.840 --> 00:22:35.100 ist in Python überhaupt kein Problem. 00:22:35.300 --> 00:22:37.440 Das geht super. Das ist tatsächlich einer 00:22:37.440 --> 00:22:39.120 der beliebtesten Anwendungsfälle für Python. 00:22:39.820 --> 00:22:40.960 Also ich würde sagen, Data Science... 00:22:40.960 --> 00:22:43.720 Python ist wahrscheinlich die Sprache Nummer 1 00:22:43.720 --> 00:22:45.640 gerade und das ist ja 00:22:45.640 --> 00:22:47.780 hauptsächlich so ein Zeugs und da geht das super. 00:22:47.940 --> 00:22:49.680 Da werden immer alle Cores benutzt, gar kein Problem. 00:22:50.700 --> 00:22:50.940 Ja klar. 00:22:51.820 --> 00:22:53.720 Im Wesentlichen ist der Trick halt daran, dass die 00:22:53.720 --> 00:22:55.580 aus Python rausgehen, die 00:22:55.580 --> 00:22:57.280 Bibliotheken und dass die das halt in C machen. 00:22:57.420 --> 00:22:59.520 Ja, oder du kannst halt auch so Dinge machen, 00:23:00.180 --> 00:23:01.300 nee, nee, nicht nur. Also 00:23:01.300 --> 00:23:03.800 du kannst auch pure Python-Funktionen parallelisieren. 00:23:03.940 --> 00:23:06.040 Also mit REST geht das. 00:23:06.700 --> 00:23:07.640 Auch mit mehreren Maschinen hinweg. 00:23:07.640 --> 00:23:08.200 Achso, ja, okay. 00:23:09.300 --> 00:23:11.360 Aber das ist, also 00:23:11.360 --> 00:23:12.500 ich habe hier gerade die... 00:23:12.500 --> 00:23:13.860 Das ist jedenfalls Parallelität. 00:23:14.200 --> 00:23:16.440 Man macht Berechnungen auf mehreren 00:23:16.440 --> 00:23:18.580 Prozessoren und die sind gleichzeitig 00:23:18.580 --> 00:23:20.440 im Wesentlichen. Und es spielt keine Rolle, 00:23:20.560 --> 00:23:22.400 ob es die gleiche Berechnung ist oder eine andere Berechnung. 00:23:22.720 --> 00:23:24.380 In den meisten Fällen werden es ja die 00:23:24.380 --> 00:23:25.980 gleichen Berechnungen sein. 00:23:26.880 --> 00:23:29.040 Auf allen 00:23:29.040 --> 00:23:30.580 Teilen dieser Tabelle möchte ich 00:23:30.580 --> 00:23:32.560 jetzt ausgerechnet haben, was die Summe ist. 00:23:33.340 --> 00:23:33.520 Genau. 00:23:35.100 --> 00:23:36.360 Also ich habe hier die 00:23:36.360 --> 00:23:37.700 Definition von 00:23:37.700 --> 00:23:38.900 Rob Pike, 00:23:39.300 --> 00:23:42.440 der sich da mal ausgedacht 00:23:42.440 --> 00:23:43.880 hat und der sagt halt, 00:23:44.240 --> 00:23:46.320 Concurrency is about dealing with lots of 00:23:46.320 --> 00:23:48.340 things at once. Parallelism 00:23:48.340 --> 00:23:50.600 is about doing lots of things at once. 00:23:51.040 --> 00:23:52.220 Not the same, but related. 00:23:52.480 --> 00:23:53.920 One is about structure, one 00:23:53.920 --> 00:23:56.340 is about execution. Concurrency 00:23:56.340 --> 00:23:58.220 provides a way to structure a solution 00:23:58.220 --> 00:23:59.980 to solve a problem that may, 00:24:00.240 --> 00:24:02.120 but may not necessarily be 00:24:02.120 --> 00:24:02.860 parallelizable. 00:24:03.880 --> 00:24:05.000 Ja, das hätte ich erst mal. 00:24:06.400 --> 00:24:07.740 Ich dachte, das hätte ich gerade. 00:24:09.060 --> 00:24:10.420 Nee, das fand ich jetzt auch 00:24:10.420 --> 00:24:11.840 nicht arg erhellend, aber 00:24:11.840 --> 00:24:12.840 Verdammt, na gut 00:24:12.840 --> 00:24:15.020 Ja, Parallelität ist halt 00:24:15.020 --> 00:24:16.640 Sachen gleichzeitig machen 00:24:16.640 --> 00:24:20.120 und Concurrency ist verschiedene Sachen machen 00:24:20.120 --> 00:24:22.060 Das ist so wie es in meinem Kopf ist 00:24:22.060 --> 00:24:23.700 Ja, eine Erklärung, die ich mal gehört habe 00:24:23.700 --> 00:24:24.780 vielleicht ist die besser 00:24:24.780 --> 00:24:26.960 ein paar durchprobieren 00:24:26.960 --> 00:24:29.280 ist das halt sozusagen 00:24:29.280 --> 00:24:31.760 ein Bartender kann 00:24:31.760 --> 00:24:33.460 irgendwie viele Kunden 00:24:33.460 --> 00:24:35.600 concurrent 00:24:35.600 --> 00:24:37.520 behandeln, sozusagen, oder wenn ein Bartender 00:24:37.520 --> 00:24:39.680 viele Kunden hat, die er 00:24:39.680 --> 00:24:42.780 mit Drinks beschickt, 00:24:43.160 --> 00:24:44.520 dann ist das irgendwie Concurrency. 00:24:45.160 --> 00:24:47.000 Aber wenn du mehrere Drinks gleichzeitig machen willst, 00:24:47.060 --> 00:24:48.700 brauchst du mehrere Bartender. Da reicht einer nicht. 00:24:50.240 --> 00:24:50.800 Und das wäre dann 00:24:50.800 --> 00:24:51.720 Parallelität sozusagen. 00:24:54.400 --> 00:24:55.160 Ja, also 00:24:55.160 --> 00:24:56.220 mehr Arme für den Barkeeper. 00:24:56.820 --> 00:24:58.060 In meinem Kopf 00:24:58.060 --> 00:25:13.770 geht es bei mir ganz viel um das Wort gleichzeitig Parallelit hei du machst mehrere Sachen gleichzeitig Und Nebenl oder Concurrency hei du machst mehrere Sachen nebeneinander her 00:25:13.970 --> 00:25:16.990 Also nicht an einem abschließenden Schritt erstmal den einen Drink mixen, 00:25:17.330 --> 00:25:21.370 sondern fünf Gläser hinstellen, jedes Mal einmal ein bisschen Zitrone rein und dann ein bisschen Drink. 00:25:21.750 --> 00:25:26.010 Genau, also du hast fünf Drinks, die du zubereiten musst und du machst halt die Schritte von denen 00:25:26.010 --> 00:25:29.810 und du machst erstmal was an dem Drink 1, dann machst du was an Drink 2, dann machst du was an Drink 3. 00:25:30.010 --> 00:25:32.810 am Ende sind alle fertig. Die Gesamtzeit 00:25:32.810 --> 00:25:34.310 ist dann ja genau dieselbe, also 00:25:34.310 --> 00:25:35.770 du wirst ja fünf Einzel machen, nur du hast halt 00:25:35.770 --> 00:25:38.290 dann fünf gleichzeitig rausgeschickt und alle haben 00:25:38.290 --> 00:25:40.210 quasi die Zeit gewartet, anstatt 00:25:40.210 --> 00:25:42.270 dass du jeweils erstmal den ersten, den zweiten, den dritten, den vierten, 00:25:42.350 --> 00:25:44.210 den fünften... Genau, also du machst 00:25:44.210 --> 00:25:45.370 eventuell die Latenz 00:25:45.370 --> 00:25:48.250 geringer. Du kannst schon mal die Bestellung 00:25:48.250 --> 00:25:49.510 des Nächsten annehmen, während 00:25:49.510 --> 00:25:51.310 ein Drink noch in Bearbeitung ist. 00:25:51.310 --> 00:25:53.830 Ja, du kannst halt den Nächsten bearbeiten, während einer noch, 00:25:53.930 --> 00:25:55.710 weiß ich nicht, während in einem irgendeine 00:25:55.710 --> 00:25:58.010 fürchterliche chemische Reaktion läuft, die halt eine Zeit lang 00:25:58.010 --> 00:26:00.070 braucht und du wartest halt jetzt nicht stumpf 00:26:00.070 --> 00:26:02.170 davor ab, sondern du wartest auf den 00:26:02.170 --> 00:26:02.750 Assistenten. 00:26:03.110 --> 00:26:05.970 Der Erste, der sonst seinen Drink sofort bekommen hätte, weil er das erste 00:26:05.970 --> 00:26:07.350 in der Stange stand, der muss jetzt länger warten. 00:26:08.510 --> 00:26:09.070 Potenziell ja. 00:26:10.410 --> 00:26:12.150 Aber guck mal, wenn da gerade kein 00:26:12.150 --> 00:26:13.970 Eis da ist, dann kannst du ja einen 00:26:13.970 --> 00:26:15.750 anderen Drink machen, während du aufs Eis wartest. 00:26:15.850 --> 00:26:17.690 Oder während dir jemand was aus dem Lager holt. 00:26:18.630 --> 00:26:20.150 Das merkt der erste Kunde 00:26:20.150 --> 00:26:21.770 überhaupt gar nicht, weil der muss so oder so 00:26:21.770 --> 00:26:23.150 drauf warten, bis sein Eis da ist. 00:26:23.370 --> 00:26:25.090 Ja, aber nur dann kannst du was anderes machen. 00:26:25.090 --> 00:26:26.830 sein, Tasks. 00:26:27.470 --> 00:26:28.850 Ja, genau, wenn du Wartezeiten hast 00:26:28.850 --> 00:26:30.410 und dann bemerkt der 00:26:30.410 --> 00:26:32.810 erste Kunde gar nichts, dann hast du automatisch 00:26:32.810 --> 00:26:34.950 weniger Latenz und mehr 00:26:34.950 --> 00:26:36.990 Durchsatz, weil du Wartezeiten 00:26:36.990 --> 00:26:39.110 nutzen kannst. Und das ist ja eine der großen 00:26:39.110 --> 00:26:41.050 Allüren dieser ganzen 00:26:41.050 --> 00:26:43.150 Geschichte, dass du sagst, okay, ich muss jetzt eh auf 00:26:43.150 --> 00:26:45.250 eine Datenbank warten oder auf die Dateien. 00:26:45.430 --> 00:26:46.710 Ja, also sobald zwei Leute 00:26:46.710 --> 00:26:48.950 arbeiten, also nicht nur den Barkeeper, sondern 00:26:48.950 --> 00:26:50.890 auch die Küche und du möchtest immer einen Drink mit Essen 00:26:50.890 --> 00:26:53.050 servieren oder sowas. Und solange das Essen noch nicht fertig ist, 00:26:53.050 --> 00:26:54.930 dann kannst du alle anderen Drinks schon fertig. 00:26:55.090 --> 00:26:57.210 Ja, genau. Wenn du Abhängigkeiten 00:26:57.210 --> 00:26:58.970 hast oder wenn du Wartezeiten hast, die kannst du 00:26:58.970 --> 00:27:00.810 überbrücken, indem du was anderes machst. Und das ist 00:27:00.810 --> 00:27:03.110 Concurrency. Du machst nie Sachen gleichzeitig. 00:27:03.690 --> 00:27:05.010 Der Bartender kann nie 00:27:05.010 --> 00:27:06.510 mehrere Sachen gleichzeitig machen. 00:27:06.530 --> 00:27:08.250 Die magst du keine 5 oder 6 Arme. 00:27:08.750 --> 00:27:10.590 Genau, der hat halt nur einen 00:27:10.590 --> 00:27:11.490 Prozessor. 00:27:12.770 --> 00:27:14.910 Aber der kann mehrere Drinks gleichzeitig zubereiten. 00:27:15.010 --> 00:27:16.990 Das heißt nicht, dass er überall gleichzeitig was reinschüttet, 00:27:17.050 --> 00:27:18.470 aber das heißt halt, dass die alle 00:27:18.470 --> 00:27:21.150 zu einem gleichen Zeitraum in Bearbeitung 00:27:21.150 --> 00:27:22.870 sind. Genau wie der Jochen sagt, wenn 00:27:22.870 --> 00:27:25.390 5 mal so viele Drinks machen willst, 00:27:25.470 --> 00:27:26.830 brauchst du halt mehr Bartender und 00:27:26.830 --> 00:27:28.870 die sind dann auch erstmal unabhängig voneinander. 00:27:29.410 --> 00:27:31.270 Es gibt jetzt leider keine Simdi-Bartender, 00:27:31.510 --> 00:27:35.190 mehrere Sachen identisch 00:27:35.190 --> 00:27:36.910 gleich machen können, dann könntest du 00:27:36.910 --> 00:27:39.010 5 identische Drinks gleichzeitig 00:27:39.010 --> 00:27:39.770 zubereiten. 00:27:40.910 --> 00:27:43.170 Da wirst du jetzt keine 00:27:43.170 --> 00:27:45.110 Analogie in der echten Welt. 00:27:45.650 --> 00:27:47.210 Aber Async 00:27:47.210 --> 00:27:48.630 ist jetzt Parallelität oder 00:27:48.630 --> 00:27:50.750 Concurrency? Also ich würde sagen, 00:27:50.750 --> 00:27:51.990 dieses Problem Parallelität 00:27:51.990 --> 00:27:55.850 ist, also dass du beides gleichzeitig brauchst, 00:27:55.970 --> 00:27:57.650 also das wäre jetzt mal eine steile These, 00:27:58.330 --> 00:28:01.690 ich meine, ich weiß jetzt auch wieder, wann wir das schon mal hatten und ich glaube, das war tatsächlich in der ersten Sendung, 00:28:02.250 --> 00:28:04.970 wo ich halt auch meinte, so eigentlich diesen Fall, dass man beides hat, 00:28:05.130 --> 00:28:07.390 dass man Concurrency braucht und Parallelität, 00:28:07.910 --> 00:28:10.890 den hat man fast nie, also oder mir fällt es schwer, 00:28:11.050 --> 00:28:13.690 mir dafür einen Use Case auszudenken. Die anderen 00:28:13.690 --> 00:28:16.590 Fälle hat man, dass man viel Concurrency braucht, 00:28:16.670 --> 00:28:19.590 hat man, dass man viel Parallelität braucht, hat man, 00:28:19.590 --> 00:28:21.110 aber beides zusammen 00:28:21.110 --> 00:28:22.890 Ja, also ich habe mir viele Sachen vorgestellt 00:28:22.890 --> 00:28:25.930 Autonomes Fahren 00:28:25.930 --> 00:28:26.750 oder Sport 00:28:26.750 --> 00:28:29.210 und gleichzeitig fahren bestimmte Menschen 00:28:29.210 --> 00:28:30.590 übers Eis oder sowas 00:28:30.590 --> 00:28:33.570 und da musst du prognostizieren 00:28:33.570 --> 00:28:35.270 was dann passiert, das ist echt parallel 00:28:35.270 --> 00:28:36.190 für jeden Einzelnen 00:28:36.190 --> 00:28:38.550 Ja, aber das ist nicht konkurrent 00:28:38.550 --> 00:28:40.390 Du machst das Auto fahren gleichzeitig 00:28:40.390 --> 00:28:42.210 Nein, das fahren alle gleichzeitig 00:28:42.210 --> 00:28:43.690 und alle müssen gleichzeitig darauf reagieren 00:28:43.690 --> 00:28:46.350 und du möchtest ja für alle gleichzeitig irgendwie Werte haben 00:28:46.350 --> 00:28:47.750 und möchtest dann das ganze Team 00:28:47.750 --> 00:28:49.450 Das verstehe ich nicht, tut mir leid 00:28:49.450 --> 00:28:51.730 Also du hast mehrere Fahrzeuge 00:28:51.730 --> 00:28:52.750 Du hast mehrere Fahrzeuge 00:28:52.750 --> 00:28:55.610 Du hast so einen Rechner, auf dem mehrere Fahrzeuge fahren, das verstehe ich nicht 00:28:55.610 --> 00:28:57.730 Genau, du hast die ganze Flotte, die du steuerst 00:28:57.730 --> 00:28:58.930 Ja, aber die sind ja unabhängig 00:28:58.930 --> 00:29:01.630 Also ich würde sagen, das ist ein Anwendungsfall 00:29:01.630 --> 00:29:03.310 Aber du hast ein gegnerisches Team 00:29:03.310 --> 00:29:05.010 und das ist halt nicht unter deiner Kontrolle 00:29:05.010 --> 00:29:07.250 und du möchtest dann trotzdem alle deine Leute, 00:29:07.390 --> 00:29:09.290 deren Informationen du dann halt gerade erst 00:29:09.290 --> 00:29:11.350 live einlesen kannst 00:29:11.350 --> 00:29:13.450 dazu bringen, dass sie parallel 00:29:13.450 --> 00:29:15.010 die Entscheidung treffen 00:29:15.010 --> 00:29:16.910 die vernünftig 00:29:16.910 --> 00:29:18.430 statistisch wahrscheinlich ja 00:29:18.430 --> 00:29:20.350 zu besseren Ergebnismöglichkeiten irgendwie so. 00:29:21.370 --> 00:29:23.190 Der Dominik überspringt so die simplen 00:29:23.190 --> 00:29:23.410 Schritte. 00:29:24.550 --> 00:29:27.730 Also, der macht direkt komplett. 00:29:28.010 --> 00:29:28.790 Ne, tu mir leid. 00:29:28.890 --> 00:29:30.350 Das ist kein Newscase. 00:29:31.350 --> 00:29:31.850 Vielleicht doch. 00:29:32.010 --> 00:29:32.850 Der wüsste ich jetzt auch nicht. 00:29:34.450 --> 00:29:36.850 Ne, aber wir können ja direkt mal 00:29:36.850 --> 00:29:38.870 zu einem super guten Newscase zurückgehen 00:29:38.870 --> 00:29:39.710 und der heißt Eve Online. 00:29:40.210 --> 00:29:42.750 Da sind ganz viele Spieler, die gleichzeitig 00:29:42.750 --> 00:29:44.630 Sachen machen wollen und du hast aber 00:29:44.630 --> 00:29:46.650 trotzdem die große Statustabelle auf dem Server, 00:29:46.750 --> 00:29:48.270 die du die ganze Zeit aktualisieren musst. 00:29:48.270 --> 00:29:49.270 und das musste parallel machen. 00:29:49.870 --> 00:29:52.170 Also ich meine, die Lösung, die EVE Online dafür hat, ist halt, 00:29:52.250 --> 00:29:53.210 dass sie es langsamer machen. 00:29:53.430 --> 00:29:54.370 Habt ihr EVE Online mal gespielt? 00:29:55.110 --> 00:29:57.190 Nein, nur ganz viel drüber gelesen. 00:29:57.530 --> 00:29:59.170 Ich habe es tatsächlich auch mal ausprobiert. 00:29:59.670 --> 00:30:00.730 Ich muss gestehen, ich war nicht in dem Boot. 00:30:01.650 --> 00:30:03.370 Das habe ich auch nicht geschafft. 00:30:03.570 --> 00:30:04.790 Aber es gab tatsächlich tolle Schlachten. 00:30:05.030 --> 00:30:08.430 Man hat dann so Schlachten gehabt, wo dann so 20.000, 30.000 Schiffe verloren gegangen sind. 00:30:08.790 --> 00:30:09.870 Und man konnte da ein Business draus machen, 00:30:09.950 --> 00:30:11.170 weil da konnte man die Schiffe kaufen. 00:30:11.250 --> 00:30:12.570 Das war richtig Geld, was da vernichtet wurde. 00:30:12.650 --> 00:30:14.850 Ich glaube, in der größten Schlacht wurden mehrere Millionen Dollar 00:30:14.850 --> 00:30:17.130 an WTLM-Kapital vernichtet gleichzeitig, 00:30:17.130 --> 00:30:19.310 weil man irgendwelche Sprungtore blockiert hat 00:30:19.310 --> 00:30:20.790 mit riesigen Flotten an Schiffen 00:30:20.790 --> 00:30:23.030 und alles in die Luft gesprengt hat, was dann ja nie 00:30:23.030 --> 00:30:25.130 zu finden war. Ja, das ist das Geschäftsmodell von 00:30:25.130 --> 00:30:26.370 EVE Online, oder? Ja. 00:30:26.710 --> 00:30:30.910 Du kannst aber in diesem Spiel 00:30:30.910 --> 00:30:33.230 echt Gelddinger generieren, die du halt 00:30:33.230 --> 00:30:34.870 verkauft hast und wenn du halt ein Wirtschaftsunternehmen 00:30:34.870 --> 00:30:37.030 Imperium in diesem Spiel aufgebaut hast, es gab eine Leute, 00:30:37.110 --> 00:30:39.170 ich glaube, die haben über 20.000 Dollar 00:30:39.170 --> 00:30:41.250 oder sowas im Monat gemacht, indem die für EVE Online 00:30:41.250 --> 00:30:43.110 Businesses gebaut haben, die sie 00:30:43.110 --> 00:30:45.150 da durch die Dachen 00:30:45.150 --> 00:30:46.950 geschleust haben und wenn du dann halt sowas gemacht hast, wie 00:30:46.950 --> 00:30:49.610 einen Krieg zu organisieren zwischen den einzelnen Fraktionen, 00:30:49.630 --> 00:30:51.210 sich gegen das in die Luft sprengen und das halt alles auf dieser 00:30:51.210 --> 00:30:53.330 spielerischen Karte, ohne dass das reale Auswirkungen hätte, 00:30:53.410 --> 00:30:55.190 außer wirtschaftliche, für die Jungs, 00:30:55.310 --> 00:30:56.370 die da vor dem Rechner saßen, 00:30:56.930 --> 00:30:59.110 dann war das schon irgendwie sehr faszinierende 00:30:59.110 --> 00:31:00.350 Geschichte, die da irgendwie losging. 00:31:00.570 --> 00:31:02.710 Aber guck mal, Jochen, das ist doch ein perfektes Beispiel. 00:31:02.870 --> 00:31:05.090 Du hast ganz viele Spiele, die gleichzeitig Sachen machen 00:31:05.090 --> 00:31:07.150 wollen und du musst aber 00:31:07.150 --> 00:31:08.790 diese Statustabelle, das ist parallel. 00:31:08.950 --> 00:31:09.750 Ja, also ich würde sagen, 00:31:09.750 --> 00:31:13.070 ich bin nicht so der Spiele-Experte, insofern 00:31:13.070 --> 00:31:15.090 keine Ahnung, aber ich würde jetzt mal 00:31:15.090 --> 00:31:17.010 und sagen, Spiele, die sind alle nur 00:31:17.010 --> 00:31:18.170 concurrent. Da brauchst du nix. 00:31:18.210 --> 00:31:20.010 Wenn ich jetzt so gegenseitig spiele, 00:31:20.150 --> 00:31:22.870 ein ganz klassisches Killerspiel, ja, und wir schießen beide 00:31:22.870 --> 00:31:23.730 gleichzeitig aufeinander. 00:31:24.050 --> 00:31:26.510 Wo brauchen die Spiele denn bitte CPU? 00:31:27.090 --> 00:31:27.890 Die brauchen eine offene CPU. 00:31:28.710 --> 00:31:31.070 Die Spiele 00:31:31.070 --> 00:31:32.610 heutzutage laufen nicht mehr auf dem Client, 00:31:32.690 --> 00:31:34.170 sondern die laufen komplett auf dem Server. 00:31:34.310 --> 00:31:36.950 Ja, selbst wenn die komplett auf dem Server laufen, wo brauchen die denn CPU? 00:31:37.470 --> 00:31:38.690 Diese vorher 00:31:38.690 --> 00:31:40.570 genannte Battle, die der 00:31:40.570 --> 00:31:42.770 Dominik genannt hat, wo dann 30.000 Leute 00:31:42.770 --> 00:31:44.810 teilnehmen. Der Trick an der Sache, warum 00:31:44.810 --> 00:31:46.770 das funktioniert, ist, dass die den Timestep 00:31:46.770 --> 00:31:48.710 runterdrehen. Das heißt, in so einer Zone, 00:31:48.810 --> 00:31:50.550 wo viele Leute gleichzeitig 00:31:50.550 --> 00:31:52.530 sind, die müssen 00:31:52.530 --> 00:31:54.890 auf einem Server sein, damit diese Zone kohärent ist. 00:31:56.090 --> 00:31:56.730 Wenn da 00:31:56.730 --> 00:31:58.470 zu viele Leute sind, dann 00:31:58.470 --> 00:32:00.550 tun die so, als ob die Zeit langsamer läuft. 00:32:00.950 --> 00:32:02.750 Weil der Rechner ausgelastet 00:32:02.750 --> 00:32:04.530 ist. Und wenn die diese 00:32:04.530 --> 00:32:05.830 Status-Updates parallel 00:32:05.830 --> 00:32:08.210 arbeiten könnten, auf einem Rechner, 00:32:09.350 --> 00:32:10.710 dann müssten sie das nicht machen. 00:32:10.970 --> 00:32:12.590 Die gehen ganz, ganz hart 00:32:12.590 --> 00:32:14.790 ans Limit, weil die Simulation 00:32:14.790 --> 00:32:16.610 auf dem Server passiert. 00:32:16.890 --> 00:32:19.190 Zum Teil passiert die Physik-Simulation 00:32:19.190 --> 00:32:19.670 auf dem Server. 00:32:20.070 --> 00:32:21.390 Das ist im Wesentlichen der Grund. 00:32:22.770 --> 00:32:24.670 Man hört ganz oft, dass 00:32:24.670 --> 00:32:27.010 so und so viele Millionen Leute gleichzeitig in Fortnite sind. 00:32:27.390 --> 00:32:28.710 Aber das stimmt nicht. Es sind nur 00:32:28.710 --> 00:32:31.090 höchstens 50 auf einer Instanz. 00:32:31.730 --> 00:32:33.130 Jetzt gab es 00:32:33.130 --> 00:32:34.990 so Events, wo 10 Millionen Leute bei so einem 00:32:34.990 --> 00:32:36.670 Konzert dabei waren. Das ist 00:32:36.670 --> 00:32:38.990 ein kleines bisschen gelogen. Das waren 250.000 00:32:38.990 --> 00:32:40.950 Instanzen mit jeweils 00:32:40.950 --> 00:32:42.850 maximal 50 Leuten, weil da einfach 00:32:42.850 --> 00:32:44.550 die Auslastung 00:32:44.550 --> 00:32:45.710 ist der Prozessor voll. 00:32:46.650 --> 00:32:48.550 Und da ist 00:32:48.550 --> 00:32:50.370 Parallelität einfach 00:32:50.370 --> 00:32:51.630 da. 00:32:52.310 --> 00:32:54.610 Je mehr Parallelität du nutzen kannst, umso höher 00:32:54.610 --> 00:32:55.870 kannst du diese Zahl setzen. 00:32:56.550 --> 00:32:58.010 Umso weniger Instanzen brauchst du. 00:32:58.090 --> 00:33:00.330 Da ist Geld drin und da ist richtig... 00:33:00.330 --> 00:33:02.510 Vielleicht weiß ich einfach noch nicht gut genug, 00:33:02.590 --> 00:33:04.570 wie Spiele funktionieren, dass ich mir 00:33:04.570 --> 00:33:06.370 gar nicht so richtig vorstellen kann, warum die jetzt CPU brauchen. 00:33:06.390 --> 00:33:07.770 Die Frage ist halt, wo ist der Flaschenhals? 00:33:07.810 --> 00:33:10.510 Der Flaschenhals heißt, das ist CPU, das ist dann sowas wie Netzwerk. 00:33:10.510 --> 00:33:12.090 Ich glaube eher Concurrency und Netzwerk. 00:33:12.210 --> 00:33:14.510 Da müsste man Peer-to-Peer vielleicht machen, das würde vielleicht schneller gehen, 00:33:14.550 --> 00:33:17.610 über Peace verteilt, als dass man irgendwie alles durch einen Hals schickt. 00:33:18.310 --> 00:33:19.650 Bei allen Leuten irgendwie so ein bisschen... 00:33:19.650 --> 00:33:20.750 Da gibt es sicher viele Flaschenhälse. 00:33:20.930 --> 00:33:22.230 Ich glaube, da ist alles... 00:33:22.230 --> 00:33:24.490 Das ist so ein blödes Problem. 00:33:24.590 --> 00:33:27.070 Wenn du ein Problem gelöst hast, dann kommt direkt das nächste. 00:33:27.170 --> 00:33:29.370 Wenn du einen Kopf abgeschlagen hast, wachsen direkt vier neuere. 00:33:29.450 --> 00:33:29.590 Okay. 00:33:30.890 --> 00:33:33.230 Aber CPU ist da einfach einer der Faktoren. 00:33:33.790 --> 00:33:34.950 Vielleicht ist es bei Spielen so. 00:33:35.090 --> 00:33:37.590 Ich kann es noch nicht so richtig nachvollziehen, aber okay. 00:33:37.910 --> 00:33:39.530 Also ich meine, mir fällt auch ein Beispiel ein 00:33:39.530 --> 00:33:40.410 und das sind halt Datenbanken. 00:33:40.490 --> 00:33:41.230 Da hast du nämlich auch beides. 00:33:41.230 --> 00:33:42.870 Da hast du halt sowohl I.O. 00:33:42.870 --> 00:34:12.850 und Jochen unterhalten sich über die Programmiersprache Python 00:34:12.870 --> 00:34:42.870 Na klar. Also außer du kodierstststststststststststststststststststststststststststststststst 00:34:42.870 --> 00:34:44.750 auf dem Server und dann bist du ganz knallhart. 00:34:45.550 --> 00:34:46.710 Ja, aber da würde ich sagen, 00:34:46.790 --> 00:34:48.730 da bist du doch sowieso schon, da ist der Flaschenhals auch 00:34:48.730 --> 00:34:50.750 wieder woanders, weil dadurch, 00:34:50.970 --> 00:34:52.510 dass die einzelnen 00:34:52.510 --> 00:34:54.770 Clients, die du dran hast, so fett sind, 00:34:56.170 --> 00:34:56.890 macht es doch überhaupt nichts, 00:34:56.950 --> 00:34:58.590 wenn du pro Verbindung dann halt was Fettes aufmachst, 00:34:58.650 --> 00:34:59.350 wie ein Prozess oder so. 00:35:00.630 --> 00:35:02.230 Ja klar, aber du hast auf jeden Fall Parallelität. 00:35:02.650 --> 00:35:04.530 Ja gut, aber dann hast du halt diese 8 Streams. 00:35:04.770 --> 00:35:06.610 Das ist auch bei dem Spiel, wenn du sagst, es gehen nur 00:35:06.610 --> 00:35:08.650 50 Leute auf eine Instanz oder es gehen nur 00:35:08.650 --> 00:35:10.690 50 Streams über einen Rechner, dann machst du halt 00:35:10.690 --> 00:35:12.510 für die 50 Prozesse auf, gar kein Problem. 00:35:12.510 --> 00:35:14.750 geht das auch mit Python. Ja klar, aber das ist dann 00:35:14.750 --> 00:35:16.110 schon Parallelität, also du machst schon 00:35:16.110 --> 00:35:17.550 viele Sachen gleichzeitig. 00:35:18.450 --> 00:35:20.690 Ja, aber ein Fall, nach dem ich suche, ist, 00:35:21.170 --> 00:35:22.770 wo du ganz, ganz viel Concurrency 00:35:22.770 --> 00:35:24.690 hast, so viel, dass du das mit Prozessen nicht 00:35:24.690 --> 00:35:26.350 erschlagen kannst, weil es zu viele sind. 00:35:26.630 --> 00:35:28.270 Also sagen wir mal, du hast 10.000 Verbindungen gleichzeitig. 00:35:29.390 --> 00:35:30.870 Aber das kannst du ja bei einem Web-Server 00:35:30.870 --> 00:35:32.590 locker mal haben. Ja, natürlich, genau. 00:35:32.710 --> 00:35:34.770 Also du hast 10.000 gleichzeitig, die auch gleichzeitig aktiv 00:35:34.770 --> 00:35:36.530 sind. Nicht nur einfach eine Verbindung, die rumliegt, 00:35:36.590 --> 00:35:38.390 sondern tatsächlich aktiv, über die irgendwas drüber geht. 00:35:39.570 --> 00:35:40.650 Wenn du Testprobleme hast, 00:35:40.650 --> 00:35:43.010 plus irgendwie CPU, dann kannst du es vergessen. 00:35:43.130 --> 00:35:45.550 Dann kriegst du es mit Python nicht mehr hin, weil Prozesse kannst du dann nicht mehr nehmen. 00:35:45.810 --> 00:35:47.150 Ich glaube, du hast das ausprobiert. 00:35:47.210 --> 00:35:48.930 Hast du mal so eine Story erzählt auf deinem Mac 00:35:48.930 --> 00:35:50.950 und hast da keine Panik verursacht. Kann das sein? 00:35:51.410 --> 00:35:52.710 Ja, das habe ich jetzt genau. 00:35:53.130 --> 00:35:55.110 Aber das waren Threads tatsächlich, keine Prozesse. 00:35:55.330 --> 00:35:56.510 Also mit Prozessen würde das gar nicht gehen. 00:35:56.590 --> 00:35:57.930 10.000 Prozesse ist nicht möglich. 00:35:58.210 --> 00:36:01.410 Aber Threads sollten eigentlich möglich sein. 00:36:03.430 --> 00:36:04.270 Nicht auf dem Mac. 00:36:04.670 --> 00:36:06.670 Und ich habe es tatsächlich dann auch mal auf einem anderen ausprobiert, 00:36:06.670 --> 00:36:09.590 um auszuschließen, dass irgendwie meine Hardware leicht defekt ist oder so. 00:36:09.590 --> 00:36:11.890 auf Catalina macht das halt sofort 00:36:11.890 --> 00:36:13.550 Kernelpanic, wenn man 10.000 Threads aufmacht. 00:36:14.270 --> 00:36:15.770 Also die Lüfter gingen kurz an 00:36:15.770 --> 00:36:16.670 und dann ist der Rechner aus. 00:36:17.230 --> 00:36:19.250 Ich habe da tatsächlich auch einen Bug bei Apple aufgemacht. 00:36:19.710 --> 00:36:20.910 Das geht ja so nicht. 00:36:22.950 --> 00:36:23.990 Ja gut, aber ich meine, 00:36:24.170 --> 00:36:25.710 wenn man da in die Ecken und Kanten geht, 00:36:26.210 --> 00:36:27.870 ich habe auch schon mal mein Mac mit einem 00:36:27.870 --> 00:36:28.930 Programm abgeschützt, was nur 00:36:28.930 --> 00:36:31.570 das Clipboard ausgelesen hat. 00:36:33.190 --> 00:36:34.190 Ja, es ist 00:36:34.190 --> 00:36:35.870 ein großes 00:36:35.870 --> 00:36:36.610 Kartenhaus. 00:36:36.610 --> 00:36:38.210 ein großes Kartenhaus 00:36:38.210 --> 00:36:40.570 ja, tatsächlich 00:36:40.570 --> 00:36:42.270 ich habe es dann jetzt auch nochmal auf Linux probiert und so 00:36:42.270 --> 00:36:44.410 und da geht es problemlos, gar kein Ding 00:36:44.410 --> 00:36:47.070 ja gut, aber so eine Situation 00:36:47.070 --> 00:36:48.450 wurde 10.000 00:36:48.450 --> 00:36:50.250 also ich meine, dieses 00:36:50.250 --> 00:36:52.810 berühmte C10K Problem 00:36:52.810 --> 00:36:54.850 wie schaffst du es, einen Web-Server 00:36:54.850 --> 00:36:56.730 zu machen, der 10.000 Clients 00:36:56.730 --> 00:36:59.290 gleichzeitig benutzen, bedienen kann 00:36:59.290 --> 00:37:00.990 wenn du das 00:37:00.990 --> 00:37:02.210 hinkriegst, ist es besser 00:37:02.210 --> 00:37:04.270 weil dann hast du weniger Web-Server 00:37:04.270 --> 00:37:10.570 Aber dafür würde ich sagen, brauchst du eben keine CPU, sondern das ist rein Concurrency und das geht problemlos mit einem Prozess. 00:37:11.590 --> 00:37:14.670 Aber ich finde bestimmt irgendeine Workload, wo du noch was berechnen musst. 00:37:14.870 --> 00:37:18.270 Ich glaube auch, dass es sowas tatsächlich gibt. 00:37:18.270 --> 00:37:24.770 Aber es ist so einfach, dass man sagt, ich kenne das ja dann immer so, dass Leute sagen, das ist ja gar keine richtige Programmiersprache. 00:37:25.090 --> 00:37:26.330 Aber ich meine, wer hat solche Probleme? 00:37:27.570 --> 00:37:29.450 Ich hatte sowas ehrlich gesagt noch nie. 00:37:30.130 --> 00:37:31.510 Und ich habe schon eine Menge Zwochs gesehen. 00:37:31.510 --> 00:37:31.790 also 00:37:31.790 --> 00:37:34.470 bei mir war es entweder 00:37:34.470 --> 00:37:35.830 vielleicht ist es einfach so 00:37:35.830 --> 00:37:39.470 ich glaube da ist so ein bisschen Selection Bias 00:37:39.470 --> 00:37:41.030 auch drin, oder? Gut, kann auch sein, ja 00:37:41.030 --> 00:37:43.170 wir haben auch schon viele Sachen gesehen, aber wir sind halt 00:37:43.170 --> 00:37:45.670 in Python unterwegs, wir sehen nur solche Sachen, die es in Python gibt 00:37:45.670 --> 00:37:47.190 ja, ja, ja 00:37:47.190 --> 00:37:49.390 das mag sein, das kann durchaus 00:37:49.390 --> 00:37:51.330 ja, ja gut, wie auch immer 00:37:51.330 --> 00:37:53.090 wie auch immer, aber genau 00:37:53.090 --> 00:37:55.350 dieses Parallelität Ding, also wenn man beides braucht 00:37:55.350 --> 00:37:57.070 ist halt schlecht, das ist nach wie vor nicht gut in Python 00:37:57.070 --> 00:37:58.930 aber sagen wir mal so 00:37:58.930 --> 00:38:00.610 dieser Concurrency Use Case 00:38:00.610 --> 00:38:02.690 für den es ja tatsächlich auch Anwendungen gibt und 00:38:02.690 --> 00:38:04.890 ich meine Node.js ist einer der Gründe, warum Node.js 00:38:04.890 --> 00:38:06.990 so populär ist, ist halt 00:38:06.990 --> 00:38:08.850 dass es damit besser 00:38:08.850 --> 00:38:09.350 ging 00:38:09.350 --> 00:38:12.290 oder dafür halt besser benutzt wurde, 00:38:12.530 --> 00:38:13.550 besser benutzbar war 00:38:13.550 --> 00:38:15.870 und ja. 00:38:16.890 --> 00:38:18.850 Ja, auch ein besseres Programmiermodell hat, 00:38:18.970 --> 00:38:20.370 oder? Also dieses 00:38:20.370 --> 00:38:22.550 Promisers 00:38:22.550 --> 00:38:24.330 und Futures und so weiter, das 00:38:24.330 --> 00:38:26.330 ist schon sehr einfach. 00:38:26.970 --> 00:38:28.650 Ja, aber das ist eigentlich alles, sozusagen 00:38:28.650 --> 00:38:29.790 das gibt es halt in Python ja auch 00:38:30.610 --> 00:38:32.570 Ja 00:38:32.570 --> 00:38:34.010 Was gibt es denn da? 00:38:34.150 --> 00:38:36.590 Kannst du das kurz beschreiben? 00:38:38.850 --> 00:38:40.350 Ja, also gut, okay 00:38:40.350 --> 00:38:42.150 Also wenn wir jetzt schon 00:38:42.150 --> 00:38:44.390 im Grunde wissen, okay, wir wollen das 00:38:44.390 --> 00:38:46.490 eigentlich schon haben und das ist schon cool und das kann ja 00:38:46.490 --> 00:38:48.210 wohl nicht sein, dass ich jetzt Node.js lernen muss, nur 00:38:48.210 --> 00:38:50.490 irgendwie um immer noch 00:38:50.490 --> 00:38:51.030 hip zu sein 00:38:51.030 --> 00:38:54.430 dann kann man sich ja 00:38:54.430 --> 00:38:56.370 genau, kann man so, okay, wie macht Node.js das denn 00:38:56.370 --> 00:38:58.370 eigentlich, weil Node.js hat 00:38:58.370 --> 00:39:00.510 die gleichen Beschränkungen im Grunde, es ist sehr vergleichbar zu 00:39:00.510 --> 00:39:02.550 zu Python, hat die gleichen Beschränkungen. 00:39:02.670 --> 00:39:04.210 Da gibt es auch in GIL 00:39:04.210 --> 00:39:06.490 ganz genauso wie in Ruby on Rails 00:39:06.490 --> 00:39:08.430 und sonst irgendwie in PHP. 00:39:08.530 --> 00:39:10.150 Die ganzen Skriptsprachen machen das ja alle. 00:39:10.150 --> 00:39:12.350 Die machen das alle so, weil es halt auch sinnvoll ist. 00:39:13.410 --> 00:39:14.510 Ja, und weil es halt auch 00:39:14.510 --> 00:39:16.190 single-threaded die Performance, also wenn du 00:39:16.190 --> 00:39:18.410 kein Multiprocessing brauchst, also wenn du 00:39:18.410 --> 00:39:20.430 keine Parallelität brauchst und keine 00:39:20.430 --> 00:39:21.930 Concurrency, dann ist es halt das Schnellste. 00:39:24.430 --> 00:39:26.230 Ja, genau. Und was 00:39:26.230 --> 00:39:27.710 Node.js macht, ist halt, 00:39:28.310 --> 00:39:29.870 sie haben halt eine Event-Loop und 00:39:29.870 --> 00:39:37.310 und dann kann man halt sozusagen Callbacks auf dieser Event-Loop, 00:39:37.490 --> 00:39:39.490 oder sagen wir mal so, das ist halt das, was ganz früher schon immer, 00:39:39.590 --> 00:39:43.630 ich glaube, das ist schon immer möglich, man kann halt Callbacks auf dieser Event-Loop registrieren, oder? 00:39:44.510 --> 00:39:47.350 Ja, Callbacks sind ja was Schreckliches, das ist doch die Callback-Hell. 00:39:47.370 --> 00:39:47.930 Genau, ja. 00:39:47.930 --> 00:39:50.450 Gar keine lineare Programmierung mehr. 00:39:50.670 --> 00:39:51.990 Hast du was gesagt? Hatte ich irgendwas gesagt? 00:39:52.110 --> 00:39:54.530 Vielleicht gab es irgendjemand, der hat was gesagt, der wollte, er wartet noch auf irgendwas. 00:39:54.910 --> 00:39:57.210 Wie heißt denn das? Wie muss ich dann da fragen, wenn ich das wissen will? 00:39:57.210 --> 00:39:59.110 Ach Moment, da steht jemand, der hat da rumgegangen. 00:39:59.110 --> 00:39:59.110 00:39:59.110 --> 00:40:01.070 Ach nee, da war doch jemand anders. Ach Moment, 00:40:01.170 --> 00:40:02.790 da war doch jemand, der hat aber was gesagt. 00:40:03.170 --> 00:40:05.310 Ach Callback, achso da hinten, ach nee, da unten. 00:40:05.470 --> 00:40:06.850 A, O. Das ist ja gar nicht so schlimm. 00:40:06.970 --> 00:40:09.250 Diese Vermischung kriegst du ja immer. Das Problem ist, 00:40:09.330 --> 00:40:11.150 dass dein Programm dann auch so aussieht, weil 00:40:11.150 --> 00:40:13.110 du die Callbacks quasi in der falschen 00:40:13.110 --> 00:40:14.230 Reihenfolge definieren musst. 00:40:14.770 --> 00:40:17.110 Du kannst nicht sagen, erst A, dann B, dann C, 00:40:17.230 --> 00:40:19.210 sondern du musst erst sagen, erst A und wenn 00:40:19.210 --> 00:40:21.110 es erfolgreich ist, dann B, ansonsten 00:40:21.110 --> 00:40:23.370 C und wenn B erfolgreich ist, dann 00:40:23.370 --> 00:40:24.870 zwischendurch D und E und dann hast du 00:40:24.870 --> 00:40:27.210 A, B, E, F und 00:40:27.210 --> 00:40:28.710 C kommt dann irgendwo ganz anders. 00:40:28.710 --> 00:40:51.410 Das heißt, du kannst dein Programm nicht mehr von oben nach unten lesen, sondern du musst es so gemixt lesen. Und das ist ganz, ganz, ganz blöd zu programmieren. Und deshalb hat JavaScript dann irgendwann diese Promises and Futures eingeführt, wo du einfach sagen kannst, da kommt jetzt was zurück, was irgendwann fertig ist. Und sobald du es benutzt, musst du halt warten. 00:40:51.410 --> 00:40:55.310 Ja, kann man 00:40:55.310 --> 00:40:57.570 in Python 00:40:57.570 --> 00:40:59.670 gibt es das halt quasi ganz genauso 00:40:59.670 --> 00:41:01.570 also seit 3.2 00:41:01.570 --> 00:41:03.130 gibt es concurrent 00:41:03.130 --> 00:41:04.290 Futures 00:41:04.290 --> 00:41:07.230 Ich weiß nicht, ob sich 00:41:07.230 --> 00:41:09.350 JavaScript das Promises-Konzept 00:41:09.350 --> 00:41:11.310 da so ein bisschen abgeguckt hat, also Python hat sich das 00:41:11.310 --> 00:41:13.210 abgeguckt aus der Java-Welt tatsächlich 00:41:13.210 --> 00:41:15.050 wo es dieses Future-Konzept wohl schon länger gibt 00:41:15.050 --> 00:41:19.230 Aber in Java nimmt man doch viel eher Threads, oder? 00:41:19.330 --> 00:41:20.850 Ja, aber man kann 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:20.850 00:41:20.850 --> 00:41:21.850 auch das machen. 00:41:24.370 --> 00:41:27.090 Aber sagen wir so, wenn wir jetzt schon bei den Callbacks sind 00:41:27.090 --> 00:41:28.570 oder bei 00:41:28.570 --> 00:41:30.970 dieser Art, das kann man halt in Python 00:41:30.970 --> 00:41:32.930 im Grunde auch 00:41:32.930 --> 00:41:33.470 so machen. 00:41:36.730 --> 00:41:38.870 Das ist auch in dem Async-Teil, 00:41:38.950 --> 00:41:40.810 man muss das wahrscheinlich 00:41:40.810 --> 00:41:42.530 alles ein bisschen voneinander unterscheiden. 00:41:42.530 --> 00:41:44.250 Es gibt ein riesiges Glossar machen. 00:41:44.390 --> 00:41:46.130 Ja, genau, wie das unten drunter aussieht, 00:41:46.190 --> 00:41:48.230 was man unten drunter für einen Mechanismus verwendet, um halt 00:41:48.230 --> 00:41:50.130 Concurrency zu erreichen 00:41:50.130 --> 00:41:52.170 und was man dann für Abstraktionen 00:41:52.170 --> 00:41:53.730 darüber verwendet, weil tatsächlich 00:41:53.730 --> 00:41:56.050 in Async.io jetzt sozusagen die 00:41:56.050 --> 00:41:56.510 aktuell 00:41:56.510 --> 00:41:59.450 in der Standardbibliothek befindliche 00:41:59.450 --> 00:42:02.350 Lösungen für diese Conferency-Geschichte 00:42:02.350 --> 00:42:04.090 ist halt... Ja, sogar in der Sprache, 00:42:04.190 --> 00:42:05.810 oder? Ist nicht in der Bibliothek, sondern ist 00:42:05.810 --> 00:42:07.430 richtig in die Sprache integriert mit den 00:42:07.430 --> 00:42:09.870 Schlüsselwörtern. Ja, aber das ist 00:42:09.870 --> 00:42:11.770 auch eine gute Sache, dass es 00:42:11.770 --> 00:42:13.610 voneinander getrennt. Also was in der Sprache 00:42:13.610 --> 00:42:15.830 tatsächlich drin ist, sind 00:42:15.830 --> 00:42:17.950 halt Async-Funktionen. 00:42:18.030 --> 00:42:20.010 Also wie man halt mit Async-Def 00:42:20.010 --> 00:42:21.910 genau und Await. Mit diesen 00:42:21.910 --> 00:42:24.050 Schlüsselwörtern kann man 00:42:24.050 --> 00:42:25.250 da operieren, aber 00:42:25.250 --> 00:42:27.770 in der Sprache ist nur definiert, dass diese 00:42:27.770 --> 00:42:29.650 Geschichten dann, wenn du sie aufrufst, halt eine 00:42:29.650 --> 00:42:30.490 Kurroutine zurückgeben. 00:42:31.750 --> 00:42:33.890 Es ist nicht gesagt, wie das jetzt alles sonst 00:42:33.890 --> 00:42:36.010 funktionieren muss. Der Rest ist halt... 00:42:36.010 --> 00:42:37.450 Ja, okay, klar, die Event-Loop und so weiter. 00:42:37.570 --> 00:42:38.930 Du kannst halt 00:42:38.930 --> 00:42:41.790 Async-Def und Await auch in Trio verwenden 00:42:41.790 --> 00:42:43.950 und Trio verwendet ein ganz anderes Modell unten drunter als 00:42:43.950 --> 00:42:44.630 jetzt Async-Trio. 00:42:46.510 --> 00:42:47.530 Das ist eine 00:42:47.530 --> 00:42:49.150 Implementierung, 00:42:49.150 --> 00:42:51.430 sowas ähnliches wie AsyncIO, bloß 00:42:51.430 --> 00:42:53.270 mit einer etwas 00:42:53.270 --> 00:42:55.270 moderneren, etwas anderen Zielsetzung. Also es gibt 00:42:55.270 --> 00:42:57.030 diverse. Es gibt AsyncIO, 00:42:57.150 --> 00:42:59.110 ist in der Standardbibliothek. Es gibt 00:42:59.110 --> 00:43:01.130 Curio, das ist das von 00:43:01.130 --> 00:43:01.730 David Beasley. 00:43:02.930 --> 00:43:05.130 Ist halt sozusagen erst ab Python 3.7 00:43:05.130 --> 00:43:06.810 und irgendwie so ein bisschen 00:43:06.810 --> 00:43:08.430 advancer. 00:43:09.050 --> 00:43:10.770 Und dann gibt es nochmal die advancer 00:43:10.770 --> 00:43:12.610 Version von Nathaniel Smith 00:43:12.610 --> 00:43:13.750 im Trio. 00:43:14.830 --> 00:43:16.950 Und das Ding macht 00:43:16.950 --> 00:43:18.770 im Grunde sowas ähnliches, aber halt 00:43:18.770 --> 00:43:21.970 und anders. Also die Art, wie man es programmiert, ist halt anders. 00:43:22.910 --> 00:43:26.130 Und benutzt aber Async-Dev kann man in all diesen Dingern verwenden, 00:43:26.690 --> 00:43:30.650 weil das halt nur sagt, okay, wenn ich eine Async-Funktion habe, 00:43:30.770 --> 00:43:34.310 dann gibt die halt eine Core-Routine zurück und ich kann jetzt damit irgendwas machen. 00:43:34.410 --> 00:43:38.510 Aber wie das Programmiermodell aussieht, was ich dann mit diesen Core-Routinen mache, das ist ja demjenigen, 00:43:38.590 --> 00:43:42.370 der das sozusagen, dieses Framework implementiert, überlassen. Und da gibt es 00:43:42.370 --> 00:43:45.950 unterschiedliche Ansätze. Und im Grunde Trio 00:43:45.950 --> 00:43:47.970 ist so ein bisschen das zu Ende gedacht, 00:43:48.070 --> 00:43:49.550 dass das halt so ein Problem ist. Also das 00:43:49.550 --> 00:43:51.810 wurde ja auch schon angedeutet mit dieser Kohlberg-Hell-Geschichte. 00:43:52.410 --> 00:43:54.150 Also das grundsätzliche 00:43:54.150 --> 00:43:55.930 Problem, was auch der Autor von Trio da 00:43:55.930 --> 00:43:57.630 identifiziert hat, also 00:43:57.630 --> 00:43:59.350 ich packe da auch mal einen Artikel, wo man das 00:43:59.350 --> 00:44:01.730 in Detail nachlesen kann in die Shownotes, 00:44:02.210 --> 00:44:03.750 dass er sagt, das ist alles, also 00:44:03.750 --> 00:44:05.950 ein großer Teil der Probleme, die wir hier 00:44:05.950 --> 00:44:07.790 sehen, sind die gleichen Probleme, 00:44:08.270 --> 00:44:09.490 die Leute früher mit Gotoh hatten. 00:44:11.330 --> 00:44:11.970 Oder er sagt, 00:44:12.010 --> 00:44:13.410 das ist halt eine sehr gute Analogie dafür. 00:44:13.610 --> 00:44:15.790 Wir sind in der Assembler-Welt angekommen, wenn wir über Gotoh 00:44:15.790 --> 00:44:17.850 sprechen? Ja, äh, nee, nicht ganz 00:44:17.850 --> 00:44:19.650 Assembler. Ganz viele Sprachen, die Gotoh haben. 00:44:19.790 --> 00:44:19.950 Ja. 00:44:21.450 --> 00:44:23.030 Also, äh, ja, also, ähm, 00:44:23.610 --> 00:44:25.030 das Problem bei Gotoh ist halt irgendwie, 00:44:25.590 --> 00:44:27.570 dass es dir, das ist nicht, 00:44:27.750 --> 00:44:29.790 das ist, was das unmöglich macht, ist halt 00:44:29.790 --> 00:44:31.230 lokal über Code nachzudenken. 00:44:31.770 --> 00:44:33.610 Weil du weißt halt nicht, also, er hat dann halt 00:44:33.610 --> 00:44:35.830 so ein schönes Diagramm, wo man halt, äh, 00:44:35.910 --> 00:44:37.710 er macht halt immer, er geht von einem Gotoh zu einer 00:44:37.710 --> 00:44:39.650 Zeile und dann, er macht das halt immer weiter, 00:44:39.710 --> 00:44:42.150 bis du halt siehst, das ist ein riesiges Spaghetti, ein riesiges Spaghetti-Kneuel. 00:44:42.930 --> 00:44:43.730 Das heißt, du weißt halt 00:44:43.730 --> 00:44:45.470 nie genau, ähm, 00:44:45.470 --> 00:44:47.730 wie du eigentlich hingekommen bist 00:44:47.730 --> 00:44:49.010 und wo es hingeht 00:44:49.010 --> 00:44:51.550 und zum Beispiel kannst du halt keine Facebacks 00:44:51.550 --> 00:44:53.690 werfen, weil du weißt überhaupt nicht, wo du herkommst eigentlich 00:44:53.690 --> 00:44:55.910 und das ist halt 00:44:55.910 --> 00:44:56.710 relativ schrecklich 00:44:56.710 --> 00:44:59.770 du musst halt dann das Programm immer komplett 00:44:59.770 --> 00:45:01.410 verstehen, ansonsten 00:45:01.410 --> 00:45:03.750 kannst du nicht sagen, was da gerade passiert, weil 00:45:03.750 --> 00:45:05.730 es keine lokalen Blöcke 00:45:05.730 --> 00:45:06.850 gibt, die 00:45:06.850 --> 00:45:09.830 irgendwie, wo man sagt, okay, ich habe jetzt ungefähr verstanden 00:45:09.830 --> 00:45:10.930 was das Ding tut 00:45:10.930 --> 00:45:13.230 das muss ich jetzt nicht noch 00:45:13.230 --> 00:45:15.330 also ich brauche nur zu wissen, wie die Abstraktion 00:45:15.330 --> 00:45:17.370 davon ist und das reicht mir, um damit arbeiten 00:45:17.370 --> 00:45:19.190 zu können. Also zum Beispiel irgendwie sowas wie 00:45:19.190 --> 00:45:21.310 Print Hello World. Print 00:45:21.310 --> 00:45:23.310 macht intern was relativ kompliziertes. 00:45:24.270 --> 00:45:24.830 Das macht irgendwie 00:45:24.830 --> 00:45:27.510 Syscalls, das macht irgendwie alle möglichen 00:45:27.510 --> 00:45:29.350 komischen Dinge, die halt dann so zu tun sind, wenn man 00:45:29.350 --> 00:45:30.830 irgendwie, wenn dann was 00:45:30.830 --> 00:45:33.130 auf der Konsole erscheinen soll. 00:45:34.950 --> 00:45:35.490 Aber das 00:45:35.490 --> 00:45:37.250 muss man alles nicht wissen, sondern man ruft das einfach auf 00:45:37.250 --> 00:45:39.350 und das geht. Und Funktionen sind 00:45:39.350 --> 00:45:40.710 halt super, weil genau die 00:45:40.710 --> 00:45:43.150 brauchst du ja eigentlich nur zu merken, was das Ding tut, aber wie 00:45:43.150 --> 00:46:13.130 und Jochen unterhalten sich über die Programmiersprache Python 00:46:13.150 --> 00:46:15.190 Ende der 60er, Anfang der 70er 00:46:15.190 --> 00:46:17.570 Dijkstra und so, da gab es halt den berühmten Artikel, 00:46:18.210 --> 00:46:19.270 die haben sich da Gedanken gemacht 00:46:19.270 --> 00:46:21.050 und deren Vorschlag war halt, 00:46:21.390 --> 00:46:23.530 ja, Guto rauswerfen, 00:46:23.610 --> 00:46:25.150 verbannen, irgendwie ächten 00:46:25.150 --> 00:46:27.250 und stattdessen sowas verwenden 00:46:27.250 --> 00:46:29.210 wie Funktionen und Blöcke und so. 00:46:30.170 --> 00:46:31.570 Und das hat sich durchgesetzt 00:46:31.570 --> 00:46:33.470 und auch lustig, 00:46:33.570 --> 00:46:35.470 die Gegenargumente damals 00:46:35.470 --> 00:46:37.050 und auch Knut hat zum Beispiel gesagt, 00:46:37.130 --> 00:46:38.850 oh nö, ich finde Guto eigentlich ganz gut, 00:46:39.530 --> 00:46:40.390 auch sehr interessant. 00:46:41.090 --> 00:46:41.370 Knut? 00:46:41.370 --> 00:46:41.850 Ja. 00:46:41.850 --> 00:46:43.330 Don't Include. 00:46:44.170 --> 00:46:45.790 Ah, war das nicht der, der 00:46:45.790 --> 00:46:48.210 sowas gesagt hat wie, premature optimization 00:46:48.210 --> 00:46:49.510 is the root of all evil? 00:46:49.810 --> 00:46:50.570 Genau, genau der. 00:46:51.830 --> 00:46:54.050 Aber dieses Zitat ist mit sehr viel 00:46:54.050 --> 00:46:56.090 Vorsicht zu genießen. Er hat auch gesagt, wenn man 3% 00:46:56.090 --> 00:46:57.710 rausholen kann, dann ist es nicht mehr premature. 00:47:00.750 --> 00:47:02.230 Jaja, das war... 00:47:02.230 --> 00:47:03.090 Ach ja, andere Zeiten. 00:47:04.930 --> 00:47:05.590 Ja, jedenfalls. 00:47:05.990 --> 00:47:08.070 Genau, der war da auch nicht unbedingt 00:47:08.070 --> 00:47:09.870 so totaler Fan von Gotoh rausschmeißen, weil 00:47:09.870 --> 00:47:12.370 und eine Frage im Moment war halt so, ja, das bedeutet ja, 00:47:12.410 --> 00:47:13.910 wir müssen ganz anders programmieren lernen. 00:47:14.650 --> 00:47:16.070 Wir haben jetzt über Jahre irgendwie 00:47:16.070 --> 00:47:17.090 haben wir uns 00:47:17.090 --> 00:47:20.110 auf ein Level begeben, 00:47:20.210 --> 00:47:22.170 dass wir damit irgendwie jetzt klarkommen und 00:47:22.170 --> 00:47:24.070 haben uns so Methoden angewöhnt, wie man damit umgeht 00:47:24.070 --> 00:47:26.010 und wenn wir das jetzt so ändern, 00:47:26.150 --> 00:47:27.870 dann müssen wir im Grunde nochmal neu 00:47:27.870 --> 00:47:29.910 programmieren lernen und ja, das ist so. 00:47:30.050 --> 00:47:31.970 Ja, und vielleicht wird es 00:47:31.970 --> 00:47:33.510 dann sogar langsamer, weil eben diese 00:47:33.510 --> 00:47:36.070 Funktionsaufrufe und diese ganzen Strukturmechanismen, 00:47:36.850 --> 00:47:37.850 die brauchen ja auch Rechenzeit. 00:47:38.170 --> 00:47:39.690 Ja, natürlich. Und Speicherplatz. 00:47:39.870 --> 00:47:43.130 und wenn du nochmal 3% irgendwo rausholen kannst, 00:47:43.570 --> 00:47:46.070 dann kannst du das auch machen. 00:47:46.330 --> 00:47:48.210 Und wenn der Mainframe super teuer ist 00:47:48.210 --> 00:47:49.430 und Arbeitskraft super beliebt, 00:47:49.550 --> 00:47:50.310 dann macht es vielleicht sogar Sinn. 00:47:50.310 --> 00:47:52.310 Aber heute... 00:47:52.310 --> 00:47:54.510 Ja, das ist halt... 00:47:54.510 --> 00:47:56.210 Wir stehen auf den Schultern von Riesen. 00:47:56.310 --> 00:47:57.490 Wir haben heute genügend Prozessoren. 00:47:58.210 --> 00:47:59.550 Wir haben genügend Megahertz, 00:47:59.850 --> 00:48:01.670 dass wir uns das leisten können. 00:48:02.970 --> 00:48:04.510 Ja, und im Grunde, 00:48:04.550 --> 00:48:05.230 er sagt halt, 00:48:05.650 --> 00:48:08.050 bei Concurrent 00:48:08.050 --> 00:48:12.950 Programmierung hat man im Grunde in gewisser Weise das gleiche Modell und 00:48:12.950 --> 00:48:16.910 er sagt zum Beispiel, Futures findet ja ganz schrecklich, weil die 00:48:16.910 --> 00:48:21.170 im Grunde das gleiche Problem haben wie Gotoh, weil du kriegst halt was zurück, also du rufst eine Funktion auf, 00:48:21.790 --> 00:48:25.150 du kriegst was zurück, aber du bist ja gar nicht, es ist ja gar nicht 00:48:25.150 --> 00:48:29.110 linear zurück, dein Code geht ja nicht linear weiter, sondern irgendwo 00:48:29.110 --> 00:48:33.330 anders passiert irgendwas, das aber durchaus Auswirkungen darauf haben kann, 00:48:33.710 --> 00:48:37.370 was später in dem Code, der dann jetzt sozusagen von dir ausgesehen weiterläuft, 00:48:37.370 --> 00:48:40.030 drauf ausgeguckt hat. 00:48:40.130 --> 00:48:41.870 Das heißt, du musst wissen, okay, 00:48:41.970 --> 00:48:44.070 der Task, der da noch läuft, der wird später mal 00:48:44.070 --> 00:48:46.170 irgendwas Böses machen oder vielleicht noch irgendwie 00:48:46.170 --> 00:48:48.050 keine Ahnung. Und da muss ich auf jeden Fall dran denken, 00:48:48.190 --> 00:48:49.890 dass der mir vielleicht irgendwie dazwischen gratscht 00:48:49.890 --> 00:48:52.130 oder ich muss hier mal ein Lock setzen, damit das irgendwie 00:48:52.130 --> 00:48:53.870 atomar bleibt und keine Ahnung. 00:48:55.430 --> 00:48:56.130 Das heißt, ich kann 00:48:56.130 --> 00:48:57.970 nicht mehr sagen, okay, ich habe jetzt 00:48:57.970 --> 00:48:59.610 diese Funktion aufgerufen, es ist gut, 00:49:00.150 --> 00:49:01.350 ich weiß jetzt Bescheid, 00:49:01.970 --> 00:49:04.010 es hat funktioniert oder nicht und ich mache jetzt weiter. 00:49:04.530 --> 00:49:06.070 Sondern, ja, ich habe dieses 00:49:06.070 --> 00:49:07.370 Future-Ding in der Hand, aber 00:49:07.370 --> 00:49:10.230 tatsächlich muss ich mir irgendwie selber merken, 00:49:10.390 --> 00:49:11.990 was da noch alles passieren kann. 00:49:12.390 --> 00:49:13.970 Und das ist natürlich schlecht, weil es macht halt genau 00:49:13.970 --> 00:49:15.050 diese lokale 00:49:15.050 --> 00:49:17.670 Nachdenken über Code 00:49:17.670 --> 00:49:19.830 kaputt. Und er sagt halt so, alle 00:49:19.830 --> 00:49:22.030 Concurrency-Lösungen, die dazu 00:49:22.030 --> 00:49:24.130 führen, dass man nicht mehr lokal über Code nachdenken kann, 00:49:24.750 --> 00:49:25.390 das ist alles 00:49:25.390 --> 00:49:28.030 nicht richtig. Das sollte man so 00:49:28.030 --> 00:49:30.030 nicht machen. Ja, was ist da die Lösung 00:49:30.030 --> 00:49:32.270 jetzt davon? Ja, also er hat da 00:49:32.270 --> 00:49:32.830 so ein Konzept, 00:49:34.070 --> 00:49:35.070 das heißt da irgendwie 00:49:35.070 --> 00:49:35.750 Nurseries. 00:49:39.590 --> 00:49:40.870 Nurseries, die kleine Krankenschwester, 00:49:40.990 --> 00:49:42.370 die die Babys auf der Aufsatzstation ist. 00:49:42.370 --> 00:49:44.250 Genau, er sagt so, ja, so Tars 00:49:44.250 --> 00:49:45.950 oder sind so wie so kleine Kinder, 00:49:46.330 --> 00:49:48.350 die darf man nicht einfach so frei rumlaufen lassen, 00:49:48.530 --> 00:49:48.950 das ist nicht gut. 00:49:49.470 --> 00:49:51.730 Die muss man irgendwo einsperren, wo sie dann 00:49:51.730 --> 00:49:52.910 gepflegt werden. 00:49:54.770 --> 00:49:55.930 Wo sich jemand drum kümmert. 00:49:56.630 --> 00:49:57.770 Die dürfen aber nicht raus. 00:49:58.250 --> 00:50:00.110 Ja, genau. Und das Ganze ist in so einem 00:50:00.110 --> 00:50:02.010 Context Manager drin und tatsächlich, also 00:50:02.010 --> 00:50:04.370 ich habe noch nicht so viel damit rumgespielt, also es sah gut aus, 00:50:04.370 --> 00:50:15.900 auf Ja angeblich ist das wohl eine M das so hinzukriegen dass man weiterhin lokal Sachen nachdenken kann und dieses Problem dass man Spalter hat gar nicht mehr bekommt 00:50:16.960 --> 00:50:24.920 Und es ist sogar teilweise einfacher, Sachen damit umzusetzen. Es gibt ja diesen für IP Happy Eyeballs-Algorithmus, der auch in Twisted drin ist. 00:50:24.920 --> 00:50:26.440 und es gibt eine Twisted-Implementierung, die ist 00:50:26.440 --> 00:50:28.880 120 Zeilen und relativ fies 00:50:28.880 --> 00:50:31.000 und es gibt eine in Trio und die 00:50:31.000 --> 00:50:32.880 ist halt irgendwie, weiß ich nicht, 00:50:33.020 --> 00:50:34.820 also ich meine, obwohl Zeilenvergleich ist auch wieder ein bisschen 00:50:34.820 --> 00:50:36.760 Quatsch, aber also viel, viel 00:50:36.760 --> 00:50:38.160 weniger und viel klarer. 00:50:38.760 --> 00:50:40.740 Und als er das Ding in Trio nachgeschrieben hat, hat er auch 00:50:40.740 --> 00:50:42.600 diverse logische Fehler in der 00:50:42.600 --> 00:50:44.320 Twisted-Implementation gefunden, 00:50:44.920 --> 00:50:46.760 weil das einfach super schwierig ist, das 00:50:46.760 --> 00:50:48.300 so hinzukriegen mit den Futures. 00:50:48.900 --> 00:50:50.740 Also in Trio gibt es keine Futures 00:50:50.740 --> 00:50:52.500 mehr, es ist halt eher so, 00:50:52.500 --> 00:50:53.800 es gibt diese Nurseries und 00:50:53.800 --> 00:50:55.500 und ja, es wurde auch schon 00:50:55.500 --> 00:50:57.380 darüber nachgedacht, ob das nicht vielleicht eine gute 00:50:57.380 --> 00:50:58.500 Geschichte wäre, das in 00:50:58.500 --> 00:51:01.900 Python direkt einzubauen 00:51:01.900 --> 00:51:03.460 und statt AsyncIO zum Beispiel 00:51:03.460 --> 00:51:05.500 zu verwenden, aber das ist 00:51:05.500 --> 00:51:07.380 alles noch gerade so dabei, 00:51:07.680 --> 00:51:08.440 quasi noch nicht 00:51:08.440 --> 00:51:11.020 Der Zug ist nicht schon längst abgefahren, weil 00:51:11.020 --> 00:51:12.980 der ist ja jetzt schon drin in Python 00:51:12.980 --> 00:51:14.980 Ja, vielleicht ist er das schon, 00:51:15.080 --> 00:51:17.540 viele Leute verwenden 00:51:17.540 --> 00:51:19.360 AsyncIO, als dass man das noch 00:51:19.360 --> 00:51:21.100 vielleicht ändern könnte und es gibt halt da 00:51:21.100 --> 00:51:22.940 diesen Ökosystem-Split und 00:51:22.940 --> 00:51:24.600 und ja, wahrscheinlich ist es besser dann eben 00:51:24.600 --> 00:51:26.700 auf das zu versetzen, was eh dabei ist. 00:51:26.860 --> 00:51:28.820 Also Trio macht ja sowas, du hast jetzt gesagt 00:51:28.820 --> 00:51:30.800 Kontextmanager, das heißt man muss diesen lokalen 00:51:30.800 --> 00:51:32.600 Scope nicht verlassen. Ist das nicht eigentlich das, was 00:51:32.600 --> 00:51:34.000 Funktionen tun, sowieso schon? 00:51:34.720 --> 00:51:36.600 Ja, ja, aber Funktionen funktioniert halt nicht so richtig. 00:51:37.420 --> 00:51:37.740 Weil? 00:51:38.960 --> 00:51:40.400 Die Tats laufen ja weiter. 00:51:42.320 --> 00:51:42.900 Das ist halt 00:51:42.900 --> 00:51:44.700 auch bei Asso, wenn du halt eine Funktion 00:51:44.700 --> 00:51:48.980 wenn du Concurrence irgendwas machst, 00:51:49.120 --> 00:51:50.860 dann hört das halt nicht in dem Moment auf, 00:51:50.860 --> 00:51:52.700 wo du das aufgerufen hast, sondern das läuft halt unter 00:51:52.700 --> 00:51:56.260 Umständen weiter. Das heißt, ich habe beispielsweise nur den halben Whisky 00:51:56.260 --> 00:52:00.380 eingeschenkt und die andere Hälfte, die kommt aber noch. Ja, genau. Aber woanders fängt der halt an, 00:52:00.460 --> 00:52:03.640 dann schon andere Limetten reinzubekommen. 00:52:05.020 --> 00:52:08.400 Und was ist der Unterschied in Trio? Da macht er dann trotzdem erst 00:52:08.400 --> 00:52:12.200 den einen Schritt fertig? Oder wieso ist das so isoliert? Also vielleicht 00:52:12.200 --> 00:52:16.300 bei diesem Barkeeper-Beispiel das so anschaulich hinzubekommen? Ich weiß nicht, ob ich das 00:52:16.300 --> 00:52:20.120 tatsächlich hinkriege. Also muss man sich selber angucken. Da gibt es auch 00:52:20.120 --> 00:52:22.400 Schaubilder auf der Seite, aber das zu erklären, 00:52:23.360 --> 00:52:24.100 weiß ich nicht, ob das... 00:52:24.100 --> 00:52:26.200 Das ist so ein bisschen das Problem, das generelle Problem 00:52:26.200 --> 00:52:28.240 an Concurrent Programming, oder? Dass diese Sachen alle 00:52:28.240 --> 00:52:29.940 gleich so kompliziert werden, dass man dann 00:52:29.940 --> 00:52:32.000 diverse Schaubilder braucht und 00:52:32.000 --> 00:52:34.340 Leute dann irgendwann sagen, ja, lass lieber 00:52:34.340 --> 00:52:35.520 die Finger davon, das ist nicht so. 00:52:35.580 --> 00:52:37.640 Ja, und tatsächlich ist das vielleicht gar keine so schlechte... 00:52:37.640 --> 00:52:39.760 Ich würde auch sagen, also auch meine Erfahrungen, die ich damit 00:52:39.760 --> 00:52:42.220 so bisher gesammelt habe, die waren alle immer... 00:52:42.220 --> 00:52:44.300 Es war immer ziemlich fies. Also das war immer... 00:52:45.200 --> 00:52:46.080 Also die 00:52:46.080 --> 00:52:47.620 Beispiele, die haben immer funktioniert, 00:52:48.000 --> 00:52:49.740 wenn man sich irgendwie so Tutorials oder so anguckt. 00:52:50.120 --> 00:52:52.500 Wenn man es dann tatsächlich ausprobiert mit irgendwie 00:52:52.500 --> 00:52:55.180 in den Fällen, wo man es dann halt wirklich braucht, 00:52:55.260 --> 00:52:56.600 wo man dann viel Last macht, 00:52:57.360 --> 00:52:58.500 dann sind mir jedes Mal 00:52:58.500 --> 00:53:00.080 passieren komische Sachen 00:53:00.080 --> 00:53:02.500 und das Debugging ist jedes Mal 00:53:02.500 --> 00:53:05.280 Das ist so bei Google, da passieren immer komische Sachen. 00:53:05.380 --> 00:53:06.520 Ja, also wirklich, also 00:53:06.520 --> 00:53:07.720 zum Beispiel einen Bug, 00:53:08.240 --> 00:53:10.400 da habe ich jetzt noch, und diese 00:53:10.400 --> 00:53:11.920 Geschichten, ich meine, das passiert anderen Leuten auch. 00:53:12.540 --> 00:53:13.420 Zum Beispiel der 00:53:13.420 --> 00:53:16.040 Gründer von, 00:53:16.840 --> 00:53:18.600 der ursprüngliche Entwickler von Twisted 00:53:18.600 --> 00:53:21.000 hat einen langen Artikel darüber geschrieben, warum man Multithreading 00:53:21.000 --> 00:53:22.900 hasst, wo er dann 00:53:22.900 --> 00:53:24.780 geschrieben hat, sie hatten also Probleme 00:53:24.780 --> 00:53:25.620 und sie hatten dieses 00:53:25.620 --> 00:53:28.600 sie hatten einen wirklich fiesen Bug in ihrem 00:53:28.600 --> 00:53:29.980 größeren System und 00:53:29.980 --> 00:53:32.580 der ist halt irgendwie nur ab und zu 00:53:32.580 --> 00:53:34.580 aufgetreten, sie haben es überhaupt niemals reproduzieren 00:53:34.580 --> 00:53:36.460 können und sie sind es nicht losgeworden 00:53:36.460 --> 00:53:38.740 und sie haben alles from scratch 00:53:38.740 --> 00:53:40.540 nochmal neu geschrieben, reimplementiert 00:53:40.540 --> 00:53:42.680 um den Bug wegzukriegen, weil sie ihn einfach 00:53:42.680 --> 00:53:43.940 über Monate nicht finden konnten 00:53:43.940 --> 00:53:45.740 und das ist eigentlich schon echt bitter 00:53:45.740 --> 00:53:48.520 und es ist auch super schwer zu testen 00:53:48.520 --> 00:53:50.320 so Zeug, das ist auch super schwer zu sagen 00:53:50.320 --> 00:53:52.440 wenn ich X mache und Y, dann passiert 00:53:52.440 --> 00:53:54.500 Z, sondern es ist halt, wenn 37 00:53:54.500 --> 00:53:56.460 Leute gleichzeitig X machen und einer von denen 00:53:56.460 --> 00:53:58.380 aber Z macht und einer von denen Y 00:53:58.380 --> 00:54:00.460 und 23 A 00:54:00.460 --> 00:54:02.200 und B, dann passiert 00:54:02.200 --> 00:54:03.960 irgendwas 00:54:03.960 --> 00:54:05.760 Buchstabensuppe 00:54:05.760 --> 00:54:08.240 dann passiert Buchstabensuppe und das ist ein Bug 00:54:08.240 --> 00:54:10.700 ja, was ich da mal hatte 00:54:10.700 --> 00:54:12.520 war halt, genau, ich hab halt 00:54:12.520 --> 00:54:14.380 so ein Webcrawler-artiges geschrieben 00:54:14.380 --> 00:54:15.580 und 00:54:15.580 --> 00:54:18.500 mit ein paar tausend Seiten und weiß ich nicht, so 00:54:18.500 --> 00:54:20.640 100 Seiten 00:54:20.640 --> 00:54:22.760 gleichzeitig abfragen pro Sekunde oder so, alles gar kein Problem. 00:54:23.200 --> 00:54:24.560 Also okay, gehen wir auf eine halbe 00:54:24.560 --> 00:54:26.560 Million oder eine Million und machen das mal so 00:54:26.560 --> 00:54:28.260 irgendwie ordentlich so mit ein paar tausend pro Sekunde. 00:54:29.040 --> 00:54:30.440 Und dann passieren plötzlich 00:54:30.440 --> 00:54:31.720 seltsame Geschichten. 00:54:32.640 --> 00:54:34.320 Irgendwie sterben plötzlich Sachen 00:54:34.320 --> 00:54:36.280 oder was ich dann hatte, es wird plötzlich 00:54:36.280 --> 00:54:38.140 irgendwie seltsam langsamer. 00:54:38.320 --> 00:54:40.180 Man weiß nicht warum. Plötzlich 00:54:40.180 --> 00:54:41.800 kriegt man ganz eigenartige 00:54:41.800 --> 00:54:43.840 Tracebacks aus den Tiefen von Python. 00:54:43.840 --> 00:54:45.860 also was ich dann irgendwie 00:54:45.860 --> 00:54:48.100 rausgefunden habe, 00:54:48.100 --> 00:54:50.120 das war halt irgendwie die Resolver-Library 00:54:50.120 --> 00:54:51.920 auf meinem Mac, ich habe es auf dem Mac probiert, 00:54:52.400 --> 00:54:54.080 die hat halt irgendwie angefangen plötzlich Probleme 00:54:54.080 --> 00:54:55.720 zu machen und 00:54:55.720 --> 00:54:58.160 zum Glück auf Linux ging es dann, das ist auch immer 00:54:58.160 --> 00:54:59.460 sowas, ja Mac gibt es dann 00:54:59.460 --> 00:55:02.160 vielleicht für Smoketest gar nicht so 00:55:02.160 --> 00:55:03.260 schlecht, der macht dann irgendwie 00:55:03.260 --> 00:55:06.280 ein bisschen früher irgendwie, fängt an zu rauchen 00:55:06.280 --> 00:55:08.180 dann heißt das schon, so bei Linux 00:55:08.180 --> 00:55:09.900 gehen dann viele Sachen, wo der Mac dann schon raucht 00:55:09.900 --> 00:55:12.020 aber also das war 00:55:12.020 --> 00:55:14.200 und da habe ich auch lange dran rumgedebuggt und nichts gefunden 00:55:14.200 --> 00:55:15.320 und das ist ganz schrecklich. 00:55:17.240 --> 00:55:17.640 Ja, 00:55:18.160 --> 00:55:20.100 Load macht Dinge kaputt, 00:55:20.540 --> 00:55:22.040 die schwer 00:55:22.040 --> 00:55:23.820 zu finden sind und schwer zu sehen sind. 00:55:25.000 --> 00:55:25.240 Und 00:55:25.240 --> 00:55:27.560 die dann auch nur so sporadisch auftauchen. 00:55:27.700 --> 00:55:29.840 Da wird es dann auf einmal statistisch, wenn du sagst, okay, 00:55:30.000 --> 00:55:32.640 mein Programm geht in 99% 00:55:32.640 --> 00:55:33.340 der 00:55:33.340 --> 00:55:35.340 Abläufe. Das ist dann der echte Bug. 00:55:35.520 --> 00:55:38.260 Das ist dann wie, dass in der Schaltung irgendwo ein Käfer reingeklettert 00:55:38.260 --> 00:55:39.940 ist, weil die Schaltung so groß ist, dass 00:55:39.940 --> 00:55:41.720 da irgendein Käfer dazwischen passt und du weißt aber nicht, 00:55:41.720 --> 00:55:44.120 Wenn halt der DNS-Resolver nur 99% 00:55:44.120 --> 00:55:45.820 aller Anfragen korrekt beantwortet und 00:55:45.820 --> 00:55:47.620 in einem Prozent der Anfragen halt abstürzt oder 00:55:47.620 --> 00:55:49.380 irgendeinen Quatsch macht, dann 00:55:49.380 --> 00:55:51.840 hast du halt so statistische Dinge. Aber das ist natürlich 00:55:51.840 --> 00:55:53.480 sehr unbefriedigend, weil ja eigentlich 00:55:53.480 --> 00:55:55.340 also als 00:55:55.340 --> 00:55:57.800 Softwareentwickler oder als Informatiker ist man 00:55:57.800 --> 00:56:00.220 ja gewöhnt, dass wenn es geht, dass es dann zu 100% 00:56:00.220 --> 00:56:00.900 geht und immer. 00:56:01.940 --> 00:56:02.880 Und nicht eben... 00:56:02.880 --> 00:56:05.840 Ein anderes Beispiel, eben Lukas Langer, der hat 00:56:05.840 --> 00:56:07.740 ja bei Facebook gearbeitet und hat dann auch so ein 00:56:07.740 --> 00:56:09.720 Beispiel für, sie hatten halt irgendwie ein Ding, 00:56:09.720 --> 00:56:11.900 was halt auch Async.io gemacht hat 00:56:11.900 --> 00:56:13.900 und dann haben sie da auch Durchsatz 00:56:13.900 --> 00:56:15.940 wenn es anfing so richtig Durchsatz 00:56:15.940 --> 00:56:17.680 zu machen, wurde es plötzlich 00:56:17.680 --> 00:56:19.000 irgendwie magisch langsamer 00:56:19.000 --> 00:56:21.520 und sie haben dann 00:56:21.520 --> 00:56:24.020 auf ihre Kurven geguckt und sie haben es nicht verstanden 00:56:24.020 --> 00:56:26.220 und dann bis dann irgendwann jemandem aufgefallen ist 00:56:26.220 --> 00:56:28.120 oh, wo kommen 00:56:28.120 --> 00:56:29.040 eigentlich diese Kurven her? 00:56:29.500 --> 00:56:32.000 Es gibt da halt noch einen Thread, der guckt sich 00:56:32.000 --> 00:56:33.820 halt an, was die anderen Threads so machen 00:56:33.820 --> 00:56:35.060 und was die anderen Tasks so machen 00:56:35.060 --> 00:56:37.720 und der hatte halt in der Art, wie er 00:56:37.720 --> 00:56:39.760 dann halt die Ergebnisse von dem, was er gesehen hat, 00:56:39.800 --> 00:56:41.160 wie er sammelt hat, irgendwie so einen naiven 00:56:41.160 --> 00:56:43.700 Algorithmus drin, der mit der Last nicht gut 00:56:43.700 --> 00:56:45.320 klargekommen ist, der dann halt 00:56:45.320 --> 00:56:47.600 schnell langsamer geworden ist und der wurde 00:56:47.600 --> 00:56:49.540 dann so langsam, dass er alles andere aufgehalten hat. 00:56:50.180 --> 00:56:51.920 Und da ist dann sozusagen die CPU rausgelegt. 00:56:53.580 --> 00:56:55.600 Ja, also, aber das sind 00:56:55.600 --> 00:56:56.980 alles so ganz ekelhafte Probleme. 00:56:57.540 --> 00:56:59.720 Wenn man das nicht braucht, sollte man 00:56:59.720 --> 00:57:00.480 das nicht machen, glaube ich. 00:57:02.880 --> 00:57:03.660 Ja, oder halt 00:57:03.660 --> 00:57:05.580 sich möglichst weit davon fernhalten. 00:57:05.580 --> 00:57:07.460 Also ich meine, wir sind ja Django-Entwickler 00:57:07.460 --> 00:57:08.500 und wir haben das ja schon lange. 00:57:08.940 --> 00:57:11.040 Wir haben ja schon lange Sachen, die 00:57:11.040 --> 00:57:13.260 Concurrency sind, weil wir halt, wenn du irgendwo 00:57:13.260 --> 00:57:15.440 was deployst, dann machst du halt 10 Unicorn-Prozesse 00:57:15.440 --> 00:57:17.300 an oder so. Aber die 00:57:17.300 --> 00:57:19.140 sind ja im Wesentlichen unabhängig voneinander. 00:57:19.820 --> 00:57:19.960 Die 00:57:19.960 --> 00:57:23.460 kommunizieren nur über die Datenbank. 00:57:23.540 --> 00:57:25.220 Die Datenbank ist da das, was 00:57:25.220 --> 00:57:26.580 die Concurrency macht oder was die 00:57:26.580 --> 00:57:29.100 Datensätze hat. Dass die Datenprobleme löst, 00:57:29.180 --> 00:57:30.520 dass das isoliert ist. Genau. 00:57:30.660 --> 00:57:33.240 Da bin ich ganz froh, dass es eine gute Datenbank gibt. 00:57:34.240 --> 00:57:34.600 Genau. 00:57:35.140 --> 00:57:36.100 Wo ich einfach sagen kann, okay, 00:57:36.100 --> 00:58:06.080 und Jochen unterhalten sich über die Programmiersprache Python 00:58:06.100 --> 00:58:10.380 gar nicht, dass sie keine Kommunikation machen müssen. Dann kannst du sie auf verschiedenen 00:58:10.380 --> 00:58:13.440 Rechnern ausführen. Dann kannst du sie skalieren. 00:58:14.020 --> 00:58:17.980 Kannst du sie wegskalieren. Entweder über Prozesse oder über Prozessoren, 00:58:18.140 --> 00:58:21.360 über unterschiedliche Maschinen oder über Docker-Container, 00:58:21.360 --> 00:58:24.560 oder über einen Kubernetes-Cluster, wo du dann halt 00:58:24.560 --> 00:58:28.780 im Prinzip das Gleiche an ganz vielen verschiedenen Stellen 00:58:28.780 --> 00:58:31.420 ausführst. Das ist ein Modell. 00:58:31.420 --> 00:58:55.940 Ja, aber nehmen wir jetzt mal den Fall, du willst jetzt eben sowas machen wie zum Beispiel, keine Ahnung, was mit Felix Elixier und Liveview geht, du hast halt eine Webseite und pushst den Leuten quasi reaktiv irgendwie Dinge in den DOM und du hast dann natürlich eine Websocket-Connection zu jedem Client und das können ja dann Tausende sein oder Zehntausende, dann musst du all diese Verbindungen irgendwie handeln, musst damit was machen. 00:58:55.940 --> 00:58:57.900 Wenn du jetzt dieses klassische Worker-Modell 00:58:57.900 --> 00:58:59.360 mit Unicorn machst, das geht auch, 00:58:59.500 --> 00:59:01.720 dann hast du aber irgendwie einen Haufen 00:59:01.720 --> 00:59:03.400 Verbindungen und brauchst einen Haufen Server. 00:59:04.940 --> 00:59:05.900 Wahrscheinlich kannst du das auch 00:59:05.900 --> 00:59:07.540 mit einem machen. Ja, da würde ich 00:59:07.540 --> 00:59:09.940 mir einfach wünschen, dass es sozusagen so eine 00:59:10.640 --> 00:59:12.100 Verbindungsdatenbank 00:59:12.100 --> 00:59:12.340 gibt, 00:59:12.880 --> 00:59:15.700 die dieses schwierige Problem 00:59:15.700 --> 00:59:17.480 wegabstrahiert, aber ich glaube, da gibt es noch nichts. 00:59:18.240 --> 00:59:19.340 Ja, aber tatsächlich 00:59:19.340 --> 00:59:21.540 mit Django 3.1 00:59:21.540 --> 00:59:23.480 Async Views geht das tatsächlich. 00:59:23.480 --> 00:59:25.080 Also ich meine, man kann auch einfach was anderes nehmen. 00:59:25.080 --> 00:59:26.920 also womit man das schon länger machen kann 00:59:26.920 --> 00:59:28.820 ist wahrscheinlich sowas wie man Starlet 00:59:28.820 --> 00:59:30.900 nimmt oder so oder irgendwas 00:59:30.900 --> 00:59:32.760 in der Richtung. Ja, aber die nehmen ja auch alle 00:59:32.760 --> 00:59:34.840 AsyncIO, also die machen ja auch keine Magie. 00:59:34.900 --> 00:59:36.900 Genau, genau, genau, aber da ging das halt 00:59:36.900 --> 00:59:38.560 in Django ging es bisher halt noch nicht 00:59:38.560 --> 00:59:40.480 also jetzt geht es halt dann halbwegs. 00:59:40.740 --> 00:59:42.360 Was macht Django denn jetzt alles so schönes? 00:59:42.600 --> 00:59:43.180 Genau, jetzt 00:59:43.180 --> 00:59:46.860 kann es, also was neu 00:59:46.860 --> 00:59:48.820 dazukommt sind AsyncViews 00:59:48.820 --> 00:59:50.780 wo man 00:59:50.780 --> 00:59:52.700 halt sozusagen als View tatsächlich 00:59:52.700 --> 00:59:54.720 eine Funktion hat oder eben auch eine Klasse, wo man dann 00:59:54.720 --> 00:59:58.400 halt die Call-Methode als async-dev markiert, 00:59:59.200 --> 01:00:02.280 also async-Funktionen hat, die Views sind und 01:00:02.280 --> 01:00:05.880 die dann Core-Routinen zurückgeben. 01:00:06.740 --> 01:00:10.620 Und dafür muss das Interface, also das ist bei mir schon mit Django 3.0 01:00:10.620 --> 01:00:14.360 passiert, das Interface zum Server, es muss möglich sein, was anderes zu benutzen als 01:00:14.360 --> 01:00:18.020 BSGI. Und das, was man da verwendet, ist halt dann ASGI. 01:00:19.980 --> 01:00:22.400 Und das kann halt beide Richtungen und 01:00:22.400 --> 01:00:24.120 und ja, ist halt... 01:00:24.120 --> 01:00:26.200 Also Web-Server-Gateway-Interface und Asynchronos 01:00:26.200 --> 01:00:27.640 Ja, genau. 01:00:28.240 --> 01:00:29.840 Ist sozusagen das 01:00:29.840 --> 01:00:31.920 übertragen auf den Fall, den man jetzt halt dann hat. 01:00:32.820 --> 01:00:34.100 Und genau, 01:00:34.200 --> 01:00:35.860 kommt auch aus dem Channels-Projekt irgendwie. 01:00:35.960 --> 01:00:37.780 Andrew Godwin hat das Ding halt auch in den Standard 01:00:37.780 --> 01:00:40.100 irgendwie dafür sozusagen hauptsächlich 01:00:40.100 --> 01:00:41.400 glaube ich irgendwie geschrieben. 01:00:42.280 --> 01:00:43.940 Ist jetzt in der Version 2.0 01:00:43.940 --> 01:00:45.880 oder sowas da und ist auch mehr oder weniger 01:00:45.880 --> 01:00:47.880 fertig und wird auch von allen anderen quasi 01:00:47.880 --> 01:00:49.660 so adaptiert. Also das hat sich wohl tatsächlich 01:00:49.660 --> 01:00:51.980 mittlerweile eigentlich als Standard für solche 01:00:51.980 --> 01:00:53.760 hat sich durchgesetzt 01:00:53.760 --> 01:00:55.920 für, das ist halt der Standard, wie jetzt ein 01:00:55.920 --> 01:00:57.940 Applikationsserver mit der Applikation irgendwie kommuniziert. 01:00:58.960 --> 01:00:59.200 Und 01:00:59.200 --> 01:01:00.460 genau. 01:01:02.640 --> 01:01:04.020 Und was in Django 01:01:04.020 --> 01:01:05.280 3.1 jetzt dazugekommen ist, 01:01:06.980 --> 01:01:08.260 sind die 01:01:08.260 --> 01:01:09.940 Views, das ging halt in 3.0 noch nicht. 01:01:11.820 --> 01:01:12.260 Middlewares 01:01:12.260 --> 01:01:14.120 und das war halt 01:01:14.120 --> 01:01:15.900 auch einer der schwierigen Teile halt. 01:01:16.120 --> 01:01:17.120 Das Problem ist, du musst halt 01:01:17.120 --> 01:01:20.040 es hinkriegen. Also wenn eine synchrone Middleware dazwischen ist, 01:01:20.040 --> 01:01:21.060 dann geht es halt schon eigentlich nicht mehr. 01:01:21.980 --> 01:01:23.820 die ganzen Mittelbeurs-Async zu kriegen 01:01:23.820 --> 01:01:24.860 und 01:01:24.860 --> 01:01:28.120 auch Async-Tests 01:01:28.120 --> 01:01:28.740 gehen halt auch. 01:01:30.080 --> 01:01:31.820 Und damit ist halt tatsächlich schon mal was da, 01:01:31.900 --> 01:01:33.400 womit man was machen kann. Ich meine, 01:01:34.060 --> 01:01:36.060 tatsächlich, also die Wunschvorstellung, die ich an das Ganze 01:01:36.060 --> 01:01:37.660 hätte, eigentlich ist da so, dass 01:01:37.660 --> 01:01:39.860 alle Dinge, die jetzt I.O. machen 01:01:39.860 --> 01:01:41.700 auf meinem Server, also normale Webseite, 01:01:42.000 --> 01:01:43.060 kommt ein Request rein, 01:01:43.980 --> 01:01:45.860 das Ding macht halt, irgendwie, 01:01:45.920 --> 01:01:47.820 keine Ahnung, fünf Statements an 01:01:47.820 --> 01:01:49.760 eine Datenbank, fragt irgendwie 01:01:49.760 --> 01:01:51.100 ein Redis-Cache, 01:01:51.980 --> 01:01:53.640 fragt noch irgendeine API oder sowas 01:01:53.640 --> 01:01:56.000 und gibt dann irgendwie eine Antwort zurück 01:01:56.000 --> 01:01:58.020 in dem View und momentan 01:01:58.020 --> 01:01:59.980 ist es halt so, da wartet man dann halt 01:01:59.980 --> 01:02:02.060 synchron auf jede einzelne Anfrage, 01:02:02.140 --> 01:02:03.920 die man irgendwo hinstellt und alle Latenzen addieren 01:02:03.920 --> 01:02:05.200 sich und 01:02:05.200 --> 01:02:08.120 bis man das erste Byte am Client 01:02:08.120 --> 01:02:10.000 empfängt, muss man halt diese ganzen 01:02:10.000 --> 01:02:11.980 Netzwerk 01:02:11.980 --> 01:02:14.300 Zeiten 01:02:14.300 --> 01:02:15.980 abgewartet haben und 01:02:15.980 --> 01:02:17.960 das kann halt sein, dass das dann irgendwann, wenn man 01:02:17.960 --> 01:02:19.880 viele Statements macht oder wenn man viele APIs 01:02:19.880 --> 01:02:22.060 fragt, dann wird das halt viel und man kann 01:02:22.060 --> 01:02:23.860 im Grunde nichts tun, so wirklich. 01:02:24.280 --> 01:02:26.180 Oder man muss es halt komplett selber machen. Das Framework 01:02:26.180 --> 01:02:27.960 gibt einem da nichts an die Hand, womit man 01:02:27.960 --> 01:02:28.840 das irgendwie verbessern kann. 01:02:30.340 --> 01:02:32.120 Und sozusagen in einer goldenen 01:02:32.120 --> 01:02:34.060 Zukunft wäre es halt 01:02:34.060 --> 01:02:35.880 vielleicht so, dass man sagt, okay, 01:02:36.880 --> 01:02:37.940 das wird alles async 01:02:37.940 --> 01:02:39.940 zusammengesammelt. Alle Sachen, die 01:02:39.940 --> 01:02:42.240 I.O. machen nach außen, 01:02:42.940 --> 01:02:43.680 erwägtet man halt. 01:02:45.360 --> 01:02:45.760 Und 01:02:45.760 --> 01:02:48.100 die Latenz, die man 01:02:48.100 --> 01:02:49.940 als Client, wenn man die Seite 01:02:49.940 --> 01:02:51.960 abfragt, zu sehen bekommt, 01:02:52.080 --> 01:02:53.900 ist die, die der 01:02:53.900 --> 01:02:56.420 längste I.O. 01:02:57.140 --> 01:02:58.120 Ding nach draußen braucht. 01:02:58.240 --> 01:02:59.420 Aber alle anderen sind dann halt schon da. 01:03:00.500 --> 01:03:01.500 Das heißt, es ist nicht mehr, 01:03:01.820 --> 01:03:04.000 alle Latenzen addieren sich, sondern die Latenz, die man sieht, 01:03:04.100 --> 01:03:05.600 ist die von dem längsten 01:03:05.600 --> 01:03:07.200 Einzelteil, sozusagen. 01:03:08.760 --> 01:03:08.880 Ja. 01:03:10.380 --> 01:03:11.440 Aber ist das jetzt nicht 01:03:11.440 --> 01:03:12.560 Parallelität? 01:03:13.180 --> 01:03:14.360 Nö, das ist Concurrency. 01:03:14.500 --> 01:03:16.220 Das ist alles immer nur... 01:03:16.220 --> 01:03:18.120 Genau. Weil ich sehe da, 01:03:18.220 --> 01:03:20.160 ich sehe echt einen ganz anderen Anwendungsfall für diese 01:03:20.160 --> 01:03:22.300 Async-Views und Async- 01:03:22.300 --> 01:03:23.020 Middlewares und so weiter. 01:03:23.900 --> 01:03:25.060 Ich sehe halt, dass du 01:03:25.060 --> 01:03:28.300 lange laufende 01:03:28.300 --> 01:03:29.980 Views hast und nicht den 01:03:29.980 --> 01:03:32.200 Worker 01:03:32.200 --> 01:03:34.160 blockierst. Das heißt, du kannst derweil 01:03:34.160 --> 01:03:35.580 andere Clients behandeln. 01:03:35.680 --> 01:03:38.180 Das ist ja genau das, 01:03:38.240 --> 01:03:39.980 was du bei WebSockets brauchst. Du hast ja im Wesentlichen 01:03:39.980 --> 01:03:41.960 einen Request, der für immer läuft. 01:03:42.180 --> 01:03:43.760 Oder solange wie der Client halt da ist. 01:03:44.480 --> 01:03:45.940 Und zwischendurch kannst du aber was anderes machen. 01:03:45.940 --> 01:03:48.120 und der kann prinzipiell ja dann auch mit anderen 01:03:48.120 --> 01:03:50.380 Views kommunizieren. 01:03:50.940 --> 01:03:52.200 Du hast dich gerade freiwillig 01:03:52.200 --> 01:03:53.800 gemeldet, nochmal zu erklären, was WebSockets sind 01:03:53.800 --> 01:03:56.100 und weil das kam heute 01:03:56.100 --> 01:03:56.640 noch gar nicht dran. 01:03:57.520 --> 01:03:59.280 Ja, WebSockets sind, also 01:03:59.280 --> 01:04:02.160 da muss man ein kleines bisschen ausholen, 01:04:02.280 --> 01:04:02.860 glaube ich, weil 01:04:02.860 --> 01:04:05.940 das, was man so als Webseite kennt, ist, 01:04:05.940 --> 01:04:07.900 das hat so ein Modell, das heißt Request Response. 01:04:08.040 --> 01:04:09.940 Das heißt, du schickst eine Anfrage 01:04:09.940 --> 01:04:11.020 hin und der Server 01:04:11.020 --> 01:04:13.760 bearbeitet die und dann schickt irgendwann eine Antwort 01:04:13.760 --> 01:04:15.760 zurück und dann ist das abgeschlossen. 01:04:15.940 --> 01:04:18.320 Das ist alles, was da passiert. 01:04:18.380 --> 01:04:20.200 Also das, was man da hinschickt, ist dann so eine Anfrage, 01:04:20.340 --> 01:04:22.160 entweder will man irgendwie aus dem klassischen 01:04:22.160 --> 01:04:24.320 Crudstream irgendwas machen, also lesen 01:04:24.320 --> 01:04:26.440 oder schreiben oder updaten 01:04:26.440 --> 01:04:27.880 oder löschen oder sowas und dann 01:04:27.880 --> 01:04:30.140 bekommst du eine Antwort, die dann 01:04:30.140 --> 01:04:31.980 irgendwie so einen Statuscode hat, den man vielleicht irgendwie so kennt. 01:04:32.860 --> 01:04:34.220 Genau, das ist alles 01:04:34.220 --> 01:04:35.620 Feinheiten, die da drin sind. 01:04:35.920 --> 01:04:38.180 Dieser Request-Response-Zyklus ist einfach nur, ich schicke 01:04:38.180 --> 01:04:39.160 dir eine Anfrage hin, 01:04:39.980 --> 01:04:42.040 einen Arbeitsauftrag und der Server 01:04:42.040 --> 01:04:44.160 bearbeitet diesen Arbeitsauftrag und schickt dann 01:04:44.160 --> 01:04:45.740 das Ergebnis zurück. Und was da drin steht, 01:04:45.940 --> 01:04:49.160 spielt erstmal keine Rolle. Das kann sein, gib mir die Homepage, das kann auch sein, 01:04:49.660 --> 01:04:52.180 update alle Bilder in der Datenbank 01:04:52.180 --> 01:04:54.740 und es kann auch sein, lösche alle 01:04:54.740 --> 01:04:58.040 was weiß ich. Das spielt erstmal keine Rolle, sondern 01:04:58.040 --> 01:05:01.120 das Wichtige ist, das ist eine abgeschlossene Welt. 01:05:01.400 --> 01:05:04.300 Ich schicke eine Anfrage hin und die wird bearbeitet und dann 01:05:04.300 --> 01:05:07.200 wird sie zurückgeschickt. Und wenn ich eine neue Anfrage hinschicke, 01:05:07.340 --> 01:05:09.300 dann hat die mit der vorherigen erstmal gar nichts zu tun. 01:05:11.380 --> 01:05:13.140 Man muss dann Tricks benutzen, damit 01:05:13.140 --> 01:05:15.300 damit da sozusagen so eine Kohärenz da ist, 01:05:15.400 --> 01:05:17.200 dass ich der eingeloggte Benutzer bin, 01:05:17.300 --> 01:05:19.160 aber im Endeffekt sind das 01:05:19.160 --> 01:05:20.640 alles Tricks, um einzelne 01:05:20.640 --> 01:05:21.740 Request-Responses, 01:05:22.480 --> 01:05:25.100 um einzelne solche Zyklen so zu machen, 01:05:25.660 --> 01:05:27.540 dass die ausschauen, als ob sie zusammengehören. 01:05:27.560 --> 01:05:29.200 Du meinst sowas wie Session oder sowas? 01:05:29.900 --> 01:05:31.520 Genau, das mit Cookies, 01:05:31.940 --> 01:05:33.300 wo du dann so eine Session-ID hast, 01:05:33.860 --> 01:05:34.680 dann kannst du 01:05:34.680 --> 01:05:37.140 simulieren, dass diese verschiedenen 01:05:37.140 --> 01:05:39.160 Requests alle zusammengehören. 01:05:39.620 --> 01:05:41.260 Aber im Endeffekt sind die alle unterschiedlich. 01:05:41.260 --> 01:06:11.240 und Jochen unterhalten sich über die Programmiersprache Python 01:06:11.260 --> 01:06:13.180 das abgeschlossen. Und wenn du danach 01:06:13.180 --> 01:06:15.300 was Neues brauchst, schickst du eine neue Anfrage, kriegst du eine neue 01:06:15.300 --> 01:06:15.700 Antwort zurück. 01:06:17.400 --> 01:06:19.540 Bei WebSockets ist es anders. Bei WebSockets 01:06:19.540 --> 01:06:21.460 machst du eine Verbindung 01:06:21.460 --> 01:06:23.200 auf und diese Verbindung bleibt 01:06:23.200 --> 01:06:23.900 dann bestehen. 01:06:25.180 --> 01:06:26.980 Und du kannst dann über diese Verbindung 01:06:26.980 --> 01:06:28.780 Daten an den Server schicken. 01:06:29.420 --> 01:06:31.260 Der Server kann aber auch selbstständig Daten 01:06:31.260 --> 01:06:31.760 an dich schicken. 01:06:32.780 --> 01:06:35.060 Und das löst so ein Problem, 01:06:35.180 --> 01:06:36.160 was man früher hatte, wenn 01:06:36.160 --> 01:06:39.060 das klassische Beispiel ist eine Chat 01:06:39.060 --> 01:06:39.960 Anwendung, 01:06:39.960 --> 01:06:44.940 wo halt einer was in sein Chatfenster eintippt und die anderen sollen das dann sehen 01:06:44.940 --> 01:06:48.880 und bei einem Request-Response-Mechanismus 01:06:48.880 --> 01:06:51.640 heißt es, dass die halt die ganze Zeit fragen müssen, gibt es schon was Neues? 01:06:51.920 --> 01:06:55.100 gibt es schon was Neues? gibt es schon was Neues? und der Server die ganze Zeit Nein sagt 01:06:55.100 --> 01:06:58.140 und irgendwann sagt er halt Ja, weil da irgendjemand anderes was eingetippt hat 01:06:58.140 --> 01:07:01.500 viel besser wäre es aber doch, wenn die alle sagen 01:07:01.500 --> 01:07:05.780 ich bin jetzt hier und ich möchte gerne alle Nachrichten aus dem Chatraum hören 01:07:05.780 --> 01:07:08.580 und sobald es eine neue Nachricht in diesem Chatraum gibt 01:07:08.580 --> 01:07:10.660 sagt der Server allen angeschlossenen Clients 01:07:10.660 --> 01:07:11.760 hier ist was Neues. 01:07:12.680 --> 01:07:14.660 Dafür braucht man aber so eine bestehende Verbindung. 01:07:14.840 --> 01:07:16.820 Das heißt, dafür kannst du nicht nur sagen 01:07:16.820 --> 01:07:19.000 beantworte 01:07:19.000 --> 01:07:20.600 mal die Anfrage, gibt es was Neues, sondern 01:07:20.600 --> 01:07:22.680 da ist die Anfrage, informiere mich 01:07:22.680 --> 01:07:23.780 sobald es was Neues gibt. 01:07:24.720 --> 01:07:26.580 Man hat da früher ganz schlimme Technologien 01:07:26.580 --> 01:07:28.580 gemacht. Man hat dann irgendwelche Long-Polling-Requests 01:07:28.580 --> 01:07:30.580 gemacht oder irgendwelche Meteor-Sachen, die 01:07:30.580 --> 01:07:32.080 die HTTP so ein bisschen 01:07:32.080 --> 01:07:34.460 verbogen haben, um das eben 01:07:34.460 --> 01:07:35.060 hinzukriegen. 01:07:36.200 --> 01:07:37.840 Und hat dann irgendwann 01:07:37.840 --> 01:07:40.380 Websocket zum Standard gemacht, was im Wesentlichen 01:07:40.380 --> 01:07:41.520 das macht. Das ist eine 01:07:41.520 --> 01:07:44.180 normale HTTP-Anfrage, die 01:07:44.180 --> 01:07:46.240 dann upgegradet wird, damit die Verbindung 01:07:46.240 --> 01:07:48.300 nicht geschlossen wird. Und diese Verbindung bleibt dann bestehen 01:07:48.300 --> 01:07:50.080 und ist dann bidirektional. Das heißt, 01:07:50.140 --> 01:07:52.260 der Client, der Browser kann Nachrichten 01:07:52.260 --> 01:07:54.100 schicken. Es muss nicht unbedingt ein Browser sein, kann auch 01:07:54.100 --> 01:07:56.160 was anderes sein. Und der Server kann aber auch 01:07:56.160 --> 01:07:58.220 Nachrichten schicken. Und dadurch 01:07:58.220 --> 01:07:59.840 wird eben so dieses 01:07:59.840 --> 01:08:02.200 Modell, dieses Programmiermodell, was man 01:08:02.200 --> 01:08:04.360 früher hatte, ein Request kommt rein, 01:08:04.660 --> 01:08:05.760 erzeugt eine Response, 01:08:05.760 --> 01:08:10.920 ausgehebelt, weil ein Request kommt rein, heißt, wir machen jetzt eine Verbindung auf 01:08:10.920 --> 01:08:15.060 und danach können sehr viele Responses darüber gehen. Da können auch noch neue Requests 01:08:15.060 --> 01:08:19.160 drüber kommen, weil jemand was in sein Chatfenster eingetippt hat und der 01:08:19.160 --> 01:08:21.700 Client sagt dann, bitte veröffentliche das in diesem Kanal. 01:08:23.480 --> 01:08:26.380 Das heißt, Websoft-Grips sind so ein bisschen die 01:08:26.380 --> 01:08:30.760 Erweiterung, nicht eine Erweiterung, 01:08:30.760 --> 01:08:34.200 sondern eine 01:08:34.200 --> 01:08:36.140 eine Möglichkeit, 01:08:36.880 --> 01:08:38.420 ruhere Netzwerkverbindungen 01:08:38.420 --> 01:08:40.560 zu haben, länger bestehende Netzwerkverbindungen 01:08:40.560 --> 01:08:41.000 zu haben, 01:08:41.660 --> 01:08:44.000 aus normaler Browser-Hardware, 01:08:44.400 --> 01:08:46.160 aus normaler Browser-Software aus. 01:08:47.300 --> 01:08:48.380 Es gibt inzwischen auch ganz viele 01:08:48.380 --> 01:08:50.040 andere Clients, die WebSockets verwenden. 01:08:50.180 --> 01:08:52.360 Die meisten Native-Anwendungen 01:08:52.360 --> 01:08:54.260 werden mit ihren 01:08:54.260 --> 01:08:56.320 Servern über WebSockets kommunizieren, 01:08:56.620 --> 01:08:58.500 weil das eben der Standard ist. 01:09:00.860 --> 01:09:02.320 Wie macht man sowas in Tango? 01:09:04.200 --> 01:09:06.420 In Django macht man sowas erstmal gar nicht. 01:09:08.740 --> 01:09:11.100 Beziehungsweise jetzt in 3.1 kann man das eventuell machen. 01:09:11.720 --> 01:09:14.640 Die Websocket-Verbindung muss vom Client aufgebaut werden. 01:09:14.760 --> 01:09:17.000 Das heißt, der Client muss sich irgendwo anmelden und sagen, 01:09:17.100 --> 01:09:18.480 ich möchte gerne einen Websocket haben. 01:09:19.060 --> 01:09:22.200 Und dafür gab es eben in Django diese Erweiterung, die Channel-sized, 01:09:22.340 --> 01:09:23.540 weil Django selber kann das nicht. 01:09:23.620 --> 01:09:25.620 Django selber hat nur den Request-Response-Mechanismus. 01:09:27.100 --> 01:09:30.620 Das ist sofort ersichtlich, wenn man die erste View-Funktion schreibt, 01:09:30.620 --> 01:09:32.700 weil die eben einen Request kriegt. 01:09:32.700 --> 01:09:34.960 und das ist genau der Request, der vom Browser geschickt wird. 01:09:35.700 --> 01:09:36.700 Der sagt, mach mal bitte 01:09:36.700 --> 01:09:37.200 folgendes. 01:09:38.420 --> 01:09:40.660 Und das, was eine View-Funktion erzeugt, ist dann 01:09:40.660 --> 01:09:42.640 eine Response und das ist genau der Abschluss 01:09:42.640 --> 01:09:44.580 dieses, sobald die View-Funktion fertig ist, ist 01:09:44.580 --> 01:09:45.280 die Verbindung weg. 01:09:47.520 --> 01:09:49.020 Um da weiterzugehen, 01:09:49.280 --> 01:09:50.500 um da Websockets machen zu können, 01:09:50.580 --> 01:09:52.440 braucht man eben was anderes und das war früher Channels 01:09:52.440 --> 01:09:54.420 und jetzt wandert das so langsam in Django 01:09:54.420 --> 01:09:56.380 selbst rein. Wobei, also 01:09:56.380 --> 01:09:58.620 das soll wohl nie tatsächlich nach Django reinkommen, 01:09:59.040 --> 01:10:00.380 sondern Channels wird jetzt halt 01:10:00.380 --> 01:10:02.320 das Ding zum Handeln von anderen 01:10:02.320 --> 01:10:04.580 Protokollen, die nicht HTTP sind. 01:10:06.240 --> 01:10:07.940 Und zwar nicht nur... 01:10:07.940 --> 01:10:09.220 Das ist dann halt nicht... 01:10:09.220 --> 01:10:10.500 Das sind halt Django Channels. 01:10:10.900 --> 01:10:13.120 Also es ist quasi... 01:10:13.120 --> 01:10:16.200 Genau, Django Channels macht halt sowas wie WebSockets, 01:10:16.440 --> 01:10:18.080 aber halt nicht nur das, sondern auch WebRTC 01:10:18.080 --> 01:10:19.920 und halt auch MQTT 01:10:19.920 --> 01:10:20.380 und so. 01:10:21.800 --> 01:10:23.940 Also alles, was eben lange Verbindungen braucht. 01:10:24.300 --> 01:10:25.940 Genau, genau. Aber du kannst es 01:10:25.940 --> 01:10:27.940 dann halt schon auch an Django damit anbinden 01:10:27.940 --> 01:10:28.920 in gewisser Weise. 01:10:30.060 --> 01:10:31.560 Genau. Und es wird halt natürlich 01:10:31.560 --> 01:10:31.560 01:10:52.340 --> 01:10:55.780 Ja, also das ist das, was ich da als Anwendungsfall sehe, dass man da leichter sozusagen in diese Welt reinkommt. 01:10:55.780 --> 01:10:57.880 Ja, also was ich total interessant finde, 01:10:57.980 --> 01:10:59.580 also wie gesagt nochmal, also wenn ihr das nicht kennt, 01:10:59.960 --> 01:11:02.060 Phoenix Elixier würde ich mir im Live-View 01:11:02.060 --> 01:11:03.960 angucken. Ja, das ist super spannend. Ja, was das Ding 01:11:03.960 --> 01:11:05.740 nämlich macht ist, also man kennt das ja so, 01:11:05.820 --> 01:11:07.660 also ich würde sagen, das was halt jetzt die meisten Leute schon kennen, 01:11:07.740 --> 01:11:09.880 Single-Page-App mit JavaScript, da funktioniert 01:11:09.880 --> 01:11:11.860 das halt so, du machst halt irgendwie auch 01:11:11.860 --> 01:11:13.840 immer GraphQL oder REST oder 01:11:13.840 --> 01:11:15.640 sonst was abfragen irgendwie gegen 01:11:15.640 --> 01:11:16.620 ein Backend 01:11:16.620 --> 01:11:19.900 und da gibt es 01:11:19.900 --> 01:11:21.620 auch teilweise sowas wie WebSockets oder so, aber 01:11:21.620 --> 01:11:23.360 im Grunde das ganze State-Handling 01:11:23.360 --> 01:11:25.620 deiner Applikation machst 01:11:25.620 --> 01:11:26.480 halt im Client. 01:11:28.300 --> 01:11:29.780 Beliebig eklig oder halt 01:11:29.780 --> 01:11:31.780 auch gut, keine Ahnung. Redux war 01:11:31.780 --> 01:11:33.360 eine Zeit lang in, ist jetzt nicht mehr so. 01:11:33.980 --> 01:11:35.280 Jetzt gibt es halt andere. 01:11:35.620 --> 01:11:36.220 Vue X. 01:11:38.860 --> 01:11:39.300 Aber 01:11:39.300 --> 01:11:41.560 im Grunde, du machst das halt in der 01:11:41.560 --> 01:11:43.120 Applikation, weil 01:11:43.120 --> 01:11:45.060 du dann halt auch da 01:11:45.060 --> 01:11:47.840 das ganze DOM-Diffing machen kannst 01:11:47.840 --> 01:11:49.700 und dann halt nur die Sachen updaten, 01:11:49.860 --> 01:11:51.140 die wirklich geändert werden müssen 01:11:51.140 --> 01:11:53.740 und so. Und damit 01:11:53.740 --> 01:11:55.900 das alles funktioniert, musst du das halt dann im Client 01:11:55.900 --> 01:11:57.440 machen und so. Und 01:11:57.440 --> 01:12:00.140 dieses Phoenix macht das 01:12:00.140 --> 01:12:01.780 halt anders. Das macht das alles auf dem 01:12:01.780 --> 01:12:03.620 Server. Und das schickt 01:12:03.620 --> 01:12:05.500 sozusagen nicht irgendwie 01:12:05.500 --> 01:12:07.780 dir jetzt gedifft irgendwie 01:12:07.780 --> 01:12:09.620 den DOM zurück, sondern es schickt dir halt sozusagen 01:12:09.620 --> 01:12:10.780 die Änderung an deinem State 01:12:10.780 --> 01:12:13.840 zurück an den Client und da 01:12:13.840 --> 01:12:15.780 wird es halt direkt im DOM geändert. Aber 01:12:15.780 --> 01:12:17.640 dadurch, dass das halt sozusagen auf dem Server 01:12:17.640 --> 01:12:19.580 alles ausgerechnet wird, kann das sehr blöd sein auf dem Client. 01:12:19.940 --> 01:12:21.300 Also da ist halt irgendwie das 01:12:21.300 --> 01:12:23.380 JavaScript halt von dem 01:12:23.380 --> 01:12:26.960 von diesem Liveview-Dings ist halt irgendwie so 1000 Zeilen 01:12:26.960 --> 01:12:30.060 und ich habe einen Vortrag von dem Entwickler davon gesehen, 01:12:30.140 --> 01:12:32.780 er meinte immer so, also er muss immer aufpassen, 01:12:32.880 --> 01:12:35.140 er hatte manchmal das Gefühl, er ist jetzt hauptsächlich JavaScript-Entwickler 01:12:35.140 --> 01:12:37.380 und da muss er sich immer selber sagen, nein, 01:12:38.500 --> 01:12:41.740 ich fand diese JavaScript-Frameworks alle immer ganz furchtbar 01:12:41.740 --> 01:12:45.540 und ich wollte das anders machen und ich sollte nicht 01:12:45.540 --> 01:12:48.120 jetzt anfangen, irgendwie das nächste verrückte 01:12:48.120 --> 01:12:50.820 JavaScript-Font endzuschreiben, sondern das muss so wenig 01:12:50.820 --> 01:12:52.220 JavaScript bleiben wie möglich 01:12:52.220 --> 01:12:54.600 und es ist halt auch relativ wenig, es sind halt irgendwie tausend 01:12:54.600 --> 01:12:56.280 Zeilen oder so und 01:12:56.280 --> 01:12:58.400 alles andere passiert auf dem Server 01:12:58.400 --> 01:13:00.380 und das updatet 01:13:00.380 --> 01:13:02.540 den DOM direkt, also 01:13:02.540 --> 01:13:04.560 was über die Leitung geht, ist tatsächlich nur so 01:13:04.560 --> 01:13:05.220 etwas wie 01:13:05.220 --> 01:13:07.960 Name des 01:13:07.960 --> 01:13:10.720 Attributs von irgendeinem Formularfeld oder sowas 01:13:10.720 --> 01:13:12.720 dann neuer Wert und dann wird es halt geändert 01:13:12.720 --> 01:13:13.560 und zwar direkt im DOM 01:13:13.560 --> 01:13:16.600 und das ist halt natürlich nochmal deutlich schneller 01:13:16.600 --> 01:13:18.440 als man das normalerweise so gewöhnt ist 01:13:18.440 --> 01:13:19.960 wenn man den JavaScript 01:13:19.960 --> 01:13:22.640 Frameworks und es ist halt weniger 01:13:22.640 --> 01:13:23.560 Kram auf der Leitung. 01:13:24.020 --> 01:13:26.580 Was man normalerweise, was man selbst bei diesen 01:13:26.580 --> 01:13:28.420 Single-Page-Apps-Geschichten halt auf der Leitung hat, 01:13:28.480 --> 01:13:30.440 ist ja nicht nur der Payload, der 01:13:30.440 --> 01:13:32.420 übertragen wird von den 01:13:32.420 --> 01:13:34.380 APIs sozusagen, also 01:13:34.380 --> 01:13:35.440 weiß ich nicht, irgendwelches JSON, 01:13:36.780 --> 01:13:38.380 wo halt auch ganz viel immer 01:13:38.380 --> 01:13:40.520 dupliziert wird und ganz viel Boilerplate 01:13:40.520 --> 01:13:41.840 dabei ist, sondern 01:13:41.840 --> 01:13:44.280 was halt auch da immer noch mitkommt, ist halt 01:13:44.280 --> 01:13:46.180 diese ganze Protokollgeschichte und die Cookies. 01:13:46.360 --> 01:13:48.340 So 4-Kilobyte-Cookie-Kram, der 01:13:48.340 --> 01:13:49.300 da hin und her geschickt wird. 01:13:49.960 --> 01:13:52.520 und es wird jedes Mal 01:13:52.520 --> 01:13:54.260 nochmal, auch der Server 01:13:54.260 --> 01:13:55.440 muss immer nochmal, achso, 01:13:56.120 --> 01:13:57.900 hier ist deine Signatur, ach du bist der User, 01:13:58.020 --> 01:14:00.540 ach sehr gut und alles klar, ich merke mir das mal 01:14:00.540 --> 01:14:02.600 und vergesse es sofort wieder beim nächsten Request. 01:14:02.840 --> 01:14:04.440 Das ist halt eigentlich, wenn man sich anguckt, 01:14:04.520 --> 01:14:05.920 was da tatsächlich passiert auf der Leitung, 01:14:06.080 --> 01:14:07.040 das ist alles ganz schön verrückt. 01:14:07.740 --> 01:14:09.780 Und wenn man sich dem gegenüber anguckt, 01:14:09.860 --> 01:14:12.640 was Elixir da macht, da geht einfach nur die rohen Daten, 01:14:13.120 --> 01:14:14.580 die gebraucht werden, um den DOM 01:14:14.580 --> 01:14:16.640 zu ändern, gehen über die Leitung und sonst nichts. 01:14:16.820 --> 01:14:18.760 Und das ist wirklich super wenig. 01:14:18.760 --> 01:14:20.660 Das klingt ziemlich schlau. 01:14:21.040 --> 01:14:23.240 Und der Witz ist, genau das gleiche könnte man 01:14:23.240 --> 01:14:24.520 mit Django eigentlich auch machen. 01:14:25.860 --> 01:14:26.980 Du brauchst eigentlich auch nur diese tausend Zeilen. 01:14:26.980 --> 01:14:27.700 Das müsste doch mal jemand machen. 01:14:28.580 --> 01:14:29.780 Ich dachte auch schon, 01:14:30.620 --> 01:14:33.280 vielleicht sollte man sich diese tausend 01:14:33.280 --> 01:14:35.360 Zeilen JavaScript da mal genau 01:14:35.360 --> 01:14:37.000 angucken und dann halt 01:14:37.000 --> 01:14:39.240 das Ganze mit Channels und 01:14:39.240 --> 01:14:40.500 WebSockets machen, weil 01:14:40.500 --> 01:14:42.760 dass man den State mit Async 01:14:42.760 --> 01:14:43.960 super handeln kann, 01:14:44.840 --> 01:14:47.220 das kann man in Python und Django ganz genauso 01:14:47.220 --> 01:14:47.440 machen. 01:14:47.440 --> 01:14:49.180 das muss man nicht, da braucht man 01:14:49.180 --> 01:14:50.580 das Erlangen da gar nicht 01:14:50.580 --> 01:14:52.920 ja also 01:14:52.920 --> 01:14:55.360 genau, das ist halt so ein bisschen das Versprechen 01:14:55.360 --> 01:14:57.440 und das wäre natürlich schon sehr 01:14:57.440 --> 01:14:58.460 cool, wenn man sowas machen könnte 01:14:58.460 --> 01:15:00.120 ja 01:15:00.120 --> 01:15:02.800 genau 01:15:02.800 --> 01:15:05.400 wir müssen noch ein paar Schlüsselwörter 01:15:05.400 --> 01:15:06.300 sagen, bevor wir 01:15:06.300 --> 01:15:08.520 bevor wir aufhören können 01:15:08.520 --> 01:15:19.210 soll ich mal einfach so W haben kooperatives Multitasking ach ja kooperatives Multitasking Genau wir haben jetzt noch gar nicht die wirklichen Unterschiede Also genau 01:15:20.310 --> 01:15:21.650 Es gibt jetzt unterschiedliche Ansätze, 01:15:21.730 --> 01:15:23.830 wie man diese Concurrency-Geschichte hinbekommt. 01:15:25.250 --> 01:15:25.830 Ah, soll ich ein bisschen 01:15:25.830 --> 01:15:26.790 was über Geschichte erzählen? 01:15:27.510 --> 01:15:28.150 Interessiert euch das? 01:15:29.150 --> 01:15:30.390 19. Jahrhundert, oder? 01:15:30.610 --> 01:15:31.390 Also, damals. 01:15:33.390 --> 01:15:35.870 Also, wie Concurrency irgendwie nach Python gekommen ist. 01:15:36.310 --> 01:15:37.330 Ich weiß nicht, ich habe das... 01:15:37.330 --> 01:15:39.010 Ein Großteil davon habe ich aus der... 01:15:39.010 --> 01:15:40.410 Märchen, was man seinen Kindern erzählt. 01:15:40.510 --> 01:15:42.770 Wie Procurrency damals nach Python gekommen ist. 01:15:43.070 --> 01:15:45.030 Ich kann nur diese Serie von 01:15:45.030 --> 01:15:46.930 Lukas Langer über Async.io empfehlen. 01:15:47.090 --> 01:15:48.790 Da habe ich jetzt einen Teil von dem, was ich jetzt erzähle. 01:15:50.470 --> 01:15:51.090 Und zwar 01:15:51.090 --> 01:15:53.010 ist es so Mitte der 90er oder so 01:15:53.010 --> 01:15:54.830 gab es da halt so erste Anwendungen für 01:15:54.830 --> 01:15:57.030 man will vielleicht diverse Dinge 01:15:57.030 --> 01:15:58.930 parallel machen. Ach verdammt, 01:15:58.950 --> 01:15:59.890 jetzt bin ich selber in die Falle getroffen. 01:16:00.870 --> 01:16:01.570 Procurrency machen. 01:16:02.370 --> 01:16:02.770 Nebenläufig. 01:16:04.690 --> 01:16:06.930 Und da gab es das Medusa 01:16:06.930 --> 01:16:08.410 Framework für. 01:16:09.010 --> 01:16:14.430 und das wurde zum Beispiel verwendet von Google, dann um den Webcrawler zu bauen. 01:16:15.970 --> 01:16:19.570 Und so ist halt Python ja auch irgendwie bei Google reingekommen, halt über den Crawler. 01:16:21.310 --> 01:16:25.450 Und das ist auch irgendwann dann in die Standardbibliothek reingekommen als AsyncCore. 01:16:25.810 --> 01:16:29.890 Ich glaube, das Modul ist auch heute noch in der Standardbibliothek, aber ja, deprecated. 01:16:31.630 --> 01:16:37.410 Und dann gab es halt eine ganze Zeit lang irgendwie so Ansätze. 01:16:37.410 --> 01:16:41.210 dann kam irgendwie, glaube ich, zur Jahrtausendwende irgendwie so um den Dreh irgendwie Twisted dazu 01:16:41.210 --> 01:16:45.450 wurde dann auch viel verwendet, war aber immer 01:16:45.450 --> 01:16:49.170 inkompatibel zum Rest von Python 01:16:49.170 --> 01:16:53.430 so die normalen Standardbibliothek-Funktionen, die blockieren alle, die machen alle 01:16:53.430 --> 01:16:57.490 synchronen I.O. und so, das hat nie so richtig dazu gepasst, das heißt, das musste alles irgendwie anders 01:16:57.490 --> 01:16:59.850 gemacht werden, das heißt, man konnte Code, den man jetzt in Twisted 01:16:59.850 --> 01:17:05.490 wo man Twisted benutzt hatte, um das Concurrent zu machen, nicht jetzt mit irgendwas 01:17:05.490 --> 01:17:06.250 verwendet. 01:17:06.250 --> 01:17:08.510 Wenn man jetzt vorhatte, auf G-Event umzusteigen 01:17:08.510 --> 01:17:09.290 oder so ging das halt nicht. 01:17:10.930 --> 01:17:11.090 Ja, 01:17:11.370 --> 01:17:14.230 aber Twisted ist auch ein 01:17:14.230 --> 01:17:16.170 Riesending. Es gibt ganz viele Firmen, die 01:17:16.170 --> 01:17:18.130 das für irgendwelche Netzwerkgeschichten benutzt haben. 01:17:18.330 --> 01:17:19.570 Apple hat das. 01:17:19.570 --> 01:17:22.250 Super viele Sachen, die man vorher einfach nicht machen konnte. 01:17:22.690 --> 01:17:24.170 Genau, genau. Also es ist 01:17:24.170 --> 01:17:24.790 schon ein Riesending. 01:17:26.510 --> 01:17:28.290 Der Mensch, der das entwickelt hat, 01:17:28.370 --> 01:17:30.710 Levkovits, 01:17:30.930 --> 01:17:31.990 glaube ich, der hat auch 01:17:31.990 --> 01:17:34.570 den Pep zu Async.io mitgeschrieben. 01:17:35.490 --> 01:17:41.410 später, also Async.io ist dann auch sehr stark beeinflusst von Twisted. 01:17:42.710 --> 01:17:46.190 Ein anderer starker Einfluss ist Tornado. 01:17:47.770 --> 01:17:51.530 Auch einer aus dem Tornado-Projekt hat halt auch, ist einer von den drei Leuten, 01:17:51.670 --> 01:17:55.350 die halt den Async.io-Pep mitgeschrieben haben, der andere ist dann Guido. 01:17:56.570 --> 01:17:59.870 Und also Tornado und Twisted haben das beide stark beeinflusst. 01:18:00.350 --> 01:18:03.430 Tornado auch eine ganz interessante Geschichte, ist auch ein Ding, 01:18:03.430 --> 01:18:05.350 was Leute 01:18:05.350 --> 01:18:07.450 geschrieben haben, oder ich glaube 01:18:07.450 --> 01:18:09.590 ursprünglich hat das mal Brad Taylor geschrieben, Brad Taylor war 01:18:09.590 --> 01:18:11.170 bei Google, der hat irgendwie 01:18:11.170 --> 01:18:13.810 Gmail gemacht und Google Maps 01:18:13.810 --> 01:18:15.750 und dann haben ein paar von den 01:18:15.750 --> 01:18:17.370 Leuten, auch Paul Buchheit war glaube ich auch dabei 01:18:17.370 --> 01:18:19.470 die haben dann eine neue Firma gemacht, irgendwann so 01:18:19.470 --> 01:18:21.350 2007 oder so, Friendfeed, ich weiß nicht 01:18:21.350 --> 01:18:23.030 ob ihr euch daran erinnert 01:18:23.030 --> 01:18:25.790 ich habe es auch mal gehört, ich weiß nicht ob ich es mal benutzt 01:18:25.790 --> 01:18:27.250 habe, keine Ahnung, ist dann von 01:18:27.250 --> 01:18:29.310 Facebook gekauft worden 01:18:29.310 --> 01:18:31.310 2009 01:18:31.310 --> 01:18:32.470 und 01:18:32.470 --> 01:18:33.470 und 01:18:33.470 --> 01:18:35.070 ja, 01:18:35.290 --> 01:18:37.130 Brad Taylor ist dann CTO von 01:18:37.130 --> 01:18:37.810 Facebook geworden. 01:18:39.050 --> 01:18:41.190 Und ich hatte ja, das letzte Zufall, ich war auch 01:18:41.190 --> 01:18:43.030 glaube ich in einer Podcast-Version mit Lukas Langer, 01:18:43.470 --> 01:18:45.070 der war ja lange bei Facebook und 01:18:45.070 --> 01:18:47.010 erzählte dann so, dass intern bei Facebook 01:18:47.010 --> 01:18:49.170 ein großer Teil von Facebook ist halt irgendwie 01:18:49.170 --> 01:18:51.410 Python. Fand ich überraschend, 01:18:51.470 --> 01:18:53.470 wusste ich gar nicht. Und so komisch, 01:18:53.590 --> 01:18:55.110 wie kam denn da Python rein? Ja gut, vielleicht 01:18:55.110 --> 01:18:56.430 über Instagram oder so, aber 01:18:56.430 --> 01:18:58.710 tatsächlich irgendwie, ja, 01:18:58.890 --> 01:19:01.010 der Autor von Tornado ist halt irgendwie, 01:19:01.010 --> 01:19:02.790 war halt CTO von Facebook lange Zeit. 01:19:03.650 --> 01:19:04.950 Und hat da wahrscheinlich auch 01:19:04.950 --> 01:19:06.830 seine Python-Vorlieben vielleicht so ein bisschen 01:19:06.830 --> 01:19:07.550 ausgelebt. 01:19:09.730 --> 01:19:10.890 Jeder bringt seine eigene 01:19:10.890 --> 01:19:11.650 Technologie mit. 01:19:11.650 --> 01:19:12.110 Ja. 01:19:14.310 --> 01:19:14.870 Genau. 01:19:16.970 --> 01:19:17.530 Das 01:19:17.530 --> 01:19:19.610 Tornado 01:19:19.610 --> 01:19:21.430 ist auch heute noch eine ganz 01:19:21.430 --> 01:19:23.450 interessante Geschichte. Wird auch noch 01:19:23.450 --> 01:19:24.790 nach wie vor aktiv entwickelt. 01:19:25.410 --> 01:19:27.230 Ist auch bei der Jupiter-Geschichte liegt das 01:19:27.230 --> 01:19:27.870 irgendwie drunter. 01:19:30.390 --> 01:19:30.950 Ja. 01:19:31.010 --> 01:19:34.090 und genau, aber das waren halt 01:19:34.090 --> 01:19:35.970 alles Dinge, die unabhängig 01:19:35.970 --> 01:19:37.770 voneinander halt existiert haben 01:19:37.770 --> 01:19:39.930 und mit Python 2 war 01:19:39.930 --> 01:19:41.930 das sowieso alles nicht so gut kombinierbar 01:19:41.930 --> 01:19:43.390 und 01:19:43.390 --> 01:19:45.870 dann 01:19:45.870 --> 01:19:47.590 genau, ist halt 01:19:47.590 --> 01:19:49.970 2012, glaube ich, gab es dann so erste 01:19:49.970 --> 01:19:52.150 Ansätze dazu, das mal 01:19:52.150 --> 01:19:54.450 dann tatsächlich in die Standardbibliothek 01:19:54.450 --> 01:19:56.070 und in die Sprache irgendwie reinzubringen und ich glaube 01:19:56.070 --> 01:19:57.750 mit 3.4, das muss dann irgendwann so 01:19:57.750 --> 01:19:59.870 2013 irgendwann gewesen sein 01:19:59.870 --> 01:20:03.670 ist dann halt auch 01:20:03.670 --> 01:20:08.750 sozusagen das in der Sprache gelandet, beziehungsweise in der Standardbibliothek 01:20:08.750 --> 01:20:12.470 mit diesen Dekoratoren 01:20:12.470 --> 01:20:16.370 für Async-Funktionen 01:20:16.370 --> 01:20:20.410 und dann in 3.5 kam die echte Sprachunterstützung mit 01:20:20.410 --> 01:20:24.610 AsyncDev und Await dazu, also ab dann gibt es eigentlich tatsächlich 01:20:24.610 --> 01:20:26.310 richtig Unterstützung in der Syntax 01:20:26.310 --> 01:20:29.370 Ja, und es gab noch ein paar 01:20:29.370 --> 01:20:31.590 weitere Geschichten, die dann auch später dazugekommen sind 01:20:31.590 --> 01:20:33.390 Da hat sich auch noch einiges 01:20:33.390 --> 01:20:35.330 getan, also es ist heute 01:20:35.330 --> 01:20:37.290 viel angenehmer, das Ganze zu 01:20:37.290 --> 01:20:39.350 benutzen, also es ist viel angenehmer, das zu benutzen als 01:20:39.350 --> 01:20:39.590 früher 01:20:39.590 --> 01:20:43.230 und es ist eigentlich inzwischen richtig 01:20:43.230 --> 01:20:43.910 klasse, also 01:20:43.910 --> 01:20:47.350 es ist aber was, es ist eine völlig andere 01:20:47.350 --> 01:20:48.610 Geschichte 01:20:48.610 --> 01:20:51.090 als jetzt, es gibt jetzt auch andere Sachen 01:20:51.090 --> 01:20:51.850 also man kann zum Beispiel 01:20:51.850 --> 01:20:55.250 Multisredding gab es in Python auch 01:20:55.250 --> 01:20:57.210 schon immer, war in Python 2 01:20:57.210 --> 01:20:58.990 ganz, ganz schrecklich, weil 01:20:58.990 --> 01:21:01.370 Lochschreckliche? 01:21:01.890 --> 01:21:02.230 Ja, 01:21:02.890 --> 01:21:05.030 weil es tatsächlich 01:21:05.030 --> 01:21:07.130 so ein Lock-Contention-Problem gab. Also einmal 01:21:07.130 --> 01:21:09.250 ist es natürlich langsamer, als wenn es nur in einem Thread ist. 01:21:09.330 --> 01:21:11.090 Also je mehr Threads man hat, desto langsamer wird es eigentlich. 01:21:11.890 --> 01:21:13.130 Und Python 2 ganz besonders 01:21:13.130 --> 01:21:15.130 schrecklich auf mehreren Prozessoren, weil 01:21:15.130 --> 01:21:17.210 da haben die Threads sich dann tatsächlich um den 01:21:17.210 --> 01:21:18.710 Gill gekloppt und ja, 01:21:19.010 --> 01:21:20.670 das Ganze wurde noch viel schlimmer, langsamer. 01:21:21.470 --> 01:21:23.230 Aber auch da, seit Python 3.2 01:21:23.230 --> 01:21:24.990 gibt es einen neuen Jill, also 01:21:24.990 --> 01:21:27.850 In Python 2 wurde das so gemacht, 01:21:28.030 --> 01:21:29.830 beziehungsweise vor Python 3.2, 01:21:30.930 --> 01:21:31.210 dass 01:21:31.210 --> 01:21:34.270 der Interpreter 01:21:34.270 --> 01:21:35.570 alle 100 Ticks, also 01:21:35.570 --> 01:21:37.590 ein Tick ist halt irgendwie so eine 01:21:37.590 --> 01:21:39.150 ja, ich weiß nicht 01:21:39.150 --> 01:21:41.470 Das ist ein Upcode, oder? 01:21:41.470 --> 01:21:43.430 Ja, genau. 01:21:43.650 --> 01:21:45.230 Das ist sozusagen eine primitive 01:21:45.230 --> 01:21:47.250 Operation, aber das kann auch so was sein, also wenn man sagt 01:21:47.250 --> 01:21:49.010 so for i in range eine Million, 01:21:49.830 --> 01:21:50.770 dann ist das auch nur ein Tick. 01:21:51.970 --> 01:21:53.150 Das ist so ein bisschen schlecht, 01:21:53.150 --> 01:21:55.210 weil es kann halt sein, dass ein Tick sehr, sehr lange dauert. 01:21:56.970 --> 01:21:57.410 Aber 01:21:57.410 --> 01:21:58.230 das Ding hat halt fix 01:21:58.230 --> 01:22:01.110 nach 100 Ticks irgendwie geguckt, 01:22:01.250 --> 01:22:03.010 okay, hat so eine Check-Funktion aufgerufen 01:22:03.010 --> 01:22:04.290 und die hat dann einmal 01:22:04.290 --> 01:22:05.830 Signal-Handling gemacht, 01:22:05.910 --> 01:22:09.110 aber auch geguckt, okay, welcher 01:22:09.110 --> 01:22:09.990 Thread läuft denn gerade? 01:22:10.650 --> 01:22:12.830 Muss ich vielleicht einen anderen Thread 01:22:12.830 --> 01:22:14.810 in die Warteschlange 01:22:14.810 --> 01:22:16.890 der Threads, die jetzt 01:22:16.890 --> 01:22:19.230 runnable sind, fürs Betriebssystem reintun oder nicht? 01:22:19.850 --> 01:22:21.150 Das ist auch so, dass Python-Threads 01:22:21.150 --> 01:22:22.550 sind echte Betriebssystem-Threads, also 01:22:22.550 --> 01:22:25.050 was ich dann oft lese, irgendwie so was wie 01:22:25.050 --> 01:22:27.050 ja, der Python-Interpreter, der Scheduleter, irgendwas 01:22:27.050 --> 01:22:28.850 ne, macht er nicht, das betriebssystem 01:22:28.850 --> 01:22:30.330 aber der 01:22:30.330 --> 01:22:32.890 Python-Interpreter kann natürlich sagen, okay, also 01:22:32.890 --> 01:22:35.110 dieser Stretch hier wäre jetzt theoretisch runnable 01:22:35.110 --> 01:22:37.230 der dann vom Betriebssystem 01:22:37.230 --> 01:22:38.550 tatsächlich 01:22:38.550 --> 01:22:41.010 sozusagen, wo der Kontext dazwischen geht und welcher dann 01:22:41.010 --> 01:22:43.310 weiter ausgeführt wird, das macht das Betriebssystem 01:22:43.310 --> 01:22:43.750 dann 01:22:43.750 --> 01:22:46.610 Wie nennt man das, Jochen? 01:22:46.790 --> 01:22:48.630 Jetzt muss ich kurz das Schlüsselwort dazwischen sagen 01:22:48.630 --> 01:22:50.970 Präemptives Multitasking 01:22:50.970 --> 01:22:53.470 weil man zwischendurch abgebrochen werden kann 01:22:53.470 --> 01:22:55.270 präemptives Multitasking, weil 01:22:55.270 --> 01:22:57.390 man selber sozusagen, wenn man jetzt 01:22:57.390 --> 01:22:59.350 in einem Thread ist, kann man nicht bestimmen 01:22:59.350 --> 01:23:01.170 wann einem die Kontrolle 01:23:01.170 --> 01:23:02.810 entzogen wird oder wann man sie wieder bekommt 01:23:02.810 --> 01:23:04.390 und das kann jederzeit passieren 01:23:04.390 --> 01:23:05.570 auch in 01:23:05.570 --> 01:23:09.230 ich habe mich da mal mit jemandem drüber gestritten 01:23:09.230 --> 01:23:10.190 und musste dann leider 01:23:10.190 --> 01:23:13.210 mir zeigen lassen, dass ich 01:23:13.210 --> 01:23:14.870 da Unrecht hatte, das kann auch innerhalb 01:23:14.870 --> 01:23:16.690 eines Python Befehls sein, also 01:23:16.690 --> 01:23:19.230 Python Befehle selbst sind da nicht atomar, sondern 01:23:19.230 --> 01:23:21.210 und es sind eben diese Bytecodes, die 01:23:21.210 --> 01:23:22.530 darunter liegen, die atomar sind. 01:23:23.370 --> 01:23:25.330 Aber so eine Zuweisung wie 01:23:25.330 --> 01:23:27.150 i plus gleich 1 01:23:27.150 --> 01:23:28.630 ist auch nicht atomar, sondern 01:23:28.630 --> 01:23:31.270 das kann zwischendurch unterbrochen 01:23:31.270 --> 01:23:31.490 werden. 01:23:33.010 --> 01:23:35.170 Das ist da die große Gefahr daran, 01:23:35.370 --> 01:23:36.890 dass man eben innerhalb eines 01:23:36.890 --> 01:23:38.870 Befehls, den man selbst 01:23:38.870 --> 01:23:41.410 als unteilbar sieht, 01:23:41.410 --> 01:23:43.270 kann man irgendwie 01:23:43.270 --> 01:23:45.410 die Kontrolle wegnommen kriegen, es passiert 01:23:45.410 --> 01:23:47.390 irgendwas anderes, jemand anders ändert 01:23:47.390 --> 01:23:49.370 irgendeinen Wert und man selber 01:23:49.370 --> 01:23:51.610 fängt wieder an und plötzlich sind die Sachen 01:23:51.610 --> 01:23:53.610 anders, als man erwartet hätte und es passieren schreckliche Dinge. 01:23:54.830 --> 01:23:55.570 Also das ist 01:23:55.570 --> 01:23:56.610 präventives Multitasking. 01:23:56.750 --> 01:23:58.470 Präventives Multitasking, ja genau. 01:23:58.830 --> 01:24:00.890 Hat natürlich gewisse Vorteile, aber 01:24:00.890 --> 01:24:02.470 ist halt, also ja. 01:24:03.610 --> 01:24:05.110 Genau, aber erstmal um das so zu, genau. 01:24:05.170 --> 01:24:06.950 Das ist präventives und das, was man aber heute 01:24:06.950 --> 01:24:08.930 hauptsächlich macht und was halt auch eine 01:24:08.930 --> 01:24:10.310 gewisse Geschichte, 01:24:11.050 --> 01:24:12.230 also auch schon immer eine Geschichte hatte, 01:24:12.410 --> 01:24:14.870 sind halt diese sozusagen 01:24:14.870 --> 01:24:16.970 Dinge, die man innerhalb 01:24:16.970 --> 01:24:19.110 von dem Thread oder innerhalb von dem 01:24:19.110 --> 01:24:20.250 Prozess ausführt. 01:24:21.030 --> 01:24:23.030 Also wo das Betriebssystem gar nichts darüber weiß, 01:24:23.250 --> 01:24:23.830 dass man das macht. 01:24:25.590 --> 01:24:27.270 Wo man das halt selber sozusagen 01:24:27.270 --> 01:24:31.270 entscheidet, dass man jetzt die Kontrolle 01:24:31.270 --> 01:24:33.050 abgibt oder was anderes macht. 01:24:33.610 --> 01:24:35.550 Und das ist dann halt kooperatives Multitasking. 01:24:35.910 --> 01:24:36.990 Und das ist halt so das, was man 01:24:36.990 --> 01:24:39.210 kennt aus, also in Java heißen die Dinger 01:24:39.210 --> 01:24:41.250 dann Green Threads oder das ist halt auch 01:24:41.250 --> 01:24:42.850 das, was in Stacklist-Fighting passiert ist. 01:24:43.170 --> 01:24:45.330 Oder das, was G-Event gemacht hat. 01:24:45.330 --> 01:24:47.250 Eventlets oder so. 01:24:47.650 --> 01:24:48.730 Ja, genau, Eventlets. 01:24:50.450 --> 01:24:51.990 LibEV liegt da, glaube ich, 01:24:52.030 --> 01:24:53.490 zum Beispiel unter Umständen 01:24:53.490 --> 01:24:55.310 drunter oder auch LibUV, 01:24:55.770 --> 01:24:56.250 also die 01:24:56.250 --> 01:24:59.850 Eventloop von Node.js. 01:25:00.510 --> 01:25:01.730 LibEV hat 01:25:01.730 --> 01:25:03.810 glaube ich 01:25:03.810 --> 01:25:05.650 Armin Rigo geschrieben. 01:25:06.070 --> 01:25:07.210 Was ja auch faszinierend war, 01:25:07.210 --> 01:25:08.150 die gleichen Namen, 01:25:08.610 --> 01:25:11.030 da tauchten viele Namen auf, die ich schon kannte. 01:25:11.050 --> 01:25:12.130 Das sind erstaunlich wenige Leute. 01:25:13.470 --> 01:25:15.290 Ich kannte die aus anderen Teilen, 01:25:15.330 --> 01:25:18.410 und dachte so, ach, die haben auch diese ganzen Geschichten da, 01:25:18.490 --> 01:25:20.510 da haben die auch alle irgendwie mitgemacht, das wusste ich gar nicht. 01:25:21.010 --> 01:25:21.730 Also, genau, 01:25:22.030 --> 01:25:24.690 Amin Rigo habe ich nur gehört im Zusammenhang mit PyPI, 01:25:24.930 --> 01:25:25.550 aber nie mit, 01:25:26.670 --> 01:25:28.430 äh, nicht PyPI, 01:25:28.510 --> 01:25:30.590 äh, PyPi, aber nie mit 01:25:30.590 --> 01:25:32.570 irgendwie so 01:25:32.570 --> 01:25:34.590 Concurrency-Geschichten, aber, ja, 01:25:34.970 --> 01:25:36.630 der hat, glaube ich, eine Bibliothek 01:25:36.630 --> 01:25:38.650 geschrieben, GreenLed, 01:25:38.770 --> 01:25:40.370 die auf LibEV basiert 01:25:40.370 --> 01:25:42.590 und darauf basiert 01:25:42.590 --> 01:25:44.610 wieder G-Event und G-Event 01:25:44.610 --> 01:25:46.110 macht halt quasi sozusagen 01:25:46.110 --> 01:25:48.610 User-Space-Threads 01:25:49.550 --> 01:25:50.230 und 01:25:50.230 --> 01:25:51.970 macht da aber auch 01:25:51.970 --> 01:25:54.590 teilt das irgendwie so halbwegs zufällig 01:25:54.590 --> 01:25:56.470 ein, wann die laufen und wann die nicht laufen 01:25:56.470 --> 01:25:58.530 und damit das halt mit dem 01:25:58.530 --> 01:25:59.490 Rest von der 01:25:59.490 --> 01:26:02.010 synchronen und blockierenden 01:26:02.010 --> 01:26:03.650 I.O. 01:26:04.410 --> 01:26:06.150 Funktion und so im Rest von Python funktioniert, 01:26:06.270 --> 01:26:07.570 monkeypatchen sie einfach alles. 01:26:08.010 --> 01:26:09.490 Zum Beispiel das Rocketman-Rule, ganz böse. 01:26:10.390 --> 01:26:11.430 Das ist ziemlich hart. 01:26:11.430 --> 01:26:12.810 Sie weiß so, okay, 01:26:12.810 --> 01:26:42.790 und Jochen unterhalten sich über die Programmiersprache Python 01:26:42.810 --> 01:26:45.250 und kooperatives Multitasking im weitesten Sinne. 01:26:45.310 --> 01:26:47.790 Wobei, weiß ich jetzt gar nicht, bei G-Event bin ich mir jetzt gar nicht so super sicher. 01:26:48.610 --> 01:26:50.250 Klar, bei G-Event ist es auch kooperativ. 01:26:50.270 --> 01:26:51.510 Ja, im Prinzip ist es kooperativ. 01:26:51.730 --> 01:26:54.190 Im Wesentlichen jetzt ist ja AsyncIO oder so der... 01:26:54.190 --> 01:26:59.590 Genau, das ist jetzt sozusagen der heißeste Scheiß, den man jetzt da macht. 01:26:59.750 --> 01:27:02.750 Und ehrlich gesagt, ich habe ja jetzt da auch eine ganze Zeit lang Sachen an, 01:27:02.770 --> 01:27:05.210 das sieht auch deutlich besser aus als alles, was man da so vorher gemacht hat. 01:27:06.550 --> 01:27:09.270 Aber im Wesentlichen heißt es doch, jedes Mal, wenn du Yield sagst, 01:27:10.030 --> 01:27:12.170 wird dir die Kontrolle erstmal weggenommen. 01:27:12.170 --> 01:27:14.050 Yield? Ja, nicht, Await. 01:27:14.910 --> 01:27:15.890 Ah, wenn du Await sagst, okay. 01:27:16.310 --> 01:27:18.150 Ja, früher war es Yield. Ja, Yield 01:27:18.150 --> 01:27:19.810 from, genau, das war noch die 01:27:19.810 --> 01:27:22.230 Syntax davor. Aber das ist 01:27:22.230 --> 01:27:23.910 so ein bisschen der zentrale Mechanismus, oder? 01:27:23.970 --> 01:27:26.050 Dass du sagst, okay, ich mache jetzt was 01:27:26.050 --> 01:27:28.030 und sobald ich Await sage, 01:27:28.150 --> 01:27:30.130 kann jemand anderes was machen. Genau, 01:27:30.230 --> 01:27:32.370 genau. Und das hat eine interessante 01:27:32.370 --> 01:27:33.490 Auswirkung auf die 01:27:33.490 --> 01:27:35.970 Art oder auf die Schwierigkeit, also wie schwer das 01:27:35.970 --> 01:27:38.370 zu programmieren ist, weil wenn du primitives Multitasking 01:27:38.370 --> 01:27:39.910 hast und an jeder Stelle kann im Grunde 01:27:39.910 --> 01:27:41.990 die Kontrolle weggehen, dann 01:27:41.990 --> 01:27:44.130 alle Dinge, die irgendwie atomar 01:27:44.130 --> 01:27:45.950 sein müssen, musst du halt dann mit Logs 01:27:45.950 --> 01:27:47.890 absichern. Ja, es gibt dann so kritische 01:27:47.890 --> 01:27:50.030 Sektionen, die musst du sehr ab. Genau, und das Problem 01:27:50.030 --> 01:27:52.030 ist halt, du darfst halt nichts vergessen und das kann 01:27:52.030 --> 01:27:53.490 halt überall passieren und du musst halt 01:27:53.490 --> 01:27:55.670 Ja, und selbst wenn du nichts 01:27:55.670 --> 01:27:57.970 vergessen hast, kommst du immer noch in so 01:27:57.970 --> 01:27:59.550 Deadlock-Situationen rein oder in so 01:27:59.550 --> 01:28:01.950 Starving-Situationen. Selbst wenn du 01:28:01.950 --> 01:28:03.850 alles richtig machst, kannst du immer noch 01:28:03.850 --> 01:28:05.910 Das ist eine Starving-Situation, es 01:28:05.910 --> 01:28:08.170 wartet irgendjemand darauf, dass irgendwie wer losrennen 01:28:08.170 --> 01:28:09.730 kann, aber da kommt einfach nichts. 01:28:10.350 --> 01:28:11.950 Ne, das ist ein 01:28:11.950 --> 01:28:16.730 Deadlock heißt, zwei oder mehr Dinge warten auf sich gegenseitig. 01:28:17.010 --> 01:28:17.710 Und ein Starving? 01:28:17.710 --> 01:28:18.890 Dann kann keiner loslaufen. 01:28:19.270 --> 01:28:23.210 Und Starving heißt, jemand, der etwas tun könnte, kommt nie dran. 01:28:24.290 --> 01:28:26.110 Weil immer jemand anders schon was tut. 01:28:26.810 --> 01:28:31.270 Das heißt, dass der nicht selber gelockt ist, sondern dass er einfach nicht... 01:28:31.270 --> 01:28:32.730 Schnapp, wie man vor Aspekt ist. 01:28:32.730 --> 01:28:35.310 ...zu niedrig ist oder weil er immer sagt, macht ihr erstmal. 01:28:35.770 --> 01:28:39.990 Dass der sozusagen für immer wartet, obwohl er etwas tun könnte, obwohl er nicht irgendwo... 01:28:39.990 --> 01:28:45.330 Ach, wäre ja so schön, aber die können das ja alle schon so gut. Ich bleib da mal hier stehen. 01:28:46.210 --> 01:28:52.930 Genau, und sowas passiert dann halt. Sowas passiert halt in so präemptiven Sachen, weil du keine Kontrolle drüber hast, wer läuft. 01:28:53.050 --> 01:28:57.350 Beziehungsweise die Kontrolle, die jemand hat, ist eben das Betriebssystem. 01:28:57.610 --> 01:29:06.490 Und das muss dafür sorgen, dass so ein Deadlock entweder aufgelöst wird und dass solche Starving-Situationen nicht passieren. 01:29:06.490 --> 01:29:36.490 Ja, also es gibt da halt diverse Techniken, mit denen man das halt auch, also die Probleme minimieren kann, es gibt dann so ein paar Patterns und wahrscheinlich würde ich auch sagen, also für die meisten Fälle nimmt man halt so ein Pattern und dann kann eigentlich nicht mehr so wahnsinnig viel passieren, man nimmt halt eine Queue oder halt viele Queues und macht da halt Logs rein und da gibt es auch schon fertige Dinge, wo man die Logs nicht selber ersetzen muss und dann Ja, aber auch da ist es erstaunlich leicht in so Situationen reinzukommen, wo du dich deadlogst 01:29:36.490 --> 01:29:38.430 Das ist erstaunlich leicht 01:29:38.430 --> 01:29:40.770 Jaja, ich würde auch sagen, also es ist halt 01:29:40.770 --> 01:29:41.830 sehr scharfkantige Geschichte 01:29:41.830 --> 01:29:44.590 Ja, man muss da echt aufpassen 01:29:44.590 --> 01:29:46.450 und genau, achso 01:29:46.450 --> 01:29:47.630 richtig genau 01:29:47.630 --> 01:29:50.410 das habe ich eben nicht mehr erzählt, genau 01:29:50.410 --> 01:29:52.770 nach 100 Ticks immer diese Geschichten, aber das hat halt 01:29:52.770 --> 01:29:54.610 diverse Nachteile, weil Tick kann halt sehr lange 01:29:54.610 --> 01:29:56.730 sein und dann gab es halt auch diese 01:29:56.730 --> 01:29:58.150 Battles über 01:29:58.150 --> 01:29:59.670 wer kriegt den Gill 01:29:59.670 --> 01:30:02.790 quasi auf unterschiedlichen Prozessoren und da so war 01:30:02.790 --> 01:30:04.290 halt, das war, wie 01:30:04.290 --> 01:30:06.250 David Beasley gibt es halt 01:30:06.250 --> 01:30:08.130 Understanding the Jill, zum Beispiel 01:30:08.130 --> 01:30:10.090 den Vortrag von 2014 01:30:10.090 --> 01:30:12.350 oder Verhalten auf 01:30:12.350 --> 01:30:14.350 mehreren... Urgeschichte. 01:30:15.110 --> 01:30:16.230 Also er sagte irgendwie auf 01:30:16.230 --> 01:30:18.170 einer, also mit einem Stride, also alles gut, mit mehreren 01:30:18.170 --> 01:30:19.710 Strides, na, nicht so toll, 01:30:20.110 --> 01:30:21.750 auf mehreren Prozessoren, Diabolical. 01:30:22.270 --> 01:30:24.190 Das war wirklich irgendwie nicht schön. 01:30:25.230 --> 01:30:25.670 Und 01:30:25.670 --> 01:30:28.190 ja, das ist aber mit Python 3.2 01:30:28.190 --> 01:30:30.170 besser geworden, da gab es einen neuen Jill 01:30:30.170 --> 01:30:32.170 und der macht das nicht mehr nach 01:30:32.170 --> 01:30:34.150 Ticks, sondern es gibt jetzt einen Zeitintervall 01:30:34.150 --> 01:30:35.750 was halt eben 01:30:35.750 --> 01:30:37.750 das führt das halt nicht 01:30:37.750 --> 01:30:40.330 quasi Dinge für immer warten 01:30:40.330 --> 01:30:41.430 müssen, weil halt 01:30:41.430 --> 01:30:43.690 ein Tick halt super lang war 01:30:43.690 --> 01:30:45.910 und zwar jetzt ist es halt so 01:30:45.910 --> 01:30:48.650 jetzt ist es nicht alle 100 Texte, jetzt ist es alle 5 Millisekunden 01:30:48.650 --> 01:30:50.190 man kann das aber auch einstellen, wie man möchte 01:30:50.190 --> 01:30:51.210 also das konnte man vorher auch schon 01:30:51.210 --> 01:30:54.290 so alle 5 Millisekunden guckt halt der Interpreter 01:30:54.290 --> 01:30:54.630 nach 01:30:54.630 --> 01:30:59.150 muss mal jemand anders dran 01:30:59.150 --> 01:31:02.410 kann mal jemand anders dran 01:31:02.410 --> 01:31:03.630 oder welches Schatz könnte laufen 01:31:03.630 --> 01:31:05.730 wobei letztlich wer das entscheidet ist das Betriebssystem 01:31:05.730 --> 01:31:07.870 ja und das 01:31:07.870 --> 01:31:10.270 funktioniert jetzt deutlich besser, das funktioniert auf mehreren CPUs 01:31:10.270 --> 01:31:11.950 auch gut, ja es ist nicht so, dass jetzt da 01:31:11.950 --> 01:31:13.990 auf mehreren CPUs gleichzeitig was gemacht würde, aber 01:31:13.990 --> 01:31:16.130 es ist nicht mehr so, dass die Performance viel schlechter ist 01:31:16.130 --> 01:31:17.150 als wenn man nur eine CPU hätte 01:31:17.150 --> 01:31:19.650 was ja schon mal auch nicht so schlecht ist 01:31:19.650 --> 01:31:21.470 genau, daher 01:31:21.470 --> 01:31:23.550 also Threading kann man auch verwenden 01:31:23.550 --> 01:31:25.570 also es ist auch nicht so, also es funktioniert mittlerweile 01:31:25.570 --> 01:31:27.830 ganz gut auf Linux, also auch 10.000 01:31:27.830 --> 01:31:29.970 Threads aufmachen, gar kein Problem 01:31:29.970 --> 01:31:30.530 funktioniert 01:31:30.530 --> 01:31:32.450 Genau, neulich hast du ausprobiert, Jochen 01:31:32.450 --> 01:31:34.070 bei 9500 war Schluss bei mir 01:31:34.070 --> 01:31:36.530 Aber 01:31:36.530 --> 01:31:38.410 also das geht alles und das ist auch 01:31:38.410 --> 01:31:40.470 nicht, das findet man auch oft, ich war überrascht 01:31:40.470 --> 01:31:41.530 ich habe da so ein bisschen recherchiert 01:31:41.530 --> 01:31:44.570 wie oft da so Dinge auch in Büchern 01:31:44.570 --> 01:31:46.610 drinstehen, ich habe zum Beispiel Fluent Python mir angeguckt 01:31:46.610 --> 01:31:48.330 oder auch Effective Python von 01:31:48.330 --> 01:31:50.350 Brad Slatkin, also eigentlich beides sehr renommierte 01:31:50.350 --> 01:31:52.330 Quellen, weil ich dachte so, okay, so die 01:31:52.330 --> 01:31:54.250 Standardwerke, da muss doch drinstehen wie es geht und die sagen 01:31:54.250 --> 01:31:56.290 beide irgendwie, ah, Threads ganz schlecht 01:31:56.290 --> 01:31:57.990 du kannst irgendwie keine 01:31:57.990 --> 01:31:59.930 nicht so viele Threads aufmachen, weil 01:31:59.930 --> 01:32:02.010 der Stackspace 01:32:02.010 --> 01:32:04.450 Betriebssystem riesig, brauchst halt 01:32:04.450 --> 01:32:06.550 8 MB, zum Beispiel sagt Effective 01:32:06.550 --> 01:32:08.450 Python, weil Fluid Python sind halt auch 01:32:08.450 --> 01:32:10.310 immer in Größenordnung von, jeder Thread braucht so 01:32:10.310 --> 01:32:12.730 Größenordnung MB, aber das ist halt nur Virtual Memory 01:32:12.730 --> 01:32:13.590 das ist gar nicht 01:32:13.590 --> 01:32:15.890 Resident Memory, das heißt 01:32:15.890 --> 01:32:17.270 das stimmt so nicht 01:32:17.270 --> 01:32:20.050 das ist viel weniger und das 01:32:20.050 --> 01:32:22.290 Context-Switchen, also es gibt da auch so einen schönen Artikel, wo jemand das 01:32:22.290 --> 01:32:23.610 alles mal gemessen hat und das ist 01:32:23.610 --> 01:32:25.970 eigentlich sollte das alles kein Problem sein 01:32:25.970 --> 01:32:28.310 und vielleicht war 01:32:28.310 --> 01:32:58.290 und Jochen unterhalten sich über die Programmiersprache Python 01:32:58.310 --> 01:33:12.850 Das heißt, das passiert, selbst wenn man ein kreatives Multitasking hat, passiert das automatisch. Also muss man sich auch nicht selber darum kümmern, sondern da gibt der Thread, der halt irgendeinen blockierenden Netzwerkaufruf gemacht hat oder I.O. Aufruf, da ist der Jill sofort weg. 01:33:12.850 --> 01:33:14.190 und 01:33:14.190 --> 01:33:15.230 ja, 01:33:17.070 --> 01:33:18.830 also ich würde sagen, mit Threads kann man 01:33:18.830 --> 01:33:20.970 eigentlich auch alle Sachen so, also wenn es 01:33:20.970 --> 01:33:22.890 darum geht, I.O. zu multiplexen, das kann man mit Threads 01:33:22.890 --> 01:33:24.830 auch wunderbar machen. Es ist 01:33:24.830 --> 01:33:26.990 schwerer zu programmieren, es ist halt ätzend, 01:33:26.990 --> 01:33:29.010 dass man nicht weiß, wann man die Kontrolle 01:33:29.010 --> 01:33:30.190 weggenommen wird und so. 01:33:31.510 --> 01:33:32.550 Es ist im Debugging 01:33:32.550 --> 01:33:34.750 ziemlich übel, 01:33:35.010 --> 01:33:37.110 aber... Probleme, die wir vorhin 01:33:37.110 --> 01:33:39.230 erzählt haben, da kommen dann halt irgendwelche Fehlermeldungen 01:33:39.230 --> 01:33:40.930 von irgendwo her. Irgendein 01:33:40.930 --> 01:33:42.730 Callback hat Markus gesagt, hallo, 01:33:42.850 --> 01:33:44.630 Ich sterbe. Dann steht man halt da. 01:33:45.330 --> 01:33:46.890 Aber es geht auch. Und ich würde jetzt 01:33:46.890 --> 01:33:48.930 nicht sagen, das kann man gar nicht machen, sondern 01:33:48.930 --> 01:33:50.750 ja, es geht auch. 01:33:51.970 --> 01:33:52.810 Aber tatsächlich 01:33:52.810 --> 01:33:54.990 Async.io würde ich auch sagen mittlerweile deutlich 01:33:54.990 --> 01:33:55.610 besser, weil 01:33:55.610 --> 01:33:57.690 das ist jetzt kooperativ. 01:33:57.890 --> 01:34:00.970 Es dreht sozusagen die Geschichte um. 01:34:01.390 --> 01:34:02.210 Bei Threads ist es so, 01:34:03.030 --> 01:34:04.910 man kann überall die Kontrolle weggenommen 01:34:04.910 --> 01:34:06.950 kriegen und Dinge sind bedroht, solange man 01:34:06.950 --> 01:34:08.590 nicht gesagt hat, okay, ich locke das jetzt hier. 01:34:08.830 --> 01:34:10.990 Ich benutze irgendeine Kernel-Datenstruktur 01:34:10.990 --> 01:34:12.790 um zu sagen, da bitte nicht 01:34:12.790 --> 01:34:16.410 so, dann ist das geschützt, aber alles andere ist halt irgendwie 01:34:16.410 --> 01:34:19.490 wilde, wilder Westen, Drachen kommen 01:34:19.490 --> 01:34:22.670 vorbei, verbrennen einen die Hütte, also ist halt, ja, weiß man nicht 01:34:22.670 --> 01:34:25.630 und bei Async.io ist es quasi umgekehrt, da gibt's 01:34:25.630 --> 01:34:28.530 halt, also die Stellen, an denen böse Dinge passieren 01:34:28.530 --> 01:34:31.650 können, die sieht man, die sind markiert, da steht await vor 01:34:31.650 --> 01:34:34.690 und alle anderen Sachen, der ganze andere 01:34:34.690 --> 01:34:37.690 Code, das ist einfach ganz normaler Code, der so durchläuft 01:34:37.690 --> 01:34:40.510 wo man sich sicher sein kann, dass einem die Kontrolle da nicht weggenommen 01:34:40.510 --> 01:34:42.150 wird und da kann man auch 01:34:42.150 --> 01:34:44.390 Operationen machen und wenn da nur, 01:34:44.530 --> 01:34:46.690 wenn da kein Await kommt, dann ist das alles atomar, weil 01:34:46.690 --> 01:34:48.530 kann sonst ja gar nichts passieren. 01:34:49.770 --> 01:34:50.550 Und das ist natürlich schön, 01:34:50.650 --> 01:34:51.170 weil die 01:34:51.170 --> 01:34:54.330 Anzahl möglicher Fehlerquellen wird halt 01:34:54.330 --> 01:34:56.450 deutlich geringer, aber 01:34:56.450 --> 01:34:58.510 man bezahlt natürlich in gewisser Weise einen Preis dafür 01:34:58.510 --> 01:35:00.510 und der ist halt, naja, also man muss 01:35:00.510 --> 01:35:01.970 sich halt auch selber darum kümmern, dass das halt, 01:35:02.750 --> 01:35:04.330 dass man die Kontrolle 01:35:04.330 --> 01:35:06.470 abgibt, wenn es geht, weil man alle anderen 01:35:06.470 --> 01:35:08.510 blockiert, wenn man das nicht tut. Also wenn man jetzt irgendwas... 01:35:09.030 --> 01:35:10.470 Man muss einfach kooperativ sein. 01:35:10.510 --> 01:35:12.650 muss kooperativ sein. Wenn man irgendwas macht, was lange 01:35:12.650 --> 01:35:14.530 dauert, dann gehen halt 01:35:14.530 --> 01:35:16.930 alle anderen kaputt, was halt auch unter Umständen 01:35:16.930 --> 01:35:18.450 natürlich sehr böse Konsequenzen haben kann. 01:35:20.090 --> 01:35:20.210 Ja. 01:35:20.490 --> 01:35:22.450 Aber da sieht man dann wenigstens. Also ich meine, wenn 01:35:22.450 --> 01:35:24.610 du da dann den Interpreter unterbrichst, weißt du, 01:35:24.950 --> 01:35:25.790 siehst du, wo du bist. 01:35:26.330 --> 01:35:28.330 Wer schuld ist. Genau. Es ist auch so, dass man 01:35:28.330 --> 01:35:30.530 kann, ich glaube, 01:35:30.570 --> 01:35:32.270 Python-X, wenn man Debug 01:35:32.270 --> 01:35:34.030 anschaltet und 01:35:34.030 --> 01:35:36.350 TraceMalloc anschaltet, das sollte man immer 01:35:36.350 --> 01:35:38.030 machen, wenn man irgendwie so Async-IO-Sachen 01:35:38.030 --> 01:35:40.350 zumindest auf der Entwicklungsseite macht, dann 01:35:40.350 --> 01:35:42.510 ist, sollte man das mal anschalten. 01:35:43.490 --> 01:35:44.570 Produktion natürlich unter Umständen 01:35:44.570 --> 01:35:45.950 nicht, kostet auch Ressourcen, aber 01:35:45.950 --> 01:35:48.330 dann sagt einem der Interpreter zum Beispiel 01:35:48.330 --> 01:35:50.470 sowas wie, also hier hast du 01:35:50.470 --> 01:35:52.370 irgendwie ein Task oder was, diese Funktion 01:35:52.370 --> 01:35:54.190 hockt die CPU und zwar ganz übel, 01:35:54.530 --> 01:35:56.390 weil er das intern halt aufruft mit 01:35:56.390 --> 01:35:58.670 einem Timeout und das halt mitkriegt 01:35:58.670 --> 01:35:59.730 und dann die Exception fängt, 01:36:00.430 --> 01:36:01.770 wenn das halt zu lange dauert. 01:36:01.850 --> 01:36:04.470 Also diese Funktion da, die macht irgendwas Böses. 01:36:04.930 --> 01:36:06.610 Das sieht man dann tatsächlich in der Ausgabe 01:36:06.610 --> 01:36:08.430 oder sagt einem auch, wenn man Sachen 01:36:08.430 --> 01:36:09.390 nicht awaited hat und so. 01:36:10.010 --> 01:36:12.210 Type Annotation ist auch total sinnvoll, 01:36:12.330 --> 01:36:13.890 vielleicht bei so hakeligen Geschichten. 01:36:14.350 --> 01:36:16.210 Da kann einem der Interpreter auch noch eine Menge 01:36:16.210 --> 01:36:17.530 sagen, was da halt dann schief geht. 01:36:18.650 --> 01:36:20.130 Weil er halt weiß, dass da jetzt eigentlich 01:36:20.130 --> 01:36:22.230 eine Coroutine zurückkommen sollte und so. Und wenn das 01:36:22.230 --> 01:36:24.310 halt nicht passiert und dann, ja. 01:36:24.890 --> 01:36:26.370 Also da geht 01:36:26.370 --> 01:36:27.190 einiges. 01:36:28.370 --> 01:36:30.090 Und es ist halt, wie gesagt, also 01:36:30.090 --> 01:36:32.230 die bösen Stellen sind die, wo await davorsteht 01:36:32.230 --> 01:36:34.090 und alles andere ist halt sozusagen ganz 01:36:34.090 --> 01:36:35.410 normaler Python-Code eigentlich. 01:36:36.050 --> 01:36:36.110 Ja. 01:36:36.110 --> 01:36:38.930 und das ist halt schon schön 01:36:38.930 --> 01:36:40.970 und von den Ressourcengeschichten 01:36:40.970 --> 01:36:42.970 würde ich jetzt zwar sagen, nachdem 01:36:42.970 --> 01:36:45.030 ich mich so ein bisschen damit beschäftigt habe, es ist nicht so 01:36:45.030 --> 01:36:47.090 also es ist, ich weiß 01:36:47.090 --> 01:36:48.410 es geht hier hinten ins Fetz auch 01:36:48.410 --> 01:36:50.990 aber natürlich ist es auch so, dass die sind schon 01:36:50.990 --> 01:36:52.750 Ressourcen aufwendiger, also 01:36:52.750 --> 01:36:55.230 das habe ich jetzt nicht nachvollzogen 01:36:55.230 --> 01:36:57.050 aber also Coroutine ist halt eigentlich 01:36:57.050 --> 01:36:58.590 nur ein Funktionsaufruf und 01:36:58.590 --> 01:37:01.090 braucht halt einen Kilobyte Hauptspeicher oder so 01:37:01.090 --> 01:37:03.130 und davon halt ganz ganz viel zu haben ist im Grunde 01:37:03.130 --> 01:37:04.070 überhaupt kein Problem, du kannst 01:37:04.070 --> 01:37:07.270 Zehn, Hunderttausende davon haben, kein Ding. 01:37:08.510 --> 01:37:09.210 Du musst halt bloß 01:37:09.210 --> 01:37:10.670 schnell genug bleiben, dass du halt tatsächlich, 01:37:11.170 --> 01:37:13.150 dass diese Hunderttausende auch irgendwann alle mal wieder drankommen, 01:37:13.290 --> 01:37:14.830 aber ansonsten geht das. 01:37:15.330 --> 01:37:17.190 Und ja, da gibt es ja dann auch 01:37:17.190 --> 01:37:19.190 sehr schnelle Event-Clubs drunter, also man kann 01:37:19.190 --> 01:37:21.350 halt auch, es gibt die Referenz-Implementation, 01:37:22.050 --> 01:37:23.010 der Event-Club in 01:37:23.010 --> 01:37:25.310 Python, die ist nicht schnell, 01:37:25.470 --> 01:37:26.970 aber die ist halt dafür da, damit man weiß, 01:37:26.970 --> 01:37:27.730 wie es funktioniert. 01:37:28.390 --> 01:37:30.810 Wenn man jetzt eine andere Implementation schreibt, die auch 01:37:30.810 --> 01:37:32.670 dagegen testen kann und zu gucken, verhält die sich jetzt genauso, 01:37:32.850 --> 01:37:33.730 wie sie sollte und so. 01:37:34.070 --> 01:37:37.650 für Produktionen kann man dann halt sowas nehmen wie 01:37:37.650 --> 01:37:39.790 diese UV-Loop, 01:37:40.450 --> 01:37:41.070 also Leap UV 01:37:41.070 --> 01:37:43.690 und das ist die Node.js Event-Loop und die ist halt 01:37:43.690 --> 01:37:44.290 echt sackschnell. 01:37:46.250 --> 01:37:47.610 Damit möchte man halt unter Python 01:37:47.610 --> 01:37:49.810 quasi da auch dann die gleiche Geschwindigkeit 01:37:49.810 --> 01:37:50.050 hin. 01:37:52.750 --> 01:37:53.670 Haben wir erklärt, was 01:37:53.670 --> 01:37:54.370 eine Event-Loop ist? 01:37:55.390 --> 01:37:57.730 Nein. Ich hätte jetzt mal einen Vorschlag. 01:37:57.950 --> 01:37:59.610 Ich würde jetzt auch so langsam mal die Kontrolle 01:37:59.610 --> 01:38:00.010 abgeben. 01:38:00.010 --> 01:38:00.490 Ja, ja. 01:38:01.210 --> 01:38:03.950 Einmal Awave machen. 01:38:04.070 --> 01:38:05.270 Yield. 01:38:07.090 --> 01:38:08.290 Ich würde einmal Yield sagen 01:38:08.290 --> 01:38:09.450 und dann direkt Sleep aufrufen. 01:38:10.010 --> 01:38:11.750 Das ist doch ein sehr schönes Stichwort, oder? 01:38:12.270 --> 01:38:14.210 Ja. Aber es hört sich für mich 01:38:14.210 --> 01:38:15.950 an, als ob wir noch mindestens zwei, drei 01:38:15.950 --> 01:38:18.110 Episoden daraus machen müssen. Vielleicht machen wir einfach 01:38:18.110 --> 01:38:19.950 noch eine. Alle Worte 01:38:19.950 --> 01:38:22.070 gesagt haben, die gesagt werden müssen. Also mir fallen noch viele 01:38:22.070 --> 01:38:24.030 Worte ein. Dir fallen sicherlich auch noch ganz 01:38:24.030 --> 01:38:24.570 viele Worte ein. 01:38:25.890 --> 01:38:28.050 Es ist auch, wenn ich 01:38:28.050 --> 01:38:29.850 mich so an diese Vorlesungen erinnere, 01:38:29.990 --> 01:38:31.270 die wir da gemacht haben, 01:38:31.270 --> 01:38:33.010 und es hat eine gewisse 01:38:33.010 --> 01:38:34.130 intellektuelle 01:38:34.130 --> 01:38:36.750 Schönheit, wenn man diese ganzen 01:38:36.750 --> 01:38:38.490 Locking-Algorithmen dann hat, 01:38:38.570 --> 01:38:41.110 wenn man die Dining-Philosophers einmal besiegt hat 01:38:41.110 --> 01:38:42.130 oder wenn man einmal die 01:38:42.130 --> 01:38:44.710 Lockless-Data-Structures alle 01:38:44.710 --> 01:38:46.990 erfunden hat. Das hat auch was Schönes, 01:38:47.130 --> 01:38:47.310 aber 01:38:47.310 --> 01:38:50.930 es ist nicht was, was man 01:38:50.930 --> 01:38:52.930 jeden Tag in seiner Arbeit machen möchte, 01:38:53.030 --> 01:38:53.350 glaube ich. 01:38:53.470 --> 01:38:55.330 Es ist wirklich schwer. 01:38:55.330 --> 01:38:57.230 Es ist auch eine massive Fehlerquelle. 01:38:57.790 --> 01:38:59.730 Ich finde es auch 01:38:59.730 --> 01:39:00.030 wirklich 01:39:00.030 --> 01:39:24.030 und 01:39:30.030 --> 01:39:31.150 und ich sage, passiert mir nichts. 01:39:31.350 --> 01:39:33.630 Und das nimmt ganz, ganz, ganz viele 01:39:33.630 --> 01:39:35.550 von diesen Ecken und Kanten da raus, 01:39:36.010 --> 01:39:37.890 die einem sonst eben ganz schlimm 01:39:37.890 --> 01:39:39.290 da reinfahren, die einem sonst die kritischen 01:39:39.290 --> 01:39:40.870 Sektionen kaputt machen. 01:39:42.530 --> 01:39:43.130 Und das 01:39:43.130 --> 01:39:45.750 ist eine sehr gute Entwicklung, ich begrüße das sehr. 01:39:45.950 --> 01:39:47.510 Und das war ein sehr schönes Schlusswort, 01:39:47.710 --> 01:39:48.110 lieber Johannes. 01:39:49.690 --> 01:39:50.590 Alles klar, dann... 01:39:50.590 --> 01:39:51.550 Ob ich es geplant hätte. 01:39:53.370 --> 01:39:55.070 Ja, würde ich sagen, machen wir doch einfach... 01:39:55.070 --> 01:39:57.110 Ja, an dieser Stelle, bleibt uns gewogen, 01:39:57.110 --> 01:39:59.090 wenn immer ihr uns hört, 01:39:59.090 --> 01:40:00.350 lieber gerne immer weiter. 01:40:00.970 --> 01:40:03.110 Abends, morgens, mittags, nachts, an welchem 01:40:03.110 --> 01:40:04.690 Erdballteil ihr euch gerade befindet. 01:40:05.730 --> 01:40:07.430 Oder irgendwo out of space, 01:40:07.510 --> 01:40:08.350 man weiß es immer nicht genau. 01:40:10.950 --> 01:40:11.050 Ja, 01:40:11.430 --> 01:40:12.790 schön, dass ihr wieder eingestaltet habt. 01:40:13.130 --> 01:40:14.310 Alle Kritik, Feedback und so weiter, 01:40:14.370 --> 01:40:17.310 bis zum nächsten Mal. Tschüss. 01:40:17.350 --> 01:40:18.510 Bis dann. Tschüss.