WEBVTT

00:00:00.940 --> 00:00:03.680
Ja, hallo liebe Hörerinnen und Hörer, willkommen im Python-Podcast.

00:00:04.020 --> 00:00:07.340
Heute ist die 23. Episode, also für uns wieder eine ganz besondere Zahl.

00:00:08.140 --> 00:00:12.280
Was machen wir heute? Heute machen wir wieder Async und Multiswelling und sowas.

00:00:12.720 --> 00:00:16.120
Und zwar Django Async kommt bald raus und darüber haben wir eine eigene Folge aufgenommen.

00:00:16.540 --> 00:00:19.120
Und zwar in dem schönen Wintergarten von Jochen. Ich bin der Dominik.

00:00:19.520 --> 00:00:22.960
Und diesmal haben wir natürlich wieder einen Gast. Den kennt ihr vielleicht schon.

00:00:24.060 --> 00:00:24.800
Hallo Johannes.

00:00:25.820 --> 00:00:27.040
Hallo Dominik. Hallo Jochen.

00:00:27.040 --> 00:00:27.780
Und hallo Jochen.

00:00:27.780 --> 00:00:29.620
Hallo, genau, auch wieder dabei.

00:00:30.240 --> 00:00:32.320
Ja, falls euch irgendwas gefällt oder nicht gefällt,

00:00:32.420 --> 00:00:34.540
dann schreibt uns doch wie immer gerne eine E-Mail an

00:00:34.540 --> 00:00:35.700
hallo-at-pison-podcast.de

00:00:35.700 --> 00:00:38.520
Und wir möchten uns auch gerne noch für ein paar Abonnenten bedanken.

00:00:38.620 --> 00:00:40.040
Und zwar haben wir allein auf Spotify

00:00:40.040 --> 00:00:42.100
mittlerweile über 1111 Abonnenten.

00:00:42.380 --> 00:00:44.080
Herzlichen Dank dafür und wuhuu!

00:00:44.680 --> 00:00:46.140
Sehr cool, wir freuen uns, wir finden das toll.

00:00:46.180 --> 00:00:46.560
Naja.

00:00:48.640 --> 00:00:50.080
Reicht es noch nicht, du willst die Welt verschaffen.

00:00:50.880 --> 00:00:52.760
Du guckst zu viele YouTube-Channels,

00:00:52.980 --> 00:00:53.920
oder? Ich weiß nicht genau.

00:00:55.040 --> 00:00:56.360
Ist das da so üblich?

00:00:56.560 --> 00:00:58.140
Ich weiß nicht, ob das beim Podcast auch so üblich ist.

00:00:58.540 --> 00:01:00.020
Ach, was denn? Ich habe mich einfach gefreut.

00:01:00.260 --> 00:01:02.700
Ja, nee, ist schon toll, aber keine Ahnung.

00:01:03.140 --> 00:01:05.540
Ja, und wo wir gerade schon bei so anderen Sachen sind.

00:01:05.780 --> 00:01:07.200
Also ihr habt ja vielleicht den Thomas gehört,

00:01:07.280 --> 00:01:08.880
der mit uns eine schöne Folge gemacht hat.

00:01:08.880 --> 00:01:10.980
Und der hat jetzt seinen Podcast umbenannt.

00:01:11.100 --> 00:01:12.400
Also wir hatten ihn das letzte Mal zu wenig erwähnt.

00:01:12.480 --> 00:01:13.820
Deswegen müssen wir es auch einmal extra erwähnen.

00:01:13.940 --> 00:01:16.760
Der ist ein ziemlich cooler Podcast, den er da hat.

00:01:16.920 --> 00:01:17.540
Wie heißt der jetzt, Jochen?

00:01:18.640 --> 00:01:20.380
Dads and Stats.

00:01:20.780 --> 00:01:22.620
Und er hat Kevin Sisson dabei in einem letzten Talk

00:01:22.620 --> 00:01:24.040
und redet über Pi MC3.

00:01:24.500 --> 00:01:26.380
Ich glaube, ist sehr hörenswert, die Co-Founder von Pi MC3.

00:01:26.380 --> 00:01:28.020
Ja, ich hab's gestern schon gehört, fand's sehr gut.

00:01:28.400 --> 00:01:28.900
Also, ja.

00:01:30.080 --> 00:01:32.740
Ja, vielen Dank, Thomas, für die nächste tolle Episode.

00:01:33.120 --> 00:01:34.780
Ja, und hätte ich jetzt

00:01:34.780 --> 00:01:36.520
gar nicht gedacht, ich meine, dass Instagram Python macht,

00:01:36.600 --> 00:01:38.740
aber dass sich halt deren Gründer und Ex-CEO

00:01:38.740 --> 00:01:39.560
irgendwie so viel mit

00:01:39.560 --> 00:01:42.700
Statistik und Machine Learning-Kram so beschäftigt

00:01:42.700 --> 00:01:44.540
ist und Data Science. Oder, naja, gut,

00:01:44.560 --> 00:01:46.080
das hat er ja vorher nicht so gemacht, aber das macht er jetzt halt,

00:01:46.460 --> 00:01:47.800
das fand ich schon sehr interessant und

00:01:47.800 --> 00:01:50.660
ja, war auf jeden Fall eine interessante Geschichte.

00:01:51.040 --> 00:01:52.260
Ja, hört doch da mal rein, wenn ihr möchtet.

00:01:52.820 --> 00:01:54.620
Ja, wir machen heute wieder

00:01:54.620 --> 00:01:56.840
Django, vor allen Dingen halt, weil Django 3.1

00:01:56.840 --> 00:01:58.300
jetzt im August erscheint und

00:01:58.300 --> 00:02:00.300
tatsächlich jetzt mehr Async-Features

00:02:00.300 --> 00:02:02.460
unterstützt als in der 3.0-Version, die

00:02:02.460 --> 00:02:04.560
seit Dezember draußen ist. Und wir

00:02:04.560 --> 00:02:06.400
möchten ein bisschen mit euch darüber reden oder

00:02:06.400 --> 00:02:08.460
untereinander darüber reden, was das überhaupt

00:02:08.460 --> 00:02:09.780
heißt, was das alles so ist.

00:02:10.980 --> 00:02:12.340
Was ist überhaupt dieses Multisprengen? Wir hatten das

00:02:12.340 --> 00:02:14.340
in irgendeiner Episode schon mal so ein bisschen angerissen,

00:02:14.660 --> 00:02:16.440
vielleicht auch so ein bisschen kurz gesprochen, aber

00:02:16.440 --> 00:02:18.320
uns sind noch so ein paar andere Erkenntnisse gekommen und

00:02:18.320 --> 00:02:20.680
darüber wollten wir halt so sprechen. Warum

00:02:20.680 --> 00:02:22.600
macht man so ein Shred und warum

00:02:22.600 --> 00:02:24.640
macht man so ein Multiprocess? Und warum macht man

00:02:24.640 --> 00:02:26.620
das dann irgendwie Async? Und warum macht man das mit Async.io?

00:02:26.940 --> 00:02:28.020
Und was gibt es dann noch für Alternativen?

00:02:28.560 --> 00:02:30.160
Wann braucht man das überhaupt? Und warum?

00:02:30.380 --> 00:02:31.640
Und warum vielleicht auch überhaupt nicht?

00:02:32.740 --> 00:02:33.220
Irgendwie so.

00:02:34.100 --> 00:02:36.540
Ja, wollten wir vielleicht erst noch so ein bisschen News machen?

00:02:37.080 --> 00:02:38.620
Oh, News, ja. Du hast natürlich

00:02:38.620 --> 00:02:40.860
recht. Neuigkeiten aus der Szene.

00:02:41.560 --> 00:02:42.660
Ja, wobei

00:02:42.660 --> 00:02:44.580
so wahnsinnig viel gab es nicht. Ich habe mir noch ein paar

00:02:44.580 --> 00:02:46.540
Dinge aufgeschrieben. Ich weiß nicht,

00:02:46.540 --> 00:02:48.560
ob du das verwendest. Insofern kannst du vielleicht

00:02:48.560 --> 00:02:49.980
Pylance. Ach ja.

00:02:51.120 --> 00:02:52.460
Ja, sehr gut. Ja, also Pylance

00:02:52.460 --> 00:02:54.460
ist ein neues Plugin, was für VS Code rausgekommen ist.

00:02:54.500 --> 00:02:56.080
Also ein neuer Language-Server, wenn ich das

00:02:56.080 --> 00:02:58.420
richtig verstehe, der eine ziemlich coole Sache macht.

00:02:58.520 --> 00:03:00.440
Also mit der Auto-Import-Sätze in VS Code und so

00:03:00.440 --> 00:03:02.380
und fast alle Features, die man sonst

00:03:02.380 --> 00:03:04.320
so auf PyCharm eher hatte. Und also

00:03:04.320 --> 00:03:06.440
ich mag ihn sehr gerne. Hast du ihn auch schon aktiv im Einsatz?

00:03:06.500 --> 00:03:08.300
Ich habe das auch schon aktiviert

00:03:08.300 --> 00:03:09.920
und finde es auch ziemlich gut. Also

00:03:09.920 --> 00:03:11.960
ich mache jetzt gar nicht so viel mit

00:03:11.960 --> 00:03:14.380
Type-Annotationen, aber die Verlockung

00:03:14.380 --> 00:03:16.020
wird stärker. Ja. Und

00:03:16.020 --> 00:03:18.420
das Ding kann da irgendwie einiges rausholen,

00:03:18.520 --> 00:03:20.260
ja. Finde ich auch. Tja, Johannes,

00:03:20.320 --> 00:03:21.520
da bist du raus, wenn du uns PyCharm, ne?

00:03:22.020 --> 00:03:23.700
Ja, tut mir leid, ich habe die Features alle schon.

00:03:24.760 --> 00:03:26.400
Ich meine, ich benutze ja auch PyCharm.

00:03:28.140 --> 00:03:29.760
Also insofern, ich finde das auch gar nicht schlecht.

00:03:30.080 --> 00:03:32.020
Du wurdest dazu gezwungen, habe ich gehört, Jochen.

00:03:32.740 --> 00:03:33.680
Naja, mehr oder weniger.

00:03:34.560 --> 00:03:35.840
Ich meine, ich finde es ja auch interessant.

00:03:36.180 --> 00:03:37.840
Also ab und zu mal andere Dinge verwenden, ist vielleicht gar nicht so schwierig.

00:03:37.860 --> 00:03:39.400
Bei uns nutzen wir alle VS Code.

00:03:40.960 --> 00:03:42.920
Achso, wer übrigens auch VS Code natürlich nutzt,

00:03:43.000 --> 00:03:44.300
ist Daniel Feldtroy, falls ihn kennt,

00:03:44.440 --> 00:03:46.020
der Autor von Two Schools of Django,

00:03:46.420 --> 00:03:48.940
der ja bald das 3X-Version-Buch rausnimmt.

00:03:49.240 --> 00:03:51.520
Und ich war letztens bei ihm ein, zwei Mal in seinem Twitch-Stream,

00:03:51.620 --> 00:03:53.480
weil er irgendwie streamt, irgendwie twitcht und er

00:03:53.480 --> 00:03:55.320
hat mir versprochen, dass er in Düsseldorf zum Essen

00:03:55.320 --> 00:03:57.540
vorbeikommt. Bin natürlich ganz gespannt, ob das

00:03:57.540 --> 00:03:58.540
irgendwie nicht nur blöd ist.

00:03:58.940 --> 00:04:01.380
Ja, das kann man leicht

00:04:01.380 --> 00:04:03.560
versprechen, ne? Solange keine Flugzeuge fliegen und so,

00:04:03.620 --> 00:04:05.660
ist das immer irgendwie relativ...

00:04:05.660 --> 00:04:07.320
Also ich glaube, ein zweites Mal, als ich da war, hat er gedacht,

00:04:07.400 --> 00:04:09.260
oh, warst du nicht der aus Istanbul? Ich so, nee,

00:04:09.400 --> 00:04:11.080
das war aus Düsseldorf, aber...

00:04:11.080 --> 00:04:13.200
Ja, relativ gesehen...

00:04:13.200 --> 00:04:15.520
Ach, Düsseldorf, Istanbul. Kann man sich dann da

00:04:15.520 --> 00:04:17.320
Bücher signieren lassen? Ja, also wenn die

00:04:17.320 --> 00:04:19.040
Altersdiener auf jeden Fall, ja, das hat er ja auch gesagt,

00:04:19.140 --> 00:04:21.380
vielleicht verlieh ich dann sogar dahin und dann

00:04:21.380 --> 00:04:22.860
Quatsch mir ein bisschen. Nein, fand ich super.

00:04:23.020 --> 00:04:24.020
Wollte ich nur mal kurz erwähnt haben.

00:04:24.720 --> 00:04:27.320
Ja, aber es stimmt. Ich gucke in letzter

00:04:27.320 --> 00:04:29.240
Zeit auch gerade in

00:04:29.240 --> 00:04:31.300
Vorbereitung auf diese Episode, habe ich relativ

00:04:31.300 --> 00:04:32.740
viel YouTube-Channels und so geguckt.

00:04:33.800 --> 00:04:35.160
Und da verwenden doch sehr viele

00:04:35.160 --> 00:04:36.700
VS Code. Du hast dich

00:04:36.700 --> 00:04:39.160
vorbereitet? Ja, ausnahmsweise mache

00:04:39.160 --> 00:04:40.940
ich ja sonst eigentlich nicht. Es bestehen noch Zeichen und Wunder.

00:04:41.380 --> 00:04:43.080
Ja, ich fand es auch sehr unangenehm, ehrlich

00:04:43.080 --> 00:04:44.860
gesagt. Ich weiß nicht, ob ich das nochmal machen möchte.

00:04:46.440 --> 00:04:47.240
Aber gerade

00:04:47.240 --> 00:04:48.080
zum Beispiel, da gab es

00:04:48.080 --> 00:04:50.040
eine Serie

00:04:50.040 --> 00:04:52.220
von Lukas Langer, der hat

00:04:52.220 --> 00:04:54.060
auch VS Code verwendet.

00:04:54.620 --> 00:04:55.920
Zu Async.io und so.

00:04:56.880 --> 00:04:58.220
Auch sehr empfehlenswert, kommt auch noch

00:04:58.220 --> 00:05:00.220
in die Show-Nutzung. Ja, ansonsten

00:05:00.220 --> 00:05:02.240
war, glaube ich, irgendwie für 3.7

00:05:02.240 --> 00:05:03.400
ist die letzte

00:05:03.400 --> 00:05:06.280
Bugfix-Release irgendwie

00:05:06.280 --> 00:05:08.420
gerade erschienen. Für 3.6

00:05:08.420 --> 00:05:10.420
noch irgendeine Security-

00:05:10.420 --> 00:05:12.140
Geschichte, Python, und

00:05:12.140 --> 00:05:13.960
das war es dann so ziemlich irgendwie mit

00:05:13.960 --> 00:05:16.040
Ja, dann bald ist 3.9 durch, ne?

00:05:16.100 --> 00:05:17.640
Ja, bald kommt dann 3.9, genau.

00:05:18.240 --> 00:05:19.500
Was ist denn das Tolle an 3.9?

00:05:20.040 --> 00:05:22.880
Jetzt hast du jetzt mal gefragt.

00:05:22.880 --> 00:05:24.400
Auf dem falschen Fuß erwischt.

00:05:25.440 --> 00:05:27.000
Also ich meine, das Tolle an 3.8

00:05:27.000 --> 00:05:28.740
ist ja der Walrus-Operator und den wir

00:05:28.740 --> 00:05:30.740
auch alle ständig immer benutzen.

00:05:31.060 --> 00:05:32.880
Ich wüsste nicht, was in 3.9 neues drin ist.

00:05:33.180 --> 00:05:34.220
Doch, also ich habe gehört,

00:05:34.460 --> 00:05:36.800
dass zum Beispiel diese

00:05:36.800 --> 00:05:38.640
Subinterpreter-Geschichte da

00:05:38.640 --> 00:05:40.700
irgendwie mit drin sein soll.

00:05:41.360 --> 00:05:42.940
Also das war fraglich eine Zeit

00:05:42.940 --> 00:05:44.960
lang und dann gab es... Bitte erkläre

00:05:44.960 --> 00:05:46.640
uns dann, was ist ein Subinterpreter?

00:05:47.560 --> 00:05:48.620
Ja, das ist im Grunde auch so eine

00:05:48.620 --> 00:05:50.300
so eine Methode, um dann halt eventuell,

00:05:50.500 --> 00:05:51.580
also, ähm, ja,

00:05:51.840 --> 00:05:54.080
um halt den Gil so ein bisschen

00:05:54.080 --> 00:05:55.980
loszuwerden oder halt das so ein bisschen...

00:05:55.980 --> 00:05:57.520
Gil ist der Global Interpreter-Log, ja?

00:05:57.640 --> 00:06:00.580
Ja, da werden wir sicherlich gleich noch ganz viel drüber sprechen.

00:06:00.580 --> 00:06:02.180
Genau, die Konsequenzen so ein bisschen zu

00:06:02.180 --> 00:06:04.440
mitigieren und das

00:06:04.440 --> 00:06:06.360
sollte, ich weiß es nicht,

00:06:06.400 --> 00:06:07.980
vielleicht auch so hinterher zählen, ich habe keine Ahnung.

00:06:08.180 --> 00:06:10.320
Also, ich habe gehört, Python 3.9 unterstützt einen neuen

00:06:10.320 --> 00:06:12.320
Parser und der macht ganz viel anders und deswegen

00:06:12.320 --> 00:06:14.440
kann man jetzt auf einmal ganz viele andere Code-Analysen

00:06:14.440 --> 00:06:15.980
oder irgendwas benutzen. Ja.

00:06:17.040 --> 00:06:17.640
Aber...

00:06:17.640 --> 00:06:19.380
Ja, diese Pack-Parser-Geschichte, ja.

00:06:20.900 --> 00:06:22.500
Ja, weiß ich aber auch nicht so viel zu.

00:06:23.060 --> 00:06:26.480
Also für den normalen Programmierer erstmal keine Unterschiede.

00:06:27.520 --> 00:06:28.780
Ja, nicht so richtig viel.

00:06:29.160 --> 00:06:31.000
Also muss man sich mal mit beschäftigen.

00:06:31.120 --> 00:06:32.340
Vielleicht gibt es auch irgendwelche total coolen Sachen.

00:06:32.660 --> 00:06:32.940
Na gut.

00:06:34.400 --> 00:06:39.280
Ansonsten Django, genau, war auch 2.2.14 und 3.0.8 sind irgendwie vor kurzem raus.

00:06:40.740 --> 00:06:40.900
Ja.

00:06:41.400 --> 00:06:43.920
Ja, also Django ist jetzt hart an der Entwicklung zu 3.1.

00:06:44.620 --> 00:06:46.360
Und das ist ja das, worüber wir heute reden wollen,

00:06:46.360 --> 00:06:48.540
weil es halt tatsächlich diese Async-Features jetzt gibt.

00:06:48.820 --> 00:06:50.440
Oder hast du noch mehr News aus der Szene?

00:06:50.500 --> 00:06:52.640
Ja, ich habe welche aus dem Hintergrat,

00:06:52.720 --> 00:06:56.340
beziehungsweise aus meinem persönlichen Setup.

00:06:56.600 --> 00:06:56.740
Oh.

00:06:57.000 --> 00:06:59.440
Und zwar, genau, ich weiß nicht, ob man es hören kann,

00:06:59.600 --> 00:07:04.240
aber jetzt ist hier, wir haben irgendwie eine große Bohrmaschine genommen

00:07:04.240 --> 00:07:08.720
und dann irgendwie hier mal die Außenmauer durchlöchert

00:07:08.720 --> 00:07:10.920
und jetzt ist hier tatsächlich kabelbasiertes Netz.

00:07:11.860 --> 00:07:12.120
Oh.

00:07:12.300 --> 00:07:15.060
Und es könnte sein, dass es jetzt deutlich weniger knackst als vorher.

00:07:15.300 --> 00:07:16.620
Also du meinst, weil es weniger

00:07:16.620 --> 00:07:18.460
Wi-Fi gibt und jetzt mehr konstantes

00:07:18.460 --> 00:07:20.740
Laden. Jetzt gibt es halt richtig ordentliches

00:07:20.740 --> 00:07:22.400
Stimmt, ich sehe sogar da hinten das Kabel,

00:07:22.500 --> 00:07:23.960
das durch die Wand in den Raum geht.

00:07:24.440 --> 00:07:25.720
Genau. Und

00:07:25.720 --> 00:07:28.700
eine zweite Geschichte, die auch

00:07:28.700 --> 00:07:30.440
neu ist und die ich eigentlich ganz

00:07:30.440 --> 00:07:32.500
cool finde, weil ich nicht wusste,

00:07:32.780 --> 00:07:34.540
also ich habe das Ding einfach mal so auf Verdacht

00:07:34.540 --> 00:07:36.540
gekauft und wusste nicht, ob es geht, aber es ging tatsächlich,

00:07:37.360 --> 00:07:39.000
war, ich habe mir so eine

00:07:39.000 --> 00:07:40.820
Kaldigit Docking Station

00:07:40.820 --> 00:07:42.120
besorgt. Eine was?

00:07:43.120 --> 00:07:44.120
Kaldigit. Ja, ja, ja.

00:07:44.900 --> 00:07:53.860
Das Ding versorgt gleichzeitig einen Rechner mit Strom, macht irgendwie Thunderbolt und du kannst Monitore dran anschließen.

00:07:54.000 --> 00:07:58.060
Und was ich halt da drin habe, also ich habe sozusagen nur noch ein Kabel, das ich halt immer an den Rechner stecke.

00:07:58.360 --> 00:08:04.060
Weil ich hatte nämlich jetzt, da ich jetzt Netzwerkkabel habe, das Problem, okay, wie mache ich denn das Netzwerkkabel an meinem Rechner fest?

00:08:04.060 --> 00:08:05.040
Der hat ja nur USB-C.

00:08:06.200 --> 00:08:10.400
Da so irgendwie so ein Dongle dran zu hängen, der dann so rumbaumelt, ist auch irgendwie etwas unschön.

00:08:10.700 --> 00:08:14.620
Zusätzlich zu den ganzen anderen Adaptern und Dongle, die da sowieso schon rumbaumeln.

00:08:14.900 --> 00:08:44.880
Ähm, äh, und, ähm, das geht damit halt ganz gut, weil da steckt man einfach Ethernet hinten rein plus irgendwie das, was zum Monitor geht und, äh, hat halt nur ein einziges Kabel, was zum Laptop geht und alles andere, äh, geht dann über die Dockingstation und was tatsächlich funktioniert ist, man hat halt, ich hab da hinten halt dann noch Storage dran und das ist schnell, äh, und, also so eine externe SSD und das ist ordentlich schnell, der Monitor ist so ein, so ein, so ein ultrafein, äh, LG 5K und da dachte ich auch so, uh, ob das funktioniert, aber es funktioniert tatsächlich.

00:08:44.900 --> 00:08:46.040
Und es kommt auch noch Strom durch.

00:08:47.140 --> 00:08:48.100
Also ich suche auch so etwas Ähnliches.

00:08:48.160 --> 00:08:50.220
Ich möchte gerne meine Monitore umschalten

00:08:50.220 --> 00:08:50.860
mit so einem Switch.

00:08:50.980 --> 00:08:53.000
Und zwar einmal auf eine Workstation

00:08:53.000 --> 00:08:55.260
und einmal auf meinen normalen Rechner.

00:08:55.640 --> 00:08:56.520
So eine KVM-Switch?

00:08:56.740 --> 00:08:57.760
Ja, genau, eine KVM-Switch.

00:08:57.860 --> 00:08:58.560
Und ich habe mich dann gefragt,

00:08:58.640 --> 00:08:59.540
ob es da was Vernünftiges für gibt.

00:08:59.640 --> 00:09:02.300
Weil ich hätte gerne auch die Auflösung der Monitore

00:09:02.300 --> 00:09:04.580
und mit Switch immer hin und her geschaltet

00:09:04.580 --> 00:09:05.740
zwischen allen Setups.

00:09:06.720 --> 00:09:07.380
Das finde ich cool.

00:09:07.480 --> 00:09:08.700
Aber ich habe noch keine Ahnung, was es da gibt.

00:09:08.800 --> 00:09:09.780
Falls ihr da irgendjemanden kennt

00:09:09.780 --> 00:09:10.780
oder einen guten Tipp habt,

00:09:11.220 --> 00:09:12.180
her damit, ich freue mich drüber.

00:09:12.780 --> 00:09:14.200
Das schaffe ich mir an und probiere das mal aus.

00:09:14.900 --> 00:09:17.920
Ansonsten

00:09:17.920 --> 00:09:20.040
habe ich nichts mehr. Johannes, hast du eine News?

00:09:20.040 --> 00:09:21.900
Eine Neuigkeit? Nee, ich bin immer noch im WLAN.

00:09:21.980 --> 00:09:22.680
Ich habe kein Kabel.

00:09:23.340 --> 00:09:24.900
Du bist tatsächlich im WLAN bei dir im Haus?

00:09:25.880 --> 00:09:27.500
Ja, das geht ja nicht anders.

00:09:28.220 --> 00:09:29.140
Das ist zu weit weg.

00:09:29.620 --> 00:09:31.900
Rohrmaschine? Ja, nicht in einem

00:09:31.900 --> 00:09:32.240
Miethaus.

00:09:33.960 --> 00:09:35.080
Und ich habe schon lange

00:09:35.080 --> 00:09:37.760
so ein relativ altes

00:09:37.760 --> 00:09:39.840
Lenovo-Dock. Das gehört auch

00:09:39.840 --> 00:09:41.680
gar nicht zu meinem Rechner, sondern das habe ich einfach mal irgendwo

00:09:41.680 --> 00:09:43.500
gekriegt für, keine Ahnung, 50 Euro oder so.

00:09:44.900 --> 00:09:47.140
Ein Dock ist total gut.

00:09:47.220 --> 00:09:49.300
Da ist einfach alles eingesteckt. Tastatur eingesteckt,

00:09:49.400 --> 00:09:50.920
Maus eingesteckt, Monitore eingesteckt,

00:09:51.700 --> 00:09:52.760
Storage ist auch dran.

00:09:53.460 --> 00:09:55.380
Das ist total gut. Und du sitzt diesmal auf einem

00:09:55.380 --> 00:09:57.320
anderen Stuhl und auf einem anderen Schreibtisch,

00:09:57.360 --> 00:09:58.580
vor einem anderen Schreibtisch in deinem Büro.

00:10:00.020 --> 00:10:01.140
Naja, nee, ich habe ja zwei

00:10:01.140 --> 00:10:02.620
Arbeitsplätze in meinem Büro.

00:10:02.760 --> 00:10:04.240
Der andere Arbeitsplatz.

00:10:04.520 --> 00:10:05.880
Der ist ja praktikant nicht zu Hause, na gut.

00:10:08.040 --> 00:10:09.400
Es gibt den

00:10:09.400 --> 00:10:11.220
mobilen Arbeitsplatz und den immobilen

00:10:11.220 --> 00:10:13.540
Arbeitsplatz und das ist jetzt der fest installierte

00:10:13.540 --> 00:10:14.920
mit den großen Monitoren.

00:10:15.020 --> 00:10:15.560
Okay, okay.

00:10:17.200 --> 00:10:17.960
Ja, cool.

00:10:18.060 --> 00:10:19.660
Dann würde ich sagen, von mir aus

00:10:19.660 --> 00:10:22.160
kann man jetzt tatsächlich das Thema

00:10:22.160 --> 00:10:24.640
Ich bin absolut begeistert,

00:10:24.700 --> 00:10:26.180
das ist eine Weltpremiere hier heute.

00:10:26.780 --> 00:10:28.140
Liebe Hörerinnen und Hörer, hört zu,

00:10:28.200 --> 00:10:29.500
ihr wisst genau, was euch jetzt erwartet.

00:10:29.820 --> 00:10:31.820
Weltpremiere Dango Async 3.1.

00:10:32.900 --> 00:10:34.220
Ja, also genau.

00:10:34.380 --> 00:10:35.720
Ich habe direkt mal eine Frage.

00:10:36.040 --> 00:10:37.060
Ja, was ist denn der Async?

00:10:38.060 --> 00:10:39.900
Muss ich irgendwas beachten,

00:10:39.980 --> 00:10:41.620
wenn ich jetzt von 3.0 auf 3.1 upgrade?

00:10:42.080 --> 00:10:43.140
Muss ich dann irgendwas machen

00:10:43.140 --> 00:10:44.400
oder geht es dann auch noch alles?

00:10:44.560 --> 00:10:46.500
Das geht alles genauso wie vorher auch.

00:10:47.440 --> 00:10:48.680
Wichtigste Frage direkt geklärt.

00:10:49.420 --> 00:10:51.280
Okay, also erstmal nochmal so vielleicht ganz kurz

00:10:51.280 --> 00:10:53.440
so zum Frame, zum Rahmen, worum es eigentlich geht.

00:10:54.340 --> 00:10:56.640
Was Async dann überhaupt bedeutet

00:10:56.640 --> 00:10:58.220
und was man jetzt damit machen kann,

00:10:58.320 --> 00:10:59.980
was vorher schon so ging, so diese Geschichte

00:10:59.980 --> 00:11:02.280
und wofür man das eigentlich braucht.

00:11:02.500 --> 00:11:04.140
Also womit wollt ihr denn anfangen?

00:11:04.300 --> 00:11:07.140
Vielleicht, was das ist, Async überhaupt?

00:11:07.740 --> 00:11:11.100
Und ja, dann kommt man vielleicht darauf,

00:11:11.100 --> 00:11:13.200
warum man das vielleicht haben wollen

00:11:13.200 --> 00:11:14.480
möchte oder vielleicht auch gar nicht braucht.

00:11:16.180 --> 00:11:17.060
Das ist gleich eine schwierige

00:11:17.060 --> 00:11:17.720
Frage am Anfang.

00:11:18.520 --> 00:11:20.740
Also ich glaube, ich würde tatsächlich mit der

00:11:20.740 --> 00:11:22.920
Motivation starten, weil sonst

00:11:22.920 --> 00:11:24.900
wird das direkt so trocken und alle Leute

00:11:24.900 --> 00:11:26.360
schalten sofort auf Durchzug und

00:11:26.360 --> 00:11:28.800
wenn man so zumindest

00:11:28.800 --> 00:11:30.880
weiß, dass es irgendwie vielleicht nicht so

00:11:30.880 --> 00:11:32.740
super unwichtig ist und dass tatsächlich

00:11:32.740 --> 00:11:34.580
interessante Dinge damit gehen, dann

00:11:34.580 --> 00:11:36.680
vielleicht hält man ein bisschen länger durch.

00:11:36.960 --> 00:11:38.960
Also du weißt schon, dass da Eve Online steht und das ist

00:11:38.960 --> 00:11:40.940
gleich sonst einen Exkurs von mir zu EVE Online.

00:11:41.460 --> 00:11:42.840
Ja, genau, das wäre

00:11:42.840 --> 00:11:44.100
interessant.

00:11:45.120 --> 00:11:46.580
Aber die sind doch noch auf 2.7.

00:11:46.700 --> 00:11:48.840
Die kriegen ja doch die ganzen Sachen gar nicht mit.

