Stephen Cleary gehört zu den
Top 100 Benutzern von Stack Overflow. Vor allem dank seiner asynchronen Antworten in .NET. Sein Leben beschränkt sich nicht nur auf das Programmieren: Auf Twitter schreibt er zuerst über sich selbst „Christian“ und erst dann „Entwickler“.
Im Zusammenhang mit dem Auftreten von asynchronen Streams ist sein Wissen besonders relevant: Als Berichterstatter zu diesem Thema bittet Stephens Figur nur darum. Und sehr bald wird er auf DotNext
davon erzählen . In der Zwischenzeit haben wir ihn nach all dem gefragt: Religion, Stapelüberlauf und Asynchronität.
Biografie
- Die erste Frage ist einfach: Erzählen Sie uns von Ihrer beruflichen Biografie.- Ich habe mich schon früh für das Programmieren interessiert, ich war 7-8 Jahre alt. In der Schule konnte ich dann ein kleines Programm in der Sprache Logo schreiben, und dies war meine erste Programmiererfahrung. Später, als ich 12-13 Jahre alt war, habe ich auf meinem ersten Computer gespeichert. Und als ich mich für Informatik entschied, als ich aufs College kam, war es eine ziemlich offensichtliche Entscheidung: Ich interessierte mich bereits für eine greifbare Zeit für Computer.
Nach meinem College-Abschluss begann ich 1998 bei einem lokalen Unternehmen zu arbeiten, das sich mit Förderbändern befasste, die automatisch von Fahrzeugen für die Industrie und andere Fabrikautomationen gesteuert werden. Sieben Jahre später zog das Unternehmen nach Detroit, aber ich wollte nicht dorthin ziehen, und seitdem konnte ich in verschiedenen Unternehmen arbeiten. Seit 2013 arbeite ich in den letzten anderthalb Jahren remote - in Faithlife.
- Es ist lustig, dass Sie mit Logo angefangen haben und jetzt in einem Unternehmen, dessen Hauptprodukt Logos heißt. Und was genau machst du da?- Backend: Webdienste, auf die Logos und andere Produkte des Unternehmens zugreifen. Faithlife bietet eine Reihe kirchlicher Produkte an. Logos - zum Bibelstudium. Und es gibt auch Proclaim, das für diejenigen gedacht ist, die Predigten halten (hilft bei Folien und dergleichen). Faithlife hat in der Vergangenheit Produkte für Pastoren hergestellt, aber jetzt fügen sie Dinge hinzu, die gewöhnlichen Menschen helfen.
Ich mache Backend, ich muss mich oft mit ASP.NET Web API beschäftigen und im Moment arbeite ich mit Docker. Im Moment haben wir einen Teil in der Cloud und einen Teil vor Ort, und etwas sollte überhaupt nicht in die Cloud übertragen werden, aber wir möchten einige Dinge dorthin übertragen - und ich mache es.
Religion
- Es kommt nicht oft vor, dass Sie ein Unternehmen treffen, das "kirchliche" Software herstellt. Deshalb möchte ich klarstellen: Sieht die Arbeit am Backend wie überall sonst aus oder hat es seine eigenen Besonderheiten? Und Entwickler sind normalerweise Gläubige und verwenden selbst die Produkte des Unternehmens oder nicht?- Es gibt keine grundlegenden Unterschiede in der Arbeit: Sie müssen genauso wie überall über das richtige Design der API nachdenken. Einige unserer Produkte (insbesondere Desktop-Produkte) gibt es schon sehr lange, und wir müssen uns mit alten APIs auseinandersetzen. Wenn Sie Docker verwenden, ist es wichtig, über die Abwärtskompatibilität nachzudenken. Im Allgemeinen haben wir ungefähr die gleichen Bedenken wie andere.
Obwohl Faithlife Produkte für die Kirche herstellt, ist es kein christliches Unternehmen. Um hierher zu gelangen, müssen Sie kein Christ sein: Erstens würde eine solche Auswahl gegen das amerikanische Recht verstoßen (wäre religiöse Diskriminierung bei der Einstellung), und zweitens würde das Unternehmen dies sowieso nicht wollen.
Entwickler, die Produkte des Unternehmens verwenden möchten, werden jedoch in jeder Hinsicht ermutigt. Zum Beispiel verbrachte ich kürzlich einen Schulungstag mit der Verwendung von Logos. Wir haben auch viele interne Tools. In diesem Fall sollten wir an dem Tag in der Abteilung arbeiten, die Ihr Tool verwendet, um persönlich zu sehen, wie dies geschieht.
- Auf Ihrem Twitter im Bio-Bereich gibt es die Wörter "Christian" und "Entwickler". Überschneiden sich diese beiden Teile Ihrer Identität irgendwie?- Ich würde sagen, dass sie getrennt sind. Ich habe immer versucht, das Arbeitsleben und das Zuhause zu trennen, ohne in meiner Freizeit zu arbeiten (obwohl es nicht immer geklappt hat). Die Kirche ist ein großer Teil meiner Persönlichkeit, die meisten meiner Freunde kommen von dort. Bei der Arbeit habe ich nur wenige Freunde gefunden.
"Nun, Ihre Biografie sagt auch" süchtig nach dem Schreiben von OSS ", und Menschen freie Software zu geben, klingt altruistisch und christlich. In diesem Fall gibt es keine Korrelation?- Hmm, vielleicht. Ich denke, aus philosophischer Sicht kann man die Beziehung zwischen Open Source und Christentum wirklich erkennen: In beiden Fällen liegt der Schwerpunkt auf dem von Ihnen erwähnten „Geben an Menschen“.
Es gibt auch eine „humanitäre“ Art von Open Source. Ich selbst bin daran nicht beteiligt, ich habe Allzweckbibliotheken. Aber ich kenne christliche Entwickler, die kostenlos an etwas gearbeitet haben, das sich direkt auf andere Leben auswirkt, insbesondere an Orten mit armen Menschen. Zum Beispiel eine Software, mit der Sie sicherstellen können, dass Feuermelder ordnungsgemäß funktionieren. Hier besteht natürlich eine Korrelation.
- Sie sind auch bei Stack Overflow aktiv. Ist dies auch eine Möglichkeit für Sie, der Community selbstlos etwas zu geben?- Das würde ich nicht sagen, für mich fühlt es sich eher nach "Lehren" an. Obwohl "Lehren" auch mit dem Christentum verbunden sein kann ... Meine Familie hatte viele Lehrer, und ich setze dies auf meine eigene Weise fort - nicht als Beruf, sondern mit Hilfe von Stack Overflow und Konferenzen. Also befriedige ich mein Bedürfnis danach.
Stapelüberlauf
- Wir haben noch eine Reihe von Fragen zu Stack Overflow, dem ersten verrückten. Sie haben dort kürzlich ein Abzeichen für Antworten unter Windows Phone 8 erhalten:
Wie kam es, dass Sie 2019 ein Abzeichen für Antworten auf eine fast tote Technologie erhalten haben? Stellt noch jemand Fragen über sie?- Um ein Abzeichen zu erhalten, benötigen Sie normalerweise mindestens eine bestimmte Anzahl von Antworten mit einer bestimmten Anzahl von Stimmen für diese Antworten. Ich nehme an, ich habe dieses Abzeichen bekommen, weil jetzt jemand für einen Teil meiner vor Jahren veröffentlichten Antwort gestimmt hat und damit endlich die richtige Anzahl von Stimmen erhalten hat. Das ist lustig, weil ich Windows Phone 8-Fragen schon sehr lange nicht mehr gesehen habe!
(lacht)- Auf SO ist Ihr Ruf 320.000 - und dies ist mehr als ein Viertel des Rufs des legendären John Skeet, obwohl Sie Antworten gegeben haben, die um eine Größenordnung kleiner sind als er. Wie hast du das bekommen?- Ich bin mir nicht ganz sicher. Es ist einfacher, sich einen Namen für diejenigen zu machen, die vor allen anderen auf die Website gekommen sind, und obwohl ich zu den Early Adopters gehörte, kam ich immer noch später als viele andere. Ich fing an, Fragen zu beantworten - zuerst 1-2 pro Tag, was wahnsinnig weit von John Skeet entfernt ist. Konzentriert auf das Thema Async / Warten sowie Parallelität und Multithreading - einfach, weil es dann tatsächlich meine Spezialität wurde. Vor vielen Jahren war ich bereits mit Asynchronität beschäftigt, und dann war es schmerzhaft. Als async / await auftauchte, sah ich sofort, was ihre Bedeutung war. Ich war also zur richtigen Zeit am richtigen Ort und mein „Lehrerblut“ half mir, alles in einer Sprache zu erklären, die die Leute verstanden. Und im Fall von Stack Overflow stellte sich heraus, dass ich ein lokaler Async / Wait-Spezialist war. Und John Skeet - nun, er hat es nicht direkt gesagt, aber ich nehme an, es lässt die meisten Fragen zu Async / warte auf mich. Aber er antwortet natürlich viel mehr als ich, er kann nicht eingeholt werden!
- Wenn man die Anzahl der Reputationen betrachtet, ist es leicht zu glauben, dass „eine Person die Hälfte ihres Lebens braucht, um zu antworten“ - und wie viel Zeit verbringen Sie tatsächlich mit SO?"Nicht so sehr." Ich überprüfe den Stapelüberlauf ein paar Mal am Tag und beantworte normalerweise 1-3 Fragen. Und ich bekomme die Mehrheit der positiven Stimmen für die Antworten, die ich vor Jahren hinterlassen habe. So hilft SO denen, die früher gekommen sind: Sie haben vor Jahren als erste Fragen beantwortet, Stimmen erhalten, und die Stimmen machen diese Antworten sichtbarer, und am Ende erhalten sie neue Stimmen. Dies ist ein Lawineneffekt, der alte Antworten fördert.
Es scheint mir, dass dies einige Probleme verursacht, da es manchmal neue Antworten gibt, die sich auf modernere Technologien beziehen und daher besser sind, aber die alten Antworten werden nicht aktualisiert. Aber im Allgemeinen bekomme ich die Mehrheit der Stimmen für die alten Antworten, aber ich versuche immer noch, jeden Tag neue zu beantworten. Ich verbringe nicht viel Zeit damit, ich mache es einfach ständig für viele Jahre.
- Als John Skeet auf DotNext zu uns flog, fragten wir ihn nach dem aktuellen Status von Stack Overflow und den Problemen, die er als Probleme der Site ansah. Es ist interessant zu vergleichen: Was denkst du darüber?"Ich denke, SO verbessert sich, besonders im letzten Jahr." Sie bemühen sich jetzt sehr, die Qualität der Fragen zu verbessern. Oft sind die Leute, die zuerst etwas auf dieser Site fragen, nicht damit vertraut, wie man technische Fragen richtig stellt.
Und das ist ein Problem, das es im Internet schon immer gegeben hat. In den 90ern, als alle in den Newsgroups waren, war sie auch da. Zehn Jahre später passierte alles auf den Mailinglisten und in Google Groups. Jetzt eine neue Ressource für Fragen zur Stapelüberlaufprogrammierung. Aber es gab immer Fragen zum Programmieren, und wie man eine gute Frage stellt, war schon immer ein Problem, und wie man eine freundliche Gemeinschaft aufrechterhält. Vielleicht können diese Probleme nie vollständig gelöst werden. Ich sage nicht, dass wir nicht daran arbeiten sollten - wir sollten es definitiv tun. Wenn Sie jedoch in die Vergangenheit schauen, stellt sich heraus, dass es bereits in den 90er Jahren schriftliche Tutorials zum Stellen technischer Fragen gab.
Es gibt einige Probleme, die bei Stack Overflow neu sind. Sie können damit beginnen, dass viele von ihnen nie jemand anderen gefragt haben, bevor sie ihre erste Frage gestellt haben. Daher erkennen sie in vielen Fällen einfach nicht alle Dinge, die in der Frage dargestellt werden müssen, damit sie beantwortet werden kann.
Stellen Sie sich dann vor, Sie arbeiten an einer Aufgabe. Sie sind Hals über Kopf im Code, Ihr Kopf ist mit all dem gefüllt. Und Sie betrachten eine bestimmte Sache, die sich in keiner Weise eignet. Dies ist ein kleines konkretes Detail eines großen Systems, und normalerweise fragen Sie "Wie kann ich dieses kleine Ding machen?", Ohne zu bemerken, dass Sie all diesen Kontext haben, den Sie kennen, aber Sie stellen ihn nicht in die Frage. Oft ist die Frage "Wie mache ich X" die richtige Antwort "Mach nicht X, mach Y". Dies ist eine Falle, in die Menschen beim Schreiben der ersten Fragen oft geraten. Sie erkennen nicht, dass ihre Antwort in der aktuellen Form „nicht reagiert“.
Und neben dem Problem der Qualität der Fragen gibt es auch eine Tendenz - insbesondere beim Stapelüberlauf, bei dem jeder um Punkte kämpft und versucht, so schnell wie möglich zu antworten - die Frage schnell zu schließen oder nicht die angenehmsten Antworten zu kritzeln. Ich meine nicht "boshaft", ich habe nur sehr wenige ehrlich boshafte Kommentare gesehen - nur wenige im Laufe der Jahre. Sie sind eher hart, und für den Autor der Frage wird dies als Unfreundlichkeit gelesen.
Der Stapelüberlauf hat einige einfache Schritte unternommen, um dies zu beheben. Wenn die Leute zum ersten Mal eine Frage stellen, erfahren Sie auf der Website, was darin enthalten sein soll. Sie fügten zuvor hinzu: "Schauen Sie sich diese ähnlichen Fragen an", was ein guter erster Schritt war. Und jetzt gibt es ein ganzes System, das für die erste Frage vervollständigt werden muss, was dazu beiträgt, sie gut zusammenzustellen.
Sie fügen auch Erinnerungen für diejenigen hinzu, die die Antworten schreiben. Es ist wie "Dies ist ein Neuling, sei freundlich" und es ist eine gute Möglichkeit, dich daran zu erinnern, dass die meisten Leute beim ersten Mal keine Fragen gut schreiben, und das ist völlig normal. Im Allgemeinen arbeiten sie daran. Wird dieses Problem jemals vollständig gelöst sein? Ich bezweifle. Aber Fortschritt ist möglich.
Asynchronität
- In einem Beitrag zum 10-jährigen Jubiläum des iPhone schreiben Sie, dass sein Erscheinungsbild die asynchrone Programmierung beeinflusst, da mobile Anwendungen reagieren müssen. Und können Sie einen allgemeinen historischen Hintergrund zur Entwicklung der Asynchronität für diejenigen geben, die vor kurzem mit der Entwicklung begonnen haben und die Welt nicht ohne Asynchronität / Warten gesehen haben?- Nun, asynchrone Programmierung war schon immer möglich. Ich denke, in den 60ern haben sie es bereits getan. Und er hatte lange Zeit die gleichen Vorteile: eine reaktionsschnellere Benutzeroberfläche und einen skalierbareren Serverteil. Und Support war schon immer ein Problem: Es war sehr schwierig, asynchronen Code zu verwalten. Ursprünglich wurde es auf Rückrufen aufgebaut.
Ich denke, der große Schritt war das Aufkommen von Promise. So nannten sie es in JavaScript, und in C # ist es Task oder ValueTask. Und das war ein großer Schritt nach vorne, denn jetzt haben wir ein Objekt, das die Operation darstellt. Sie können den Fortschritt überwachen und so weiter. Und Async / Warten in jeder Sprache ist im Wesentlichen nur syntaktischer Zucker um Promise.
Ich würde sagen, dass das Erscheinen von Promise das Ereignis ist, das den größten Einfluss auf asynchronen Code hatte. Und im Fall von Async / Warten ist es wichtig, dass die Zustandsmaschine für Sie erstellt wird. Früher, als wir mit Rückrufen arbeiteten, mussten wir unsere eigenen Zustandsautomaten selbst herstellen. Und es war immer schwierig, weil Sie unweigerlich einen Zustand oder Übergang vergessen haben und nichts funktioniert hat. Und es war sehr schwierig zu debuggen. Async / await brachte nicht die Fähigkeit, asynchronen Code zu schreiben, sondern die Fähigkeit, Code zu schreiben, der unterstützt werden kann.
- Und jetzt sehen Sie, dass sich die Situation beruhigt hat, oder warten bald neue Änderungen auf uns?- Ich denke jetzt ist alles ziemlich stabil. Async / await sah revolutionär aus - aber nur für diejenigen, die zuvor noch keine asynchrone Programmierung durchgeführt hatten. Und für diejenigen, die arbeiteten, fühlte es sich sehr natürlich an. Aber im Allgemeinen war dies ein großes Ereignis.
Und jetzt kommt ein weiteres Ereignis mit .NET Core 3. Sie tun das, was jeder als asynchrone Streams bezeichnet, obwohl sie tatsächlich asynchrone Aufzählungen sind. Ich denke, das wird die Leute verwirren, da es bereits einen Stream-Typ gibt, der nichts mit asynchronen Streams zu tun hat. Im Allgemeinen wird es weitere inkrementelle Verbesserungen geben. Werden wir etwas so massives sehen, als wenn sich async / await zum ersten Mal angekündigt hat? Ich glaube nicht.
Wenn Sie einen neuen Paradigmenwechsel wünschen, besteht immer die Möglichkeit eines akteursbasierten Systems. Oder so etwas wie Goroutine, wo jede Asynchronität implizit ist. Meiner Meinung nach sind diese Dinge etwas ähnlich. Das Problem ist, dass dies in .NET nicht so einfach hinzuzufügen ist. Ich denke, es gibt zu viele Einschränkungen für .NET, um dies zu tun, daher ist es unwahrscheinlich, dass dies geschieht. Wenn wir einen groß angelegten Übergang zur Actor-Welt oder zur Goroutine-Welt sehen, in der der Ansatz zur Parallelität nicht der gleiche ist wie beim heutigen Multithreading, werden völlig neue Sprachen und Laufzeiten erforderlich sein. Und .NET lohnt sich nicht. Und ich denke nicht, dass die Programmierung als Ganzes einen solchen Sprung machen wird. Vielleicht irre ich mich, aber meine aktuelle Position ist wie folgt.
- Mehr zur Frage, wie sehr sich alles im Laufe der Zeit ändert. Viele Programmierbücher sind schnell veraltet, aber wo Änderungen weniger sind, halten sie länger. Was ist mit Ihrer Parallelität in C # Cookbook , wie viel erfordert es Updates?- Gute Frage. Ich habe erst kürzlich die zweite Ausgabe veröffentlicht und die erste erschien 2014. Das heißt, fünf Jahre sind vergangen und wir befinden uns bereits in der zweiten Ausgabe - für mich sieht es nach einer schnellen Entwicklung aus.
Ich denke, es hängt immer noch davon ab, wie das Buch geschrieben ist. Ich habe versucht zu schreiben, damit es nicht so lange wie möglich veraltet ist. Sie müssen nur versuchen, sich nicht auf Dinge wie Windows Phone 8 zu beziehen. Aber es wird ohnehin unweigerlich veraltet sein. Asynchrone Streams und dergleichen erscheinen, und ich wollte solche Dinge in das Buch aufnehmen. Infolgedessen war etwas veraltet, aber der größte Teil des Materials wurde ohne Änderungen auf die neue Ausgabe migriert.
Und natürlich hängt alles davon ab, für wen das Buch ist. Natürlich läuft das Buch über die Verwendung von Visual Studio 2008 sehr schnell ab. Aber ich denke, dass es einen Platz für echte Klassiker gibt. Ich halte Code Complete für eines der besten Programmierbücher der Welt. Und wie lange wurde es geschrieben? Ich weiß nicht. Vor Jahrzehnten. Und das ist immer noch ein fantastisches Buch! Etwas darin ist veraltet, aber insgesamt ist es immer noch großartig.
- Vor kurzem gab es auf Twitter Verbesserungen an async / await, die mit einem Tweet von Vaughn Vernon begannen, dem Autor mehrerer Bücher über DTD- und Schauspielermodelle:
Er mag es nicht, asynchron zu sein / auf Wichtigkeit zu warten - seiner Meinung nach verbreitet sich dies im gesamten Code und kann zum Blockieren von Threads führen. Was denkst du darüber? Hat es sich gelohnt, etwas anderes zu entwerfen?- Ja, vielleicht ist die Tatsache, dass sich Async / Warten auf das Projekt ausbreitet, die häufigste Beschwerde. Ich möchte hier einige Dinge erwähnen.
Erstens erfordert asynchroner Code, um wirklich asynchron zu sein, Asynchronität von jedem, der ihn aufruft. Und es kommt nicht herum. Welches Paradigma Sie auch verwenden (sogar eines der alten), am Ende stoßen Sie darauf. Ich hatte einen Bericht, in dem ich alle Paradigmen chronologisch durchging und zeigte, wie der Code sauberer und besser wurde.
Es gibt verschiedene Ansätze, um die weit verbreitete Dominanz von Async / Warten zu vermeiden. Die erste besteht darin, alle Ein- / Ausgaben in separate Objekte zu isolieren. Sie können Entwurfsmuster wie Ports & Adapter verwenden: Auf diese Weise können Sie alle E / A außerhalb Ihrer Geschäftslogik enthalten, und dann ist überhaupt kein Async / Warten erforderlich. Kürzlich habe ich einen ganzen Bericht darüber gesehen, wie man "überall asynchron" verhindern kann, indem man das Projekt so umgestaltet, dass die Geschäftslogik sich nie mit E / A befasst. Ich würde diesen Ansatz empfehlen.
Es gibt einen anderen Ansatz, um mit der Dominanz von async / await umzugehen, der in .NET jedoch nicht möglich ist. Meiner Meinung nach hat Go versucht, dies mit den Goroutinen zu tun. In der Tat ist alles da - es ist ein solides Async / Warten. Sie können async / await aus der Sprache entfernen, indem Sie es dort zu allem hinzufügen und implizit machen.
Es gibt keine anderen Möglichkeiten. Als async / await angezeigt wurde, sagte jemand (ich weiß nicht genau, wer), dass es sich um einen Zombie-Virus handelt: Sobald ein Teil Ihres Codes infiziert ist, beginnt die Verteilung.
- Einige Entwickler verwenden das Akteurmodell und erklären dies durch die Einfachheit der Flusskontrolle (Akteure sind in der Tat Single-Threaded). Denken Sie, dass Entwickler mit der richtigen Auswahl an Bibliotheken die Komplexität der Programmier-Parallelität beseitigen können?"Nun, nicht ganz." Denn auch beim Schauspielermodell bleiben Probleme bestehen. Sie werden nicht auf solche Rennbedingungen wie in einem Multithread-Programm stoßen, aber Sie werden Schwierigkeiten mit der Freundschaft haben.
Zum Beispiel Probleme mit der Nachrichtenverzögerung oder mit asynchronen Nachrichten. Sie sind normalerweise erforderlich, um Deadlocks im Akteurmodell zu verhindern. Jedes Akteurmodell, das asynchrone Nachrichten verwendet, kann jedoch auch Deadlocks verursachen. Asynchrone Nachrichten können auch eigene Koordinationsprobleme verursachen. Normalerweise muss man sich auf dieser Ebene auch mit Idempotenz auseinandersetzen.
Die Verwendung von Akteuren mit asynchronen Nachrichten kann die Statusverwaltung ziemlich verwirrend machen, es sei denn, dies geschieht vollständig in Nachrichten. Und selbst in diesem Fall werden Sie Schwierigkeiten mit der eventuellen Konsistenz haben. Im Allgemeinen kann das Akteurmodell aus meiner Sicht nicht alle Probleme lösen. Ich würde es so beschreiben: Es kann sich nur ändern, wo genau die Probleme auftreten werden.
"Sie sind als Spender bekannt, verwenden aber andere Sprachen wie TypeScript." Wie sehen Sie C # und .NET, wenn Sie sie ausprobieren? Treffen Sie dort etwas, das Sie gerne in C # sehen würden?- Gute Frage. C # hat viel von anderen Sprachen übernommen. Einer von ihnen, von dem er viel genommen hat, ist Python. Und ich mag es. Ich habe jahrelang nicht in Python geschrieben, aber ich denke, dies ist eine sehr gut gestaltete Sprache. Ich schätze die Enumeratorblöcke, die C # von Python ausgeliehen hat, sehr. Und Python war einer der ersten, bei denen Async-Streams auftauchten. Wir können also sagen, dass C # es von dort übernommen hat.
In verschiedenen Sprachen mag ich verschiedene Dinge. Im Allgemeinen bevorzuge ich statisches Tippen, daher habe ich in letzter Zeit kein Python verwendet. Aus dem gleichen Grund verwende ich TypeScript anstelle von JavaScript. JavaScript hat seine Vorteile einfach aufgrund seines One-Threading. Wenn Sie sich beispielsweise die Relevanz von Reactive Extensions ansehen, werden Sie feststellen, dass dies in .NET nicht besonders akzeptiert wird. Und in JavaScript können Sie Rx überall sehen.
- Die letzten paar Fragen beziehen sich auf Ihren Bericht über DotNext. Sie werden dort über asynchrone Streams sprechen. Können Sie .NET-Entwicklern kurz sagen, was sie erwartet und warum dieser Bericht für sie nützlich sein wird?- Also mein Bericht über asynchrone Streams: Warum wurden sie der Sprache hinzugefügt und was ist das Hauptszenario für ihre Verwendung. Ich gehe das sehr pragmatisch an und gehe nicht auf alle Details ein, was unter der Haube passiert. , async streams, , , async streams, .
— . — DotNext?— , , , . , : , .
, , , . - async streams , , , . , DotNext.
DotNext 2019 Moscow 6-7 . , — .