Flask-Entwickler Armin Ronacher im Interview

Vorwort

Armin Ronacher hat sich zu einem sehr wertvollen Mitwirkenden des Python-Software-Ökosystem entwickelt, da er so weit verbreitete Projekte wie Flask und Jinja2 entworfen hat. In den letzten 10 Jahren hatte er an verschiedenen Open-Source- und kommerziellen Projekten gearbeitet, und wir haben uns sehr darauf gefreut, mit ihm über sein Leben und seine Karriere zu sprechen! In diesem Interview spricht Armin über seine Arbeit bei Sentry, teilt seine Gedanken über den Umgang mit Fehlern im Backend, spricht über die Unterschiede zwischen Rust und Python, den Ansatz der „graduellen Typisierung“ und natürlich über die Geheimnisse seiner Work-Life-Balance.

Das Interview

Evrone:  Ihre Berufsbezeichnung ist Technischer Leiter. Wie sieht Ihre tägliche Arbeit bei Sentry aus?

Armin: Aus terminlicher Sicht ist mein Tag typischerweise in zwei Teile geteilt. Ich arbeite von 9 bis etwa 15/16 Uhr, wenn ich die Kinder aus der Kindertagesstätte abhole. Anschließend habe ich spät abends/nachts einen zweiten Termin für zeitzonenübergreifende Meetings. Diese Aufteilung funktioniert gut für mich, weil ich auf diese Weise Zeit mit den Kindern habe, wenn es draußen hell ist. In vielerlei Hinsicht besteht meine Aufgabe darin, dafür zu sorgen, dass alle Menschen, die mit mir zusammenarbeiten, sich auf die Dinge konzentrieren, auf die es ankommt. Das ist besonders wichtig, da Sentry ein Unternehmen mit mehreren Standorten in verschiedenen Zeitzonen ist. Eigentlich ist es eine Mischung aus dem Einstellen von Mitarbeitern, dem Lösen von Problemen, dem Unterstützen der Systemarchitektur, der Gestaltung oder Vermittlung der Produktvision an die eigentlichen Projekte und dann einer Menge Unterstützung bei merkwürdigen technischen Fragen.

2. Evrone: Der beliebte „Full Stack“-Ansatz ermutigt Entwickler, sowohl Frontend- als auch Backend-Code zu schreiben. Heißen Sie als Entwickler, der viele Programmiersprachen und Technologie-Stacks kennt, eine solche Praxis gut?

Armin:  Das ist eine komplexe Frage, denn was ist bei einem komplexen Projekt wirklich „Full Stack“? Eine triviale Anwendung besteht sicherlich nur aus einem CRUD-Backend und einigen React-Frontends. Das Ganze ist relativ einfach nachzuvollziehen. Da Sentry jedoch ein viel komplexeres Unterfangen ist, funktioniert das hier in keiner Weise. Die vereinfachte Beschreibung dessen, was Sentry ist, ist ein Dienst, der Absturz- und Leistungsberichte aufnimmt und sie dem Benutzer zeigt. Aus technischer Sicht ist Sentry jedoch eine sehr komplexe Verarbeitungspipeline mit mehreren Datenbanken und mehreren Diensten zur Verarbeitung der Berichte, bevor sie persistent werden. Die Vorstellung, dass eine einzelne Person mit der Arbeit an all diesen Komponenten beauftragt werden könnte, um ein Feature zu liefern, ist nicht nur unrealistisch, sondern auch sehr ineffizient. Es hängt also sehr stark von der Art des Projekts ab, ob ich diesen Ansatz gutheiße.

3. Evrone:  Die jüngste Umstrukturierung von Mozilla hat viele Entwickler von Rust betroffen. Wie wird sich das auf die Sprachentwicklung auswirken?

Armin:  Mir persönlich tut es weh, Mozillas Entwicklungen zu beobachten. Wie Mozilla sind wir ein Open-Source-Projekt, das sich zu einem kommerziellen Geschäft entwickelt hat. Unsere Wege haben sich einige Male gekreuzt. Manchmal nutzen wir Mozilla-Technologien auf die gleiche Weise, wie Mozilla unsere nutzt. Ich denke, für Rust im Allgemeinen werden Mozillas Änderungen sicherlich Auswirkungen auf die Sprache haben, aber ich glaube nicht, dass Rust dadurch Schaden nehmen wird. Aber der Wegfall des Servo-Projekts wird mit Sicherheit Auswirkungen auf die Entwicklung der Sprache und der Community haben.