00:11:49.200 --> 00:11:50.920
Ja, ja, aber es gibt

00:11:50.920 --> 00:11:52.040
wahrscheinlich Gründe, warum das so ist.

00:11:53.180 --> 00:11:55.260
Also okay, ich fange einfach mal so an.

00:11:55.340 --> 00:11:55.880
Das ist der Grund.

00:11:57.300 --> 00:11:59.000
EVE Online hat von Anfang an gesagt,

00:11:59.000 --> 00:12:01.060
wir haben, keine Ahnung, 15 Millionen Codezeilen

00:12:01.060 --> 00:12:03.280
in unserem Server, wir fangen jetzt nicht an, die auf Python 3.

00:12:03.340 --> 00:12:04.640
Also genau, EVE Online

00:12:04.640 --> 00:12:07.160
basiert viel auf Python, falls ihr das noch nicht gehört habt.

00:12:07.360 --> 00:12:14.900
Ja, genau. Und soweit ich weiß, ich weiß nicht, ob das immer noch so ist, aber soweit ich das gehört habe, auch auf Stackless Python.

00:12:16.160 --> 00:12:20.300
Oh ja, das ist interessant. Da umgehen Sie ja gleich viele von den Dingen, weshalb man Async überhaupt braucht.

00:12:21.900 --> 00:12:26.780
Genau, also beziehungsweise zu der Zeit, wo Sie das gemacht haben, gab es das halt einfach noch nicht.

00:12:27.220 --> 00:12:29.920
Und Stackless Python war halt eine Lösung für die Probleme, die sich da gegeben haben.

00:12:30.200 --> 00:12:35.200
Und ich meine, gut, wir können auch einfach direkt so einsteigen, weil das ist ja auch eine gute Motivation, warum braucht man sowas überhaupt?

00:12:35.600 --> 00:12:38.160
Und was die wohl können, also hieß es jedenfalls,

00:12:38.800 --> 00:12:43.160
ist, dass da das alles in Stackless-Python

00:12:43.160 --> 00:12:47.260
halt auch so Userland-Threads oder Green-Threads

00:12:47.260 --> 00:12:49.160
oder wie auch immer man die nennt, sind.

00:12:50.720 --> 00:12:53.740
Stackless-Python, du brauchst keinen Execution-Stack

00:12:53.740 --> 00:12:54.440
dafür im Betriebssystem.

00:12:56.400 --> 00:12:59.360
Was Stackless-Python kann, ist, du kannst diese Threads picklen.

00:13:01.120 --> 00:13:03.500
Ja, vor allem kannst du mehr als einen ausführen, oder?

00:13:03.960 --> 00:13:05.140
Ja, ja, ja, das auch.

00:13:05.480 --> 00:13:07.680
Das hat auch keinen Global Interpreter-Log, das heißt, du kannst

00:13:07.680 --> 00:13:08.600
einfach...

00:13:08.600 --> 00:13:11.960
Jetzt gerade wieder die ganze Bagage

00:13:11.960 --> 00:13:13.960
mit dem Grammisch-Collector in den Müll.

00:13:14.680 --> 00:13:16.220
Moment! Stopp, stopp, stopp,

00:13:16.260 --> 00:13:16.800
da sind wir doch noch nicht.

00:13:18.360 --> 00:13:20.100
Also, ich wollte

00:13:20.100 --> 00:13:21.940
eigentlich nur mal kurz, warum man das eigentlich machen will,

00:13:22.280 --> 00:13:23.400
was das Coole daran ist.

00:13:24.020 --> 00:13:25.940
Dadurch, dass diese Threads, also wenn ich jetzt zum Beispiel

00:13:25.940 --> 00:13:27.780
halt ein Ding, ich habe keine Ahnung,

00:13:27.860 --> 00:13:29.940
wie die EVE Online funktioniert, ja, ich kenne das nicht gar nicht,

00:13:30.200 --> 00:13:31.520
aber ich glaube, es geht irgendwie um Raumschiffe und so,

00:13:31.520 --> 00:13:32.840
die da irgendwie im Weltraum rumfliegen.

00:13:32.920 --> 00:13:34.040
Excel in Space.

00:13:34.940 --> 00:13:37.140
Gut, wem es Spaß macht, aber

00:13:37.140 --> 00:13:37.500
naja.

00:13:38.960 --> 00:13:41.260
Und du hast jetzt irgendwie einen Thread, der jetzt so ein Raumschiff

00:13:41.260 --> 00:13:42.860
simuliert, das da so richtig gegenfliegt.

00:13:43.180 --> 00:13:45.100
Dann kannst du halt das Ding

00:13:45.100 --> 00:13:46.680
pickeln, in eine Datenbank schreiben,

00:13:47.760 --> 00:13:48.940
irgendwo anders wieder

00:13:48.940 --> 00:13:51.300
auspacken und weiter ausführen.

00:13:52.540 --> 00:13:53.280
Ja, das ist eine sogenannte

00:13:53.280 --> 00:13:55.020
Continuation, wäre mal

00:13:55.020 --> 00:13:56.700
die akademische Fachliteratur.

00:13:56.880 --> 00:13:57.880
Ah, okay, gut.

00:13:59.300 --> 00:14:00.860
Und das ist natürlich, wenn man ein

00:14:00.860 --> 00:14:02.900
Riesenuniversum hat, vielleicht eine ganz gute Sache,

00:14:02.920 --> 00:14:05.040
wenn man das machen kann, weil eventuell

00:14:05.040 --> 00:14:07.060
will man halt nicht alles immer laufen haben,

00:14:07.180 --> 00:14:08.540
sondern möchte halt auch

00:14:08.540 --> 00:14:11.020
Teile von dem Universum, das man simuliert,

00:14:11.200 --> 00:14:12.380
da irgendwie auch einfach mal

00:14:12.380 --> 00:14:14.880
einfrieren und in eine Datenbank

00:14:14.880 --> 00:14:16.880
schreiben und erst dann wieder auftauen, wenn man es

00:14:16.880 --> 00:14:18.920
tatsächlich benötigt, damit man nicht immer alles

00:14:18.920 --> 00:14:20.320
gleichzeitig ausführen muss oder so.

00:14:20.940 --> 00:14:22.280
Wäre eine gute Idee für Zeitreisen.

00:14:22.940 --> 00:14:24.780
Aber wir wollten über die Motivationen

00:14:24.780 --> 00:14:26.680
nochmal dann doch vielleicht kurz, lass das doch mal kurz

00:14:26.680 --> 00:14:28.840
heute ausnahmsweise strukturierter angehen.

00:14:29.280 --> 00:14:30.680
Und dann, wir gehen auch versprochen wieder zu

00:14:30.680 --> 00:14:31.280
EVE Online zurück.

00:14:32.160 --> 00:14:35.860
Ja, also genau, die Frage ist halt sozusagen,

00:14:36.780 --> 00:14:42.160
ob nicht es valide Use Cases gibt für so sehr,

00:14:43.340 --> 00:14:45.420
das deutsche Wort ist so ein bisschen doof,

00:14:45.900 --> 00:14:50.240
aber ich weiß auch nicht, ob man da ein besseres finden kann,

00:14:50.340 --> 00:14:52.740
nebenläufige, also massiv nebenläufige Programme.

00:14:52.740 --> 00:14:54.540
Also man braucht halt viel Concurrency.

00:14:54.740 --> 00:14:56.880
Also es gibt Probleme, da hat man halt einfach ganz viel Concurrency.

00:14:57.800 --> 00:15:06.580
Und die Frage wäre halt, muss man, wenn man so ein Problem hat, damit umgehen zu können, die Sprache wechseln oder nicht?

00:15:07.420 --> 00:15:22.740
Das ist sozusagen, also diese, ich würde sagen, das zentrale, ich habe mir ein paar Sachen angeguckt und das zentrale Ding, das hat auch Tom Christie quasi in einem Vortrag auf der DjangoCon 2019, als er irgendwie einen, den er da gehalten hat, so gesagt.

00:15:22.900 --> 00:15:25.300
Also es gibt da diverse Geschichten in Go,

00:15:25.460 --> 00:15:28.160
es gibt diverse Geschichten in Node.js oder Rust

00:15:28.160 --> 00:15:32.020
oder Erlang, Erlang ist auch ziemlich en vogue gerade

00:15:32.020 --> 00:15:33.960
und die Frage wäre halt, wenn man jetzt so einen Use Case hat,

00:15:34.560 --> 00:15:36.500
bedeutet das, dass man die Programmiersprache wechseln muss

00:15:36.500 --> 00:15:37.640
und dann halt Erlang machen muss

00:15:37.640 --> 00:15:40.260
oder halt kann man das auch in Python machen?

00:15:40.620 --> 00:15:42.060
Eigentlich kann man das auch in Python machen,

00:15:43.060 --> 00:15:44.980
ist jetzt sozusagen dafür die Infrastruktur

00:15:44.980 --> 00:15:47.580
noch nicht so ausgeprägt wie in anderen Sprachen,

00:15:47.580 --> 00:15:50.620
aber so prinzipiell geht das schon

00:15:50.620 --> 00:15:52.320
und man könnte jetzt sagen, na gut,

00:15:52.380 --> 00:15:54.460
das hat ein bisschen lange gedauert, also die Geschichte von

00:15:54.460 --> 00:15:56.160
Async in Python ist wahnsinnig lang,

00:15:56.880 --> 00:15:58.380
aber in letzter Zeit wird es halt

00:15:58.380 --> 00:16:00.440
sehr interessant. Zum Beispiel, wenn man jetzt Django als Beispiel

00:16:00.440 --> 00:16:02.440
nimmt, dann geht das jetzt gerade erst so

00:16:02.440 --> 00:16:03.980
richtig. Und der Grund dafür ist,

00:16:04.560 --> 00:16:06.200
dass eigentlich will man

00:16:06.200 --> 00:16:08.240
die Syntax dafür haben, also

00:16:08.240 --> 00:16:09.400
für Kuroutinen,

00:16:10.540 --> 00:16:12.420
und die ist erst seit 3.5 so richtig in der

00:16:12.420 --> 00:16:14.420
Sprache. Das heißt, vor 3.5 ist sowieso

00:16:14.420 --> 00:16:16.260
schwierig. Und

00:16:16.260 --> 00:16:18.320
Django hat mit Version

00:16:18.320 --> 00:16:20.360
1.11 noch Python 2 supported.

00:16:21.240 --> 00:16:22.100
Dann geht es auch nicht.

00:16:22.300 --> 00:16:23.140
Das kann man einfach vergessen.

00:16:23.780 --> 00:16:28.100
Und mit Django, glaube ich, 2.1, 2.2 weiß ich gar nicht mehr,

00:16:28.220 --> 00:16:29.640
aber noch Python 3.4.

00:16:30.000 --> 00:16:31.000
Und mit 3.4 geht es auch nicht.

00:16:31.620 --> 00:16:35.580
Das heißt, bis vor kurzem konnte Django das gar nicht

00:16:35.580 --> 00:16:36.680
mit der nativen Syntax machen,

00:16:36.820 --> 00:16:39.920
weil Python-Versionen supportet wurden,

00:16:40.200 --> 00:16:41.060
bei denen das einfach nicht geht.

00:16:42.120 --> 00:16:44.300
Und jetzt ist es halt sozusagen alt und abgehangen genug,

00:16:44.300 --> 00:16:48.980
dass sozusagen nur noch Python-Versionen unterstützt werden,

00:16:49.380 --> 00:16:51.340
mit denen man das dann tatsächlich nativ machen kann.

00:16:51.540 --> 00:16:54.000
Und jetzt kann man halt anfangen, das umzustellen.

00:16:54.120 --> 00:16:56.340
Beziehungsweise die Arbeiten daran sind ja jetzt auch schon was älter,

00:16:56.480 --> 00:16:58.700
aber jetzt ist es halt so weit, dass es tatsächlich mal in einer

00:16:58.700 --> 00:17:03.320
verwendbaren, für User verwendbaren Form halt tatsächlich in Django ankommt.

00:17:05.320 --> 00:17:06.900
Und wenn man sich sowas überlegt,

00:17:06.940 --> 00:17:08.360
also was ich zum Beispiel mir angeguckt habe,

00:17:09.500 --> 00:17:12.700
Erlang ist ja relativ irgendwo gerade,

00:17:12.820 --> 00:17:14.960
beziehungsweise halt so ein Dialekt,

00:17:14.960 --> 00:17:17.740
der oft dann so für Web-Entwicklungsgeschichten benutzt wird, Elixier.

00:17:18.760 --> 00:17:20.920
Und da gibt es auch so ein Web-Framework Phoenix zum Beispiel,

00:17:21.020 --> 00:17:22.060
Und da kann man auch mal sich angucken,

00:17:22.300 --> 00:17:23.480
so Phoenix Elixier,

00:17:24.800 --> 00:17:26.240
Live View, solche Sachen.

00:17:26.760 --> 00:17:28.580
Und das sieht alles schon sehr beeindruckend aus

00:17:28.580 --> 00:17:29.960
und ist auch sehr nett.

00:17:30.560 --> 00:17:32.660
Und die Frage wäre halt, kann man sowas in Django

00:17:32.660 --> 00:17:34.160
und Python auch machen? Und die Antwort ist eigentlich

00:17:34.160 --> 00:17:36.780
ja. Eigentlich gibt es nichts, was einen davon prinzipiell

00:17:36.780 --> 00:17:37.140
abhält.

00:17:38.300 --> 00:17:40.560
Außer, dass es halt nicht, dass noch nicht so

00:17:40.560 --> 00:17:42.240
unterstützt wird in den Frameworks und so. Aber

00:17:42.240 --> 00:17:43.640
prinzipiell geht das schon.

00:17:44.060 --> 00:17:45.560
Was macht das denn jetzt so schön?

00:17:49.680 --> 00:17:50.080
Ja.

00:17:51.020 --> 00:17:58.300
Ähm, keine Ahnung, habt ihr noch was oder wegen Motivation oder was? Ich überlege gerade, ob ich jetzt schon ausreichend motiviert habe.

00:18:01.080 --> 00:18:10.200
Ja, da fehlt noch ein kleines bisschen vielleicht. Warum man das vielleicht macht, könnte man bei der Motivation direkt sagen, oder? Also was für Problemfälle gibt es denn, die man jetzt…

00:18:10.200 --> 00:18:18.800
Ja, es gibt ja schon immer, also ich meine, es gibt ja schon immer Anstrengungen, Sachen zu parallelisieren und da gibt es auch schon ganz alte Sachen.

00:18:20.200 --> 00:18:28.800
Nur damals war es halt, damals, ja, also vor zehn Jahren war es halt noch so, dass Computer zwei Cores hatten oder vier Cores und da ist es nicht so wild, wenn du nur einen benutzt.

00:18:29.620 --> 00:18:38.480
Aber heutzutage ist es ja relativ leicht, gerade im Serverbereich, Sachen zu kriegen, die 64 oder 128 Cores haben oder noch mehr, wenn man das unbedingt haben möchte.

00:18:38.620 --> 00:18:40.340
Oder wenn man auf Grafikkarten geht, kriegt man direkt

00:18:40.340 --> 00:18:41.420
in die Tausenden von Cores.

00:18:42.720 --> 00:18:44.560
Deshalb ist das, man darf da

00:18:44.560 --> 00:18:46.380
nicht so viel Python verdammen, weil das

00:18:46.380 --> 00:18:48.380
einfach vor zehn Jahren noch kein Problem war.

00:18:49.040 --> 00:18:50.640
Ja, Moment, Moment, aber das ist jetzt, glaube ich,

00:18:50.640 --> 00:18:52.480
ein anderes Problem, oder? Also, oder aus

00:18:52.480 --> 00:18:53.320
meiner Perspektive ist es ein anderes.

00:18:54.080 --> 00:18:56.340
Generell die Nebenläufigkeit,

00:18:56.560 --> 00:18:57.680
die man da jetzt braucht.

00:18:58.880 --> 00:19:00.460
Aber das braucht man, das haben die anderen auch nicht.

00:19:00.700 --> 00:19:02.460
Das haben die anderen auch nicht. Also, das kriegst du auch

00:19:02.460 --> 00:19:03.300
auf Node.js nicht hin.

00:19:06.560 --> 00:19:08.360
Das mag sein, dass das mit Node.js nicht

00:19:08.360 --> 00:19:10.540
nicht unbedingt hinkriegst, aber mit C

00:19:10.540 --> 00:19:12.600
und Erlang und Rust und so weiter kriegst du die Sachen

00:19:12.600 --> 00:19:13.600
schon hin. Und Go auch.

00:19:14.500 --> 00:19:15.420
Ja, gut.

00:19:15.980 --> 00:19:17.600
Die nutzen schon alle Cores aus.

00:19:18.500 --> 00:19:20.380
Ja, aber da

00:19:20.380 --> 00:19:22.040
weiß ich gar nicht, ob man das unbedingt braucht.

00:19:22.300 --> 00:19:23.200
Da würde ich jetzt denken,

00:19:23.920 --> 00:19:26.020
warum? Doch, also ich glaube,

00:19:27.020 --> 00:19:28.580
für mich ist das schon eine Motivation,

00:19:29.080 --> 00:19:30.720
mehr Cores ausnutzen zu können.

00:19:31.580 --> 00:19:32.480
Geht zwar nicht mit

00:19:32.480 --> 00:19:34.020
Async, das weiß ich, aber

00:19:34.020 --> 00:19:35.600
ja.

00:19:36.500 --> 00:19:55.760
Generell, der Trend geht dazu, mehr Sachen gleichzeitig zu machen, um es mal so auszudrücken. Und dafür braucht man halt irgendeine Syntax. Und klar, es gibt die ganzen Sachen, die man früher machen konnte. Da gibt es die coolen Message-Parsing-Interfaces und die coolen, was weiß ich, verteiltes Rechnen-Ansätze und dann gibt es Threads und Multiprocessing und so weiter.

00:19:56.580 --> 00:19:57.140
Aber die

00:19:57.140 --> 00:19:59.020
haben halt alle ihre Nachteile und die haben halt alle

00:19:59.020 --> 00:20:01.140
ihre, sagen wir mal,

00:20:01.780 --> 00:20:02.540
Schwierigkeiten.

00:20:03.660 --> 00:20:04.400
Und gerade wenn man

00:20:04.400 --> 00:20:06.820
anfängt mit Threads zu arbeiten in Python,

00:20:06.980 --> 00:20:08.840
merkt man halt sehr schnell, dass das von der Geschwindigkeit her

00:20:08.840 --> 00:20:09.700
überhaupt gar nichts bringt.

00:20:11.700 --> 00:20:12.760
Also ist die Frage, was man

00:20:12.760 --> 00:20:14.180
mit Schwierigkeiten meint, ja,

00:20:14.500 --> 00:20:15.660
wenn es um

00:20:15.660 --> 00:20:18.760
quasi wie schnell kann man

00:20:18.760 --> 00:20:20.760
Dinge machen geht, dann

00:20:20.760 --> 00:20:21.580
bringt einem das nichts, sondern

00:20:21.580 --> 00:20:23.360
macht es einfach langsam.

00:20:25.300 --> 00:20:27.520
Und auch, wie viele Sachen gleichzeitig kann ich machen.

00:20:29.080 --> 00:20:29.860
Wir helfen einem

00:20:29.860 --> 00:20:31.260
im Verhältnis in Python ja erstmal gar nichts.

00:20:31.780 --> 00:20:33.720
Ja, wobei, da würde ich direkt

00:20:33.720 --> 00:20:35.220
unterscheiden zwischen Sachen

00:20:35.220 --> 00:20:37.100
parallel machen, das heißt,

00:20:37.620 --> 00:20:39.140
und Sachen concurrent,

00:20:39.540 --> 00:20:41.420
und daneben läufig, ja, weiß nicht, ob das eine gute Übersetzung

00:20:41.420 --> 00:20:42.580
ist, könnte man nicht.

00:20:43.180 --> 00:20:44.900
Die deutschen Worte sind da total blöd.

00:20:45.780 --> 00:20:47.660
Weil parallel geht

00:20:47.660 --> 00:20:49.540
halt in Python nicht, aber ich glaube auch nicht, dass

00:20:49.540 --> 00:20:50.400
das das Problem ist.

00:20:52.160 --> 00:20:52.920
Oder geht noch nicht.

00:20:52.920 --> 00:20:54.600
Da gibt es verschiedene Workloads, glaube ich, die da

00:20:54.600 --> 00:20:57.160
die du da bedenken musst.

00:20:58.440 --> 00:20:59.600
Also Multi-Processing ist parallel?

00:20:59.880 --> 00:21:01.040
Wenn du in Nampai bist, dann hast du ja schon Parallelität.

00:21:01.160 --> 00:21:02.760
Mit Nampai kriegst du die Cores schon alle voll.

00:21:03.180 --> 00:21:03.780
Ja, ja, klar, genau.

00:21:04.040 --> 00:21:04.680
Insofern würde ich sagen,

00:21:04.780 --> 00:21:05.640
das ist auch nicht so ein Problem.

00:21:06.000 --> 00:21:06.020
Vielleicht muss man erst noch erklären,

00:21:06.020 --> 00:21:07.740
was Parallelität und Nebenläufigkeit sind.

00:21:07.760 --> 00:21:08.420
Ja, bitte, bitte.

00:21:08.540 --> 00:21:09.640
Einmal kurz da einschränken.

00:21:10.740 --> 00:21:12.760
Ja, aber ist jetzt Multi-Processing

00:21:12.760 --> 00:21:13.940
nicht sowas wie parallel?

00:21:15.280 --> 00:21:16.760
Ja, Multi-Processing ist parallel,

00:21:16.760 --> 00:21:19.600
aber auch das kannst du nur machen,

00:21:19.700 --> 00:21:20.760
wenn du wenig Kommunikation hast,

00:21:20.860 --> 00:21:23.380
weil du da eben zwischen Prozessen kommunizieren musst

00:21:23.380 --> 00:21:24.420
und das ist langsam.

00:21:25.180 --> 00:21:27.540
Das ist generell die Krankheit, die du hast,

00:21:27.720 --> 00:21:30.120
wenn du solche Message-Parsing-Sachen machst.

00:21:31.220 --> 00:21:32.620
Das hatten wir ja früher auch schon gehabt.

00:21:33.680 --> 00:21:36.620
Als ich studiert habe, hatten wir einen großen Cluster,

00:21:36.700 --> 00:21:38.900
der hatte 16 Prozessoren an der Universität.

00:21:39.940 --> 00:21:42.120
Und das waren halt unterschiedlich, es waren halt 16 Computer,

00:21:43.140 --> 00:21:45.560
die mit einem schnellen Netzwerk verbunden waren.

00:21:45.660 --> 00:21:47.580
Aber je weniger Nachrichten du schicken konntest,

00:21:47.760 --> 00:21:49.720
schicken musstest, umso schneller war das dann halt.

00:21:50.180 --> 00:21:51.780
Das heißt, im Wesentlichen warst du da gar nicht

00:21:51.780 --> 00:21:53.960
die CPU gedrosselt,

00:21:54.040 --> 00:21:55.220
sondern eben durchs Netzwerk.

00:21:55.580 --> 00:21:56.020
Ja, ja, gut.

00:21:57.460 --> 00:21:59.480
So ein bisschen ist es bei Multiprocessing ja auch.

00:21:59.660 --> 00:22:01.340
Je weniger Nachrichten du schicken musst, umso

00:22:01.340 --> 00:22:03.920
besser. Aber da musst du überhaupt gar keine schicken.

00:22:04.880 --> 00:22:05.800
Irgendwie, dass man sagt, man hat so

00:22:05.800 --> 00:22:07.620
eine gemeinsame Verwaltung. Genau, es gibt Chat-Memory.

00:22:07.760 --> 00:22:09.540
Kannst du einfach wenden. Musst du gar keine Nachrichten schicken.

00:22:09.780 --> 00:22:11.700
Cool, sowas gibt es schon? Ja, ja. Das ist auch eingebaut.

00:22:11.880 --> 00:22:12.920
Seit Python 3.8 ist das drin.

00:22:13.640 --> 00:22:15.440
Also kannst du sagen, hier irgendwie, ja.

00:22:15.440 --> 00:22:15.780
Umso besser.

00:22:18.180 --> 00:22:19.480
Aber dann hast du trotzdem noch

00:22:19.480 --> 00:22:21.320
irgendwelche Locking-Mechanismen, die dir da

00:22:21.320 --> 00:22:22.660
wo wir halt warten mussten.

00:22:23.000 --> 00:22:25.660
Aber wenn du CPU-Bauern bist, ist das alles nicht mehr schlimm.

00:22:26.140 --> 00:22:27.440
Also das ist alles, also ich würde sagen,

00:22:27.540 --> 00:22:28.900
wenn du Dinge einfach,

00:22:29.460 --> 00:22:31.720
wenn du jetzt irgendwie Number-Crunch-Geschichten machst,

00:22:32.580 --> 00:22:33.780
da alle Cores zu verwenden,

00:22:33.880 --> 00:22:35.140
ist in Python überhaupt kein Problem.

00:22:35.340 --> 00:22:37.480
Das geht super. Das ist tatsächlich einer

00:22:37.480 --> 00:22:39.160
der beliebtesten Anwendungsfälle für Python.

00:22:39.840 --> 00:22:40.820
Also ich würde sagen, Data Science,

00:22:41.000 --> 00:22:44.040
da ist Python wahrscheinlich die Sprache Nummer 1 gerade.

00:22:44.840 --> 00:22:45.680
Und das ist ja

00:22:45.680 --> 00:22:47.820
hauptsächlich so ein Zeugs. Und da geht das super.

00:22:47.820 --> 00:22:49.520
Da werden immer alle Cores benutzt, gar kein Problem.

00:22:50.720 --> 00:22:57.320
Ja, klar. Im Wesentlichen ist der Trick halt daran, dass die aus Python rausgehen, die Bibliotheken, und dass die das halt in C machen.

00:22:57.460 --> 00:23:03.840
Ja, oder du kannst halt auch so Dinge machen, nee, nee, nicht nur. Also du kannst auch pure Python-Funktionen parallelisieren.

00:23:03.980 --> 00:23:07.680
Also mit REST geht das, auch mit mehreren Maschinen hinweg.

00:23:07.700 --> 00:23:08.220
Ach so, ja, okay.

00:23:09.400 --> 00:23:12.520
Aber das ist, also ich habe hier gerade die …

00:23:12.520 --> 00:23:13.860
Also das ist jedenfalls Parallelität.

00:23:14.060 --> 00:23:14.920
Ja, genau, das ist Parallelität.

00:23:14.920 --> 00:23:19.280
Man macht Berechnungen auf mehreren Prozessoren und die sind gleichzeitig im Wesentlichen.

00:23:19.620 --> 00:23:21.680
Und es spielt keine Rolle, ob es die gleiche Berechnung ist oder

00:23:21.680 --> 00:23:23.840
eine andere Berechnung. In den meisten Fällen

00:23:23.840 --> 00:23:25.960
werden es ja die gleichen Berechnungen sein.

00:23:26.620 --> 00:23:27.960
Und wenn er zuerst fertig ist,

00:23:27.960 --> 00:23:29.780
dann schreibe ich. Auf allen Zeilen dieser

00:23:29.780 --> 00:23:31.700
Tabelle möchte ich jetzt ausgerechnet haben,

00:23:31.840 --> 00:23:33.820
was die Summe ist. Genau, genau.

00:23:35.180 --> 00:23:35.880
Also ich habe

00:23:35.880 --> 00:23:37.740
hier die Definition von

00:23:37.740 --> 00:23:39.700
Rob Pike, von dem

00:23:39.700 --> 00:23:41.780
jenigen, der sich da

00:23:41.780 --> 00:23:43.920
mal ausgedacht hat. Und der sagt halt

00:23:43.920 --> 00:23:45.800
Concurrency is about dealing with

00:23:45.800 --> 00:23:47.160
lots of things at once.

00:23:47.880 --> 00:23:49.900
Parallelism is about doing lots of things

00:23:49.900 --> 00:23:51.880
at once. Not the same, but

00:23:51.880 --> 00:23:53.580
related. One is about structure,

00:23:53.840 --> 00:23:55.500
one is about execution.

00:23:55.940 --> 00:23:57.720
Concurrency provides a way to structure

00:23:57.720 --> 00:24:00.020
a solution to solve a problem that may

00:24:00.020 --> 00:24:01.720
but may not necessarily

00:24:01.720 --> 00:24:02.900
be parallelizable.

00:24:03.920 --> 00:24:05.040
Ja, das sagt er erst mal.

00:24:06.440 --> 00:24:07.780
Ich dachte, das hätte ich gerade.

00:24:09.120 --> 00:24:09.820
Nee, das

00:24:09.820 --> 00:24:11.520
fand ich jetzt auch nicht arg erhellend.

00:24:12.040 --> 00:24:12.860
Verdammt, na gut.

00:24:13.600 --> 00:24:15.060
Ja, Parallelität ist halt

00:24:15.060 --> 00:24:16.660
Sachen gleichzeitig machen

00:24:16.660 --> 00:24:19.500
und Concurrency ist verschiedene Sachen

00:24:19.500 --> 00:24:21.640
machen. Das ist so, wie es in meinem

00:24:21.640 --> 00:24:23.520
Kopf ist. Ja, eine Erklärung, die ich mal gehört

00:24:23.520 --> 00:24:24.800
habe, vielleicht ist die besser,

00:24:25.460 --> 00:24:26.980
vielleicht einfach mal ein paar durchprobieren,

00:24:27.840 --> 00:24:29.320
ist, dass halt sozusagen

00:24:29.320 --> 00:24:31.420
ein Bartender

00:24:31.420 --> 00:24:33.480
kann irgendwie viele Kunden

00:24:33.480 --> 00:24:35.640
concurrent

00:24:35.640 --> 00:24:37.560
behandeln, sozusagen, oder wenn ein Bartender

00:24:37.560 --> 00:24:38.660
viele Kunden hat,

00:24:39.380 --> 00:24:41.440
die er mit

00:24:41.440 --> 00:24:43.400
Drinks beschickt, dann

00:24:43.400 --> 00:24:45.460
ist das irgendwie Concurrency, aber

00:24:45.460 --> 00:24:47.500
wenn du mehrere Drinks gleichzeitig machen willst, brauchst du mehrere

00:24:47.500 --> 00:24:48.740
Bartender. Da reicht einer nicht.

00:24:50.260 --> 00:24:51.740
Und das wäre dann Parallelität, sozusagen.

00:24:54.440 --> 00:24:55.360
Ja, also mehr

00:24:55.360 --> 00:24:56.260
Arme für den Barkeeper.

00:24:56.880 --> 00:24:58.100
In meinem Kopf

00:24:58.100 --> 00:25:00.740
geht es

00:25:00.740 --> 00:25:03.580
bei mir ganz viel um das Wort gleichzeitig.

00:25:04.220 --> 00:25:04.940
Parallelität heißt

00:25:05.010 --> 00:25:06.970
du machst mehrere Sachen gleichzeitig.

00:25:08.310 --> 00:25:08.750
Und

00:25:08.750 --> 00:25:11.030
Nebenläufigkeit oder Concurrency heißt,

00:25:11.130 --> 00:25:12.270
du machst mehrere Sachen

00:25:12.270 --> 00:25:14.850
nebeneinander her. Also nicht an einem

00:25:14.850 --> 00:25:17.030
abschließenden Schritt erstmal den einen Drink mixen,

00:25:17.310 --> 00:25:19.050
sondern fünf Gläser hinstellen und jedes Mal

00:25:19.050 --> 00:25:20.890
einmal ein bisschen Zitrone rein und dann ein bisschen

00:25:20.890 --> 00:25:22.850
Drink. Genau, genau. Also du hast

00:25:22.850 --> 00:25:25.110
fünf Drinks, die du zubereiten musst und du machst

00:25:25.110 --> 00:25:27.070
halt die Schritte von denen und du machst erstmal was

00:25:27.070 --> 00:25:28.790
an dem Drink eins, dann machst du was an dem Drink zwei,

00:25:28.890 --> 00:25:29.850
dann machst du was an dem Drink drei.

00:25:29.950 --> 00:25:33.050
Die Gesamtzeit ist

00:25:33.050 --> 00:25:34.950
dann ja genau dieselbe, als würdest du fünf einzeln

00:25:34.950 --> 00:25:36.910
machen, nur du hast halt dann fünf

00:25:36.910 --> 00:25:38.730
gleichzeitig rausgeschickt und alle haben quasi

00:25:38.730 --> 00:25:40.850
die Zeit gewartet, anstatt dass du jeweils erstmal

00:25:40.850 --> 00:25:42.730
den ersten, den zweiten, den dritten, den vierten, den fünften

00:25:42.730 --> 00:25:44.850
Genau, also du machst eventuell die

00:25:44.850 --> 00:25:46.990
Latenz geringer. Du kannst

00:25:46.990 --> 00:25:48.810
schon mal die Bestellung des Nächsten

00:25:48.810 --> 00:25:50.690
annehmen, während ein Drink noch

00:25:50.690 --> 00:25:52.110
in Bearbeitung ist. Ja, aber dann doch nur die Durchführung.

00:25:52.110 --> 00:25:54.530
Ja, du kannst halt den Nächsten bearbeiten, während einer noch, weiß ich nicht,

00:25:54.610 --> 00:25:56.770
in einem irgendeine fürchterliche chemische

00:25:56.770 --> 00:25:58.370
Reaktion läuft, die halt eine Zeit lang braucht

00:25:58.370 --> 00:26:00.410
und du wartest halt jetzt nicht stumpf davor ab.

00:26:00.410 --> 00:26:02.790
Oder du wartest auf den Assistenten.

00:26:03.030 --> 00:26:04.490
Ja, aber der Erste, der sonst

00:26:04.490 --> 00:26:06.490
seinen Drink sofort bekommen hätte, weil es erst in der Schlange stand,

00:26:06.530 --> 00:26:08.470
der muss jetzt länger warten, weil er die anderen Drinks

00:26:08.470 --> 00:26:09.110
auch nicht hat. Potenziell ja.

00:26:10.470 --> 00:26:12.770
Aber guck mal, wenn da gerade kein Eis da ist,

00:26:13.370 --> 00:26:14.530
dann kannst du ja einen anderen Drink

00:26:14.530 --> 00:26:16.390
machen, während du aufs Eis wartest oder während dir

00:26:16.390 --> 00:26:17.730
jemand was aus dem Lager holt.

00:26:18.730 --> 00:26:20.490
Das merkt der erste Kunde überhaupt

00:26:20.490 --> 00:26:22.290
gar nicht, weil der muss so oder so drauf warten,

00:26:22.390 --> 00:26:23.170
bis sein Eis da ist.

00:26:23.170 --> 00:26:25.150
Ja, aber nur dann kannst du was anderes machen.

00:26:25.210 --> 00:26:26.870
Mit deinen Tasks.

00:26:27.490 --> 00:26:28.890
Ja, genau, wenn du Wartezeiten hast.

00:26:29.470 --> 00:26:31.210
Und dann bemerkt der erste

00:26:31.210 --> 00:26:32.850
Kunde gar nichts. Dann hast du automatisch

00:26:32.850 --> 00:26:34.730
weniger Latenz und

00:26:34.730 --> 00:26:37.030
mehr Durchsatz, weil du Wartezeiten

00:26:37.030 --> 00:26:39.150
nutzen kannst. Und das ist ja eine der großen

00:26:39.150 --> 00:26:40.790
Allüren dieser

00:26:40.790 --> 00:26:42.690
ganzen Geschichte, dass du sagst, okay, ich muss jetzt

00:26:42.690 --> 00:26:44.670
eh auf eine Datenbank warten oder auf

00:26:44.670 --> 00:26:46.730
die Dateien. Ja, also sobald zwei Leute

00:26:46.730 --> 00:26:48.770
da arbeiten, also nicht nur den Barkeeper,

00:26:48.850 --> 00:26:50.750
sondern auch noch die Küche und du möchtest immer einen Drink mit

00:26:50.750 --> 00:26:53.070
Essen servieren oder sowas. Und solange das Essen noch nicht fertig ist,

00:26:53.070 --> 00:26:55.030
dann kannst du alle anderen Drinks schon fertig

00:26:55.030 --> 00:26:57.250
bereiten. Ja, genau. Wenn du Abhängigkeiten

00:26:57.250 --> 00:26:58.990
hast oder wenn du Wartezeiten hast, die kannst du

00:26:58.990 --> 00:27:00.850
überbrücken, indem du da was anderes machst. Und das ist

00:27:00.850 --> 00:27:03.170
Concurrency. Du machst nie Sachen gleichzeitig.

00:27:03.330 --> 00:27:05.070
Du hast, der Bartender kann nie

00:27:05.070 --> 00:27:06.550
mehrere Sachen gleichzeitig machen.

00:27:06.550 --> 00:27:08.230
Dem wachsen keine fünf oder sechs Arme.

00:27:08.770 --> 00:27:10.630
Genau, der hat halt nur einen

00:27:10.630 --> 00:27:11.590
Prozessor.

00:27:12.770 --> 00:27:14.950
Aber der kann mehrere Drinks gleichzeitig zubereiten.

00:27:15.050 --> 00:27:17.010
Das heißt nicht, dass er überall gleichzeitig was reinschüttet,

00:27:17.090 --> 00:27:18.510
aber das heißt halt, dass die alle

00:27:18.510 --> 00:27:21.190
zu einem gleichen Zeitraum in Bearbeitung

00:27:21.190 --> 00:27:22.910
sind. Genau wie der Jochen sagt, wenn

00:27:22.910 --> 00:27:24.970
du fünfmal so viele Drinks

00:27:24.970 --> 00:27:26.610
machen willst, brauchst du halt mehr Bartender.

00:27:26.610 --> 00:27:28.510
Und die sind dann auch erstmal unabhängig

00:27:28.510 --> 00:27:30.490
voneinander. Es gibt jetzt leider keine

00:27:30.490 --> 00:27:31.550
Simdi-Bartender, die

00:27:31.550 --> 00:27:34.450
mehrere Sachen

00:27:34.450 --> 00:27:36.230
identisch gleich machen können, dann

00:27:36.230 --> 00:27:38.550
könntest du fünf identische Drinks

00:27:38.550 --> 00:27:39.790
gleichzeitig zubereiten.

00:27:40.950 --> 00:27:41.790
Da wüsste ich jetzt keine

00:27:41.790 --> 00:27:44.550
Analogie in der

00:27:44.550 --> 00:27:45.150
echten Welt.

00:27:46.810 --> 00:27:48.450
Async ist jetzt Parallelität

00:27:48.450 --> 00:27:50.170
oder Concurrency?

00:27:50.250 --> 00:27:52.050
Ich würde sagen, dieses Problem Parallelität

00:27:52.050 --> 00:27:54.450
ist, also dass du

00:27:54.450 --> 00:27:55.890
beides gleichzeitig brauchst,

00:27:56.210 --> 00:27:57.690
das wäre jetzt mal eine steile These,

00:27:58.390 --> 00:28:00.310
ich meine, ich weiß jetzt auch wieder, wann wir das schon mal hatten

00:28:00.310 --> 00:28:09.070
Und ich glaube, das war tatsächlich in der ersten Sendung, wo ich halt auch meinte, so eigentlich diesen Fall, dass man beides hat, dass man Concurrency braucht und Parallelität, den hat man fast nie.

00:28:09.610 --> 00:28:13.290
Also, oder mir fällt es schwer, mir dafür einen Use Case auszudenken.

00:28:13.390 --> 00:28:21.130
Die anderen Fälle hat man, dass man viel Concurrency braucht, hat man, dass man viel Parallelität braucht, hat man, aber beides zusammen.

00:28:21.390 --> 00:28:22.910
Ja, also ich kann mir jetzt viele Sachen vorstellen.

00:28:23.050 --> 00:28:27.190
Also wenn ich jetzt beispielsweise vorstelle, autonomes Fahren oder Sport oder sowas.

00:28:27.190 --> 00:28:29.230
und gleichzeitig fahren bestimmte Menschen

00:28:29.230 --> 00:28:30.610
übers Eis oder sowas.

00:28:31.850 --> 00:28:33.610
Und da musst du prognostizieren,

00:28:33.690 --> 00:28:35.310
was dann passiert. Das ist echt parallel

00:28:35.310 --> 00:28:36.210
für jeden Einzelnen.

00:28:36.830 --> 00:28:38.170
Ja, aber das ist nicht concurrent.

00:28:38.590 --> 00:28:40.390
Du machst das Auto fahren gleichzeitig.

00:28:41.230 --> 00:28:43.110
Nein, es fahren alle gleichzeitig und alle müssen gleichzeitig

00:28:43.110 --> 00:28:44.970
darauf reagieren. Und du möchtest ja für alle

00:28:44.970 --> 00:28:46.370
gleichzeitig irgendwie Werte haben.

00:28:46.370 --> 00:28:47.770
Du möchtest dann das ganze Team.

00:28:47.930 --> 00:28:49.470
Das verstehe ich nicht. Tut mir leid.

00:28:50.170 --> 00:28:51.750
Also du hast mehrere Fahrzeuge.

00:28:52.810 --> 00:28:54.510
Du hast so einen Rechner, auf den mehrere

00:28:54.510 --> 00:28:55.630
Fahrzeuge fahren? Das verstehe ich nicht.

00:28:55.670 --> 00:28:57.370
Genau, du hast die ganze Flotte, die du steuerst.

00:28:58.090 --> 00:28:58.970
Ja, aber die sind ja unabhängig.

00:28:58.990 --> 00:29:01.650
Also ich würde sagen, das ist ein Anwendungsfall,

00:29:01.710 --> 00:29:03.350
den kenne ich so nicht. Aber du hast ein gegnerisches Team

00:29:03.350 --> 00:29:05.470
und das ist halt nicht unter deiner Kontrolle und du möchtest

00:29:05.470 --> 00:29:07.270
dann trotzdem alle deine Leute,

00:29:07.410 --> 00:29:09.330
deren Informationen du dann halt gerade erst

00:29:09.330 --> 00:29:11.370
live einlesen kannst,

00:29:11.830 --> 00:29:13.490
dazu bringen, dass sie parallel

00:29:13.490 --> 00:29:15.010
die Entscheidung treffen,

00:29:15.370 --> 00:29:16.950
die vernünftig,

00:29:17.350 --> 00:29:19.430
statistisch wahrscheinlich ja zu besseren

00:29:19.430 --> 00:29:20.390
Ergebnissen funktionieren, irgendwie so.

00:29:21.290 --> 00:29:22.550
Der Dominik überspringt

00:29:22.550 --> 00:29:23.450
so die simplen Schritte.

00:29:24.550 --> 00:29:27.470
selber fahren können müssen, der macht direkt

00:29:27.470 --> 00:29:29.390
komplett. Ne, tut mir leid, das würde ich sagen,

00:29:29.450 --> 00:29:30.390
das ist kein Newscase.

00:29:31.290 --> 00:29:32.890
Vielleicht doch. Da wüsste ich jetzt auch nicht.

00:29:34.550 --> 00:29:35.150
Ne, aber

00:29:35.150 --> 00:29:37.710
wir können ja direkt mal zu einem

00:29:37.710 --> 00:29:39.290
super guten Newscase zurückgehen und der heißt

00:29:39.290 --> 00:29:41.430
EVE Online. Da sind ganz viele Spieler,

00:29:41.430 --> 00:29:43.630
die gleichzeitig Sachen machen wollen

00:29:43.630 --> 00:29:45.510
und du hast aber trotzdem die große

00:29:45.510 --> 00:29:47.530
Statustabelle auf dem Server, die du die ganze Zeit

00:29:47.530 --> 00:29:49.310
aktualisieren musst und das musst du parallel machen.

00:29:49.890 --> 00:29:51.450
Also ich meine, die Lösung, die EVE Online

00:29:51.450 --> 00:29:53.230
dafür hat, ist halt, dass sie es langsamer machen.

00:29:53.470 --> 00:29:54.430
Habt ihr EVE Online mal gespielt?

00:29:54.550 --> 00:29:57.230
Nee, nur ganz viel drüber gelesen.

00:29:57.430 --> 00:29:59.210
Oh, ich habe es tatsächlich auch mal ausprobiert.

00:29:59.730 --> 00:30:00.770
Ich muss gestehen, ich war nicht in den Gruppen.

00:30:00.770 --> 00:30:01.170
So viel Zeit habe ich nicht.

00:30:01.490 --> 00:30:03.410
Ja, das habe ich auch nicht geschafft.

00:30:03.610 --> 00:30:04.830
Aber es gab tatsächlich tolle Schlachten.

00:30:05.070 --> 00:30:06.350
Also man hat dann so Schlachten gehabt,

00:30:06.510 --> 00:30:08.450
wo dann so 20.000, 30.000 Schiffe verloren gegangen sind.

00:30:08.810 --> 00:30:09.890
Und man konnte da ein Business draus machen,

00:30:09.990 --> 00:30:11.190
weil da konnte man die Schiffe kaufen.

00:30:11.270 --> 00:30:12.590
Das war richtig Geld, was da vernichtet wurde.

00:30:12.650 --> 00:30:13.470
Ich glaube, in der größten Schlacht

00:30:13.470 --> 00:30:16.630
wurden mehrere Millionen Dollar an virtuellem Kapital vernichtet,

00:30:16.750 --> 00:30:19.330
gleichzeitig, weil man irgendwelche Sprungtouren blockiert hat

00:30:19.330 --> 00:30:20.830
mit riesigen Flotten an Schiffen

00:30:20.830 --> 00:30:22.510
und alles in die Luft gesprengt hat,

00:30:22.550 --> 00:30:24.130
was dann ja nie zu finden war.

00:30:24.150 --> 00:30:25.710
Ja, das ist das Geschäftsmodell von EVE Online, oder?

00:30:26.230 --> 00:30:26.410
Ja.

00:30:26.790 --> 00:30:29.170
Du kannst virtuelle Güter kaufen und sie dann verbrennen.

00:30:29.210 --> 00:30:30.930
Ja, und du kannst sogar tatsächlich aber in diesem Spiel

00:30:30.930 --> 00:30:32.910
konntest du halt Echtgelddinger generieren,

00:30:32.970 --> 00:30:33.750
die du halt verkauft hast.

00:30:33.850 --> 00:30:34.910
Und wenn du halt ein Wirtschaftsunternehmen,

00:30:35.010 --> 00:30:36.210
Imperium, in diesem Spiel aufgebaut hast.

00:30:36.570 --> 00:30:39.190
Es gab eine Leute, ich glaube, die haben über 20.000 Dollar

00:30:39.190 --> 00:30:40.210
oder sowas im Monat gemacht,

00:30:40.310 --> 00:30:42.870
indem die für EVE Online Businesses gebaut haben,

00:30:42.910 --> 00:30:45.650
die sie da durch die Dachen geschleust haben.

00:30:45.690 --> 00:30:46.870
Und wenn du dann halt sowas gemacht hast,

00:30:46.870 --> 00:30:49.630
wie einen Krieg zu organisieren zwischen den einzelnen Fraktionen,

00:30:49.670 --> 00:30:50.470
die sich gegenseitig in die Luft sprengen

00:30:50.470 --> 00:30:51.970
und das halt alles auf dieser spielerischen Karte,

00:30:52.050 --> 00:30:53.810
ohne dass das jetzt reale Auswirkungen hätte, also außer

00:30:53.810 --> 00:30:55.770
wirtschaftliche, für die Jungs, die da vor dem

00:30:55.770 --> 00:30:57.870
Rechner saßen, dann war das

00:30:57.870 --> 00:30:59.430
schon irgendwie sehr faszinierende Geschichte.

00:31:00.530 --> 00:31:02.050
Aber guck mal, Jochen, das ist doch

00:31:02.050 --> 00:31:03.630
ein perfektes Beispiel, oder? Du hast ganz viele

00:31:03.630 --> 00:31:05.850
Spieler, die gleichzeitig Sachen machen wollen und

00:31:05.850 --> 00:31:08.130
du musst aber diese Statustabelle,

00:31:08.210 --> 00:31:09.810
das ist parallel. Ja, also ich würde sagen,

00:31:09.810 --> 00:31:12.010
ich bin nicht

00:31:12.010 --> 00:31:13.970
so der Spielexperte, insofern, keine Ahnung,

00:31:14.150 --> 00:31:15.830
aber ich würde jetzt mal sagen, Spiele,

00:31:16.350 --> 00:31:17.910
die sind alle nur concurrent, da brauchst

00:31:17.910 --> 00:31:19.470
du nichts parallel. Wenn ich jetzt so gegenseitig

00:31:19.470 --> 00:31:21.870
spiele, ein ganz klassisches Killerspiel,

00:31:21.990 --> 00:31:23.770
Ja, und wir schießen beide gleichzeitig aufeinander.

00:31:24.070 --> 00:31:25.770
Aber wo brauchen die denn, wo brauchen die Spiele

00:31:25.770 --> 00:31:26.550
denn bitte CPU?

00:31:27.110 --> 00:31:28.210
Die brauchen überhaupt gar keine CPU.

00:31:28.750 --> 00:31:31.630
Die Spiele heutzutage

00:31:31.630 --> 00:31:33.650
laufen nicht mehr auf dem Client, sondern die laufen komplett

00:31:33.650 --> 00:31:35.770
auf dem Server. Ja, selbst wenn die komplett auf dem Server laufen,

00:31:35.910 --> 00:31:36.990
wo brauchen die denn CPU?

00:31:37.490 --> 00:31:39.590
Diese vorher genannte

00:31:39.590 --> 00:31:41.670
Battle, die der Dominik genannt hat,

00:31:41.730 --> 00:31:43.250
wo dann 30.000 Leute teilnehmen.

00:31:43.510 --> 00:31:45.450
Der Trick an der Sache, warum das funktioniert,

00:31:45.450 --> 00:31:47.210
ist, dass die den Timestamp runterdrehen.

00:31:47.310 --> 00:31:49.370
Das heißt, in so einer Zone, wo viele

00:31:49.370 --> 00:31:51.010
Leute gleichzeitig sind,

00:31:51.510 --> 00:32:02.930
Die müssen auf einem Server sein, damit diese Zone kohärent ist. Wenn da zu viele Leute sind, dann tun die so, als ob die Zeit langsamer läuft, weil der Rechner ausgelastet ist.

00:32:03.410 --> 00:32:16.650
Und wenn die diese Status-Updates parallel abarbeiten könnten auf einem Rechner, dann müssten sie das nicht machen. Die gehen ganz, ganz hart ans Limit, weil die Simulation auf dem Server passiert.

00:32:16.650 --> 00:32:19.270
zum Teil passiert die Physik-Simulation

00:32:19.270 --> 00:32:20.910
auf dem Server. Das ist im Wesentlichen

00:32:20.910 --> 00:32:21.210
der Grund.

00:32:22.790 --> 00:32:24.710
Man hört ganz oft, dass

00:32:24.710 --> 00:32:26.790
so und so viele Millionen Leute gleichzeitig in Fortnite

00:32:26.790 --> 00:32:28.750
sind. Aber das stimmt nicht. Es sind nur

00:32:28.750 --> 00:32:30.730
höchstens 50 auf einer

00:32:30.730 --> 00:32:32.030
Instanz. Jetzt

00:32:32.030 --> 00:32:34.590
gab es so Events, wo 10 Millionen Leute

00:32:34.590 --> 00:32:35.910
bei so einem Konzert dabei waren.

00:32:36.390 --> 00:32:39.030
Das ist ein kleines bisschen gelungen. Das waren 250.000

00:32:39.030 --> 00:32:40.650
Instanzen mit

00:32:40.650 --> 00:32:42.490
jeweils maximal 50 Leuten, weil da

00:32:42.490 --> 00:32:44.570
einfach die Auslastung,

00:32:44.970 --> 00:32:45.730
da ist der Prozessor voll.

00:32:46.470 --> 00:32:51.910
Und da ist Parallelität einfach ...

00:32:51.910 --> 00:32:52.130
Okay.

00:32:52.370 --> 00:32:54.070
Je mehr Parallelität du nutzen kannst,

00:32:54.170 --> 00:32:55.910
umso höher kannst du diese Zahl setzen.

00:32:56.570 --> 00:32:58.050
Und umso weniger Instanzen brauchst du.

00:32:58.110 --> 00:33:00.390
Und das ist richtig, da ist Geld drin und da ist richtig ...

00:33:00.390 --> 00:33:02.550
Okay, vielleicht weiß ich einfach noch nicht gut genug,

00:33:02.630 --> 00:33:03.910
wie Spiele funktionieren,

00:33:04.270 --> 00:33:05.550
dass ich mir gar nicht so richtig vorstellen kann,

00:33:05.630 --> 00:33:06.410
warum die jetzt CPU brauchen.

00:33:06.430 --> 00:33:07.790
Also die Frage ist halt, wo ist da der Flaschenhalt?

00:33:07.830 --> 00:33:08.970
Ist der Flaschenhalt tatsächlich CPU?

00:33:09.110 --> 00:33:10.530
Das ist dann irgendwie sowas wie Netzwerk.

00:33:10.650 --> 00:33:12.250
Ich glaube eher Concurrency und Netzwerk, ja.

00:33:12.250 --> 00:33:13.730
Da müsste man Peer-to-Peer vielleicht machen.

00:33:13.810 --> 00:33:14.550
Das würde vielleicht schneller gehen,

00:33:14.610 --> 00:33:15.910
wenn man das irgendwie über Peers verteilt,

00:33:15.990 --> 00:33:17.650
als dass man irgendwie alles durch einen Hals schickt.

00:33:18.370 --> 00:33:19.690
Bei allen Leuten irgendwie so ein bisschen was weitergeht.

00:33:19.690 --> 00:33:20.770
Da gibt es sicher viele Flaschenhälse.

00:33:20.970 --> 00:33:24.530
Ich glaube, da ist alles, das ist so ein blödes Problem.

00:33:24.630 --> 00:33:27.150
Wenn du ein Problem gelöst hast, dann kommt direkt das Nächste.

00:33:27.210 --> 00:33:28.450
Wenn du einen Kopf abgeschlagen hast,

00:33:28.510 --> 00:33:29.410
wachsen direkt vier neuere.

00:33:30.330 --> 00:33:33.270
Aber CPU ist da einfach einer der Faktoren.

00:33:33.830 --> 00:33:34.990
Vielleicht ist es bei Spielen so.

00:33:35.130 --> 00:33:37.630
Ich kann es noch nicht so richtig nachvollziehen, aber okay.

00:33:37.970 --> 00:33:39.570
Also ich meine, mir fällt auch ein Beispiel ein,

00:33:39.630 --> 00:33:40.430
und das sind halt Datenbanken.

00:33:40.510 --> 00:33:41.270
Da hast du nämlich auch beides.

00:33:41.270 --> 00:33:42.990
Da hast du halt sowohl I.O.,

00:33:42.990 --> 00:33:45.630
du hast halt, weiß ich nicht, 30.000, 40.000 Requests pro Sekunde,

00:33:45.990 --> 00:33:47.470
Und die machen alle CPU.

00:33:47.730 --> 00:33:49.090
Die machen alle irgendwie

00:33:49.090 --> 00:33:51.370
Geschichten in irgendwelchen

00:33:51.370 --> 00:33:53.170
Biotrees irgendwie durchsuchen,

00:33:53.450 --> 00:33:54.410
irgendwelche Indizes

00:33:54.410 --> 00:33:56.170
abgleichen,

00:33:57.450 --> 00:33:59.050
ja, Hashes ausrechnen. Und je mehr

00:33:59.050 --> 00:34:00.390
du gleichzeitig machen kannst, umso besser.

00:34:01.130 --> 00:34:03.050
Genau. Also an der Stelle würde ich sagen, also Datenbank-Server

00:34:03.050 --> 00:34:04.990
und Python schreiben, vielleicht nicht die beste Idee, weil das

00:34:04.990 --> 00:34:07.050
wird schwierig. Aber... Wie ist es mit

00:34:07.050 --> 00:34:09.010
Videostreaming? Auch das ist sowas, wo...

00:34:09.010 --> 00:34:11.090
Würde ich sagen, komplett concurrent. Da gibt es nichts,

00:34:11.190 --> 00:34:12.270
was irgendwie CPU braucht. Nein, überhaupt nicht.

00:34:13.110 --> 00:34:14.990
Na klar. Also außer du kodierst irgendwie

00:34:14.990 --> 00:34:16.890
um, aber ansonsten. Ja, und zwar, und musst

00:34:16.890 --> 00:34:18.850
du. Du musst die Sachen umkodieren.

00:34:19.350 --> 00:34:20.610
Dann. Jeder, jeder,

00:34:20.750 --> 00:34:23.190
jeder moderne Streaming-Dienst,

00:34:23.350 --> 00:34:24.630
also wir sind jetzt hier auf Whereby,

00:34:25.190 --> 00:34:26.950
aber wenn du auf BBB gehst oder auf

00:34:26.950 --> 00:34:28.510
Zoom oder auf sonst was, die kodieren alles um.

00:34:28.930 --> 00:34:29.290
Tatsächlich

00:34:29.290 --> 00:34:32.930
machen die Größenskalierungen,

00:34:33.430 --> 00:34:34.730
damit die Clients mit

00:34:34.730 --> 00:34:36.690
unterschiedlichen Bitraten versorgen können.

00:34:36.690 --> 00:34:38.550
Und das kannst du entweder auf dem Client machen, was

00:34:38.550 --> 00:34:40.530
nicht super zuverlässig ist, weil die Clients

00:34:40.530 --> 00:34:41.930
halt auch Mobilgeräte sein können.

00:34:42.590 --> 00:34:44.790
Du machst auf dem Server und dann bist du ganz knallhart

00:34:44.790 --> 00:34:47.730
Ja, aber da würde ich sagen, da bist du doch sowieso schon

00:34:47.730 --> 00:34:49.650
da ist der Flaschenhals auch wieder woanders, weil

00:34:49.650 --> 00:34:51.270
dadurch, dass du

00:34:51.270 --> 00:34:53.570
dass die einzelnen Clients, die du

00:34:53.570 --> 00:34:54.810
dran hast, so fett sind

00:34:54.810 --> 00:34:57.590
macht es doch überhaupt nichts, wenn du pro Verbindung

00:34:57.590 --> 00:34:59.410
dann halt was Fettes aufmachst, wie ein Prozess oder so

00:34:59.410 --> 00:35:01.830
Ja klar, aber du hast auf jeden Fall

00:35:01.830 --> 00:35:03.010
Parallelität, du musst auf jeden Fall

00:35:03.010 --> 00:35:04.570
diese 8 Streams

00:35:04.570 --> 00:35:07.510
Das ist auch bei dem Spiel, wenn du sagst, es gehen nur 50 Leute

00:35:07.510 --> 00:35:09.430
auf eine Instanz oder es gehen nur 50 Streams

00:35:09.430 --> 00:35:10.930
über einen Rechner, dann machst du halt für die

00:35:10.930 --> 00:35:13.190
50 Prozesse auf, gar kein Problem, geht das auch mit

00:35:13.190 --> 00:35:15.430
Ja klar, aber das ist dann schon Parallelität.

00:35:15.610 --> 00:35:17.590
Also du machst schon viele Sachen gleichzeitig.

00:35:18.490 --> 00:35:18.870
Ja, aber

00:35:18.870 --> 00:35:20.730
ein Fall, nach dem ich suche, ist,

00:35:21.210 --> 00:35:23.010
wo du ganz, ganz viel Concurrency hast,

00:35:23.090 --> 00:35:25.350
so viel, dass du das mit Prozessen nicht erschlagen kannst,

00:35:25.570 --> 00:35:26.990
weil es zu viele sind. Also sagen wir mal,

00:35:26.990 --> 00:35:28.350
du hast 10.000 Verbindungen gleichzeitig.

00:35:29.390 --> 00:35:31.470
Aber das kannst du ja bei einem Webserver locker mal haben.

00:35:31.990 --> 00:35:33.130
Ja, natürlich, genau. Also du hast

00:35:33.130 --> 00:35:35.030
10.000 gleichzeitig, die auch gleichzeitig aktiv sind.

00:35:35.130 --> 00:35:37.150
Nicht nur einfach eine Verbindung, die rumliegt, sondern tatsächlich

00:35:37.150 --> 00:35:38.410
aktiv, über die irgendwas drüber geht.

00:35:39.410 --> 00:35:40.710
Wenn du das Problem hast,

00:35:41.010 --> 00:35:43.070
plus irgendwie CPU, dann kannst du es vergessen.

00:35:43.190 --> 00:35:45.150
kriegst du es mit Python nicht mehr hin, weil Prozesse kannst du dann

00:35:45.150 --> 00:35:47.190
nicht mehr nehmen. Ich glaube, du hast das ausprobiert.

00:35:47.250 --> 00:35:49.090
Hast du mal so eine Story erzählt auf deinem Mac und

00:35:49.090 --> 00:35:50.990
hast Kernelpanik verursacht. Kann das sein?

00:35:51.470 --> 00:35:53.010
Ja, das habe ich jetzt im Zug.

00:35:53.130 --> 00:35:55.130
Aber das waren Threads tatsächlich, keine Prozesse.

00:35:55.350 --> 00:35:57.230
Also mit Prozessen wird das gar nicht gehen. 10.000 Prozesse

00:35:57.230 --> 00:35:58.510
ist nicht möglich. Aber

00:35:58.510 --> 00:36:01.150
Threads sollten eigentlich möglich

00:36:01.150 --> 00:36:01.390
sein.

00:36:03.470 --> 00:36:05.110
Nicht auf dem Mac. Und ich habe es

00:36:05.110 --> 00:36:06.710
tatsächlich dann auch mal auf einem anderen ausprobiert,

00:36:06.810 --> 00:36:09.110
um auszuschließen, dass irgendwie meine Hardware leicht defekt

00:36:09.110 --> 00:36:11.070
ist oder so. Nö, auf Catalina

00:36:11.070 --> 00:36:13.010
macht das halt sofort Kernelpanik, wenn man 10.000

00:36:13.010 --> 00:36:15.070
Threads aufmacht. Also die

00:36:15.070 --> 00:36:16.710
Lüfter gehen kurz an und dann ist der Rechner aus.

00:36:17.230 --> 00:36:18.890
Ich habe da tatsächlich auch einen Bug bei Apple

00:36:18.890 --> 00:36:20.930
aufgemacht. Das geht ja so nicht.