4. Evrone:  Was ist Ihrer Meinung nach der Hauptgrund, warum Python-Packaging immer noch so kompliziert ist?

Armin:  Das ist eine sehr komplexe Geschichte, aber ich denke, dass das Ganze auf technische Herausforderungen und mangelnden Fokus zurückzuführen ist. Um das beispielsweise mit der Rust-Community in Kontrast zu setzen: dort wurde Packaging als eine wichtige Sache anerkannt und ein Community-Projekt (cargo) für Packaging wurde Teil der Sprachentwicklung. In der Python-Welt sind diese Bemühungen immer getrennt. Die Packaging-Infrastruktur (pip, setuptools, virtualenv) wird weitgehend unabhängig von der Sprache entwickelt. Von der technischen Seite her gibt es in Python viele Unzulänglichkeiten, die einer besseren Benutzerfreundlichkeit im Wege stehen. Man kann z. B. nur eine einzige Version einer Bibliothek zur gleichen Zeit laden. Das schränkt ein, wie sehr man mit Abhängigkeiten herumspielen kann.

5. Evrone:  Wenn Sie Python, Rust, TypeScript und andere Sprachen vergleichen, mit denen Sie arbeiten: Was ist Ihrer Meinung nach die beste Strategie für einen durchschnittlichen Entwickler, um Fehler in seinem Backend-Code zu behandeln?

Armin:  Da ich für ein Unternehmen arbeite, das auf Crash-Reporting spezialisiert ist, habe ich regelmäßig mit vielen Backend-Fehlern zu tun :) Daraus habe ich gelernt, dass man genauso viel Zeit für das Designen der Fehlertypen wie für die Rückgabewerte aufwenden sollten. Man kann nicht genügend Kontextinformationen zu Fehlern haben. Es gibt eine schockierend große Menge an Code, wo Fehlermeldungen nur in eine Exception geschrieben werden und sonst nichts weiter. Irgendwann will dann jemand auf diese Fehler reagieren und fängt an, die Fehlermeldungen zu parsen. Diese Art der „strikten Typ-Fehlerbehandlung“ stellt eine Quelle großer Frustration da. Ich erinnere mich an einen Datenbank-Code, der durch Parsen der Fehlermeldung und Behandlung mehrerer Sprachen (Deutsch, Französisch usw.) auf einen bestimmten Typ von Verbindungsfehlern geprüft hat, da die Datenbank auf der anderen Seite Fehlermeldungen lokalisierte.

6. Evrone:  Gibt es irgendwelche Features der Python-Sprache oder des Ökosystems, die Sie bei der Arbeit mit Rust wirklich vermissen?

Armin:  Auf jeden Fall. Python ist eine sehr ausgereifte und erwachsene Sprache. Immer dann, wenn man woanders hin wechselt, gibt es eine Menge Dinge, die einem fehlen. Es wird viel Zeit brauchen, bis andere Ökosysteme so reichhaltig werden wie das von Python. Eines der ersten Dinge, die mir aufgefallen sind, als ich mehr Rust-Code geschrieben habe, ist, dass sich das Ökosystem schnell an die typischen „2020“-Technologien angepasst hat, aber weniger an ältere Technologien. Als ich das erste Mal mit XML statt mit JSON arbeiten musste, fiel mir auf, wie schwach beispielsweise die XML-Unterstützung von Rust ist. Weiterhin bestraft Python einen als eher „langsame“ Sprache nicht sonderlich dafür, mehr Debugging-Funktionen in einen Produktions-Build einzubauen. In Rust kann man das nicht wirklich tun, ohne eine der besten Eigenschaften (die Leistung) aus dem Fenster zu werfen. Das führt dazu, dass man damit sehr unterschiedlich programmiert.

7. Evrone:  Was ist Ihrer Meinung nach die beste Methode, das Fachwissen von Software-Entwicklern zu bewerten?

Armin:  Eine sehr schwierige Frage. Ich habe das Gefühl, dass es die richtige Art und Weise, Leute einzustellen oder zu beurteilen, nicht gibt, sondern dass viel davon abhängt, wie gut man Leute im Allgemeinen einschätzen kann. Es gibt eine ganze Community von Menschen, die nichts anderes tun, als die Interviewfragen von FAANG-Unternehmen zu „üben“, und das hat sicherlich einige Veränderungen nach sich gezogen. Meine Teams arbeiten oft an ziemlich einzigartigen Themen. Daher ist es wichtiger, herauszufinden, ob Entwickler daran interessiert sind, einzigartige und manchmal frustrierende Probleme zu lösen, und wie sie in einem Team an kniffligen Dingen arbeiten.