00:36:22.990 --> 00:36:24.930
Ja gut, aber ich meine, wenn man da in die

00:36:24.930 --> 00:36:26.850
Ecken und Kanten geht. Also ich habe auch schon mal

00:36:26.850 --> 00:36:28.970
mein Mac mit einem Programm abgeschützt, was nur

00:36:28.970 --> 00:36:30.850
das Clipboard

00:36:30.850 --> 00:36:31.610
ausgelesen hat.

00:36:33.230 --> 00:36:34.230
Ja, es ist

00:36:34.230 --> 00:36:36.630
ein großes Kartenhaus.

00:36:37.290 --> 00:36:38.230
Ein großes Kartenhaus.

00:36:39.310 --> 00:36:40.930
Ja, tatsächlich. Ich habe es dann

00:36:40.930 --> 00:36:42.830
jetzt auch nochmal auf Linux probiert und so und da

00:36:42.830 --> 00:36:44.430
geht es problemlos, gar kein Ding.

00:36:46.110 --> 00:36:47.130
Ja gut, aber so eine Situation

00:36:47.130 --> 00:36:48.810
wurde 10.000 Threads.

00:36:48.850 --> 00:36:50.470
Also ich meine, das ist dieses

00:36:50.470 --> 00:36:52.850
berühmte C10K-Problem.

00:36:53.390 --> 00:36:54.890
Wie schaffst du es, einen Web-Server

00:36:54.890 --> 00:36:56.770
zu machen, der 10.000 Clients

00:36:56.770 --> 00:36:59.050
gleichzeitig benutzen, bedienen

00:36:59.050 --> 00:37:00.910
kann? Und wenn du

00:37:00.910 --> 00:37:02.250
das hinkriegst, ist es besser.

00:37:03.070 --> 00:37:04.250
Weil dann hast du weniger Web-Server.

00:37:04.250 --> 00:37:06.630
Aber dafür würde ich sagen, brauchst du eben keine CPU, sondern das ist rein

00:37:06.630 --> 00:37:08.930
Concurrency und das geht

00:37:08.930 --> 00:37:10.590
problemlos mit einem Prozess

00:37:10.590 --> 00:37:12.470
und einer zu bringen. Aber ich finde

00:37:12.470 --> 00:37:14.710
bestimmt irgendeine Workload, wo du noch was berechnen musst.

00:37:14.850 --> 00:37:16.270
Wo du noch, keine Ahnung, Bilder skalieren musst.

00:37:16.350 --> 00:37:18.310
Ich glaube auch. Ich glaube, dass es sowas tatsächlich gibt.

00:37:18.670 --> 00:37:20.510
Aber es ist so einfach, dass man

00:37:20.510 --> 00:37:22.390
sagt, also ich kenne das ja dann immer so,

00:37:22.930 --> 00:37:24.430
dass Leute sagen, das ist ja gar keine richtige

00:37:24.430 --> 00:37:26.370
Problemgespräche. Aber ich meine, wer hat solche Probleme?

00:37:26.650 --> 00:37:28.610
Also ich hatte sowas

00:37:28.610 --> 00:37:29.490
ehrlich gesagt noch nie.

00:37:30.150 --> 00:37:31.530
Und ich habe schon eine Menge Zwergs gesehen.

00:37:33.410 --> 00:37:34.510
Bei mir war es entweder

00:37:34.510 --> 00:37:35.850
Vielleicht ist es einfach so,

00:37:36.050 --> 00:37:38.790
ich glaube, da ist so ein bisschen

00:37:38.790 --> 00:37:40.010
Selection Bias auch drin, oder?

00:37:40.210 --> 00:37:41.050
Gut, kann auch sein, ja.

00:37:41.070 --> 00:37:42.350
Klar, wir haben auch schon viele Sachen gesehen,

00:37:42.470 --> 00:37:43.890
aber wir sind halt in Python unterwegs

00:37:43.890 --> 00:37:45.650
und wir sehen nur solche Sachen, die es in Python gibt.

00:37:46.050 --> 00:37:47.850
Ja, ja, ja, das mag sein.

00:37:48.050 --> 00:37:50.450
Das kann durchaus, ja.

00:37:50.710 --> 00:37:51.330
Ja gut, wie auch immer.

00:37:51.770 --> 00:37:54.490
Wie auch immer, aber genau, diese Parallelität-Ding,

00:37:54.590 --> 00:37:55.910
also wenn man beides braucht, ist halt schlecht.

00:37:56.010 --> 00:37:57.110
Das ist nach wie vor nicht gut in Python.

00:37:57.730 --> 00:38:00.650
Aber sagen wir mal so, dieser Concurrency-Use-Case,

00:38:00.950 --> 00:38:02.190
für den es ja tatsächlich auch Anwendungen gibt

00:38:02.190 --> 00:38:04.390
und ich meine, Node.js ist einer der Gründe,

00:38:04.490 --> 00:38:06.550
warum Node.js so populär ist,

00:38:06.630 --> 00:38:09.370
ist halt, dass es damit besser ging.

00:38:10.210 --> 00:38:12.330
oder dafür halt besser benutzt wurde,

00:38:12.570 --> 00:38:14.190
äh, besser benutzbar war, äh,

00:38:14.470 --> 00:38:16.730
und, ähm, ja, äh.

00:38:17.110 --> 00:38:18.670
Ja, auch ein besseres Programmiermodell

00:38:18.670 --> 00:38:20.390
hat, oder? Also dieses,

00:38:21.050 --> 00:38:21.490
ähm,

00:38:21.990 --> 00:38:24.370
Promisers und Futures und so weiter, das,

00:38:24.610 --> 00:38:26.370
ja, das ist alles schon sehr einfach.

00:38:26.970 --> 00:38:28.450
Ja, aber das ist eigentlich alles, äh,

00:38:28.450 --> 00:38:29.790
sozusagen, das gibt's halt in Python ja auch.

00:38:31.930 --> 00:38:32.330
Ähm.

00:38:32.470 --> 00:38:34.190
Ja. Was, was gibt's denn da in Python?

00:38:34.190 --> 00:38:36.630
Gibt's schon, aber. Kannst du das kurz beschreiben?

00:38:38.590 --> 00:38:40.370
Ja, also gut, okay.

00:38:40.610 --> 00:38:42.170
Also wenn wir jetzt schon

00:38:42.170 --> 00:38:44.430
im Grunde wissen, okay, wir wollen das

00:38:44.430 --> 00:38:46.510
eigentlich schon haben und das ist schon cool und das kann ja

00:38:46.510 --> 00:38:48.250
wohl nicht sein, dass ich jetzt Node.js lernen muss, nur

00:38:48.250 --> 00:38:50.530
irgendwie, um immer noch

00:38:50.530 --> 00:38:51.070
hip zu sein,

00:38:52.750 --> 00:38:54.470
dann kann man sich ja,

00:38:54.590 --> 00:38:56.410
genau, kann man so, okay, wie macht Node.js das denn

00:38:56.410 --> 00:38:58.410
eigentlich, weil Node.js hat

00:38:58.410 --> 00:39:00.330
die gleichen Beschränkungen im Grunde, ist sehr vergleichbar

00:39:00.330 --> 00:39:02.570
zu Python, hat die gleichen Beschränkungen,

00:39:02.570 --> 00:39:04.250
da gibt es auch in GIL,

00:39:04.510 --> 00:39:06.510
ja, ganz genauso wie in Ruby on Rails

00:39:06.510 --> 00:39:08.450
und sonst irgendwie in PHP

00:39:08.450 --> 00:39:10.190
Die ganzen Skript-Sprachen machen das ja alle.

00:39:10.210 --> 00:39:12.370
Die machen das alle so, weil es halt auch sinnvoll ist.

00:39:13.490 --> 00:39:14.430
Ja, und weil es halt

00:39:14.430 --> 00:39:16.230
auch single-threaded die Performance, also wenn du

00:39:16.230 --> 00:39:18.330
kein Multiprocessing brauchst, also wenn

00:39:18.330 --> 00:39:20.270
du keine Parallelität brauchst und

00:39:20.270 --> 00:39:21.970
keine Concurrency, dann ist es halt das Schnellste.

00:39:24.470 --> 00:39:26.270
Ja, genau. Und was

00:39:26.270 --> 00:39:27.750
Node.js macht, ist halt,

00:39:28.350 --> 00:39:29.930
sie haben halt eine Event-Loop und

00:39:29.930 --> 00:39:32.230
ja,

00:39:32.530 --> 00:39:34.210
dann kann man halt

00:39:34.210 --> 00:39:35.090
sozusagen

00:39:35.090 --> 00:39:37.950
Callbacks auf dieser Event-Loop, oder sagen wir so,

00:39:37.990 --> 00:39:39.510
das ist halt das, was ganz früher schon immer,

00:39:39.650 --> 00:39:41.830
ich glaube, das ist schon immer möglich, irgendwie, man kann halt Callbacks

00:39:41.830 --> 00:39:43.670
auf dieser Event-Loop registrieren, oder?

00:39:44.590 --> 00:39:45.770
Ja, Callbacks sind ja was Schreckliches,

00:39:45.870 --> 00:39:47.970
das ist doch die Callback-Hell. Genau, ja.

00:39:47.970 --> 00:39:49.790
Gar keine richtige, gar keine lineare

00:39:49.790 --> 00:39:52.030
Programmierung mehr. Hast du was gesagt? Hatte ich irgendwas gesagt?

00:39:52.150 --> 00:39:53.690
Vielleicht gab es da irgendjemand, der hat was gesagt, der wollte,

00:39:53.790 --> 00:39:55.770
er wartet noch auf irgendwas. Wie heißt denn das? Wie muss ich

00:39:55.770 --> 00:39:57.850
dann da fragen, wenn ich das wissen will? Ach, Moment,

00:39:57.910 --> 00:39:59.810
da steht jemand, der hat da rumgegangen, ach nee, da war noch

00:39:59.810 --> 00:40:01.670
jemand anders. Ach, Moment, da war noch jemand,

00:40:01.790 --> 00:40:03.850
der hat aber was gesagt, was dann irgendwie, ach, Callback,

00:40:03.950 --> 00:40:05.830
ach so, da hinten, ach nee, da unten, ah, oh.

00:40:07.990 --> 00:40:09.950
kriegst du ja immer. Das Problem ist, dass dein Programm

00:40:09.950 --> 00:40:12.010
dann auch so aussieht, weil du die Callbacks

00:40:12.010 --> 00:40:14.090
quasi in der falschen Reihenfolge definieren

00:40:14.090 --> 00:40:16.030
musst. Du kannst nicht sagen, erst

00:40:16.030 --> 00:40:18.030
A, dann B, dann C, sondern du musst

00:40:18.030 --> 00:40:20.050
erst sagen, erst A und wenn es erfolgreich ist,

00:40:20.110 --> 00:40:21.910
dann B, ansonsten C und wenn

00:40:21.910 --> 00:40:23.850
B erfolgreich ist, dann zwischendurch

00:40:23.850 --> 00:40:25.850
D und E und dann hast du A, B,

00:40:26.030 --> 00:40:27.790
E, F und C

00:40:27.790 --> 00:40:29.910
kommt dann irgendwo ganz anders. Das heißt, du hast dein

00:40:29.910 --> 00:40:31.790
Programm nicht mehr, kannst es nicht mehr

00:40:31.790 --> 00:40:33.190
von oben nach unten lesen,

00:40:33.310 --> 00:40:35.870
sondern du musst es so gemixt

00:40:35.870 --> 00:40:37.870
lesen und das ist ganz, ganz, ganz blöd

00:40:37.870 --> 00:40:39.810
zu programmieren. Und deshalb hat JavaScript dann

00:40:39.810 --> 00:40:41.690
irgendwann diese Promises und Futures eingeführt,

00:40:42.650 --> 00:40:43.830
wo du einfach sagen kannst,

00:40:44.430 --> 00:40:45.990
da kommt jetzt was zurück,

00:40:46.650 --> 00:40:47.770
was irgendwann

00:40:47.770 --> 00:40:49.970
fertig ist und

00:40:49.970 --> 00:40:51.450
sobald du es benutzt, musst du halt warten.

00:40:54.070 --> 00:40:55.310
Ja, kann man,

00:40:56.610 --> 00:40:57.610
in Python

00:40:57.610 --> 00:40:59.710
gibt es das halt quasi ganz genauso.

00:41:00.090 --> 00:41:01.610
Also seit 3.2

00:41:01.610 --> 00:41:03.270
gibt es Concurrent

00:41:03.270 --> 00:41:04.310
Futures.

00:41:05.730 --> 00:41:07.270
Ich weiß nicht, ob sich

00:41:07.270 --> 00:41:09.370
JavaScript, das auch so das Promises-Konzept

00:41:09.370 --> 00:41:11.350
da so ein bisschen abgeguckt hat. Also Python hat sich das

00:41:11.350 --> 00:41:13.230
abgeguckt aus der Java-Welt tatsächlich,

00:41:13.350 --> 00:41:15.050
wo es dieses Future-Konzept wohl schon länger gibt.

00:41:17.330 --> 00:41:19.270
Aber in Java nimmt man doch viel eher Threads, oder?

00:41:19.350 --> 00:41:21.530
Ja, aber man kann auch

00:41:21.530 --> 00:41:21.890
das machen.

00:41:24.430 --> 00:41:25.310
Genau, also aber

00:41:25.310 --> 00:41:27.130
sagen wir so, wenn wir jetzt schon bei den Callbacks sind,

00:41:27.590 --> 00:41:29.390
oder bei dieser

00:41:29.390 --> 00:41:30.990
Art, das kann man halt in Python

00:41:30.990 --> 00:41:33.490
im Grunde auch so machen.

00:41:33.970 --> 00:41:34.390
Ja, klar.

00:41:36.710 --> 00:41:37.230
Ja, also

00:41:37.230 --> 00:41:39.050
das ist auch in dem Async-Teil, also

00:41:39.050 --> 00:41:41.090
sagen wir mal so, man muss das wahrscheinlich alles

00:41:41.090 --> 00:41:42.990
so ein bisschen voneinander unterscheiden, es gibt halt

00:41:42.990 --> 00:41:44.870
ein riesiges Glossar machen. Ja, genau,

00:41:44.950 --> 00:41:46.950
wie das unten drunter aussieht, was man unten drunter für

00:41:46.950 --> 00:41:48.250
einen Mechanismus verwendet, um halt

00:41:48.250 --> 00:41:50.770
Concurrency zu erreichen und

00:41:50.770 --> 00:41:52.870
was man dann für Abstraktionen darüber verwendet,

00:41:53.250 --> 00:41:55.090
weil tatsächlich in Async.io jetzt

00:41:55.090 --> 00:41:56.590
sozusagen die aktuell

00:41:56.590 --> 00:41:59.010
in der Standardbibliothek

00:41:59.010 --> 00:42:00.850
befindliche Lösung für diese

00:42:00.850 --> 00:42:03.070
Concurrency-Geschichte ist halt

00:42:03.070 --> 00:42:04.910
Ja, sogar in der Sprache, oder? Ist nicht

00:42:04.910 --> 00:42:07.130
eine Bibliothek, sondern ist richtig in die Sprache integriert

00:42:07.130 --> 00:42:09.290
mit Schlüsselwörtern. Ja, aber

00:42:09.290 --> 00:42:11.150
das ist auch eine

00:42:11.150 --> 00:42:12.970
gute Sache, das ist voneinander getrennt. Also,

00:42:13.130 --> 00:42:15.170
was in der Sprache tatsächlich drin ist, ist halt

00:42:15.170 --> 00:42:17.130
sind halt Async-Funktionen.

00:42:18.070 --> 00:42:19.410
Also, die man halt mit Async-Dev

00:42:19.410 --> 00:42:20.910
Async-Dev, genau, und Await

00:42:20.910 --> 00:42:22.550
mit diesen Schlüsselwörtern

00:42:22.550 --> 00:42:25.270
kann man da operieren, aber

00:42:25.270 --> 00:42:27.110
in der Sprache ist nur definiert,

00:42:27.310 --> 00:42:29.090
dass diese Geschichten dann, wenn du sie

00:42:29.090 --> 00:42:30.530
aufrufst, halt eine Co-Routine zurückgeben.

00:42:31.790 --> 00:42:33.090
Es ist nicht gesagt, wie

00:42:33.090 --> 00:42:35.150
das jetzt alles sonst funktionieren muss. Der Rest ist

00:42:35.150 --> 00:42:37.070
halt... Ja, okay, klar, die Event-Loop

00:42:37.070 --> 00:42:39.050
und so weiter. Du kannst nämlich, genau, du kannst halt

00:42:39.050 --> 00:42:40.890
Async-Dev und Await

00:42:40.890 --> 00:42:42.950
auch in Trio verwenden. Und Trio verwendet ein ganz anderes

00:42:42.950 --> 00:42:44.630
Modell unten drunter als jetzt Async-IO.

00:42:45.650 --> 00:42:46.990
Trio, das

00:42:46.990 --> 00:42:49.190
ist eine Implementierung

00:42:49.190 --> 00:42:50.910
sowas Ähnliches wie Async-IO,

00:42:51.130 --> 00:42:52.950
bloß mit einer

00:42:52.950 --> 00:42:54.930
etwas moderneren, etwas anderen Zielsetzung.

00:42:55.030 --> 00:42:57.050
Also es gibt diverse. Es gibt Async-IO,

00:42:57.190 --> 00:42:59.130
ist in der Standard-Bibliothek. Es gibt

00:42:59.130 --> 00:43:01.030
Curio, das ist das

00:43:01.030 --> 00:43:01.750
von David Beasley.

00:43:03.050 --> 00:43:05.130
Ist halt sozusagen erst ab Python 3.7

00:43:05.130 --> 00:43:06.850
und irgendwie so ein bisschen

00:43:06.850 --> 00:43:08.470
advancer.

00:43:09.170 --> 00:43:11.030
Und dann gibt es nochmal die advancedere

00:43:11.030 --> 00:43:12.650
Version von Nathaniel Smith

00:43:12.650 --> 00:43:13.790
im Trio.

00:43:14.850 --> 00:43:16.990
Und das Ding macht

00:43:16.990 --> 00:43:18.810
im Grunde sowas ähnliches, aber halt

00:43:18.810 --> 00:43:21.090
anders. Also die Art, wie man es

00:43:21.090 --> 00:43:21.990
programmiert, ist halt anders.

00:43:22.950 --> 00:43:25.090
Und benutzt aber Async-Def kann man

00:43:25.090 --> 00:43:26.890
in all diesen Dingern verwenden, weil

00:43:26.890 --> 00:43:28.590
das halt nur sagt, okay, wenn ich

00:43:28.590 --> 00:43:30.970
eine Async-Funktion habe, dann

00:43:30.970 --> 00:43:32.210
gibt die halt eine Core-Routine zurück.

00:43:32.710 --> 00:43:34.770
Und ich kann jetzt damit irgendwas machen. Aber wie das

00:43:34.770 --> 00:43:36.670
Programmiermodell aussieht, was ich dann mit diesen

00:43:36.670 --> 00:43:38.710
Co-Routinen mache. Das ist ja demjenigen, der

00:43:38.710 --> 00:43:40.490
das sozusagen, dieses Framework implementiert,

00:43:40.590 --> 00:43:42.890
überlassen. Und da gibt es unterschiedliche

00:43:42.890 --> 00:43:44.770
Ansätze. Und im Grunde

00:43:45.430 --> 00:43:46.790
Trio ist

00:43:46.790 --> 00:43:48.630
so ein bisschen das zu Ende gedacht, dass das halt so

00:43:48.630 --> 00:43:50.750
ein Problem ist. Also das wurde ja auch schon angedeutet

00:43:50.750 --> 00:43:52.510
mit dieser Callback-Hell-Geschichte. Also

00:43:52.510 --> 00:43:54.650
das grundsätzliche Problem, was

00:43:54.650 --> 00:43:56.710
auch der Autor von Trio da identifiziert

00:43:56.710 --> 00:43:58.730
hat, also ich packe da auch mal

00:43:58.730 --> 00:44:00.690
einen Artikel, wo man das in Detail nachlesen

00:44:00.690 --> 00:44:02.570
kann in die Shownotes, dass er sagt,

00:44:02.570 --> 00:44:04.570
das ist alles, also die Problematik

00:44:04.770 --> 00:44:06.810
großer Teil der Probleme, die wir hier sehen, sind

00:44:06.810 --> 00:44:08.630
die gleichen Probleme, die Leute

00:44:08.630 --> 00:44:09.510
früher mit GoTo hatten.

00:44:11.390 --> 00:44:12.710
Oder ich sag, das ist halt eine sehr gute

00:44:12.710 --> 00:44:14.730
Analogie dafür. Wir sind in der Assembler-Welt

00:44:14.730 --> 00:44:16.170
angekommen, wenn wir über GoTo sprechen.

00:44:16.330 --> 00:44:18.310
Ja, nee, nicht ganz Assembler.

00:44:18.430 --> 00:44:19.690
Ganz viele Sprachen, die GoTo haben.

00:44:19.690 --> 00:44:19.950
Ja.

00:44:22.070 --> 00:44:22.510
Also,

00:44:22.730 --> 00:44:25.070
das Problem bei GoTo ist halt irgendwie,

00:44:25.690 --> 00:44:26.170
dass es dir,

00:44:26.770 --> 00:44:29.510
was das unmöglich macht,

00:44:29.590 --> 00:44:31.270
ist halt lokal über Code nachzudenken.

00:44:31.770 --> 00:44:33.370
Weil du weißt halt nicht, also er hat

00:44:33.370 --> 00:44:35.330
dann halt so ein schönes Diagramm, wo man halt

00:44:35.330 --> 00:44:37.190
er macht halt immer, er geht von einem

00:44:37.190 --> 00:44:39.350
Go-To zu einer Zeile und dann, er macht das halt

00:44:39.350 --> 00:44:40.630
immer weiter, bis du halt siehst, das ist ein riesiges

00:44:40.630 --> 00:44:43.330
Spaghetti-Kneuel. Das heißt, du

00:44:43.330 --> 00:44:44.430
weißt halt nie genau,

00:44:44.950 --> 00:44:47.470
wie du eigentlich hingekommen

00:44:47.470 --> 00:44:49.030
bist und wo es hingeht.

00:44:49.710 --> 00:44:51.090
Und zum Beispiel, du kannst halt keine

00:44:51.090 --> 00:44:53.350
Tracebacks werfen, weil du weißt überhaupt nicht, wo du herkommst

00:44:53.350 --> 00:44:55.010
eigentlich. Und

00:44:55.010 --> 00:44:56.750
das ist halt relativ schrecklich,

00:44:57.290 --> 00:44:59.310
du musst halt dann das Programm

00:44:59.310 --> 00:45:01.310
immer komplett verstehen. Ansonsten

00:45:01.310 --> 00:45:03.330
kannst du nicht sagen, was da gerade passiert

00:45:03.330 --> 00:45:08.650
weil es keine lokalen Blöcke gibt, wo man sagt,

00:45:08.770 --> 00:45:10.970
okay, ich habe jetzt ungefähr verstanden, was das Ding tut.

00:45:12.110 --> 00:45:13.250
Das muss ich jetzt nicht noch,

00:45:13.470 --> 00:45:15.790
also ich brauche nur zu wissen, wie die Abstraktion davon ist.

00:45:16.270 --> 00:45:17.790
Und das reicht mir, um damit arbeiten zu können.

00:45:18.290 --> 00:45:20.770
Zum Beispiel irgendwie sowas wie Print Hello World.

00:45:20.950 --> 00:45:23.330
Print macht intern was relativ Kompliziertes.

00:45:24.310 --> 00:45:25.570
Das macht irgendwie Syscalls,

00:45:26.250 --> 00:45:28.050
das macht irgendwie alle möglichen komischen Dinge,

00:45:28.130 --> 00:45:29.090
die halt dann so zu tun sind,

00:45:29.090 --> 00:45:33.170
wenn dann was auf der Konsole erscheinen soll.

00:45:33.330 --> 00:45:35.770
Aber das muss man

00:45:35.770 --> 00:45:37.290
alles nicht wissen, sondern man ruft das einfach auf

00:45:37.290 --> 00:45:39.550
und das geht. Und Funktionen sind halt

00:45:39.550 --> 00:45:41.630
super, weil genau die brauchst du ja

00:45:41.630 --> 00:45:43.350
eigentlich nur zu merken, was das Ding tut, aber wie das

00:45:43.350 --> 00:45:45.050
intern funktioniert, das muss einen nicht mehr interessieren.

00:45:45.370 --> 00:45:46.910
Ist auch die gleiche Idee bei Klassen und so weiter.

00:45:47.650 --> 00:45:49.530
Und mit Gotoh funktioniert

00:45:49.530 --> 00:45:51.390
das halt nicht, weil du nicht sagen kannst,

00:45:51.510 --> 00:45:53.570
okay, ich weiß jetzt, was hier

00:45:53.570 --> 00:45:55.670
passiert und muss mir darüber keine Gedanken mehr machen,

00:45:56.110 --> 00:45:57.310
weil es kann halt passieren,

00:45:57.530 --> 00:45:59.750
dass dein Code nicht wieder dahin zurückkommt,

00:45:59.750 --> 00:46:01.650
wo du es, also es gibt nicht so einen Aufruf, der wieder

00:46:01.650 --> 00:46:03.570
zurückkommt, sondern das kann

00:46:03.570 --> 00:46:05.650
verschwinden und ist dann halt irgendwie weg und es passiert was völlig

00:46:05.650 --> 00:46:07.670
anderes. Und das ist halt schlecht, wenn

00:46:07.670 --> 00:46:09.610
das so ist, weil dann kann man nicht mehr lokal

00:46:09.610 --> 00:46:11.450
über Code nachdenken. Und

00:46:11.450 --> 00:46:13.350
er meinte halt so, ja gut, also in den

00:46:13.350 --> 00:46:15.270
Ende der 60er, 74er

00:46:15.270 --> 00:46:17.590
Dijkstra und so, da gibt es halt den berühmten Artikel,

00:46:18.230 --> 00:46:19.630
die haben sich da Gedanken gemacht und

00:46:19.630 --> 00:46:21.590
deren Vorschlag war halt, ja,

00:46:21.850 --> 00:46:23.570
Gotoh rauswerfen,

00:46:23.650 --> 00:46:25.190
verbannen, irgendwie ächten

00:46:25.190 --> 00:46:27.410
und stattdessen sowas verwenden wie

00:46:27.410 --> 00:46:29.230
Funktionen und Blöcke und so.

00:46:30.190 --> 00:46:31.590
Und das hat sich durchgesetzt

00:46:31.590 --> 00:46:33.770
und auch lustig, die

00:46:33.770 --> 00:46:35.790
Gegenargumente damals und auch

00:46:35.790 --> 00:46:37.850
Knut hat zum Beispiel gesagt, oh nö, ich

00:46:37.850 --> 00:46:38.870
finde Kutu eigentlich ganz gut.

00:46:39.570 --> 00:46:40.410
Auch sehr interessant.

00:46:41.110 --> 00:46:43.370
Knut? Ja, Donald Knut.

00:46:44.210 --> 00:46:45.850
Ah, war das nicht der, der

00:46:45.850 --> 00:46:47.630
sowas gesagt hat wie Premature

00:46:47.630 --> 00:46:49.530
Optimization is the root of all evil?

00:46:49.850 --> 00:46:50.590
Genau, genau der.

00:46:51.830 --> 00:46:53.750
Aber dieses Zitat ist mit

00:46:53.750 --> 00:46:55.670
sehr viel Vorsicht zu genießen. Er hat auch gesagt, wenn man

00:46:55.670 --> 00:46:57.430
drei Prozent rausholen kann, dann ist es nicht mehr

00:46:57.430 --> 00:46:57.790
Premature.

00:47:00.570 --> 00:47:03.130
Ja, ja, ach ja, andere Zeiten.

00:47:04.970 --> 00:47:05.630
Ja, jedenfalls.

00:47:06.030 --> 00:47:09.790
Genau, der war da auch nicht unbedingt so totaler Fan von Gotoh Rausschmeißen,

00:47:09.870 --> 00:47:11.390
weil so eines der Argumente war halt so,

00:47:11.730 --> 00:47:13.950
ja, das bedeutet ja, wir müssen ganz anders programmieren lernen.

00:47:14.670 --> 00:47:16.110
Wir haben jetzt über Jahre irgendwie,

00:47:16.110 --> 00:47:20.150
haben wir uns auf ein Level begeben,

00:47:20.230 --> 00:47:21.770
dass wir damit irgendwie jetzt klarkommen

00:47:21.770 --> 00:47:24.110
und haben uns so Methoden angewöhnt, wie man damit umgeht.

00:47:24.830 --> 00:47:26.030
Und wenn wir das jetzt so ändern,

00:47:26.190 --> 00:47:28.530
dann müssen wir im Grunde nochmal neu programmieren lernen.

00:47:28.530 --> 00:47:30.070
Und ja, das ist wohl so.

00:47:30.090 --> 00:47:32.690
Und vielleicht wird es dann sogar langsamer,

00:47:32.790 --> 00:47:34.550
weil eben diese Funktionsaufrufe

00:47:34.550 --> 00:47:36.650
und diese ganzen Strukturmechanismen,

00:47:36.850 --> 00:47:37.890
die verbrauchen ja auch Rechenzeit.

00:47:38.210 --> 00:47:38.710
Ja, natürlich.

00:47:38.990 --> 00:47:39.730
Und Speicherplatz.

00:47:39.890 --> 00:47:40.110
Genau.

00:47:40.470 --> 00:47:43.150
Und wenn du nochmal 3% irgendwo rausholen kannst,

00:47:43.610 --> 00:47:46.090
dann kannst du das auch machen.

00:47:46.330 --> 00:47:48.250
Und wenn der Mainframe super teuer ist

00:47:48.250 --> 00:47:49.490
und Arbeitskraft super billig,

00:47:49.570 --> 00:47:50.350
dann macht es vielleicht sogar Sinn.

00:47:50.350 --> 00:47:53.030
Aber heute vielleicht nicht.

00:47:53.030 --> 00:47:54.170
Ja, das ist halt,

00:47:54.570 --> 00:47:56.250
wir stehen auf den Schultern von Riesen.

00:47:56.350 --> 00:47:57.510
Wir haben heute genügend Prozessoren,

00:47:58.230 --> 00:47:59.590
Wir haben genügend Megahertz,

00:48:00.050 --> 00:48:01.690
dass wir uns das leisten können.

00:48:03.030 --> 00:48:04.550
Ja, und im Grunde,

00:48:04.590 --> 00:48:06.030
er sagt halt, ja,

00:48:06.250 --> 00:48:08.090
also bei Concurrent

00:48:08.090 --> 00:48:10.490
Programmierung

00:48:10.490 --> 00:48:12.530
hat man im Grunde in gewisser Weise das gleiche Modell

00:48:12.530 --> 00:48:14.310
und er sagt zum Beispiel, Futures

00:48:14.310 --> 00:48:15.990
findet er ganz schrecklich, weil

00:48:15.990 --> 00:48:18.290
die im Grunde das gleiche Problem haben

00:48:18.290 --> 00:48:20.070
wie Gotoh, weil du kriegst halt was zurück.

00:48:20.210 --> 00:48:22.290
Also du rufst eine Funktion auf, du kriegst was

00:48:22.290 --> 00:48:24.330
zurück, aber du bist ja

00:48:24.330 --> 00:48:25.910
gar nicht, das ist ja gar nicht linear zurück.

00:48:26.350 --> 00:48:27.830
Dein Code geht ja nicht linear weiter.

00:48:28.230 --> 00:48:29.870
sondern irgendwo anders passiert

00:48:29.870 --> 00:48:31.810
irgendwas, das aber

00:48:31.810 --> 00:48:33.370
durchaus Auswirkungen darauf haben kann,

00:48:33.750 --> 00:48:35.750
was später in dem Code, der dann

00:48:35.750 --> 00:48:37.410
jetzt sozusagen von dir aus gesehen weiterläuft,

00:48:37.970 --> 00:48:39.830
darauf Auswirkungen

00:48:39.830 --> 00:48:41.010
hat. Das heißt, du musst wissen,

00:48:41.650 --> 00:48:43.550
okay, der Task, der dann auch läuft, der wird

00:48:43.550 --> 00:48:45.370
später mal irgendwas Böses machen oder

00:48:45.370 --> 00:48:47.730
vielleicht noch irgendwie, keine Ahnung. Und da muss ich auf jeden Fall

00:48:47.730 --> 00:48:49.610
dran denken, dass der mir vielleicht irgendwie dazwischen

00:48:49.610 --> 00:48:51.670
grätscht oder ich muss hier mal einen Lock setzen, damit das irgendwie

00:48:51.670 --> 00:48:53.910
atomar bleibt und keine Ahnung.

00:48:55.490 --> 00:48:55.810
Das heißt,

00:48:55.890 --> 00:48:57.430
ich kann nicht mehr sagen, okay,

00:48:57.590 --> 00:48:58.970
ich habe jetzt diese Funktion aufgerufen,

00:48:59.230 --> 00:49:01.390
ist es gut, ich weiß jetzt Bescheid,

00:49:02.030 --> 00:49:03.390
es hat funktioniert oder nicht

00:49:03.390 --> 00:49:04.790
und ich mache jetzt weiter, sondern

00:49:04.790 --> 00:49:07.030
ja, ich habe dieses Future-Ding in der Hand,

00:49:07.210 --> 00:49:09.290
aber tatsächlich muss ich

00:49:09.290 --> 00:49:11.190
mir irgendwie selber merken, was da noch alles

00:49:11.190 --> 00:49:13.230
passieren kann und das ist natürlich schlecht,

00:49:13.290 --> 00:49:15.090
weil das macht halt genau diese lokale,

00:49:15.390 --> 00:49:17.210
dieses lokale Nachdenken

00:49:17.210 --> 00:49:19.190
über Code kaputt und er sagt

00:49:19.190 --> 00:49:21.250
halt so, alle Concurrency-Lösungen, die

00:49:21.250 --> 00:49:23.270
dazu führen, dass man nicht mehr lokal

00:49:23.270 --> 00:49:25.210
über Code nachdenken kann, das ist

00:49:25.210 --> 00:49:26.910
alles, das ist alles nicht richtig,

00:49:27.130 --> 00:49:28.410
Das sollte man so nicht machen.

00:49:29.090 --> 00:49:30.570
Was ist da die Lösung jetzt davon?

00:49:30.750 --> 00:49:32.850
Er hat da so ein Konzept,

00:49:34.090 --> 00:49:35.110
das heißt dann irgendwie

00:49:35.110 --> 00:49:35.790
Nurseries.

00:49:39.690 --> 00:49:40.910
Nurseries, die kleine Krankenschwester,

00:49:41.030 --> 00:49:42.410
die die Babys auf der Aufzuchtstation ist.

00:49:42.410 --> 00:49:44.290
Genau, er sagt so, ja, so Tars

00:49:44.290 --> 00:49:45.990
oder sind so wie so kleine Kinder,

00:49:46.370 --> 00:49:48.390
die darf man nicht einfach so frei rumlaufen lassen,

00:49:48.570 --> 00:49:48.990
das ist nicht gut.

00:49:49.510 --> 00:49:51.350
Die muss man irgendwo einsperren,

00:49:51.430 --> 00:49:52.930
wo sie dann gepflegt werden.

00:49:54.790 --> 00:49:55.970
Wo sich jemand drum kümmert.

00:49:57.050 --> 00:49:58.550
die dürften aber nicht raus. Ja, genau.

00:49:59.170 --> 00:50:00.970
Und das Ganze ist in so einem Context-Manager drin

00:50:00.970 --> 00:50:02.910
und tatsächlich, also ich habe noch nicht

00:50:02.910 --> 00:50:04.690
so viel damit rumgespielt. Also es sah gut aus, aber

00:50:04.690 --> 00:50:07.210
ja, angeblich

00:50:07.210 --> 00:50:08.570
ist das wohl eine Möglichkeit,

00:50:08.870 --> 00:50:10.030
das so hinzukriegen, dass

00:50:10.030 --> 00:50:11.780
dass man weiterhin lokal über Sachen nachdenken kann

00:50:11.780 --> 00:50:13.460
und dieses Problem, dass man

00:50:13.460 --> 00:50:15.940
Spalter-Effekte hat, gar nicht mehr bekommt.

00:50:17.120 --> 00:50:18.200
Und es ist sogar teilweise

00:50:18.200 --> 00:50:19.860
einfacher, Sachen damit umzusetzen.

00:50:19.960 --> 00:50:21.520
Es gibt da diesen für IP

00:50:21.520 --> 00:50:23.700
Happy Eyeballs-Algorithmus,

00:50:24.020 --> 00:50:26.120
der auch in Twisted drin ist. Und es gibt eine Twisted-Implementierung,

00:50:26.220 --> 00:50:27.820
die ist 120 Zeilen

00:50:27.820 --> 00:50:29.980
und relativ fies. Und es gibt eine

00:50:29.980 --> 00:50:31.700
in Trio und die ist halt irgendwie,

00:50:32.040 --> 00:50:33.840
weiß ich nicht, also ich meine, obwohl Zeilen

00:50:33.840 --> 00:50:35.480
vergleichen ist auch wieder ein bisschen Quatsch, aber

00:50:35.480 --> 00:50:37.800
also viel, viel weniger und viel

00:50:37.800 --> 00:50:39.780
klarer. Und als er das Ding

00:50:39.780 --> 00:50:41.880
in Trio nachgeschrieben, hat er auch diverse logische Fehler

00:50:41.880 --> 00:50:43.840
in der Twisted Implementation

00:50:43.840 --> 00:50:45.780
gefunden, weil das einfach

00:50:45.780 --> 00:50:47.780
super schwierig ist, das so hinzukriegen

00:50:47.780 --> 00:50:49.640
mit den Futures. Also in

00:50:49.640 --> 00:50:51.040
Trio gibt es keine Futures mehr,

00:50:51.640 --> 00:50:53.560
es ist halt eher so, es gibt diese Nurseries

00:50:53.560 --> 00:50:55.560
und ja, es wurde auch schon

00:50:55.560 --> 00:50:57.820
darüber nachgedacht, ob das nicht vielleicht eine gute Geschichte

00:50:57.820 --> 00:50:58.580
wäre, das in

00:50:58.580 --> 00:51:01.940
Python direkt einzubauen

00:51:01.940 --> 00:51:03.500
und statt AsyncIO zum Beispiel

00:51:03.500 --> 00:51:05.720
zu verwenden, aber das ist alles

00:51:05.720 --> 00:51:07.420
noch gerade so dabei,

00:51:07.720 --> 00:51:09.300
quasi noch nicht sprunghaft.

00:51:09.300 --> 00:51:10.820
Ist der Zug nicht schon längst abgefahren?

00:51:11.060 --> 00:51:11.920
Vielleicht schon, ja.

00:51:13.980 --> 00:51:15.020
Ja, vielleicht ist er das schon.

00:51:15.120 --> 00:51:17.040
Viel zu viele Leute, oder zu viele Leute

00:51:17.040 --> 00:51:19.160
verwenden Async.io, als dass man

00:51:19.160 --> 00:51:21.140
das noch vielleicht ändern könnte. Und es gibt halt da

00:51:21.140 --> 00:51:23.000
diesen Ökosystem-Split und

00:51:23.000 --> 00:51:24.660
wahrscheinlich ist es besser, dann eben

00:51:24.660 --> 00:51:26.740
auf das zu versetzen, was eh dabei ist.

00:51:27.360 --> 00:51:28.860
Trio macht das sowas, du hast jetzt gesagt,

00:51:28.920 --> 00:51:31.020
Kontextmanager, das heißt, man muss diesen lokalen Scope

00:51:31.020 --> 00:51:33.160
nicht verlassen. Ist das nicht eigentlich das, was Funktionen

00:51:33.160 --> 00:51:34.040
tun, sowieso schon?

00:51:34.780 --> 00:51:36.640
Ja, ja, aber Funktionen funktioniert halt nicht so richtig.

00:51:37.460 --> 00:51:37.780
Weil?

00:51:38.960 --> 00:51:40.440
Die Tats laufen ja weiter.

00:51:42.340 --> 00:51:43.180
Das ist halt auch bei

00:51:43.180 --> 00:51:44.760
wenn du halt eine Funktion

00:51:44.760 --> 00:51:47.780
wenn du

00:51:47.780 --> 00:51:49.300
Concurrence irgendwas machst, dann

00:51:49.300 --> 00:51:51.240
hört das halt nicht in dem Moment auf, wo du das

00:51:51.240 --> 00:51:53.360
aufgerufen hast, sondern das läuft halt unter Umständen weiter.

00:51:53.480 --> 00:51:55.100
Das heißt, ich habe beispielsweise nur

00:51:55.100 --> 00:51:57.220
den halben Whisky eingeschenkt und die andere

00:51:57.220 --> 00:51:58.040
Hälfte, die kommt aber noch.

00:51:58.980 --> 00:52:00.760
Aber woanders fängt der halt an, dann schon

00:52:00.760 --> 00:52:03.580
andere Limetten rein zu

00:52:03.580 --> 00:52:05.280
Ja, also

00:52:05.280 --> 00:52:06.960
Und was ist der Unterschied?

00:52:07.140 --> 00:52:09.140
in Trio, dann macht er dann trotzdem erst den einen Schritt fertig?

00:52:09.340 --> 00:52:11.160
Oder wieso ist das so isoliert?

00:52:11.320 --> 00:52:13.420
Also, dass du vielleicht bei diesem Barkeeper-Beispiel

00:52:13.420 --> 00:52:15.320
das so anschaulich hinzubekommen

00:52:15.320 --> 00:52:17.460
kriegst? Weiß nicht, ob ich das tatsächlich hinkriege.

00:52:17.900 --> 00:52:19.220
Also, kann man sich, müsste man

00:52:19.220 --> 00:52:20.900
sich selber angucken. Da gibt es auch Schaubilder auf der Seite.

00:52:21.320 --> 00:52:22.440
Aber das zu erklären,

00:52:23.420 --> 00:52:25.280
weiß ich nicht, ob das... Das ist so ein bisschen das Problem,

00:52:25.460 --> 00:52:27.220
das generelle Problem an Current Programming,

00:52:27.300 --> 00:52:29.180
oder? Dass diese Sachen alle gleich so kompliziert

00:52:29.180 --> 00:52:31.240
werden, dass man dann diverse Schaubilder

00:52:31.240 --> 00:52:33.300
braucht und Leute dann

00:52:33.300 --> 00:52:34.900
irgendwann sagen, ja, lass lieber die Finger davon,

00:52:34.900 --> 00:52:36.940
das ist nicht so. Ja, und tatsächlich ist das

00:52:36.940 --> 00:52:38.780
vielleicht gar keine so schlechte, ich glaube, ich würde auch sagen, also auch meine

00:52:38.780 --> 00:52:40.960
Erfahrungen, die ich damit so bisher gesammelt habe,

00:52:41.120 --> 00:52:42.700
die waren alle immer, es war immer

00:52:42.700 --> 00:52:44.340
ziemlich fies, also das war immer,

00:52:45.240 --> 00:52:46.800
also die Beispiele,

00:52:46.860 --> 00:52:48.740
die haben immer funktioniert, wenn man sich irgendwie

00:52:48.740 --> 00:52:50.740
so Tutorials oder so anguckt, wenn man es

00:52:50.740 --> 00:52:52.540
dann tatsächlich ausprobiert mit irgendwie

00:52:52.540 --> 00:52:54.700
in den Fällen, wo man es dann halt

00:52:54.700 --> 00:52:56.640
wirklich braucht, wo man dann viel Last macht,

00:52:57.360 --> 00:52:58.540
dann sind mir jedes Mal

00:52:58.540 --> 00:53:00.100
passieren komische Sachen

00:53:00.100 --> 00:53:02.540
und das Debugging ist jedes Mal

00:53:02.540 --> 00:53:04.600
Das ist so bei Ginkgo Program, da passieren immer

00:53:04.600 --> 00:53:06.580
komische Sachen. Ja, also wirklich, also

00:53:06.580 --> 00:53:07.760
zum Beispiel einen Bug

00:53:07.760 --> 00:53:10.420
und diese

00:53:10.420 --> 00:53:11.940
Geschichten, ich meine, das passiert anderen Leuten auch.

00:53:12.580 --> 00:53:13.180
Zum Beispiel

00:53:13.180 --> 00:53:16.240
der Gründer von

00:53:16.240 --> 00:53:18.360
der ursprünglichen Entwickler von

00:53:18.360 --> 00:53:20.140
Twisted hat einen langen Artikel darüber geschrieben,

00:53:20.260 --> 00:53:22.200
warum er Multithreading hasst.

00:53:22.300 --> 00:53:24.260
Wo er dann geschrieben hat, sie hatten

00:53:24.260 --> 00:53:25.660
also Probleme und sie hatten dieses

00:53:25.660 --> 00:53:28.320
sie hatten einen wirklich fiesen Bug

00:53:28.320 --> 00:53:30.020
in einem größeren System und

00:53:30.020 --> 00:53:32.180
der ist halt irgendwie nur

00:53:32.180 --> 00:53:34.000
ab und zu aufgetreten. Sie haben es überhaupt niemals

00:53:34.000 --> 00:53:36.500
reproduzieren können und sie sind es nicht losgeworden.

00:53:36.580 --> 00:53:38.180
Und sie haben alles

00:53:38.180 --> 00:53:39.740
from scratch nochmal neu geschrieben,

00:53:39.900 --> 00:53:41.500
reimplementiert, um den Bug wegzukriegen,

00:53:41.940 --> 00:53:43.960
weil sie ihn einfach über Monate nicht finden konnten.

00:53:44.420 --> 00:53:45.760
Und das ist eigentlich schon echt bitter.

00:53:46.860 --> 00:53:48.000
Es ist auch super schwer

00:53:48.000 --> 00:53:49.960
zu testen, so Zeug. Das ist auch super schwer

00:53:49.960 --> 00:53:51.880
zu sagen, wenn ich X mache und Y,

00:53:51.880 --> 00:53:53.560
dann passiert Z. Sondern es ist halt,

00:53:54.000 --> 00:53:55.820
wenn 37 Leute gleichzeitig X machen

00:53:55.820 --> 00:53:57.640
und einer von denen aber Z macht und

00:53:57.640 --> 00:53:59.380
einer von denen Y und

00:53:59.380 --> 00:54:01.540
23 A und B, dann

00:54:01.540 --> 00:54:04.000
passiert irgendwas.

00:54:04.300 --> 00:54:05.440
Und Buchstabensuppe.

00:54:05.840 --> 00:54:08.160
Aber dann passiert Buchstabensuppe und das ist ein Bug.

00:54:08.480 --> 00:54:10.160
Ja, was ich

00:54:10.160 --> 00:54:12.120
da mal hatte, war halt, genau,

00:54:12.220 --> 00:54:14.040
ich hab halt so was Webcrawler-artiges

00:54:14.040 --> 00:54:15.620
geschrieben und

00:54:15.620 --> 00:54:18.000
mit ein paar tausend Seiten und

00:54:18.000 --> 00:54:18.920
weiß ich nicht, so hundert

00:54:18.920 --> 00:54:22.120
Seiten gleichzeitig abfragen pro Sekunde oder so,

00:54:22.160 --> 00:54:23.680
alles gar kein Problem. Aber so, okay,

00:54:23.780 --> 00:54:26.060
gehen wir auf eine halbe Million oder eine Million und machen

00:54:26.060 --> 00:54:27.900
das mal so irgendwie ordentlich, so mit ein paar tausend

00:54:27.900 --> 00:54:30.100
pro Sekunde. Und dann passieren

00:54:30.100 --> 00:54:31.740
plötzlich seltsame Geschichten.

00:54:32.740 --> 00:54:34.080
Irgendwie sterben plötzlich

00:54:34.080 --> 00:54:36.000
Sachen oder was ich dann hatte, es wird

00:54:36.000 --> 00:54:38.180
plötzlich irgendwie seltsam langsamer.

00:54:38.360 --> 00:54:40.160
Man weiß nicht warum. Plötzlich

00:54:40.160 --> 00:54:41.840
kriegt man ganz eigenartige

00:54:41.840 --> 00:54:43.900
Tracebacks aus den Tiefen von Python.

00:54:44.400 --> 00:54:45.900
Also was ich dann irgendwie

00:54:45.900 --> 00:54:48.160
rausgefunden habe,

00:54:48.200 --> 00:54:50.140
das war halt irgendwie die Resolver-Library

00:54:50.140 --> 00:54:51.940
auf meinem Mac. Ich habe es auf dem Mac probiert.

00:54:52.420 --> 00:54:54.140
Die hat halt irgendwie angefangen, plötzlich Probleme

00:54:54.140 --> 00:54:55.760
zu machen. Und

00:54:55.760 --> 00:54:58.060
zum Glück auf Linux ging es dann. Das ist auch

00:54:58.060 --> 00:54:59.480
immer sowas. Ja, Mac gibt es dann

00:54:59.480 --> 00:55:02.080
vielleicht für Smoketest gar nicht

00:55:02.080 --> 00:55:03.300
so schlecht. Der macht dann irgendwie

00:55:03.300 --> 00:55:05.140
ein bisschen früher irgendwie

00:55:05.140 --> 00:55:06.320
fängt er an zu rauchen.

00:55:07.500 --> 00:55:09.460
Bei Linux gehen dann viele Sachen, wo der Mac

00:55:09.460 --> 00:55:10.400
dann schon raucht, aber

00:55:10.400 --> 00:55:13.540
das war, und da habe ich auch lange dran rumgedebuggt

00:55:13.540 --> 00:55:15.340
und nichts gefunden und das ist ganz schrecklich.

00:55:17.340 --> 00:55:19.080
Ja, Load macht

00:55:19.080 --> 00:55:21.220
Dinge kaputt, die

00:55:21.220 --> 00:55:23.580
schwer zu finden sind und schwer zu sehen

00:55:23.580 --> 00:55:23.860
sind.

00:55:25.840 --> 00:55:27.620
Die dann auch nur so sporadisch auftauchen.

00:55:27.760 --> 00:55:29.440
Da wird es dann auf einmal statistisch, wenn du

00:55:29.440 --> 00:55:30.960
sagst, okay, mein Programm geht

00:55:30.960 --> 00:55:32.800
in 99 Prozent

00:55:32.800 --> 00:55:34.600
der Abläufe.

00:55:34.620 --> 00:55:36.840
Das ist dann der echte Bug. Das ist dann wie, dass in der Schaltung

00:55:36.840 --> 00:55:38.460
irgendwo ein Käfer reingeklettert ist,

00:55:38.880 --> 00:55:40.820
weil die Schaltung so groß ist, dass da irgendein Käfer dazwischen

00:55:40.820 --> 00:55:42.160
passt und du weißt aber nicht, woran er liegt.

00:55:42.160 --> 00:55:44.780
Ja, wenn halt der DNS-Resolver nur 99 Prozent aller Anfragen

00:55:44.780 --> 00:55:46.980
korrekt beantwortet und in einem Prozent der Anfragen

00:55:46.980 --> 00:55:48.420
halt abstürzt oder irgendeinen Quatsch macht,

00:55:49.100 --> 00:55:50.860
dann hast du halt so statistische

00:55:50.860 --> 00:55:52.800
Dinge. Aber das ist natürlich sehr unbefriedigend,

00:55:52.860 --> 00:55:53.500
weil ja eigentlich,

00:55:54.660 --> 00:55:56.800
also als Softwareentwickler

00:55:56.800 --> 00:55:58.760
oder als Informatiker ist man ja gewöhnt, dass wenn es

00:55:58.760 --> 00:56:00.700
geht, dass es dann zu 100 Prozent geht und

00:56:00.700 --> 00:56:00.920
immer.

00:56:02.680 --> 00:56:04.620
Ein anderes Beispiel, eben

00:56:04.620 --> 00:56:06.700
Lukas Langer, der hat ja bei Facebook

00:56:06.700 --> 00:56:08.380
gearbeitet und hat dann auch so ein Beispiel für,

00:56:08.780 --> 00:56:10.260
sie hatten halt irgendwie ein Ding, was halt auch

00:56:10.260 --> 00:56:12.360
Async.io gemacht hat und dann

00:56:12.360 --> 00:56:13.940
haben sie da auch Durchsatz,

00:56:14.300 --> 00:56:16.320
wenn es anfing, so richtig Durchsatz zu machen,

00:56:16.880 --> 00:56:18.520
wurde es plötzlich irgendwie magisch

00:56:18.520 --> 00:56:19.040
langsamer.

00:56:20.120 --> 00:56:21.160
Das sind die schlimmsten Sachen.

00:56:21.160 --> 00:56:23.200
Sie haben dann irgendwie auf ihre Kurven geguckt

00:56:23.200 --> 00:56:25.060
und sie haben es nicht verstanden und dann, bis dann

00:56:25.060 --> 00:56:26.540
irgendwann jemandem aufgefallen ist, oh,

00:56:27.300 --> 00:56:29.060
wo kommen eigentlich diese Kurven her?

00:56:29.240 --> 00:56:44.640
Es gibt da halt noch einen Thread, der guckt sich halt an, was die anderen Threads so machen und was die anderen Tasks so machen. Und der hatte halt in der Art, wie er dann halt die Ergebnisse von dem, was er gesehen hat, wie er sammelt hat, irgendwie so einen naiven Algorithmus drin, der mit der Last nicht gut klargekommen ist.

00:56:44.640 --> 00:56:46.800
der dann halt schnell langsamer

00:56:46.800 --> 00:56:48.740
geworden ist und der wurde dann so langsam, dass er alles andere

00:56:48.740 --> 00:56:50.740
aufgehalten hat und da ist dann

00:56:50.740 --> 00:56:51.960
sozusagen die CPU rausgelegt

00:56:51.960 --> 00:56:54.360
und ja, also

00:56:54.360 --> 00:56:56.720
aber das sind alles so ganz ekelhafte

00:56:56.720 --> 00:56:58.260
Probleme, also das ist

00:56:58.260 --> 00:57:00.540
wenn man das nicht braucht, sollte man das nicht machen, glaube ich

00:57:00.540 --> 00:57:01.120
das wäre so

00:57:01.120 --> 00:57:04.300
Ja, oder halt sich möglichst

00:57:04.300 --> 00:57:06.360
weiter von fernhalten, also ich meine, wir

00:57:06.360 --> 00:57:08.540
sind ja Django-Entwickler und wir haben das ja schon lange

00:57:08.540 --> 00:57:10.300
wir haben ja schon lange

00:57:10.300 --> 00:57:12.260
Sachen, die konkurrent sind, weil wir halt

00:57:12.260 --> 00:57:14.360
wenn du irgendwo was deployst, dann machst du halt

00:57:14.360 --> 00:57:15.900
zehn Unicorn-Prozesse an oder so.

00:57:16.980 --> 00:57:18.260
Aber die sind ja im Wesentlichen

00:57:18.260 --> 00:57:19.180
unabhängig voneinander.

00:57:19.820 --> 00:57:22.580
Die kommunizieren

00:57:22.580 --> 00:57:24.320
nur über die Datenbank. Die Datenbank ist

00:57:24.320 --> 00:57:26.160
da das, was die Currency macht.

00:57:26.300 --> 00:57:28.140
Oder was die gleichzeitig

00:57:28.140 --> 00:57:30.140
hat. Dass die Datenprobleme löst, dass das isoliert ist.

00:57:30.360 --> 00:57:32.200
Genau. Da bin ich ganz froh, dass es

00:57:32.200 --> 00:57:33.280
eine gute Datenbank gibt.

00:57:34.480 --> 00:57:36.140
Genau. Wo ich einfach sagen kann, okay,

00:57:36.800 --> 00:57:38.240
das kann ich messen, wie lange braucht

00:57:38.240 --> 00:57:40.060
es, diese Query auszuführen

00:57:40.060 --> 00:57:42.100
und wie viele können das gleichzeitig. Und wenn da zu viele

00:57:42.100 --> 00:57:43.760
Leute gleichzeitig kommen, dann müssen die halt warten.

00:57:44.360 --> 00:58:02.840
Wenn dann zu viele da sind, dann muss man halt die Timeouts hochstellen und sagen, fertig. Aber das ist so ein bisschen Concurrency Light, weil du eben die Sachen so sehr voneinander abtrennst, beziehungsweise das ist die smarte Concurrency. Du trennst die Sachen so weit voneinander ab, dass sie unabhängig voneinander sind.

00:58:03.260 --> 00:58:31.460
Und wenn sie so unabhängig voneinander sind, dass sie sich gar nicht, dass sie keine Kommunikation machen müssen, dann kannst du sie auf verschiedenen Rechnern ausführen, dann kannst du sie skalieren, kannst du sie wegskalieren, ja, entweder über Prozesse oder über Prozessoren, über unterschiedliche Maschinen oder über, was weiß ich, Docker-Container, die dir dann, oder über einen Kubernetes-Cluster, ja, wo du dann halt im Prinzip das Gleiche an ganz vielen verschiedenen Stellen ausführst und das ist ein Modell.

00:58:31.460 --> 00:58:55.980
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.980 --> 00:58:57.940
wenn du jetzt dieses klassische Worker-Modell

00:58:57.940 --> 00:58:59.400
mit Unicorn machst, das geht auch,

00:58:59.540 --> 00:59:01.760
dann hast du aber irgendwie einen Haufen

00:59:01.760 --> 00:59:03.440
Verbindungen und brauchst einen Haufen Server.

00:59:05.080 --> 00:59:05.940
Wahrscheinlich kannst du es auch

00:59:05.940 --> 00:59:07.580
mit einem machen. Ja, da würde ich

00:59:07.580 --> 00:59:09.980
mir einfach wünschen, dass es sozusagen so eine

00:59:10.680 --> 00:59:12.140
Verbindungsdatenbank

00:59:12.140 --> 00:59:12.380
gibt,

00:59:12.920 --> 00:59:15.740
die dieses schwierige Problem

00:59:15.740 --> 00:59:17.520
wegabstrahiert, aber ich glaube, da gibt es noch nichts.

00:59:18.300 --> 00:59:19.380
Ja, aber tatsächlich

00:59:19.380 --> 00:59:21.580
mit Django 3.1

00:59:21.580 --> 00:59:23.520
Async Views geht das tatsächlich.

00:59:23.520 --> 00:59:25.100
Also ich meine, man kann auch einfach was anderes nehmen.

00:59:25.560 --> 00:59:27.100
Also, womit man das schon länger machen kann, ist

00:59:27.100 --> 00:59:29.140
wahrscheinlich sowas, wie man Starlet nimmt

00:59:29.140 --> 00:59:31.220
oder so, oder irgendwas in der

00:59:31.220 --> 00:59:33.260
Richtung. Ja, aber die nennen ja auch alle Async.io.

00:59:33.400 --> 00:59:35.140
Also, die machen ja auch keine Magie. Genau,

00:59:35.220 --> 00:59:36.940
genau, genau. Aber da ging das halt,

00:59:37.080 --> 00:59:38.860
Django ging es bisher halt noch nicht, bis,

00:59:39.120 --> 00:59:41.000
also jetzt geht es halt dann halbwegs. Was

00:59:41.000 --> 00:59:42.880
macht Django denn jetzt alles so Schönes? Genau,

00:59:43.020 --> 00:59:43.220
jetzt

00:59:43.220 --> 00:59:46.880
kann es, also was neu

00:59:46.880 --> 00:59:49.140
dazukommt, sind Async-Views,

00:59:50.240 --> 00:59:51.160
wo man halt

00:59:51.160 --> 00:59:53.000
sozusagen als View tatsächlich eine

00:59:53.000 --> 00:59:55.000
Funktion hat, oder eben auch eine Klasse, wo man dann halt

00:59:55.000 --> 00:59:56.980
die Call-Methode als async

00:59:56.980 --> 00:59:58.440
def markiert,

00:59:59.260 --> 01:00:00.700
also async-Funktionen hat, die

01:00:00.700 --> 01:00:02.320
Views sind und

01:00:02.320 --> 01:00:05.060
die dann

01:00:05.060 --> 01:00:07.000
Co-Routinen zurückgeben und

01:00:07.000 --> 01:00:08.880
dafür muss das Interface,

01:00:09.140 --> 01:00:11.040
also das ist bei mir schon mit Django 3.0 passiert,

01:00:11.380 --> 01:00:12.380
das Interface zum Server,

01:00:12.820 --> 01:00:14.820
es muss möglich sein, was anderes zu benutzen als BSGI

01:00:14.820 --> 01:00:17.020
und das, was man da verwendet,

01:00:17.060 --> 01:00:18.080
ist halt dann ASGI

01:00:18.080 --> 01:00:21.020
und das kann halt

01:00:21.020 --> 01:00:22.440
beide Richtungen und

01:00:22.440 --> 01:00:24.160
ja, ist halt...

01:00:24.160 --> 01:00:26.860
Also Web-Server, Gateway-Interface und Asynchronos-Server.

01:00:26.880 --> 01:00:27.680
Ja, genau.

01:00:28.260 --> 01:00:31.060
Ist sozusagen das Übertragen auf den Fall,

01:00:31.120 --> 01:00:31.960
den man jetzt halt dann hat.

01:00:32.880 --> 01:00:35.900
Und genau, kommt auch aus dem Channels-Projekt irgendwie.

01:00:36.000 --> 01:00:38.580
Andrew Godwin hat das Ding halt auch in den Standard irgendwie dafür

01:00:38.580 --> 01:00:41.440
sozusagen hauptsächlich, glaube ich, irgendwie geschrieben.

01:00:42.320 --> 01:00:44.700
Ist jetzt in der Version 2.0 oder sowas da

01:00:44.700 --> 01:00:46.320
und ist auch mehr oder weniger fertig

01:00:46.320 --> 01:00:48.680
und wird auch von allen anderen quasi so adaptiert.

01:00:48.680 --> 01:00:50.940
Also das hat sich wohl tatsächlich mittlerweile eigentlich als Standard

01:00:50.940 --> 01:00:52.320
für solche...

01:00:52.320 --> 01:00:53.120
Hat sich durchgesetzt.

01:00:53.160 --> 01:00:55.100
hat sich durchgesetzt für, das ist halt

01:00:55.100 --> 01:00:56.900
der Standard, wie jetzt ein Applikationsserver mit der