8. Evrone:  Sind Sie der Meinung, dass Python immer noch die beste Allzweck-Programmiersprache ist, die wir neuen Entwicklern zuerst beibringen sollten? Haben wir im Jahr 2020 irgendwelche Alternativen?

Armin:  Ich bin mir nicht sicher, ob ich Python jemals für die beste Allzweck-Programmiersprache gehalten habe, aber ich fand immer, dass sie ziemlich ausgewogen ist. Trotz all der Unzulänglichkeiten und Frustrationen, die die Sprache verursachen kann, lassen sich damit Probleme schnell lösen, und in diesem Sinne ist sie im Jahr 2020 genauso gut wie vor 15 Jahren. Ich dachte eine Zeit lang, dass JavaScript Python ersetzen würde, aber irgendwie hat die Communty die Komplexität mit offenen Armen begrüßt. Selbst die einfachsten Dinge können schnell komplex werden. Ich programmiere außerdem ein Wegwerfprojekt in Python immer noch schneller als in JavaScript, allein durch die Tatsache, dass ich nur eine Handvoll Bibliotheken benötige. Wenn ich jemandem im Jahr 2020 das Programmieren beibringen würde, würde ich wahrscheinlich C, Rust und Python als Sprachen wählen. Vermutlich hauptsächlich Python, weil man dort auch den Interpreter-Quellcode betrachten und hinter den Kulissen verstehen kann, wie alles funktioniert. Das trifft auf viele andere populäre Sprachen nicht zu.

9. Evrone:  Bei so vielen Programmiersprachen, mit denen man arbeiten kann, welches Betriebssystem und welche IDE bevorzugen Sie?

Armin:  Computer sind schrecklich. Ich habe eine Liebes/Hass-Beziehung zu macOS. Ich verwende es nach wie vor, und jedes Mal, wenn ich versuche, etwas anderes zu benutzen, kehre ich nach ein paar Wochen wieder zu macOS zurück. Ich deploye jedoch auf Linux-Rechner, und ich arbeite auch sehr viel mit Windows. IDE-mäßig benutze ich Visual Studio Code mit Vim-Bindings. Ich benutze Vim immer noch sehr oft unabhängig.

10. Evrone:  Die neue „async/await“-Syntax und die dazugehörigen Konzepte wurden kürzlich in Python, Rust und TypeScript eingeführt. Das sind alles Sprachen, mit denen Sie arbeiten. Was ist Ihre Meinung zu diesem Ansatz, Parallelität im Code zu behandeln?

Armin:  Ich bin hin und her gerissen. Ich denke, der Ansatz hat viele Vorteile, wenn er richtig eingesetzt wird. Dadurch werden aber viele Herausforderungen der Parallelität einfach verborgen. Auch ein mangelndes Management von „Widerständen“ wird dadurch offenbart. Ich vermute, dass der meiste „async/await“-Code, den es gibt, zusammenbrechen würde, wenn ich versuche, ihn an seine Grenzen zu bringen. Das ist etwas, worunter traditioneller Multi-Threading-Code (der meist einen Pool verwendet) nicht von vornherein leidet. Es ist auch wichtig zu verstehen, dass, nur weil mehrere Sprachen async/await besitzen, sie nicht automatisch den gleichen Ansatz verfolgen. Die async/await-Designs von Rust und JavaScript könnten unterschiedlicher nicht sein.

11. Evrone:  Python scheint die Welt aufzufressen. Können Sie irgendwelche reellen Konkurrenten dieser Allzweck-Programmiersprache nennen?

Armin:  Python scheint die Welt vor allem aufgrund von Data Science zu fressen. Ich denke, während sie in der Web-Welt an Popularität verliert, macht die Sprache diese Verluste in der Datenwelt schnell wieder wett. Da JavaScript nicht gut mit Zahlen umgehen kann (um es ganz offen zu sagen), ist in der Hinsicht dort kein Platz dafür. Abgesehen davon glaube ich, dass JavaScript nur aus der Notwendigkeit heraus immer beliebter wird.