01:00:56.900 --> 01:00:57.980
Applikation irgendwie kommuniziert.

01:00:58.980 --> 01:01:00.480
Und, genau.

01:01:02.660 --> 01:01:03.100
Und

01:01:03.100 --> 01:01:05.300
was in Django 3.1 jetzt dazugekommen ist,

01:01:07.080 --> 01:01:09.140
sind die Views, das ging halt

01:01:09.140 --> 01:01:09.960
in 3.0 noch nicht.

01:01:11.860 --> 01:01:12.300
Middlewares,

01:01:13.500 --> 01:01:15.020
und das war halt auch einer der

01:01:15.020 --> 01:01:16.900
schwierigen Teile halt, das Problem ist, du musst

01:01:16.900 --> 01:01:18.800
halt es hinkriegen, also wenn

01:01:18.800 --> 01:01:20.780
eine synchrone Middleware dazwischen ist, dann geht es halt schon eigentlich

01:01:20.780 --> 01:01:22.520
nicht mehr. Die ganzen

01:01:22.520 --> 01:01:23.860
ein Middle-Wise-Async zu kriegen

01:01:23.860 --> 01:01:24.900
und

01:01:24.900 --> 01:01:28.580
auch Async-Tests gehen halt

01:01:28.580 --> 01:01:30.680
auch. Und damit

01:01:30.680 --> 01:01:32.480
ist halt tatsächlich schon mal was da, womit man

01:01:32.480 --> 01:01:34.420
was machen kann. Ich meine, tatsächlich

01:01:34.420 --> 01:01:36.380
also die Wunschvorstellung, die ich an das Ganze hätte,

01:01:36.600 --> 01:01:37.700
eigentlich ist da so, dass

01:01:37.700 --> 01:01:40.460
alle Dinge, die jetzt I.O. machen auf meinem Server,

01:01:40.600 --> 01:01:42.340
also normale Webseite, kommt

01:01:42.340 --> 01:01:44.300
ein Request rein, das Ding

01:01:44.300 --> 01:01:46.360
macht halt irgendwie, keine Ahnung,

01:01:46.520 --> 01:01:48.580
fünf Statements an den Datenbank,

01:01:49.060 --> 01:01:49.780
fragt irgendwie

01:01:49.780 --> 01:01:52.400
ein Redis-Cache, fragt

01:01:52.400 --> 01:01:53.680
noch irgendeine API oder sowas

01:01:53.680 --> 01:01:56.040
und gibt dann irgendwie eine Antwort zurück

01:01:56.040 --> 01:01:58.340
in einem View und momentan ist es

01:01:58.340 --> 01:02:00.020
halt so, da wartet man dann halt

01:02:00.020 --> 01:02:02.320
synchron auf jede einzelne Anfrage, die man

01:02:02.320 --> 01:02:04.240
irgendwo hinstellt und alle Latenzen addieren sich

01:02:04.240 --> 01:02:05.240
und

01:02:05.240 --> 01:02:08.140
bis man das erste Byte am Client

01:02:08.140 --> 01:02:10.060
empfängt, muss man halt diese ganzen

01:02:10.060 --> 01:02:12.020
Netzwerk

01:02:12.020 --> 01:02:14.340
Zeiten

01:02:14.340 --> 01:02:16.020
abgewartet haben und

01:02:16.020 --> 01:02:18.220
das kann halt sein, dass das dann irgendwann, wenn man viele

01:02:18.220 --> 01:02:20.220
Statements macht oder wenn man viele APIs fragt,

01:02:20.260 --> 01:02:22.100
dann wird das halt viel und man kann

01:02:22.100 --> 01:02:23.900
im Grunde nichts tun, so wirklich.

01:02:24.320 --> 01:02:26.220
Oder man muss es halt komplett selber machen. Das Framework

01:02:26.220 --> 01:02:28.140
gibt einem da nichts an die Hand, womit man das

01:02:28.140 --> 01:02:28.880
irgendwie verbessern kann.

01:02:30.420 --> 01:02:32.160
Und sozusagen in einer goldenen

01:02:32.160 --> 01:02:34.100
Zukunft wäre es halt

01:02:34.100 --> 01:02:35.920
vielleicht so, dass man sagt, okay,

01:02:36.920 --> 01:02:37.980
das wird alles Async

01:02:37.980 --> 01:02:39.980
zusammengesammelt. Alle Sachen, die

01:02:39.980 --> 01:02:42.260
I.O. machen nach außen,

01:02:42.980 --> 01:02:43.720
erwartet man halt.

01:02:45.400 --> 01:02:45.800
Und

01:02:45.800 --> 01:02:48.140
die Latenz, die man

01:02:48.140 --> 01:02:49.960
als Client, wenn man die Seite

01:02:49.960 --> 01:02:52.000
abfragt, zu sehen bekommt,

01:02:52.100 --> 01:02:58.160
ist die, die der längste IO-Ding nach draußen braucht.

01:02:58.280 --> 01:02:59.460
Aber alle anderen sind dann halt schon da.

01:03:00.520 --> 01:03:02.820
Das heißt, es ist nicht mehr, alle Latenzen addieren sich,

01:03:02.940 --> 01:03:04.040
sondern die Latenz, die man sieht,

01:03:04.140 --> 01:03:07.260
ist die von dem längsten Einzelteil sozusagen.

01:03:08.800 --> 01:03:08.920
Ja.

01:03:10.420 --> 01:03:12.600
Aber ist das jetzt nicht Parallelität?

01:03:13.220 --> 01:03:14.400
Nö, das ist Concurrency.

01:03:14.540 --> 01:03:16.760
Das ist alles immer nur, genau.

01:03:17.380 --> 01:03:18.160
Weil ich sehe da,

01:03:18.260 --> 01:03:19.780
ich sehe echt einen ganz anderen Anwendungsfall

01:03:19.780 --> 01:03:23.060
für diese Async-Views und Async-Middlewares und so weiter.

01:03:23.960 --> 01:03:28.900
Ich sehe halt, dass du lange laufende Views hast

01:03:28.900 --> 01:03:32.660
und nicht den Worker blockierst.

01:03:32.760 --> 01:03:35.620
Das heißt, du kannst derweil andere Clients behandeln.

01:03:35.700 --> 01:03:36.740
Ja, das gibt es natürlich auch.

01:03:36.740 --> 01:03:39.240
Das ist ja genau das, was du bei WebSockets brauchst.

01:03:39.300 --> 01:03:40.780
Du hast ja im Wesentlichen einen Request,

01:03:40.940 --> 01:03:42.000
der für immer läuft.

01:03:42.220 --> 01:03:43.800
Oder so lange, wie der Client halt da ist.

01:03:44.520 --> 01:03:45.980
Und zwischendurch kannst du aber was anderes machen.

01:03:46.180 --> 01:03:49.760
Und der kann prinzipiell ja dann auch mit anderen Views

01:03:49.760 --> 01:03:51.880
kommunizieren. Du hast dich gerade

01:03:51.880 --> 01:03:53.840
freiwillig gemeldet, nochmal zu erklären, was WebSockets sind

01:03:53.840 --> 01:03:55.700
und weil das

01:03:55.700 --> 01:03:56.680
kam heute noch gar nicht dran.

01:03:57.560 --> 01:03:59.320
Ja, WebSockets sind, also

01:03:59.320 --> 01:04:01.360
da muss man ein kleines bisschen

01:04:01.360 --> 01:04:02.900
ausholen, glaube ich, weil

01:04:02.900 --> 01:04:05.660
das, was man so als Webseite kennt,

01:04:06.060 --> 01:04:07.940
das hat so ein Modell, das heißt Request Response.

01:04:07.940 --> 01:04:09.980
Das heißt, du schickst eine Anfrage

01:04:09.980 --> 01:04:11.060
hin und der Server

01:04:11.060 --> 01:04:13.800
bearbeitet die und dann schickt er irgendwann eine Antwort

01:04:13.800 --> 01:04:16.040
zurück und dann ist das abgeschlossen.

01:04:16.720 --> 01:04:17.980
Das ist alles, was

01:04:17.980 --> 01:04:19.720
da passiert. Also das, was man so hinschickt, ist dann so

01:04:19.720 --> 01:04:21.600
eine Anfrage, entweder will man irgendwie aus dem

01:04:21.600 --> 01:04:23.720
klassischen Crowdstream irgendwas machen, also

01:04:23.720 --> 01:04:25.600
lesen oder schreiben oder

01:04:25.600 --> 01:04:27.920
updaten oder löschen oder sowas und dann

01:04:27.920 --> 01:04:29.580
bekommst du eine Antwort, die

01:04:29.580 --> 01:04:31.840
dann irgendwie so einen Statuscode hat, den man vielleicht irgendwie so

01:04:31.840 --> 01:04:33.700
kennt. Genau, das ist

01:04:33.700 --> 01:04:35.680
alles Feinheiten, die da drin sind.

01:04:35.940 --> 01:04:37.820
Dieser Request-Response-Zyklus ist einfach nur,

01:04:37.920 --> 01:04:39.200
ich schicke dir eine Anfrage hin,

01:04:40.040 --> 01:04:41.840
einen Arbeitsauftrag und der

01:04:41.840 --> 01:04:43.840
Server bearbeitet diesen Arbeitsauftrag und

01:04:43.840 --> 01:04:45.800
schickt dann das Ergebnis zurück. Und was da drin steht,

01:04:46.360 --> 01:04:47.780
spielt erstmal keine Rolle. Das kann sein,

01:04:47.860 --> 01:04:49.200
gib mir die Homepage, das kann auch sein,

01:04:49.720 --> 01:04:52.200
update alle Bilder in der Datenbank

01:04:52.200 --> 01:04:54.060
und es kann auch sein,

01:04:54.180 --> 01:04:56.220
lösche alle, was weiß ich.

01:04:56.780 --> 01:04:57.780
Das spielt erstmal keine Rolle,

01:04:57.940 --> 01:04:59.340
sondern das Wichtige ist,

01:04:59.660 --> 01:05:01.160
das ist eine abgeschlossene Welt.

01:05:01.460 --> 01:05:02.960
Ich schicke eine Anfrage hin

01:05:02.960 --> 01:05:04.000
und die wird bearbeitet

01:05:04.000 --> 01:05:04.960
und dann wird sie zurückgeschickt.

01:05:05.460 --> 01:05:07.240
Und wenn ich eine neue Anfrage hinschicke,

01:05:07.380 --> 01:05:09.340
dann hat die mit der vorherigen erstmal gar nichts zu tun.

01:05:11.420 --> 01:05:12.820
Man muss dann Tricks benutzen,

01:05:12.820 --> 01:05:15.340
damit da sozusagen so eine Kohärenz da ist,

01:05:15.440 --> 01:05:17.240
dass ich der eingeloggte Benutzer bin.

01:05:17.360 --> 01:05:19.700
Aber im Endeffekt sind das alles Tricks,

01:05:19.720 --> 01:05:25.140
um einzelne Request-Responses, um einzelne solche Zyklen so zu machen,

01:05:25.680 --> 01:05:27.580
dass die ausschauen, als ob sie zusammengehören.

01:05:27.600 --> 01:05:29.240
Du meinst sowas wie Session oder sowas?

01:05:29.940 --> 01:05:33.340
Genau, das mit Cookies, wo du dann so eine Session-ID hast,

01:05:33.900 --> 01:05:39.200
dann kannst du simulieren, dass diese verschiedenen Requests alle zusammengehören.

01:05:39.660 --> 01:05:41.300
Aber im Endeffekt sind die alle unterschiedlich.

01:05:41.380 --> 01:05:43.600
Die könnten alle an einen anderen Web-Server gehen

01:05:43.600 --> 01:05:45.660
und es würde trotzdem funktionieren.

01:05:46.100 --> 01:05:47.940
Und das ist in ganz vielen Fällen auch der Fall.

01:05:47.940 --> 01:05:50.580
naja, wenn du bei Google die Hauptseite abrufst

01:05:50.580 --> 01:05:52.000
und danach die Suche abschickst,

01:05:52.240 --> 01:05:54.800
wirst du sicherlich nicht vom gleichen Rechner bedient werden.

01:05:55.060 --> 01:05:57.720
Beziehungsweise du wirst eventuell sogar von ganz vielen Rechnern

01:05:57.720 --> 01:05:58.700
gleichzeitig bedient werden,

01:05:59.380 --> 01:06:02.100
weil die natürlich intern ganz viel Geschwindigkeit zahlen.

01:06:02.200 --> 01:06:03.040
Aber das spielt gar keine Rolle.

01:06:03.820 --> 01:06:06.340
Für dich als Client, als Browser,

01:06:07.160 --> 01:06:08.940
ist die Welt eine ganz einfache.

01:06:09.020 --> 01:06:10.900
Du schickst eine Anfrage und dann kriegst du eine Antwort zurück.

01:06:10.960 --> 01:06:12.180
Und dann ist das abgeschlossen.

01:06:12.660 --> 01:06:14.100
Und wenn du danach was Neues brauchst,

01:06:14.140 --> 01:06:15.740
schickst du eine neue Anfrage, kriegst du eine neue Antwort zurück.

01:06:17.480 --> 01:06:44.960
Bei WebSockets ist es anders. Bei WebSockets machst du eine Verbindung auf und diese Verbindung bleibt dann bestehen. Und du kannst dann über diese Verbindung Daten an den Server schicken. Der Server kann aber auch selbstständig Daten an dich schicken. Und das löst so ein Problem, was man früher hatte, wenn diese klassische, das klassische Beispiel ist eine Chat-Anwendung, wo halt einer was in sein Chat-Fenster eintippt und die anderen sollen das dann sehen.

01:06:46.220 --> 01:06:58.180
Und bei einem Request-Response-Mechanismus heißt es, dass die halt die ganze Zeit fragen müssen, gibt es schon was Neues, gibt es schon was Neues, gibt es schon was Neues und der Server die ganze Zeit Nein sagt und irgendwann sagt er halt Ja, weil da irgendjemand anders was eingetippt hat.

01:06:59.140 --> 01:07:11.800
Viel besser wäre es aber doch, wenn die alle sagen, ich bin jetzt hier und ich möchte gerne alle Nachrichten aus dem Chatraum hören und sobald es eine neue Nachricht in diesem Chatraum gibt, sagt der Server allen angeschlossenen Clients, hier ist was Neues.

01:07:12.480 --> 01:07:23.800
Dafür braucht man aber so eine bestehende Verbindung. Das heißt, dafür kannst du nicht nur sagen, beantworte mal die Anfrage, gibt es was Neues, sondern da ist die Anfrage, informiere mich, sobald es was Neues gibt.

01:07:24.760 --> 01:07:35.100
Man hat da früher ganz schlimme Technologien gemacht. Man hat dann irgendwelche Long-Polling-Requests gemacht oder irgendwelche Meteor-Sachen, die HTTP so ein bisschen verbogen haben, um das eben hinzukriegen.

01:07:36.240 --> 01:07:56.920
Und hat dann irgendwann WebSocket zum Standard gemacht, was im Wesentlichen das macht. Das ist eine HTT, das ist erstmal eine normale HTTP-Anfrage, die dann upgradet wird, damit die Verbindung nicht geschlossen wird. Und diese Verbindung bleibt dann bestehen und ist dann bidirektional. Das heißt, der Client, der Browser kann Nachrichten schicken. Es muss nicht unbedingt ein Browser sein, kann auch was anderes sein. Und der Server kann aber auch Nachrichten schicken.

01:07:57.420 --> 01:08:13.860
Und dadurch wird eben so dieses Modell, dieses Programmiermodell, was man früher hatte, ein Request kommt rein, erzeugt eine Response, ausgehebelt, weil ein Request kommt rein, heißt, wir verbinden, wir machen jetzt eine Verbindung auf und danach können sehr viele Responses darüber gehen.

01:08:13.940 --> 01:08:21.740
Da können auch noch neue Requests drüber kommen, weil der Client halt, weil jemand was in sein Chatfenster eingetippt hat und der Client sagt dann, bitte veröffentliche das in diesem Kanal.

01:08:23.200 --> 01:08:29.260
Das heißt, WebSockets sind so ein bisschen die Erweiterung,

01:08:29.780 --> 01:08:36.060
ja nicht eine Erweiterung, sondern eine Möglichkeit,

01:08:36.560 --> 01:08:38.780
rohere Netzwerkverbindungen zu haben,

01:08:38.920 --> 01:08:41.020
länger bestehende Netzwerkverbindungen zu haben

01:08:41.020 --> 01:08:46.200
aus normaler Browser-Hardware, aus normaler Browser-Software aus.

01:08:47.340 --> 01:08:48.920
Es gibt inzwischen auch ganz viele andere Clients,

01:08:49.040 --> 01:08:50.080
die WebSockets verwenden.

01:08:50.080 --> 01:08:58.540
Die meisten Native-Anwendungen werden mit ihren Servern über Websockets kommunizieren, weil das eben der Standard ist.

01:09:00.960 --> 01:09:02.340
Wie macht man sowas in Django?

01:09:04.420 --> 01:09:06.460
In Django macht man sowas erstmal gar nicht.

01:09:08.760 --> 01:09:11.140
Beziehungsweise jetzt in 3.1 kann man das eventuell machen.

01:09:11.760 --> 01:09:14.680
Die Websocket-Verbindung muss vom Client aufgebaut werden.

01:09:14.780 --> 01:09:18.520
Das heißt, der Client muss sich irgendwo anmelden und sagen, hier, ich möchte gerne einen Websocket haben.

01:09:18.520 --> 01:09:20.660
und dafür gab es eben in Django

01:09:20.660 --> 01:09:22.540
diese Erweiterung, die Channels heißt, weil

01:09:22.540 --> 01:09:24.600
Django selber kann das nicht. Django selber hat nur den

01:09:24.600 --> 01:09:25.660
Request-Response-Mechanismus.

01:09:27.460 --> 01:09:27.860
Das ist

01:09:27.860 --> 01:09:30.660
sofort ersichtlich, wenn man die erste View-Funktion schreibt,

01:09:30.780 --> 01:09:32.080
weil die eben einen Request

01:09:32.080 --> 01:09:34.500
kriegt. Und das ist genau der Request, der vom Browser

01:09:34.500 --> 01:09:36.500
geschickt wird. Der sagt, mach mal

01:09:36.500 --> 01:09:37.240
bitte Folgendes.

01:09:38.500 --> 01:09:40.460
Und das, was eine View-Funktion erzeugt,

01:09:40.480 --> 01:09:42.400
ist dann eine Response und das ist genau der

01:09:42.400 --> 01:09:44.460
Abschluss dieses, sobald die View-Funktion fertig ist,

01:09:44.500 --> 01:09:45.340
ist die Verbindung weg.

01:09:47.380 --> 01:09:48.240
Um da

01:09:48.240 --> 01:09:50.540
weiterzugehen, um da WebSockets machen zu können,

01:09:50.620 --> 01:09:52.480
braucht man eben was anderes und das war früher Channels

01:09:52.480 --> 01:09:54.460
und jetzt wandert das so langsam in Django

01:09:54.460 --> 01:09:56.420
selbst rein. Wobei, also

01:09:56.420 --> 01:09:58.640
das soll wohl nie tatsächlich nach Django reinkommen,

01:09:59.080 --> 01:10:00.420
sondern Channels wird jetzt halt

01:10:00.420 --> 01:10:02.360
das Ding zum Handeln von anderen

01:10:02.360 --> 01:10:04.620
Protokollen, die nicht HTTP sind.

01:10:06.260 --> 01:10:07.940
also, und zwar nicht nur

01:10:07.940 --> 01:10:10.540
Das ist dann halt nicht, ja, das ist dann halt Django Channels,

01:10:10.760 --> 01:10:12.220
sondern, also es ist quasi

01:10:12.220 --> 01:10:14.320
Teil des

01:10:14.320 --> 01:10:16.240
Django Channels macht halt sowas dann wie WebSockets,

01:10:16.420 --> 01:10:18.120
aber halt nicht nur das, sondern halt auch WebRTC

01:10:18.120 --> 01:10:20.420
und halt auch MQTT und so.

01:10:20.420 --> 01:10:20.720
Ja, okay.

01:10:21.720 --> 01:10:23.980
Also alles, was eben lange Verbindungen braucht.

01:10:24.380 --> 01:10:26.240
Genau, genau. Aber du kannst es dann halt

01:10:26.240 --> 01:10:27.980
schon auch an Django damit anbinden,

01:10:28.260 --> 01:10:28.960
in gewisser Weise.

01:10:30.180 --> 01:10:32.100
Genau. Und es wird halt natürlich in

01:10:32.100 --> 01:10:34.380
Channels deutlich einfacher, weil wenn die Infrastruktur

01:10:34.380 --> 01:10:36.260
für ASGI halt schon in

01:10:36.260 --> 01:10:38.180
Django drin ist,

01:10:38.320 --> 01:10:40.140
dann, genau, brauchst du da nicht nochmal einen

01:10:40.140 --> 01:10:42.140
extra anderen Server oder so, dann kannst du einfach

01:10:42.140 --> 01:10:43.900
deine ganz normale Django-Infrastruktur weiterverwenden.

01:10:44.660 --> 01:10:44.820
Ja.

01:10:46.420 --> 01:10:49.460
Ja, ja, genau, genau.

01:10:50.340 --> 01:10:52.720
Okay, also das ist das halt, was ich da als Anwendungsfall sehe,

01:10:52.820 --> 01:10:55.820
dass man da leichter sozusagen in diese Welt reinkommt.

01:10:55.940 --> 01:10:57.920
Ja, also was ich total interessant finde,

01:10:58.000 --> 01:10:59.620
also wie gesagt nochmal, also wenn ihr das nicht kennt,

01:11:00.000 --> 01:11:02.560
Phoenix Elixier, würde ich mir ein Live-View angucken.

01:11:02.580 --> 01:11:03.260
Ja, das ist super spannend.

01:11:03.460 --> 01:11:05.800
Ja, was das Ding nämlich macht, ist, also man kennt das ja so,

01:11:05.860 --> 01:11:07.700
also ich würde sagen, das, was halt jetzt die meisten Leute schon kennen,

01:11:07.700 --> 01:11:10.560
Single-Page-App mit JavaScript, da funktioniert das halt so,

01:11:10.940 --> 01:11:13.640
du machst halt irgendwie auch immer GraphQL oder REST

01:11:13.640 --> 01:11:15.360
oder sonst was abfragen irgendwie

01:11:15.360 --> 01:11:16.680
gegen ein Backend.

01:11:18.400 --> 01:11:18.800
Und

01:11:18.800 --> 01:11:21.480
da gibt es auch teilweise sowas wie WebSockets oder so,

01:11:21.560 --> 01:11:23.400
aber im Grunde das ganze State Handling

01:11:23.400 --> 01:11:25.340
deiner Applikation

01:11:25.340 --> 01:11:26.500
machst du halt im Client.

01:11:28.400 --> 01:11:29.320
Beliebig, eklig

01:11:29.320 --> 01:11:30.760
oder halt auch gut, keine Ahnung.

01:11:31.240 --> 01:11:33.400
Redux war eine Zeit lang in, ist jetzt nicht mehr so.

01:11:34.020 --> 01:11:35.320
Jetzt gibt es halt andere.

01:11:35.800 --> 01:11:36.240
Vuex.

01:11:37.060 --> 01:11:37.640
Ja, und

01:11:37.640 --> 01:11:40.840
aber im Grunde, du machst das halt

01:11:40.840 --> 01:11:42.280
in der Applikation,

01:11:42.740 --> 01:11:44.720
weil du dann halt auch

01:11:44.720 --> 01:11:46.700
da das ganze

01:11:46.700 --> 01:11:48.280
DOM-Diffing machen kannst und

01:11:48.280 --> 01:11:50.580
dann halt nur die Sachen updaten, die wirklich geändert

01:11:50.580 --> 01:11:52.760
werden müssen und

01:11:52.760 --> 01:11:54.540
so. Und damit das alles funktioniert,

01:11:54.780 --> 01:11:56.440
musst du das halt dann im Client machen und so.

01:11:57.280 --> 01:11:57.500
Und

01:11:57.500 --> 01:12:00.800
Phoenix macht das halt anders.

01:12:00.920 --> 01:12:02.060
Das macht das alles auf dem Server.

01:12:03.000 --> 01:12:04.660
Und das schickt sozusagen nicht

01:12:04.660 --> 01:12:05.620
irgendwie

01:12:05.620 --> 01:12:08.380
jetzt gedifft irgendwie den DOM zurück,

01:12:08.380 --> 01:12:10.200
sondern es schickt dir halt sozusagen die Änderung

01:12:10.200 --> 01:12:10.800
an deinem State

01:12:10.800 --> 01:12:12.880
zurück an den

01:12:12.880 --> 01:12:14.900
Client und da wird es halt direkt im DOM

01:12:14.900 --> 01:12:16.860
geändert. Aber dadurch, dass das halt

01:12:16.860 --> 01:12:18.940
sozusagen auf dem Server alles ausgerechnet wird, kann das sehr blöd

01:12:18.940 --> 01:12:20.500
sein auf dem Client. Also da ist halt

01:12:20.500 --> 01:12:23.020
irgendwie der JavaScript-Teil

01:12:23.020 --> 01:12:25.100
von diesem

01:12:25.100 --> 01:12:27.000
Live-View-Dings ist halt irgendwie so in so tausend Zeilen

01:12:27.000 --> 01:12:28.880
und ich habe einen Vortrag irgendwie

01:12:28.880 --> 01:12:30.720
von dem Entwickler davon gesehen, der meinte immer so,

01:12:31.220 --> 01:12:32.820
also er muss immer aufpassen,

01:12:32.900 --> 01:12:35.180
er hatte manchmal das Gefühl, er ist jetzt hauptsächlich JavaScript-Entwickler

01:12:35.180 --> 01:12:36.360
und da muss er sich immer selber sagen,

01:12:37.080 --> 01:12:37.420
nein,

01:12:38.540 --> 01:12:40.680
Ich fand diese JavaScript-Frameworks

01:12:40.680 --> 01:12:42.440
alle immer ganz furchtbar und

01:12:42.440 --> 01:12:44.280
ich wollte das anders machen und

01:12:44.280 --> 01:12:46.520
ich sollte nicht jetzt anfangen

01:12:46.520 --> 01:12:48.120
irgendwie das nächste verrückte

01:12:48.120 --> 01:12:50.180
JavaScript-Font endzuschreiben, sondern das muss

01:12:50.180 --> 01:12:52.260
so wenig JavaScript bleiben wie möglich

01:12:52.260 --> 01:12:54.380
und es ist halt auch relativ wenig, es sind halt irgendwie

01:12:54.380 --> 01:12:56.320
tausend Zeilen oder so und

01:12:56.320 --> 01:12:58.440
alles andere passiert auf dem Server

01:12:58.440 --> 01:13:00.420
und das updatet

01:13:00.420 --> 01:13:01.800
den DOM direkt.

01:13:02.500 --> 01:13:04.460
Also was über die Leitung geht, ist tatsächlich nur

01:13:04.460 --> 01:13:05.260
so etwas wie

01:13:05.260 --> 01:13:08.000
Name des

01:13:08.000 --> 01:13:10.280
Attributs von irgendeinem Formularfeld

01:13:10.280 --> 01:13:12.120
oder sowas, dann neuer Wert und dann

01:13:12.120 --> 01:13:13.600
wird es halt geändert und zwar direkt im DOM.

01:13:14.480 --> 01:13:15.660
Und das ist halt natürlich nochmal

01:13:15.660 --> 01:13:18.020
deutlich schneller, als man das normalerweise

01:13:18.020 --> 01:13:19.380
so gewöhnt ist von den

01:13:19.380 --> 01:13:21.960
JavaScript-Frameworks und

01:13:21.960 --> 01:13:23.620
es ist halt weniger Kram auf der Leitung.

01:13:24.060 --> 01:13:25.780
Was man normalerweise, was man selbst bei

01:13:25.780 --> 01:13:27.860
diesen Single-Page-Apps-Geschichten halt

01:13:27.860 --> 01:13:29.060
auf der Leitung hat, ist ja nicht nur

01:13:29.060 --> 01:13:31.280
der Payload, der übertragen wird

01:13:31.280 --> 01:13:33.860
von den APs

01:13:33.860 --> 01:13:35.480
sozusagen, also weiß ich nicht, irgendwelches JSON,

01:13:36.820 --> 01:13:37.860
wo halt auch ganz

01:13:37.860 --> 01:13:39.700
viel immer dupliziert wird und

01:13:39.700 --> 01:13:41.880
ganz viel Boilerplate dabei ist, sondern

01:13:41.880 --> 01:13:43.920
was halt auch da immer noch mitkommt,

01:13:44.040 --> 01:13:45.740
ist halt diese ganze Protokollgeschichte und

01:13:45.740 --> 01:13:48.160
die Cookies, ja, so 4 Kilobyte-Cookie-Kram,

01:13:48.300 --> 01:13:49.340
der da hin und her geschickt wird,

01:13:49.960 --> 01:13:51.640
dann, und

01:13:51.640 --> 01:13:53.640
es wird jedes Mal nochmal, auch

01:13:53.640 --> 01:13:55.440
der Server muss immer nochmal, ach so,

01:13:56.180 --> 01:13:57.720
ach, hier ist deine Signatur, ach, du bist der

01:13:57.720 --> 01:13:59.840
User, ach, sehr gut, und, ja, alles klar,

01:13:59.920 --> 01:14:01.820
ich merke mir das mal und vergesse es sofort wieder

01:14:01.820 --> 01:14:03.580
beim nächsten Request, ja, das ist halt eigentlich,

01:14:03.980 --> 01:14:05.700
wenn man sich anguckt, was da tatsächlich passiert auf der

01:14:05.700 --> 01:14:07.080
Leitung, es ist alles ganz schön verrückt,

01:14:07.700 --> 01:14:09.820
Und wenn man sich dem gegenüber anguckt,

01:14:09.900 --> 01:14:11.700
was Elixir da macht, da geht einfach nur

01:14:11.700 --> 01:14:13.840
die rohen Daten, die gebraucht werden,

01:14:13.920 --> 01:14:16.000
um den DOM zu ändern, gehen über die Leitung

01:14:16.000 --> 01:14:17.400
und sonst nix. Und das ist wirklich

01:14:17.400 --> 01:14:18.800
super wenig.

01:14:19.480 --> 01:14:21.580
Das klingt ziemlich schlau. Und der Witz ist,

01:14:22.340 --> 01:14:23.660
genau das Gleiche könnte man mit Django

01:14:23.660 --> 01:14:24.540
eigentlich auch machen.

01:14:25.900 --> 01:14:27.320
Du brauchst eigentlich auch nur diese tausend Zeilen.

01:14:28.320 --> 01:14:29.820
Ja, ich dachte auch schon,

01:14:30.100 --> 01:14:30.540
ich dachte so,

01:14:31.540 --> 01:14:33.940
vielleicht sollte man sich diese tausend Zeilen

01:14:33.940 --> 01:14:35.820
JavaScript da mal genau angucken

01:14:35.820 --> 01:14:38.320
und dann halt das Ganze mit Channels

01:14:38.320 --> 01:14:40.280
oder weiß ich nicht, und WebSockets machen,

01:14:40.520 --> 01:14:41.920
weil das man in den States

01:14:41.920 --> 01:14:44.000
mit Async und so super handeln kann.