12. Evrone:  Aufgrund Ihres gesamten Flask- und Open-Source-Hintergrunds, der durch Sentry noch verstärkt wird, gelten Sie als Experte für Programmiersprachen. Was denken Sie über die Zukunft von Python?

Armin:  Ich denke, Python wird sich immer mehr auf einige spezielle Ökosysteme spezialisieren und andere völlig aufgeben. Dies stimmt in gewisser Weise mit der bisherigen Funktionsweise überein. Python hat es beispielsweise aufgegeben, zu einer Sprache für Einbettungen (Spiele- oder Anwendungsskripte usw.) oder mobile Entwicklung zu werden. Man würde es auch nicht als bevorzugte Sprache für Desktop-Anwendungen verwenden, insbesondere wenn man in die App-Stores einsteigen will. Python wird jedoch wahrscheinlich für serverlose, datenwissenschaftliche und Skripting-Infrastrukturen populärer werden. Ich habe beispielsweise bemerkt, dass immer mehr Benutzer meiner Template-Engine von klassischen Webanwendungen hin zu mehr und mehr Infrastruktur-Scripting (Ansible, Salt) wechseln.

13. Evrone:  Was halten Sie von dem neuen „graduellen Typisierungs“-Ansatz, der in Python, JavaScript (über TypeScript), Ruby, PHP und anderen dynamischen Sprachen eingeführt wurde?

Armin:  Ich finde das großartig. Ich liebe TypeScript absolut, und ich denke, dass noch viele weitere Sprachen davon lernen können.

14.  Evrone:  Wie organisieren Sie als Vater von drei Kindern und Leiter der Software-Entwicklung Ihre Work-Life-Balance und wie vermeiden Sie Burnouts?

Armin:  Zum Zeitpunkt des Verfassens dieses Interviews sind es erst zwei Kinder, noch keine drei. Das Wichtigste ist, dass ich meine Kinder nicht allein erziehe. Ich habe eine wunderbare Frau, und wir kümmern uns gemeinsam um unsere Kinder. Um uns dabei zu unterstützen, ist es enorm wichtig, eine gute Kinderbetreuung zu finden. Man kann nicht 24/7 ein guter Vater oder eine gute Mutter sein. Man kann allerdings dafür sorgen, dass man seinen Kindern in der Zeit, die man mit ihnen verbringt, die richtige Aufmerksamkeit schenkt. Vor allem in den ersten Tagen der Pandemie hatten wir die Kinder die ganze Zeit zu Hause, und ich habe bemerkt, dass das weder für uns noch für sie gut war. Sie haben mehr Zeit vor dem Fernseher und dem iPad verbracht, weil wir irgendwie Meetings und die Kinder unter einen Hut bringen mussten.

Für mich persönlich habe ich, weil wir in Wien leben und der Hauptsitz in San Francisco ist, ein Zweikammersystem gewählt, bei dem ich zweimal mit einer Pause dazwischen arbeite. Für mich ist das ideal, aber ich denke nicht, dass das für alle funktioniert. Ich habe damit angefangen, eine Liste zu erstellen, in der ich aufschreibe, wann und warum mich in einer Woche etwas emotional aufgewühlt oder gestresst hat, um zu versuchen, das zu optimieren. Irgendwann fängt man dann an, sich selbst etwas besser zu verstehen. Daraus ergeben sich einige Muster.

Sobald ich eine Situation erkenne, die mich aufregen könnte, versuche ich nun nicht mehr, sie zu verhindern oder zu vermeiden. Stattdessen versuche ich frühzeitig zu erkennen, dass sie in mir eine emotionale Reaktion hervorrufen wird. Das funktioniert nicht immer, aber hat mir insgesamt schon sehr oft geholfen, ausgelassener zu sein. Zum Beispiel stören mich die Slack-Meldungen nicht mehr so sehr wie früher, selbst im „Do not Disturb“-Modus.

Das Fazit

Es war toll, dass wir uns mit Armin unterhalten konnten und mehr über seine Einstellung zum Leben und das Schreiben von Code erfahren durften. Bei Evrone arbeiten wir häufig mit dem Flask-Framework, um maßgeschneiderte Lösungen für unsere Kunden zu entwickeln. Wenn Sie coole Ideen haben und Python so sehr lieben wie wir, kontaktieren Sie uns und lassen Sie uns gemeinsam ein neues Produkt schaffen!