01:14:44.880 --> 01:14:46.340
Das kann man in Python

01:14:46.340 --> 01:14:47.500
und mit Django ganz genauso machen.

01:14:47.700 --> 01:14:50.580
Da braucht man das Erlangen da gar nicht.

01:14:52.260 --> 01:14:53.680
Ja, also genau.

01:14:53.900 --> 01:14:55.400
Das ist halt so ein bisschen das Versprechen.

01:14:56.360 --> 01:14:57.640
Und das wäre natürlich schon sehr cool,

01:14:57.680 --> 01:14:58.460
wenn man sowas machen könnte.

01:15:00.000 --> 01:15:00.120
Ja.

01:15:02.360 --> 01:15:02.760
Genau.

01:15:04.160 --> 01:15:05.680
Wir müssen noch ein paar Schlüsselwörter sagen.

01:15:05.820 --> 01:15:08.560
bevor wir aufhören können.

01:15:08.840 --> 01:15:09.440
Was ist denn ein Bier?

01:15:10.020 --> 01:15:11.580
Soll ich mal einfach so Wörter haben?

01:15:12.160 --> 01:15:13.260
Kooperatives Multitasking.

01:15:13.380 --> 01:15:14.860
Ach ja, kooperatives Multitasking.

01:15:15.030 --> 01:15:28.410
Genau, ja, wir haben jetzt noch gar nicht die wirklichen Unterschiede. Also, genau, es gibt jetzt unterschiedliche Ansätze, wie man diese Concurrency-Geschichte hinbekommt. Ah, soll ich ein bisschen was über Geschichte erzählen? Interessiert euch das?

01:15:29.370 --> 01:15:30.670
Im 19. Jahrhundert, oder?

01:15:30.890 --> 01:15:38.710
Also, damals. Also, wie Concurrency irgendwie nach Python gekommen ist. Ich weiß nicht, ich habe das, einen Großteil davon habe ich aus der…

01:15:38.710 --> 01:15:42.990
Das hört sich an wie so ein Märchen, was man seinen Kindern erzählt. Wie Concurrency damals nach Python gekommen ist.

01:15:42.990 --> 01:15:44.450
Ich kann nur diese Serie

01:15:44.450 --> 01:15:45.870
von Lukas Langer

01:15:45.870 --> 01:15:48.370
empfehlen, da habe ich jetzt einen Teil von dem,

01:15:48.450 --> 01:15:49.050
was ich jetzt erzähle.

01:15:50.710 --> 01:15:52.290
Und zwar ist es so Mitte der

01:15:52.290 --> 01:15:54.170
90er oder so, gab es da halt so erste

01:15:54.170 --> 01:15:56.450
Anwendungen für, man will

01:15:56.450 --> 01:15:57.930
vielleicht diverse Dinge parallel machen.

01:15:58.250 --> 01:16:00.150
Ach verdammt, jetzt bin ich selber in die Falle getroffen.

01:16:01.110 --> 01:16:01.870
Concurrent machen.

01:16:02.610 --> 01:16:04.150
Nebenläufig? Nebenläufig, ja.

01:16:05.070 --> 01:16:05.850
Und zwar,

01:16:06.290 --> 01:16:08.390
da gab es das Medusa-Framework

01:16:08.390 --> 01:16:10.230
für und das wurde

01:16:10.230 --> 01:16:11.670
zum Beispiel verwendet von Google.

01:16:12.470 --> 01:16:14.510
dann, um den Webcrawler zu

01:16:14.510 --> 01:16:16.450
bauen. Und so

01:16:16.450 --> 01:16:18.290
ist halt Python ja auch irgendwie bei Google

01:16:18.290 --> 01:16:19.810
reingekommen, halt über den Crawler.

01:16:21.530 --> 01:16:22.410
Und das ist

01:16:22.410 --> 01:16:24.510
auch irgendwann dann in die Standardbibliothek reingekommen

01:16:24.510 --> 01:16:26.390
als AsyncCore. Ich glaube, das

01:16:26.390 --> 01:16:28.290
Modul ist auch heute noch in der Standardbibliothek, aber

01:16:28.290 --> 01:16:30.170
ja, deprecated.

01:16:30.670 --> 01:16:30.870
Und

01:16:30.870 --> 01:16:34.290
dann gab es halt

01:16:34.290 --> 01:16:36.110
eine ganze Zeit lang

01:16:36.110 --> 01:16:38.270
irgendwie so Ansätze, dann kam

01:16:38.270 --> 01:16:40.390
irgendwie, glaube ich, zur Jahrtausendwende irgendwie so um den Dreh

01:16:40.390 --> 01:16:41.450
irgendwie Twisted dazu.

01:16:42.470 --> 01:16:45.010
wurde dann auch viel verwendet,

01:16:45.190 --> 01:16:46.730
war aber immer inkompatibel

01:16:46.730 --> 01:16:48.790
zum Rest von

01:16:48.790 --> 01:16:50.570
Python. So die normalen Standard

01:16:50.570 --> 01:16:53.070
Bibliothek-Funktionen, die blockieren

01:16:53.070 --> 01:16:54.950
alle, die machen alle synchronen I.O. und so.

01:16:55.090 --> 01:16:56.870
Das hat nie so richtig dazu gepasst. Das heißt,

01:16:56.890 --> 01:16:58.970
es musste alles irgendwie anders gemacht werden. Das heißt, man konnte

01:16:58.970 --> 01:17:00.110
Code, den man jetzt in Twisted,

01:17:00.970 --> 01:17:03.030
wo man Twisted benutzt hatte, um das

01:17:03.030 --> 01:17:05.030
Concurrent zu machen, nicht

01:17:05.030 --> 01:17:06.870
jetzt mit irgendwas anderem verwenden, wenn man

01:17:06.870 --> 01:17:08.990
jetzt vorhatte, auf G-Event umzusteigen oder so

01:17:08.990 --> 01:17:09.550
ging das halt nicht.

01:17:11.130 --> 01:17:12.950
Ja, und

01:17:12.950 --> 01:17:14.810
aber das, aber Twisted ist auch ein riesen

01:17:14.810 --> 01:17:16.610
Ding. Es gibt ganz viele Firmen, die das

01:17:16.610 --> 01:17:18.390
für irgendwelche Netzwerkgeschichten benutzt haben.

01:17:18.570 --> 01:17:19.830
In Apple hat das ganz...

01:17:19.830 --> 01:17:22.530
Super viele Sachen, die man vorher einfach nicht machen konnte.

01:17:22.990 --> 01:17:24.650
Genau, genau. Also war, ist schon ein

01:17:24.650 --> 01:17:25.090
riesen Ding.

01:17:26.330 --> 01:17:28.550
Der Mensch, der das entwickelt hat,

01:17:28.610 --> 01:17:30.970
Levkovits,

01:17:31.170 --> 01:17:32.250
glaube ich, der hat auch

01:17:32.250 --> 01:17:34.850
den Pep zu Async.io mitgeschrieben.

01:17:37.610 --> 01:17:38.290
Später, also

01:17:38.290 --> 01:17:40.750
Async.io ist dann auch sehr stark beeinflusst

01:17:40.750 --> 01:17:41.690
von Twisted.

01:17:43.070 --> 01:17:44.830
Ein anderer starker Einfluss

01:17:44.830 --> 01:17:46.450
ist Tornado.

01:17:48.050 --> 01:17:48.810
Auch einer aus dem

01:17:48.810 --> 01:17:50.810
Tornado-Projekt hat halt auch, ist einer

01:17:50.810 --> 01:17:52.650
von den drei Leuten, die halt den

01:17:52.650 --> 01:17:54.710
Async.io-Pep mitgeschrieben haben. Der andere ist

01:17:54.710 --> 01:17:55.610
dann Guido.

01:17:57.450 --> 01:17:58.770
Also Tornado und Twisted

01:17:58.770 --> 01:18:00.110
haben das beide stark beeinflusst.

01:18:00.610 --> 01:18:02.230
Tornado, auch eine ganz interessante Geschichte.

01:18:02.730 --> 01:18:03.690
Ist auch ein Ding,

01:18:04.510 --> 01:18:06.790
was Leute geschrieben

01:18:06.790 --> 01:18:08.470
haben. Ich glaube, ursprünglich hat das mal

01:18:08.470 --> 01:18:10.290
Brad Taylor geschrieben. Brad Taylor war bei Google

01:18:10.890 --> 01:18:12.630
Der hat irgendwie Gmail gemacht

01:18:12.630 --> 01:18:14.070
und Google Maps.

01:18:15.190 --> 01:18:16.890
Und dann haben ein paar von den Leuten, auch Paul Buchheit

01:18:16.890 --> 01:18:18.390
war, glaube ich, auch dabei, die haben dann

01:18:18.390 --> 01:18:20.530
eine neue Firma gemacht, irgendwann so 2007 oder so,

01:18:20.610 --> 01:18:22.530
Friendfeed. Ich weiß nicht, ob ihr euch

01:18:22.530 --> 01:18:23.270
daran erinnert.

01:18:24.130 --> 01:18:26.230
Ich habe es auch mal gehört. Ich weiß nicht, ob ich es mal benutzt habe.

01:18:26.310 --> 01:18:28.210
Keine Ahnung. Ist dann von Facebook

01:18:28.210 --> 01:18:28.750
gekauft worden.

01:18:31.270 --> 01:18:31.590
2009.

01:18:32.730 --> 01:18:32.750
Und

01:18:32.750 --> 01:18:36.230
ja, Brad Taylor

01:18:36.230 --> 01:18:38.070
ist dann CTO von Facebook geworden.

01:18:39.350 --> 01:18:39.750
Und ich hätte ja

01:18:39.750 --> 01:18:43.310
Das letzte zufällig war auch, glaube ich, in einer Podcast-Version mit Lukas Langer.

01:18:43.750 --> 01:18:46.370
Der war ja lange bei Facebook und erzählte dann so,

01:18:46.450 --> 01:18:49.810
dass intern bei Facebook ein großer Teil von Facebook ist halt irgendwie Python.

01:18:50.810 --> 01:18:52.270
Fand ich überraschend, wusste ich gar nicht.

01:18:52.930 --> 01:18:54.870
Und so komisch, wie kam denn da Python rein?

01:18:54.970 --> 01:18:58.590
Ja gut, vielleicht über Instagram oder so, aber nee, tatsächlich irgendwie,

01:18:58.790 --> 01:19:03.050
ja, der Autor von Tornado war halt CTO von Facebook lange Zeit.

01:19:03.050 --> 01:19:06.490
Also ja, und hat da wahrscheinlich auch irgendwie seine Python-Vorlieben

01:19:06.490 --> 01:19:07.830
vielleicht so ein bisschen ausgelebt.

01:19:09.090 --> 01:19:10.190
Jedenfalls, genau.

01:19:10.290 --> 01:19:11.910
Jeder bringt seine eigene Technologie mit.

01:19:12.290 --> 01:19:15.110
Ja, genau.

01:19:15.110 --> 01:19:23.010
Und ja, das Tornado ist auch heute noch irgendwie eine ganz interessante Geschichte.

01:19:23.350 --> 01:19:25.050
Wird auch noch nach wie vor aktiv entwickelt.

01:19:25.670 --> 01:19:28.130
Ist auch bei diesen Jupiter-Geschichten liegt das irgendwie drunter.

01:19:30.650 --> 01:19:33.590
Ja, und genau.

01:19:33.770 --> 01:19:38.050
Aber das waren halt alles Dinge, die unabhängig voneinander halt existiert haben.

01:19:38.370 --> 01:19:42.210
Und mit Python 2 war das sowieso alles nicht so gut kombinierbar.

01:19:43.950 --> 01:19:50.970
Und dann, genau, ist halt 2012, glaube ich, gab es dann so erste Ansätze dazu,

01:19:51.950 --> 01:19:55.970
das mal dann tatsächlich in die Standardbibliothek und in die Sprache irgendwie reinzubringen.

01:19:55.970 --> 01:20:00.110
Und ich glaube mit 3.4, das muss dann irgendwann so 2013 gewesen sein,

01:20:01.090 --> 01:20:07.590
ich weiß es nicht so genau, ist dann halt auch sozusagen das in der Sprache gelandet,

01:20:07.650 --> 01:20:09.030
beziehungsweise in der Standardbibliothek

01:20:09.030 --> 01:20:16.030
mit diesen Dekoratoren für Async-Funktionen.

01:20:17.270 --> 01:20:20.470
Und dann in 3.5 kam die echte Sprachunterstützung

01:20:20.470 --> 01:20:23.090
mit Async-Dev und Await dazu.

01:20:23.630 --> 01:20:24.890
Also ab dann gibt es eigentlich tatsächlich

01:20:24.890 --> 01:20:26.570
richtig Unterstützung in der Syntax.

01:20:28.350 --> 01:20:30.310
Ja, und es gab noch ein paar weitere Geschichten,

01:20:30.390 --> 01:20:31.830
die dann auch später dazugekommen sind.

01:20:32.690 --> 01:20:34.090
Da hat sich auch noch einiges getan.

01:20:35.090 --> 01:20:36.370
Es ist heute viel angenehmer,

01:20:36.370 --> 01:20:38.130
das Ganze zu benutzen,

01:20:38.170 --> 01:20:39.850
also es ist viel angenehmer, das zu benutzen als früher.

01:20:41.350 --> 01:20:42.410
Und es ist

01:20:42.410 --> 01:20:43.790
eigentlich inzwischen richtig klasse.

01:20:45.330 --> 01:20:46.050
Es ist aber

01:20:46.050 --> 01:20:47.630
eine völlig andere

01:20:47.630 --> 01:20:50.130
Geschichte als jetzt.

01:20:50.370 --> 01:20:52.110
Es gibt jetzt auch andere Sachen, also man kann zum Beispiel

01:20:52.110 --> 01:20:54.470
Multistriding

01:20:54.470 --> 01:20:56.010
gab es in Python auch schon immer,

01:20:56.310 --> 01:20:58.330
war in Python 2 ganz, ganz schrecklich,

01:20:58.950 --> 01:20:59.290
weil

01:20:59.290 --> 01:21:01.630
Noch schrecklicher?

01:21:02.250 --> 01:21:02.510
Ja,

01:21:03.170 --> 01:21:06.130
weil es tatsächlich so ein Lock-on-Tension

01:21:06.130 --> 01:21:08.210
Problemen gab. Also einmal ist es natürlich langsamer,

01:21:08.310 --> 01:21:10.290
als wenn es nur in einem Thread ist. Also je mehr Threads

01:21:10.290 --> 01:21:11.390
man hat, desto langsamer wird es eigentlich.

01:21:12.210 --> 01:21:14.130
Und Python 2 ganz besonders schrecklich auf mehreren

01:21:14.130 --> 01:21:15.970
Prozessoren, weil da haben

01:21:15.970 --> 01:21:17.970
die Threads sich dann tatsächlich um den Gil gekloppt.

01:21:18.290 --> 01:21:20.110
Und ja, das Ganze wurde noch

01:21:20.110 --> 01:21:22.210
viel schlimmer, langsamer. Aber auch

01:21:22.210 --> 01:21:24.170
da seit Python 3.2 gibt es einen neuen

01:21:24.170 --> 01:21:25.290
Jill. Also

01:21:25.290 --> 01:21:28.110
in Python 2 wurde das so gemacht,

01:21:28.310 --> 01:21:30.110
oder beziehungsweise vor Python 3.2,

01:21:31.210 --> 01:21:31.470
dass

01:21:31.470 --> 01:21:34.530
der Interpreter

01:21:34.530 --> 01:21:35.830
alle 100 Ticks, also

01:21:35.830 --> 01:21:39.370
Also ein Tick ist halt irgendwie so eine, ja, ich weiß nicht.

01:21:40.250 --> 01:21:42.490
Das ist ein Opcode, oder, der ausgeführt wird.

01:21:43.370 --> 01:21:45.930
Genau, das ist sozusagen eine primitive Operation,

01:21:46.070 --> 01:21:46.930
aber das kann auch so was sein,

01:21:47.010 --> 01:21:49.330
also wenn man sagt so for i in range eine Million,

01:21:49.910 --> 01:21:51.030
dann ist das auch nur ein Tick.

01:21:52.230 --> 01:21:53.410
Das ist so ein bisschen schlecht,

01:21:53.570 --> 01:21:55.470
weil es kann halt sein, dass ein Tick sehr, sehr lange dauert.

01:21:57.350 --> 01:22:01.370
Aber das Ding hat halt fix alle, nach 100 Ticks irgendwie geguckt,

01:22:01.510 --> 01:22:03.270
okay, hat so eine Check-Funktion aufgerufen

01:22:03.270 --> 01:22:06.090
und die hat dann einmal Signal-Handling gemacht.

01:22:07.950 --> 01:22:10.270
Aber auch geguckt, okay, welcher Thread läuft denn gerade?

01:22:10.930 --> 01:22:13.090
Muss ich da irgendwas, muss ich vielleicht einen anderen Thread

01:22:13.090 --> 01:22:17.930
in die Warteschlange der Threads, die jetzt runnable sind,

01:22:18.010 --> 01:22:19.510
fürs Betriebssystem reintun oder nicht?

01:22:20.110 --> 01:22:21.410
Das ist auch so, dass Python-Threads

01:22:21.410 --> 01:22:22.610
sind echte Betriebssystem-Threads.

01:22:22.810 --> 01:22:24.490
Also was ich dann oft lese,

01:22:24.630 --> 01:22:26.610
irgendwie ist sowas wie, ja, der Python-Interpreter

01:22:26.610 --> 01:22:27.290
schedulet da irgendwas.

01:22:27.430 --> 01:22:29.130
Nee, macht er nicht, das macht das Betriebssystem.

01:22:29.930 --> 01:22:32.570
Aber der Python-Interpreter kann natürlich sagen,

01:22:32.570 --> 01:22:34.630
okay, also dieser Thread hier wäre jetzt

01:22:34.630 --> 01:22:36.270
theoretisch runnable. Wer dann

01:22:36.270 --> 01:22:37.490
vom Betriebssystem

01:22:37.490 --> 01:22:40.510
tatsächlich sozusagen, wo der Kontext-Switch

01:22:40.510 --> 01:22:42.190
hingeht und welcher dann weiter ausgeführt wird,

01:22:42.710 --> 01:22:43.810
das macht das Betriebssystem dann.

01:22:45.290 --> 01:22:46.630
Ja, und... Und wie nennt man das,

01:22:46.710 --> 01:22:48.630
Jochen? Jetzt muss ich kurz das Schlüsselwort dazwischen

01:22:48.630 --> 01:22:50.470
sagen. Präemptives

01:22:50.470 --> 01:22:52.150
Multitasking. Genau, und das ist...

01:22:52.150 --> 01:22:54.470
Weil man zwischendurch abgebrochen werden kann. Präemptives

01:22:54.470 --> 01:22:56.230
Multitasking, weil man selber

01:22:56.230 --> 01:22:58.470
sozusagen, wenn man jetzt in einem Thread ist,

01:22:58.650 --> 01:23:00.510
kann man nicht bestimmen, wann einem

01:23:00.510 --> 01:23:02.510
die Kontrolle entzogen wird oder weil man...

01:23:02.510 --> 01:23:04.610
Und es kann jederzeit passieren.

01:23:05.030 --> 01:23:05.850
Auch in,

01:23:07.330 --> 01:23:09.050
ich habe mich da mal mit jemandem

01:23:09.050 --> 01:23:10.450
darüber gestritten und musste dann leider

01:23:10.450 --> 01:23:12.910
mir zeigen lassen,

01:23:12.910 --> 01:23:14.790
dass ich da Unrecht hatte. Das kann auch

01:23:14.790 --> 01:23:16.670
innerhalb eines Python-Befehls sein.

01:23:16.950 --> 01:23:18.770
Also Python-Befehle selbst sind dann

01:23:18.770 --> 01:23:20.330
nicht atomar, sondern es sind eben diese

01:23:20.330 --> 01:23:22.790
Bytecodes, die da drunter liegen, die atomar sind.

01:23:23.690 --> 01:23:24.930
Aber so eine

01:23:24.930 --> 01:23:26.450
Zuweisung wie i plus gleich

01:23:26.450 --> 01:23:28.590
1 ist auch nicht atomar,

01:23:28.750 --> 01:23:30.750
sondern das kann

01:23:30.750 --> 01:23:31.770
zwischendurch unterbrochen werden.

01:23:32.510 --> 01:23:34.830
Und das ist da die große

01:23:34.830 --> 01:23:36.630
Gefahr daran, dass man eben innerhalb

01:23:36.630 --> 01:23:38.810
eines Befehls, den man

01:23:38.810 --> 01:23:39.770
selbst als

01:23:39.770 --> 01:23:41.670
unteilbar sieht,

01:23:42.170 --> 01:23:44.210
kann man irgendwie die Kontrolle

01:23:44.210 --> 01:23:46.750
weggenommen kriegen, es passiert irgendwas anderes, jemand anders

01:23:46.750 --> 01:23:48.390
ändert irgendeinen Wert

01:23:48.390 --> 01:23:50.970
und man selber fängt wieder an

01:23:50.970 --> 01:23:52.810
und plötzlich sind die Sachen anders, als man erwartet hätte

01:23:52.810 --> 01:23:54.110
und es passieren schreckliche Dinge, ja.

01:23:55.110 --> 01:23:56.890
Also das ist präemptives Multitasking.

01:23:57.010 --> 01:23:58.710
Präemptives Multitasking, ja, genau.

01:23:59.150 --> 01:24:00.550
Hat natürlich gewisse Vorteile,

01:24:01.010 --> 01:24:05.370
aber es ist halt, also, ja, genau, aber erstmal, um das so zu, genau,

01:24:05.430 --> 01:24:08.030
dass es präventiv ist und das, was man aber heute hauptsächlich macht

01:24:08.030 --> 01:24:12.510
und was halt auch eine gewisse Geschichte, also auch schon immer eine Geschichte hatte,

01:24:12.650 --> 01:24:18.030
auch, es sind halt diese sozusagen Dinge, die man innerhalb von dem Thread

01:24:18.570 --> 01:24:23.290
oder innerhalb von dem Prozess ausführt, also wo das Betriebssystem gar nichts darüber weiß,

01:24:23.530 --> 01:24:30.030
dass man das macht, wo man das halt selber sozusagen, ja, entscheidet,

01:24:30.810 --> 01:24:32.210
dass man jetzt die Kontrolle abgibt oder

01:24:32.210 --> 01:24:34.550
was anderes macht. Und das ist dann halt

01:24:34.550 --> 01:24:36.590
kooperatives Multitasking. Und das ist halt

01:24:36.590 --> 01:24:38.190
so das, was man kennt aus,

01:24:38.670 --> 01:24:40.470
also in Java heißen die Dinger dann Green Threads

01:24:40.470 --> 01:24:42.210
oder das ist halt auch das, was in Stackless

01:24:42.210 --> 01:24:44.290
Python passiert ist oder das, was

01:24:44.290 --> 01:24:45.610
G-Event gemacht hat.

01:24:46.770 --> 01:24:48.470
Eventlets oder so. Ja, genau.

01:24:48.590 --> 01:24:49.030
Eventlets,

01:24:49.850 --> 01:24:52.610
LibEV liegt da glaube ich zum Beispiel

01:24:52.610 --> 01:24:54.470
unter Umständen drunter

01:24:54.470 --> 01:24:56.510
oder auch LibUV, also die

01:24:56.510 --> 01:24:58.610
Eventloop

01:24:58.610 --> 01:25:00.110
von Node.js.

01:25:00.530 --> 01:25:11.290
Das ist, LibIW hat, glaube ich, Armin Rigo geschrieben, was ja auch faszinierend war, die gleichen Namen, die man, also manchmal, da tauchten viele Namen auf, die ich schon kannte.

01:25:11.310 --> 01:25:12.410
Das sind erstaunlich wenige Leute.

01:25:12.410 --> 01:25:20.770
Ja, erstaunlich wenige Leute. Ich kannte die aus anderen Teilen schon und dachte so, ach, die haben auch diese ganzen Geschichten da, da haben die auch alle irgendwie mitgemacht, das wusste ich gar nicht.

01:25:21.290 --> 01:25:23.250
Also genau, Amin Rigo habe ich nur

01:25:23.250 --> 01:25:24.970
gehört im Zusammenhang mit PyPI,

01:25:25.210 --> 01:25:25.810
aber nie mit

01:25:25.810 --> 01:25:29.250
PyPI,

01:25:29.690 --> 01:25:30.870
aber nie mit

01:25:30.870 --> 01:25:32.850
irgendwie so

01:25:32.850 --> 01:25:34.890
Concurrency-Geschichten, aber ja,

01:25:35.250 --> 01:25:36.910
der hat, glaube ich, eine Bibliothek

01:25:36.910 --> 01:25:38.910
geschrieben, GreenLed,

01:25:39.050 --> 01:25:40.650
die auf LibEV basiert

01:25:40.650 --> 01:25:43.130
und darauf basiert wieder

01:25:43.130 --> 01:25:44.890
G-Event und G-Event

01:25:44.890 --> 01:25:46.390
macht halt quasi sozusagen

01:25:46.390 --> 01:25:49.130
User-Space-Threads

01:25:49.810 --> 01:25:50.490
und

01:25:50.490 --> 01:25:52.230
macht da aber auch

01:25:52.230 --> 01:25:54.350
teilt das irgendwie so halbwegs

01:25:54.350 --> 01:25:56.390
zufällig ein, wann die laufen und wann die nicht

01:25:56.390 --> 01:25:58.310
laufen und damit das

01:25:58.310 --> 01:25:59.770
halt mit dem Rest von der

01:25:59.770 --> 01:26:02.250
synchronen und blockierenden

01:26:02.250 --> 01:26:03.910
I.O.

01:26:04.690 --> 01:26:06.070
Funktion und so im Rest von Python

01:26:06.070 --> 01:26:07.830
funktioniert, monkeypatchen sie einfach alles.

01:26:08.270 --> 01:26:09.750
So zum Beispiel das Socket-Modul, ganz böse.

01:26:09.770 --> 01:26:11.690
Das ist aber auch hart. Das ist ziemlich hart.

01:26:11.990 --> 01:26:14.230
Okay, ja, das geht natürlich

01:26:14.230 --> 01:26:14.770
auch so.

01:26:16.350 --> 01:26:17.230
Das funktioniert.

01:26:17.730 --> 01:26:19.350
Wir gehen jetzt erstmal überall rein und

01:26:19.350 --> 01:26:22.490
Ja, also das ist schon bitter,

01:26:23.210 --> 01:26:23.490
aber

01:26:23.490 --> 01:26:26.430
zum Beispiel G-Event ist halt

01:26:26.430 --> 01:26:28.290
das, was auch unter G-Unicorn liegt.

01:26:28.550 --> 01:26:29.570
Deswegen heißt das Ding G-Unicorn.

01:26:29.610 --> 01:26:30.550
Deshalb heißt es G-Unicorn.

01:26:32.130 --> 01:26:33.450
Und genau.

01:26:34.150 --> 01:26:36.450
Gab es nicht früher mal was, das hieß Green-Unicorn

01:26:36.450 --> 01:26:38.050
und es ist dann so G-Unicorn geworden?

01:26:38.270 --> 01:26:38.690
Ja, genau.

01:26:40.490 --> 01:26:41.930
Und genau, das ist halt alles

01:26:41.930 --> 01:26:43.690
sozusagen kooperatives

01:26:43.690 --> 01:26:45.870
Multitasking im weitesten Sinne, wobei

01:26:45.870 --> 01:26:48.050
weiß ich jetzt gar nicht, bei G-Event bin ich mir jetzt gar nicht so super sicher.

01:26:48.890 --> 01:26:50.510
Ja, klar, bei G-Wand ist es auch kooperativ.

01:26:50.550 --> 01:26:51.410
Ja, im Prinzip ist es auch kooperativ.

01:26:51.410 --> 01:26:54.470
Aber jetzt, im Wesentlichen jetzt ist ja Ace & Geo oder so der...

01:26:54.470 --> 01:26:56.870
Genau, das ist jetzt sozusagen der heißeste Scheiß,

01:26:56.950 --> 01:26:59.850
sozusagen, den man jetzt da macht.

01:26:59.990 --> 01:27:02.030
Und ehrlich gesagt, also ich habe ja jetzt da jetzt auch

01:27:02.030 --> 01:27:03.010
eine ganze Zeit lang Sachen...

01:27:03.010 --> 01:27:04.430
Das sieht auch deutlich besser aus als alles,

01:27:04.510 --> 01:27:05.470
was man da so vorher gemacht hat.

01:27:06.790 --> 01:27:08.110
Ja, aber im Wesentlichen heißt es doch,

01:27:08.210 --> 01:27:09.530
jedes Mal, wenn du Yield sagst,

01:27:10.290 --> 01:27:12.430
wird dir die Kontrolle erst mal weggenommen.

01:27:12.730 --> 01:27:12.930
Yield?

01:27:12.950 --> 01:27:14.310
Ja, nicht Yield, Await.

01:27:15.170 --> 01:27:16.170
Ah, wenn du Await sagst, okay.

01:27:16.550 --> 01:27:17.470
Ja, früher war es Yield.

01:27:17.790 --> 01:27:20.070
Ja, yield from, genau, das war noch die

01:27:20.070 --> 01:27:20.690
so tags davor.

01:27:21.690 --> 01:27:24.010
Aber das ist so ein bisschen der zentrale Mechanismus,

01:27:24.130 --> 01:27:26.070
oder? Dass du sagst, okay, ich mache jetzt

01:27:26.070 --> 01:27:27.990
was und sobald ich await

01:27:27.990 --> 01:27:29.310
sage, kann jemand anders was machen.

01:27:30.170 --> 01:27:31.930
Genau, genau. Und das

01:27:31.930 --> 01:27:33.750
hat eine interessante Auswirkung auf die

01:27:33.750 --> 01:27:36.050
Art oder auf die Schwierigkeit, also wie schwer

01:27:36.050 --> 01:27:38.090
das zu programmieren ist, weil wenn du präventives

01:27:38.090 --> 01:27:40.170
Multitasking hast und an jeder Stelle kann im Grunde

01:27:40.170 --> 01:27:41.510
die Kontrolle weggehen,

01:27:42.030 --> 01:27:43.570
dann alle Dinge, die irgendwie

01:27:43.570 --> 01:27:45.830
atomar sein müssen, musst du halt dann mit

01:27:45.830 --> 01:27:46.990
Logs absichern.

01:27:47.430 --> 01:27:49.390
Mit so kritischen Sektionen musst du sie absichern.

01:27:49.410 --> 01:27:51.830
Und das Problem ist halt, du darfst halt nichts vergessen.

01:27:52.050 --> 01:27:53.070
Und das kann halt überall passieren.

01:27:54.490 --> 01:27:55.610
Ja, und selbst wenn du

01:27:55.610 --> 01:27:57.730
nichts vergessen hast, kommst

01:27:57.730 --> 01:27:59.450
du immer noch in so Deadlock-Situationen rein oder

01:27:59.450 --> 01:28:01.190
in so Starving-Situationen.

01:28:01.490 --> 01:28:03.610
Selbst wenn du alles richtig machst, kann es

01:28:03.610 --> 01:28:05.610
immer noch... Wenn es eine Starving-Situation

01:28:05.610 --> 01:28:07.670
ist, es wartet irgendjemand darauf, dass irgendwie

01:28:07.670 --> 01:28:09.770
wer losrennen kann, aber da kommt einfach

01:28:09.770 --> 01:28:11.710
nichts. Ne, das

01:28:11.710 --> 01:28:13.530
ist ein Deadlock. Deadlock heißt

01:28:13.530 --> 01:28:15.650
zwei oder mehr Dinge warten auf

01:28:15.650 --> 01:28:17.650
sich gegenseitig. Und ein

01:28:17.650 --> 01:28:19.150
Starving? Dann kann keiner loslaufen.

01:28:19.530 --> 01:28:21.510
Und Starving heißt, jemand,

01:28:21.770 --> 01:28:23.490
der etwas tun könnte, kommt nie dran.

01:28:24.310 --> 01:28:25.610
Weil immer jemand anders

01:28:25.610 --> 01:28:27.450
schon was tut. Das heißt,

01:28:27.710 --> 01:28:29.330
dass der nicht selber gelockt ist,

01:28:29.330 --> 01:28:30.550
sondern dass er einfach nicht

01:28:30.550 --> 01:28:33.850
zu niedrig ist.

01:28:34.030 --> 01:28:34.990
Oder weil er immer sagt,

01:28:35.090 --> 01:28:37.390
macht ihr erstmal. Dass der sozusagen für immer

01:28:37.390 --> 01:28:39.150
wartet, obwohl er etwas tun könnte.

01:28:39.310 --> 01:28:40.230
Obwohl er nicht irgendwo...

01:28:40.230 --> 01:28:43.190
Aber die können das ja alle schon so gut.

01:28:43.310 --> 01:28:45.590
Ich bleib da mal hier stehen.

01:28:46.510 --> 01:28:47.750
Genau, und sowas passiert dann halt.

01:28:47.790 --> 01:28:50.530
Sowas passiert halt in so präemptiven Sachen,

01:28:50.690 --> 01:28:53.190
weil du keine Kontrolle drüber hast, wer läuft.

01:28:53.310 --> 01:28:55.890
Beziehungsweise die Kontrolle, die jemand hat,

01:28:56.070 --> 01:28:57.610
ist eben das Betriebssystem.

01:28:57.870 --> 01:28:59.670
Und das muss dafür sorgen,

01:28:59.670 --> 01:29:02.890
dass so ein Deadlock entweder aufgelöst wird

01:29:02.890 --> 01:29:06.770
und dass solche Starving-Situationen nicht passieren.

01:29:07.230 --> 01:29:09.110
Ja, also es gibt halt diverse Techniken,

01:29:09.250 --> 01:29:12.990
mit denen man die Probleme minimieren kann.

01:29:13.690 --> 01:29:15.310
Es gibt dann so ein paar Patterns

01:29:15.310 --> 01:29:29.150
Und wahrscheinlich würde ich auch sagen, also für die meisten Fälle nimmt man halt so einen 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 setzen muss.

01:29:30.970 --> 01:29:38.650
Ja, aber auch da ist es erstaunlich leicht, in so Situationen reinzukommen, wo du dich deadlogst. Das ist erstaunlich leicht.

01:29:39.450 --> 01:29:41.050
Ja, ja, ich würde auch sagen, also es ist halt

01:29:41.050 --> 01:29:42.090
sehr scharfkantige Geschichte.

01:29:43.550 --> 01:29:44.830
Ja, man muss da echt aufpassen

01:29:44.830 --> 01:29:46.710
und genau, achso,

01:29:47.150 --> 01:29:47.850
richtig, genau,

01:29:48.850 --> 01:29:50.690
das habe ich eben nicht mehr erzählt, genau,

01:29:50.870 --> 01:29:53.050
nach 100 Ticks immer diese Geschichten, aber das hat halt

01:29:53.050 --> 01:29:54.870
diverse Nachteile, weil Tick kann halt sehr lange

01:29:54.870 --> 01:29:57.010
sein und dann gab es halt auch diese

01:29:57.010 --> 01:29:58.410
Battles über

01:29:58.410 --> 01:29:59.950
wer kriegt den Gill

01:29:59.950 --> 01:30:02.870
quasi auf unterschiedlichen Prozessoren und da so

01:30:02.870 --> 01:30:04.590
war halt, das war, wie

01:30:04.590 --> 01:30:06.510
David Beasley, gibt es halt

01:30:06.510 --> 01:30:08.410
Understanding the Jill zum Beispiel,

01:30:08.610 --> 01:30:10.350
den Vortrag von 2014

01:30:10.350 --> 01:30:12.610
oder Verhalten auf

01:30:12.610 --> 01:30:13.950
mehreren...

01:30:13.950 --> 01:30:16.490
Also er sagte irgendwie auf

01:30:16.490 --> 01:30:18.450
einer, also mit einem Stride, also alles gut, mit mehreren

01:30:18.450 --> 01:30:19.970
Strides, nicht so toll,

01:30:20.370 --> 01:30:22.030
auf mehreren Prozessoren, diabolical.

01:30:22.570 --> 01:30:24.450
Das war wirklich irgendwie nicht schön.

01:30:25.550 --> 01:30:25.950
Und

01:30:25.950 --> 01:30:28.450
ja, das ist aber mit Python 3.2

01:30:28.450 --> 01:30:29.610
besser geworden. Da gab es einen neuen

01:30:29.610 --> 01:30:32.430
Jill und der macht das nicht mehr nach

01:30:32.430 --> 01:30:34.430
Ticks, sondern es gibt jetzt einen Zeitintervall,

01:30:34.830 --> 01:30:36.030
was halt eben

01:30:36.030 --> 01:30:37.990
dazu führt, dass halt nicht

01:30:37.990 --> 01:30:40.130
quasi Dinge für immer

01:30:40.130 --> 01:30:41.690
warten müssen, weil halt

01:30:41.690 --> 01:30:43.930
ein Tick halt super lang war.

01:30:45.210 --> 01:30:46.170
Und zwar jetzt ist es halt so,

01:30:46.290 --> 01:30:48.010
jetzt ist es nicht alle 100 Ticks, sondern jetzt ist es alle

01:30:48.010 --> 01:30:50.210
5 Millisekunden. Man kann das aber auch einstellen, wie man

01:30:50.210 --> 01:30:51.450
möchte. Also das konnte man vorher auch schon.

01:30:52.630 --> 01:30:54.190
So alle 5 Millisekunden guckt halt der

01:30:54.190 --> 01:30:54.870
Interpreter nach.

01:30:58.230 --> 01:30:59.370
Muss mal jemand anders dran.

01:30:59.550 --> 01:30:59.690
Bitte?

01:31:00.270 --> 01:31:01.250
Muss mal jemand anders dran.

01:31:01.250 --> 01:31:02.930
Ja genau, kann mal jemand anders dran oder

01:31:02.930 --> 01:31:05.050
welches Schatz könnte laufen. Wobei letztlich, wer das

01:31:05.050 --> 01:31:05.990
entscheidet, ist das Betriebssystem.

01:31:07.010 --> 01:31:08.830
Ja, und das funktioniert jetzt deutlich

01:31:08.830 --> 01:31:10.770
besser. Das funktioniert auf mehreren CPUs auch

01:31:10.770 --> 01:31:12.930
gut. Ja, es ist nicht so, dass jetzt da auf mehreren CPUs

01:31:12.930 --> 01:31:14.770
gleichzeitig was gemacht würde, aber es ist nicht

01:31:14.770 --> 01:31:16.710
mehr so, dass die Performance viel schlechter ist, als wenn man

01:31:16.710 --> 01:31:18.690
nur einen CPU hätte, was ja schon mal

01:31:18.690 --> 01:31:20.730
auch nicht so schlecht ist. Genau.

01:31:21.510 --> 01:31:22.810
Daher, also Threading kann

01:31:22.810 --> 01:31:24.730
man auch verwenden. Also es ist auch nicht

01:31:24.730 --> 01:31:26.670
so, also es funktioniert mittlerweile alles ganz gut auf

01:31:26.670 --> 01:31:28.690
Linux. Also auch 10.000 Threads aufmachen,

01:31:29.370 --> 01:31:30.710
gar kein Problem, funktioniert.

01:31:31.470 --> 01:31:32.710
Ja, neulich hast du ausprobiert, Jochen.

01:31:32.810 --> 01:31:34.310
Bei 9.500 war Schluss bei mir.

01:31:36.490 --> 01:31:36.850
Aber

01:31:36.850 --> 01:31:38.890
also das geht alles und das ist auch nicht

01:31:38.890 --> 01:31:40.750
so, das findet man auch oft, ich war überrascht,

01:31:40.830 --> 01:31:42.830
ich habe da so ein bisschen recherchiert, wie

01:31:42.830 --> 01:31:44.850
oft da so Dinge auch in Büchern

01:31:44.850 --> 01:31:46.870
drinstehen, ich habe zum Beispiel Fluent Python mir angeguckt

01:31:46.870 --> 01:31:48.610
oder auch Effective Python von

01:31:48.610 --> 01:31:50.610
Brad Slatkin, also eigentlich beides sehr renommierte

01:31:50.610 --> 01:31:52.610
Quellen, weil ich dachte so, okay, so die

01:31:52.610 --> 01:31:54.510
Standardwerke, da muss es doch drinstehen, wie es geht und die sagen

01:31:54.510 --> 01:31:56.550
beide irgendwie, ah, Threads ganz schlecht,

01:31:56.710 --> 01:31:58.250
du kannst irgendwie keine,

01:31:58.630 --> 01:32:00.210
nicht so viele Threads aufmachen, weil

01:32:00.210 --> 01:32:02.270
der Stackspace

01:32:02.270 --> 01:32:04.570
im Betriebssystem riesig, brauchst

01:32:04.570 --> 01:32:06.390
halt 8 MB, zum Beispiel sagt

01:32:06.390 --> 01:32:08.350
Effective Python, bei Fluent Python

01:32:08.350 --> 01:32:10.290
sind es halt auch immer Größenordnungen von, jeder Thread

01:32:10.290 --> 01:32:12.370
braucht so Größenordnung MB, aber das ist halt nur

01:32:12.370 --> 01:32:13.850
Virtual Memory, das ist gar nicht

01:32:13.850 --> 01:32:16.150
Resident Memory, das heißt,

01:32:16.350 --> 01:32:17.510
das stimmt so nicht.

01:32:18.470 --> 01:32:20.310
Das ist viel weniger und das

01:32:20.310 --> 01:32:22.290
Context-Switchen, also es gibt da auch so einen schönen Artikel, wo

01:32:22.290 --> 01:32:23.850
jemand das alles mal gemessen hat und das ist,

01:32:24.130 --> 01:32:26.230
eigentlich sollte das alles kein Problem sein.

01:32:27.090 --> 01:32:28.410
Und vielleicht

01:32:28.410 --> 01:32:30.250
war das früher auch ein Problem, weil auf 32-Bit

01:32:30.250 --> 01:32:32.170
ist es tatsächlich blöd, weil der

01:32:32.170 --> 01:32:34.210
REST-Space nicht so groß ist, aber 64-Bit

01:32:34.210 --> 01:32:36.330
ja, sollte

01:32:36.330 --> 01:32:37.550
alles kein Ding sein.

01:32:38.550 --> 01:32:39.750
Und ja,

01:32:40.090 --> 01:32:42.370
Context-Switchen ist auch so schnell, das sollte auch kein Problem sein.

01:32:42.810 --> 01:32:44.590
Es könnte immer noch diese Log-Contention-Probleme

01:32:44.590 --> 01:32:46.530
geben, aber ich weiß nicht so genau.

01:32:48.010 --> 01:32:48.370
Naja,

01:32:48.630 --> 01:32:49.850
und, achso, was auch so ist,

01:32:50.070 --> 01:32:51.830
der Jail wird immer automatisch

01:32:51.830 --> 01:32:54.330
abgegeben, wenn irgendwie so

01:32:54.330 --> 01:32:56.190
Netzwerk-Blocking-Funktionen aufgerufen werden.

01:32:56.490 --> 01:32:58.270
Dann ist der auch sofort immer weg.

01:32:58.870 --> 01:32:59.770
Das heißt, das passiert,

01:33:00.350 --> 01:33:01.970
selbst wenn man Präfix-Multitasking hat,

01:33:01.970 --> 01:33:04.530
genau, passiert das automatisch.

01:33:04.530 --> 01:33:05.890
Also muss man sich auch nicht selber drum kümmern,

01:33:06.330 --> 01:33:08.070
sondern da gibt der Thread, der halt irgendeinen

01:33:08.070 --> 01:33:10.290
blockierenden Netzwerkaufruf gemacht hat oder I.O.-Aufruf,

01:33:11.410 --> 01:33:12.030
da ist der

01:33:12.030 --> 01:33:13.130
Drill sofort weg.

01:33:14.210 --> 01:33:15.490
Und ja,

01:33:17.350 --> 01:33:18.290
also ich würde

01:33:18.290 --> 01:33:20.190
sagen, mit Threads kann man eigentlich auch alle Sachen

01:33:20.190 --> 01:33:22.030
so, also wenn es darum geht, I.O. zu

01:33:22.030 --> 01:33:23.870
multiplexen, das kann man mit Threads auch wunderbar machen.

01:33:24.810 --> 01:33:26.050
Es ist schwerer zu programmieren,

01:33:26.490 --> 01:33:28.070
es ist halt ätzend, dass man nicht weiß,

01:33:28.070 --> 01:33:30.090
wann die Kontrolle weggenommen wird

01:33:30.090 --> 01:33:30.450
und so.

01:33:31.730 --> 01:33:33.150
Es ist im Debugging schwierig.

01:33:33.150 --> 01:33:35.450
Im Debugging ist es ziemlich übel, ja.

01:33:35.950 --> 01:33:37.370
Probleme, die wir vorhin

01:33:37.370 --> 01:33:39.490
erzählt haben. Da kommen dann halt irgendwelche Fehlermeldungen

01:33:39.490 --> 01:33:41.650
von irgendwo her. Irgendein Callback

01:33:41.650 --> 01:33:43.730
hat mal kurz gesagt, hallo, ich sterbe.

01:33:44.130 --> 01:33:44.910
Dann steht man halt da.

01:33:45.610 --> 01:33:47.310
Aber es geht auch. Und ich würde jetzt nicht

01:33:47.310 --> 01:33:49.190
sagen, das kann man gar nicht machen, sondern

01:33:49.190 --> 01:33:51.030
ja, es geht auch.

01:33:52.190 --> 01:33:53.090
Aber tatsächlich,

01:33:53.230 --> 01:33:55.250
Async.io würde ich auch sagen mittlerweile deutlich

01:33:55.250 --> 01:33:57.370
besser, weil das ist jetzt

01:33:57.370 --> 01:33:58.630
kooperativ. Da ist es so,

01:33:59.570 --> 01:34:01.230
es dreht sozusagen die Geschichte um.

01:34:01.630 --> 01:34:02.470
Bei Threads ist es so,

01:34:03.350 --> 01:34:05.190
man kann überall die Kontrolle weggenommen

01:34:05.190 --> 01:34:07.210
kriegen und Dinge sind bedroht, solange man

01:34:07.210 --> 01:34:08.850
nicht gesagt hat, okay, ich locke das jetzt hier.

01:34:09.090 --> 01:34:11.270
Ich benutze jetzt irgendeine Kerneldatenstruktur,

01:34:11.370 --> 01:34:13.050
um zu sagen, da bitte nicht.

01:34:14.050 --> 01:34:15.070
Dann ist das geschützt,

01:34:15.170 --> 01:34:16.650
aber alles andere ist halt irgendwie

01:34:16.650 --> 01:34:19.230
wilder Westen, Drachen

01:34:19.230 --> 01:34:21.270
kommen vorbei, verbrennen an die Hütte.

01:34:21.550 --> 01:34:22.930
Also ist halt, ja, weiß man nicht.

01:34:23.570 --> 01:34:25.490
Und bei Async.io ist es quasi umgekehrt.

01:34:25.610 --> 01:34:26.270
Da gibt es halt

01:34:26.270 --> 01:34:29.090
die Stellen, an denen böse Dinge passieren können,

01:34:29.190 --> 01:34:30.870
die sieht man, die sind markiert.

01:34:31.170 --> 01:34:31.910
Da steht Await vor.

01:34:32.730 --> 01:34:35.170
Und alle anderen Sachen, der ganze andere Code,

01:34:35.650 --> 01:34:37.270
das ist einfach ganz normaler Code,

01:34:37.370 --> 01:34:38.890
der so durchläuft, wo man sich sicher sein kann,

01:34:39.310 --> 01:34:41.050
dass einem die Kontrolle da nicht weggenommen wird

01:34:41.050 --> 01:34:42.430
und da kann man auch

01:34:42.430 --> 01:34:44.950
Operationen machen und wenn da nur, wenn da

01:34:44.950 --> 01:34:46.950
kein Await kommt, dann ist das alles atomar, weil

01:34:46.950 --> 01:34:48.810
kann sonst ja gar nichts passieren.

01:34:50.050 --> 01:34:51.010
Und das ist natürlich schön, weil

01:34:51.010 --> 01:34:53.250
die Anzahl

01:34:53.250 --> 01:34:54.870
möglicher Fehlerquellen wird halt deutlich

01:34:54.870 --> 01:34:57.030
geringer, aber man

01:34:57.030 --> 01:34:58.790
bezahlt natürlich in gewisser Weise einen Preis dafür

01:34:58.790 --> 01:35:00.950
und der ist halt, naja, also man muss sich halt

01:35:00.950 --> 01:35:02.250
auch selber drum kümmern, dass das halt,

01:35:03.010 --> 01:35:05.030
dass man die Kontrolle abgibt,

01:35:05.110 --> 01:35:07.250
wenn es geht, weil man alle anderen blockiert,

01:35:07.370 --> 01:35:08.010
wenn man das nicht tut.

01:35:08.190 --> 01:35:10.730
Man muss einfach kooperativ sein.

01:35:10.770 --> 01:35:11.550
Man muss kooperativ sein.

01:35:11.710 --> 01:35:13.290
Wenn man irgendwas macht, was nicht lange dauert,

01:35:13.690 --> 01:35:15.550
dann gehen halt alle anderen kaputt,

01:35:15.810 --> 01:35:17.490
was halt auch unter Umständen natürlich

01:35:17.490 --> 01:35:18.710
sehr große Konsequenzen haben kann.

01:35:20.610 --> 01:35:21.890
Aber da sieht man dann wenigstens.

01:35:22.010 --> 01:35:24.390
Also ich meine, wenn du da dann den Interpreter unterbrichst,

01:35:24.470 --> 01:35:26.050
siehst du, wo du bist.

01:35:26.590 --> 01:35:27.350
Du siehst, wer schuld ist.

01:35:27.350 --> 01:35:29.130
Genau. Es ist auch so, dass man kann,

01:35:29.230 --> 01:35:31.490
ich glaube, Python-X,

01:35:31.950 --> 01:35:33.110
wenn man Debug anschaltet

01:35:33.110 --> 01:35:35.070
und Trace Malloc

01:35:35.070 --> 01:35:37.090
anschaltet. Das sollte man immer machen, wenn man

01:35:37.090 --> 01:35:39.090
irgendwie so Async-IO-Sachen zumindest

01:35:39.090 --> 01:35:40.690
auf der Entwicklungsseite macht, dann

01:35:40.690 --> 01:35:42.770
sollte man das immer anschalten.

01:35:43.770 --> 01:35:44.990
Produktion natürlich unter Umständen nicht,

01:35:45.170 --> 01:35:47.170
kostet auch Ressourcen, aber dann

01:35:47.170 --> 01:35:49.210
sagt einem der Interpreter zum Beispiel so was wie

01:35:49.210 --> 01:35:51.250
also hier hast du irgendwie

01:35:51.250 --> 01:35:53.010
ein Task oder diese Funktionen, hockt

01:35:53.010 --> 01:35:55.110
die CPU und zwar ganz übel, weil er das

01:35:55.110 --> 01:35:56.970
intern halt aufruft mit einem

01:35:56.970 --> 01:35:59.190
Timeout und das halt mitkriegt und dann

01:35:59.190 --> 01:36:01.170
die Exception fängt, wenn

01:36:01.170 --> 01:36:02.870
das halt zu lange dauert. Dann sagt er halt so, also

01:36:02.870 --> 01:36:04.730
diese Funktion da, die macht irgendwas Böses.

01:36:05.190 --> 01:36:06.890
Das sieht man dann tatsächlich in der Ausgabe

01:36:06.890 --> 01:36:08.850
oder sagt einem auch, wenn man Sachen nicht

01:36:08.850 --> 01:36:11.010
awaited hat und so. Type Annotation

01:36:11.010 --> 01:36:12.830
ist auch total sinnvoll, vielleicht

01:36:12.830 --> 01:36:14.850
bei so hakeligen Geschichten. Da kann

01:36:14.850 --> 01:36:16.810
einem der Interpreter auch noch eine Menge sagen,

01:36:16.910 --> 01:36:17.810
was da halt dann schief geht.

01:36:18.910 --> 01:36:20.570
Weil er halt weiß, dass da jetzt eigentlich eine

01:36:20.570 --> 01:36:22.730
Kurroutine zurückkommen sollte und so. Und wenn das halt

01:36:22.730 --> 01:36:24.590
nicht passiert und dann, ja.

01:36:25.170 --> 01:36:26.650
Also da geht

01:36:26.650 --> 01:36:27.450
einiges.

01:36:28.690 --> 01:36:30.530
Und es ist halt, wie gesagt, also die

01:36:30.530 --> 01:36:32.790
bösen Stellen sind die, wo await davor steht und alles

01:36:32.790 --> 01:36:34.770
andere ist halt sozusagen ein ganz normaler

01:36:34.770 --> 01:36:35.670
Python-Code eigentlich.

01:36:37.870 --> 01:36:38.870
Und das ist halt schon

01:36:38.870 --> 01:36:41.250
schön. Und von den Ressourcengeschichten

01:36:41.250 --> 01:36:42.550
würde ich jetzt zwar sagen,

01:36:43.050 --> 01:36:44.370
nachdem ich mich so ein bisschen damit beschäftigt habe,

01:36:44.730 --> 01:36:45.290
es ist nicht so,

01:36:46.730 --> 01:36:48.690
ich weiß, es geht mit Swatch auch,

01:36:49.270 --> 01:36:50.830
aber natürlich ist es auch so, dass

01:36:50.830 --> 01:36:52.210
die sind schon ressourcenaufwendiger.

01:36:52.870 --> 01:36:54.730
Also das habe ich

01:36:54.730 --> 01:36:56.770
jetzt nicht nachvollzogen, aber Koroutine

01:36:56.770 --> 01:36:58.850
ist halt eigentlich nur ein Funktionsaufruf und

01:36:58.850 --> 01:37:00.290
braucht halt einen Kilobyte

01:37:00.290 --> 01:37:02.770
Hauptspeicher oder so und davon halt ganz, ganz viel zu haben.

01:37:02.790 --> 01:37:04.350
ist im Grunde überhaupt kein Problem. Du kannst

01:37:04.350 --> 01:37:06.730
10 Hunderttausende davon haben,

01:37:07.130 --> 01:37:07.530
kein Ding.

01:37:08.770 --> 01:37:10.630
Du musst halt bloß schnell genug bleiben, dass du halt

01:37:10.630 --> 01:37:12.550
tatsächlich, dass diese Hunderttausend Sachen auch irgendwann

01:37:12.550 --> 01:37:14.430
alle mal wieder drankommen, aber ansonsten

01:37:14.430 --> 01:37:15.770
geht das. Und

01:37:15.770 --> 01:37:18.390
ja, da gibt es ja dann auch sehr schnelle Event-Gloops

01:37:18.390 --> 01:37:20.510
drunter, also man kann halt auch, es gibt

01:37:20.510 --> 01:37:22.470
die Referenz-Implementation der

01:37:22.470 --> 01:37:24.430
Event-Gloob in Python,

01:37:24.590 --> 01:37:26.650
die ist nicht schnell, aber die ist halt dafür da,

01:37:26.730 --> 01:37:27.990
damit man weiß, wie es funktioniert.

01:37:28.630 --> 01:37:30.470
Auch wenn man jetzt eine andere Implementation

01:37:30.470 --> 01:37:32.530
schreibt, die auch dagegen testen kann, um zu gucken, verhält die sich

01:37:32.530 --> 01:37:33.990
jetzt genauso, wie sie sollte und so.

01:37:35.710 --> 01:37:36.730
Für Produktionen

01:37:36.730 --> 01:37:37.930
kann man dann halt sowas nehmen wie

01:37:37.930 --> 01:37:40.050
diese UV-Loop,

01:37:40.730 --> 01:37:42.530
oder LeapUV, und das ist

01:37:42.530 --> 01:37:44.550
die Node.js Event-Loop und die ist halt echt sackschnell.

01:37:45.070 --> 01:37:46.070
Also, ja, und

01:37:46.070 --> 01:37:48.490
damit kriegt man halt unter Python quasi da auch

01:37:48.490 --> 01:37:50.330
dann die gleiche Geschwindigkeit hin.

01:37:51.390 --> 01:37:51.490
Ja.

01:37:53.050 --> 01:37:54.630
Haben wir erklärt, was eine Event-Loop ist?

01:37:55.490 --> 01:37:55.890
Nein.

01:37:56.350 --> 01:37:57.990
Ich hätte jetzt mal einen Vorschlag.

01:37:58.210 --> 01:38:00.270
Ich würde jetzt auch so langsam mal die Kontrolle abgeben.

01:38:00.270 --> 01:38:01.150
Ja, ja, ja.

01:38:01.750 --> 01:38:03.570
und Sleep aufrufen.

01:38:03.570 --> 01:38:04.250
Einmal Await machen.

01:38:05.170 --> 01:38:05.530
Yield.

01:38:07.370 --> 01:38:09.710
Ich würde einmal Yield sagen und dann direkt Sleep aufrufen.

01:38:09.970 --> 01:38:10.550
Ja, ja, ja.

01:38:10.570 --> 01:38:12.030
Das ist doch ein sehr schönes Stichwort, oder?

01:38:12.530 --> 01:38:12.830
Ja.

01:38:13.270 --> 01:38:14.650
Aber es hört sich für mich so an,

01:38:14.690 --> 01:38:16.650
als ob wir noch mindestens zwei, drei Episoden

01:38:16.650 --> 01:38:17.390
daraus machen müssen.

01:38:17.470 --> 01:38:18.750
Vielleicht machen wir einfach noch eine.

01:38:19.190 --> 01:38:21.490
Alle Worte gesagt haben, die gesagt werden müssen.

01:38:21.590 --> 01:38:22.810
Also mir fallen noch viele Worte ein.

01:38:22.850 --> 01:38:23.230
Ja, mir auch.

01:38:23.250 --> 01:38:24.850
Dir fallen sicherlich auch noch ganz viele Worte ein.

01:38:25.990 --> 01:38:30.110
Es ist auch, wenn ich mich so an diese Vorlesungen erinnere,

01:38:30.250 --> 01:38:31.550
die wir da gemacht haben,

01:38:31.750 --> 01:38:53.630
Und es hat eine gewisse intellektuelle Schönheit, wenn man diese ganzen Locking-Algorithmen dann hat. Wenn man die Dining-Philosophers einmal besiegt hat oder wenn man einmal die Lockless-Data-Structures alle erfunden hat. Das hat auch was Schönes, aber es ist nicht was, was man jeden Tag in seiner Arbeit machen möchte, glaube ich.

01:38:53.630 --> 01:38:55.590
Nee, es ist wirklich schwer.

01:38:56.150 --> 01:38:57.510
Das ist auch eine massive Fehlerquelle.

01:38:57.690 --> 01:38:59.990
Ja, ja. Ich finde es auch

01:38:59.990 --> 01:39:01.730
wirklich, es ist

01:39:01.730 --> 01:39:03.050
hart. Also das ist schon so.

01:39:03.050 --> 01:39:04.730
Mein Fuß brennt immer noch von so einem völligen

01:39:04.730 --> 01:39:05.850
Vorfall.

01:39:09.230 --> 01:39:09.590
Ja.

01:39:10.570 --> 01:39:11.610
Ja, also es ist einfach

01:39:11.610 --> 01:39:13.650
sehr leicht, damit Fehler zu machen. Und ich glaube,

01:39:13.750 --> 01:39:15.370
dass das einer der großen Vorteile von

01:39:15.370 --> 01:39:17.250
diesen ganzen AsyncIO-Sachen jetzt ist.

01:39:17.450 --> 01:39:19.530
Wie du eben gesagt hast, der Code ist einfach

01:39:19.530 --> 01:39:21.590
linear. Und nur wenn ich

01:39:21.590 --> 01:39:23.210
Await sage, kann irgendwas Schlimmes passieren.

01:39:23.370 --> 01:39:25.530
Ich bin in der Verantwortung, dass ich Await sagen muss,

01:39:25.650 --> 01:39:27.390
damit ich kooperativ bin, damit die anderen auch mal

01:39:27.390 --> 01:39:29.470
können. Aber solange

01:39:29.470 --> 01:39:31.410
ich das nicht sage, passiert mir nichts.

01:39:31.610 --> 01:39:33.590
Und das nimmt ganz, ganz, ganz

01:39:33.590 --> 01:39:35.250
viele von diesen Ecken und Kanten

01:39:35.250 --> 01:39:37.330
daraus, die einem sonst eben

01:39:37.330 --> 01:39:39.550
ganz schlimm da reinfahren, die einem sonst die kritischen

01:39:39.550 --> 01:39:41.150
Sektionen kaputt machen.

01:39:43.070 --> 01:39:43.410
Und das

01:39:43.410 --> 01:39:45.690
ist eine sehr gute Entwicklung. Ich begrüße

01:39:45.690 --> 01:39:47.770
das sehr. Und das war ein sehr schönes Schlusswort,

01:39:47.770 --> 01:39:48.430
lieber Johannes.

01:39:49.850 --> 01:39:51.830
Alles klar, dann... Als ob ich es geplant hätte.

01:39:53.370 --> 01:39:54.830
Ja, würde ich sagen, machen wir doch einfach

01:39:54.830 --> 01:39:56.210
vielleicht dann. Ja, an dieser Stelle

01:39:56.210 --> 01:39:58.650
bleibt uns gewogen. Hört uns, wann immer

01:39:58.650 --> 01:40:00.610
ihr uns hört, lieber gerne immer weiter.

01:40:01.230 --> 01:40:02.230
Abends, morgens, mittags, nachts.

01:40:02.830 --> 01:40:04.590
An welchem Erdballteil ihr euch gerade

01:40:04.590 --> 01:40:06.410
befindet. Oder

01:40:06.410 --> 01:40:08.610
irgendwo out of space, man weiß es immer nicht genau.

01:40:09.110 --> 01:40:09.410
Also.

01:40:11.250 --> 01:40:12.830
Ja, schön, dass ihr wieder eingeschaltet

01:40:12.830 --> 01:40:14.570
habt. Alle Kritik, Feedback und so weiter.

01:40:14.650 --> 01:40:16.710
Hallo at peisenbockers.de. Bis zum

01:40:16.710 --> 01:40:18.790
nächsten Mal. Tschüss. Bis dann. Tschüss.