Kotlin mit Sebastian Aigner von JetBrains

Hallo und herzlich willkommen, liebe Programmierer-innen zu einer neuen DeepDive Folge der Programmierbar. Ich bin Dennis. Und ich. Bin Jojo. Und wir beide reden heute mit einem Gast über Kottlin. Juhu, endlich! Endlich, könnte man sagen. Genau. Zu uns zugeschaltet ist nämlich Sebastian Eigner. Sebastian, cool, dass du dabei bist. Hi. Ja, schön, dass ich heute da bin. Ja. Wie schlimm findest du es, dass wir fast 200 Folgen rund App und Webentwicklung aufgenommen haben und heute erst zu Kottlin kommen? Ach, besser spät als nie. Das passt schon. Es war auf. Jeden Fall schon seit sehr langer Zeit eine Anfrage von unseren Hörern, dass sie gerne mehr zu Kottland erfahren möchten, weil es natürlich doch eine Sprache ist, die sehr weit verbreitet ist und genutzt wird in der App und Webentwicklung. Und ja, wir haben es auch intensiv jahrelang genutzt oder nutzen es immer noch. Aber bisher war es halt immer so ein Thema, wo man auch vielleicht den richtigen Speaker erst. Mal für braucht. Genau. Und bevor wir klären, wer du bist. Wie. Würdest du denn Kottland? Juri hat gerade schon das Wort Sprache immerhin gedropt, aber dein Pitch für Kottlin, was ist Kottlin in ein bis zwei Sätzen? Ja, also ganz persönlich ist es meine große Liebe als Programmiersprache, muss ich ganz ehrlich sagen. Ich hoffe, dass das andere Leute auch so sehen. Der allgemeinere Pitch wäre eher, ich würde es beschreiben, als eine moderne Multi Paradigma Programmiersprache, die sich größtenteils auf der JVM bewegt und die das große Ziel hat, Entwickler sowohl produktiv zu machen als auch in gewisser Weise glücklich zu machen. Das wäre so meine Zusammenfassung. Das ist ein schöner, schöner Promis, Entwickler in glücklich zu machen, hört sich schon mal gut an. Du selbst bist Developer Advoca bei ChatBrain. Genau. Ich glaube oder vermute das immer noch nicht allen, was heißt immer noch? Dass nicht allen immer ganz klar ist. Kannst du uns kurz abholen? Developer Advocate. Was ist so deine Rolle? Was hast du beruflich mit Kottland zu tun? Ja, es gibt also, da gibt es ja viele Begriffe für diese, diese Art von Beruf. Developer Advocate, Evangelist, was auch immer. Letztendlich, ich nehme die Rolle ein als das Verbindungsglied zwischen der Community und dem Entwicklerteam. Also in beide Richtungen. Das heißt, auf der einen Seite bereite ich Materialien vor, Leuten Cutland beizubringen in unterschiedlichsten Formaten. Ich bin auch auf Konferenzen unterwegs und halte da entsprechend Vorträge zu den ganzen Thematiken und versuche Leuten eben möglichst viele Fähigkeiten mitzubringen, was Cutland angeht. Und umgekehrt bin ich gerne im Dialog mit Leuten aus der Community, die Feedback haben und versuche das dann so ein bisschen so als Stand-in, so als Pseudokunde für das Entwicklungsteam darzustehen und so ein bisschen die Interessen der Community dann auch wieder rückwärts zu vertreten, wenn es darum geht, wie sich die Sprache weiterentwickelt, wie sich die Tools dafür weiterentwickeln und so weiter. Teilt ihr das irgendwie? Gibt es mehrere von dir? Ich wünschte, es gäbe mehrere von mir. Dann hätte ich nicht so viel zu tun. Ich habe Kollegen, wobei ich mich trotzdem gerne selber klonen würde. Also wir haben Developer Advocates für Kottland bei ChatBrain 3, 4, irgendwie sowas in der Größenordnung. Genau, je nachdem wie man es zählt, weil Leute sich auch mit anderen Thematiken von ChatBrain Produkten noch mit auskennen und mitarbeiten. Genau, aber so in der Größenordnung. Das heißt, du bist bei ChatBrain eingestellt? Ja. Okay. Kannst du uns vielleicht da nochmal so grundsätzlich, also ich sehe mal so grundsätzlich … Also ist ja immer so ein bisschen die Frage bei Programmiersprachen: Wo kommen die irgendwie her? Wer hat das empfunden? Wer kümmert sich darum? Wie ist das bei Kottland? Es scheint ja so, dass ChatBrain da irgendwie tief mit drin ist zumindest. Ja, also ich meine, das ist das, was wir auch immer sagen. Ich meine, wir haben es erfunden. Also so ist es. Wir haben das damals aus letztendlich aus Eigenbedarf bei uns entwickelt und haben uns dann irgendwann mal dazu entschieden, das halt öffentlich zu machen. Und es wurde halt sehr gut angenommen von der größeren Programmiergemeinschaft. Und diese ganze Entwicklung von Kottlin ist eigentlich daraus resultiert, dass im Unternehmen da irgendwie Bedarf für eine Programmiersprache war und dass man sich verschiedene Programmiersprachen angeschaut hat und so festgestellt hat, alle Programmiersprachen, die da draußen existieren, bieten uns nicht das, was wir eigentlich gerne möchten. Genau. Wenn man sich so ein bisschen anschaut von praktisch von der Historie her. Chatbrains ist halt ein Unternehmen, also man kennt es vielleicht, wir bauen halt so IDEs, also Entwicklungsumgebungen wie IntelliJ, IDR, PhpStorm, Pycharm, was auch immer so frei nach dem Motto, wenn es eine Programmiersprache gibt, gibt es dafür eine Entwicklungsumgebung von Chatbrains. Wenn es keine gibt, dann gibt es ein Plugin, sie trotzdem zu unterstützen. Genau. Und das ist halt eine Codebase. Das läuft ja alles über praktisch eine Plattform. Also unten drunter sind die IDEs irgendwie alle ähnlich, die halt seit 20 Jahren auf der JVM entwickelt wurde. Ursprünglich logischerweise in Java. Aber je größer man halt solche Code Basis zieht, desto mehr kommt man dann doch an die an die Ecken und Kanten der existierenden JVM Sprachen. Da haben wir halt irgendwann im 2010er Bereich uns halt überlegt, wir brauchen irgendwas, was nicht Java ist, was moderner ist, mit dem wir schneller iterieren können, mit dem wir produktiver arbeiten können, haben uns andere Sprachen angeschaut, aber haben nicht so wirklich was gefunden, was praktisch alle Checkboxes irgendwie für uns abhakt. Also zum Beispiel Skala war so eine der Sprachen, die auch mit in der Diskussion war. Das Problem dabei war, dass der Compiler relativ langsam ist, besonders für halt große Projekte. Und dann ist unserem Team aufgefallen, dass wir eigentlich in einer sehr besonderen Position sind. Weil wenn man Entwicklungsumgebungen schreibt, dann ist man ja so oder so schon die ganze Zeit im formalen Sprachen Bereich unterwegs. Man ist die ganze Zeit am Sprachenparsen und irgendwie an ein Static Analysis machen und so weiter. Da ist man also vom Compiler ist man da gar nicht mehr so weit entfernt. Und wir hatten dann also irgendwann mal die doch sehr ambitionierte Idee, dann lass uns doch selber eine Sprache bauen. Und daraus ist dann eben ursprünglich Project Codlin entstanden, was dann über die Jahre hinweg zur Codlin Programmiersprache geworden ist. Spannend. Ich würde mal ganz gerne kurz zu deiner Person zurückgehen, weil gerade mit diesem starken Promis ist es deine große Liebe hast du gesagt zu Beginn. Würde mich schon so als Entwickler auch interessieren, wie bist du dann zu Codlin gekommen? Also warst du zu dem Zeitpunkt, als Kottland entwickelt wurde, schon bei Chatbrains? Oder hast du eigentlich dann in einem anderen Rahmen eigentlich erst Codlin kennengelernt? Hast du es nie kennengelernt und bist dann in dem Zuge dann zu Chatbrains gekommen? Ja, also ich war ein ziemlicher Java Nerd am Anfang irgendwie. Also ich war so, wenn ich das sage, dann meine ich das tatsächlich so. Also ich war der Meinung, bevor ich einen Dash Script schreibe, baue ich lieber eine kleine Java Anwendung, weil ich mich da einfach wohlfühle. Würde ich heute noch unterschreiben, dass man das machen sollte. Genau. Auf. Jeden Fall wurde ich dann durch unterschiedliche Umstände mal dazu gezwungen, eine Zeit lang iOS Entwicklung zu machen. Damals zu dem Zeitpunkt, als SWIFT komplett neu rausgekommen ist. Und SWIFT, sehr schöne Sprache, sehr moderne Sprache, habe ich mich auch ein bisschen verliebt drin. Aber nachdem die Projekte dann fertig waren, war ich so ein bisschen in der Situation, dass ich mir gedacht habe, ich kenne jetzt so eine tolle neue moderne Sprache. Aber das Ecosystem, in dem ich mich wirklich am wohlsten fühle, ist halt die JVM. Es wäre jetzt irgendwie halt echt genial, wenn es da was gäbe, was diese modernen Sprachparadigmen halt auf der JVM hat. Und das war so der erste Punkt, an dem ich irgendwie so angefangen habe zu googeln und dann eben über die ersten Versionen von von Kottland gestolpert bin. Und ja, von da aus, also das war bei mir noch während Unizeiten, ich habe mich dann wirklich in die Sprache verliebt. Also das war so ein Ding, man setzt sich halt über ein Wochenende hin und dann ist man produktiv drin. Es war nicht so wie in anderen Sprachen, die ich vorher gelernt habe, wo es die ganze Zeit ein Struggle war. Es war einfach, ich konnte mich hinsetzen und bin super schnell produktiv damit geworden. Ich habe dann meine Abschlussarbeit in Kottan auch implementiert und bin dann über 17 Umwege irgendwie bei Chatbrains gelandet. Erst über ihre Education Marketing Abteilung, wo ich mit Universitäten kooperiert habe und dann so Schritt für Schritt bin ich halt auch da in die offizielle Rolle vom Kottland Developer Advokat gerutscht. Die sich ja ziemlich perfekt anhört an der Stelle. Würdest du denn, also wenn wir davon reden, okay, es war irgendwie JavaScript an die Grenzen gestoßen und das war dann auch der Anstoß und JVM ist trotzdem irgendwie ganz cool. Ist das für dich eine Art von Nachfolger von Java oder doch einfach irgendwie eine parallele Entwicklung? Es ist halt schwierig. Ich bin der Meinung, dass also existierende Java Entwickler definitiv davon profitieren können, wenn sie sich Kotlin anschauen. Im schlimmsten Fall nur deswegen, weil sie sich dann irgendwelche Coding Stiles oder so abschauen und die dann wieder mitnehmen. Aber in den meisten Fällen sehe ich es schon als einfach eine Weiterentwicklung, sowohl von Java als auch einfach von einer modernen Anwendungsprogrammiersprache. Wir gehen ja auch noch ein bisschen über die JVM hinaus mit unseren ganzen Multiplattformen, teilen und so weiter. Also das ist schon entsprechend gewachsen. Und man sieht halt einfach, dass in vielen Bereichen Kottland Innovation schneller betreibt als andere Sprachen. Und das ist etwas, was ich sehr schön finde. Du hast. Eben gesagt, ich war selbst mal zwölf Entwickler oder habe in der iOS Welt rumgefuhrwerkt. Und kannst du noch mal ein bisschen konkreter, du hast gesagt, alles was in der JVM, dieses Umfeld der JVM hat dir gefehlt. Kannst du da noch ein bisschen konkreter darauf eingehen, was das für Sachen waren, was das außen rum betrifft? Ja, also ich bin von Natur aus jetzt eigentlich gar kein Mobile Entwickler. Also ich bin eigentlich jemand, der auch gerne so serverseitigen Kram schreibt oder irgendwelche kleinen Desktop-Applikationen oder irgendwas von Terminal, diese ganzen Sachen. Und da muss man halt einfach dazu sagen, da ist es in der SWIFT Welt hat es da die längste Zeit relativ dünn ausgeschaut. Ich muss jetzt sagen, ich weiß jetzt nicht, wie es über die letzten Jahre gegangen ist. Ja, mit halt irgendwie den FENICS und so weiter. Man hat irgendwelche Frameworks, so serverseitige Anwendungen zu machen. Aber für mich war die die JVM halt irgendwie immer so der heilige Gral, was halt einfach so Anwendungsentwicklung angeht, wenn ich das Ding auf eine Linux Maschine packen will am Ende oder auf eine Windows Maschine oder auf meinem Mac. Genau deswegen also solche Sachen. Und natürlich man hat dann auch so ein bisschen Ecosystem-Buy-in. Wenn man sich dann schon mal irgendwie Spring Boot oder andere existierende Frameworks angeschaut hat, dann will man halt auch nicht mehr wieder von null anfangen oder alles halt neu schreiben müssen. Da ist es halt dann schön, wenn man eine Alternative hat, die mit dem gesamten Ecosystem einfach schon funktioniert. Ich glaube, das kann man so aus unserer Sicht ja eigentlich nur unterstreichen, wie das bei uns in der Entwicklung war. Wir haben auch mal früher sehr viel PAP gemacht, dann hatten wir sehr viele Backends, die in Java geschrieben waren. Und bei uns war auch mal die Überlegung, okay, Java fühlt sich so ein bisschen verstaubt an. Es gibt irgendwie nicht so viele neue Sprachinnovationen, nicht so Features. Also ich glaube, das ganze Thema Null Ability oder Null-Safety, auf das werden wir noch ausführlich später zu sprechen kommen. Also wir hatten auf jeden Fall immer schon große Bauchschmerzen. Und da war Skala immer ein sehr aussichtsreicher Kandidat, wo wir auch wirklich Prototypen mitgebaut haben. Und irgendwann war es zufällig so, dass jemand gesagt hatte, da gibt es doch diese neue Sprache von Chat-Brainings. Das sieht richtig cool aus, lass uns das ausprobieren. Und wie du es eben beschrieben hast, man hat sich ein Wochenende ein paar Tage da dran gesetzt, hatte einen direkten Zugang zu der Sprache, hat sich sofort produktiv gefühlt und auch die Sprachkonzepte, die in einer der ersten Versionen damals schon zur Verfügung gestanden waren, hat wirklich sehr überzeugend, dass man gedacht hat, das ist wirklich durchdacht. Da hat man wirklich Konstrukte, die einem das Leben vereinfachen, dass auch für uns dann relativ klar war, wir wollen nicht alle unsere Java Backends in Kottland überführen, was heutzutage der Fall ist. Also ja, da einfach sehr, sehr gute Zugänglichkeit. Und ich glaube auch, dass immer, wie du es eben gerade genannt hast, in diesem Rahmen einfach die Java Virtual Machine immer so diese Basis war und einfach so auch gesetzt war für viele Applikationen. Ich glaube, heutzutage gibt es da viel mehr Auswahl. Deswegen geht ja auch viel mehr ja auch andere Konzepte. Aber sagen wir mal so die 2010er Jahre war eigentlich noch die Java Virtual Machine halt so das Status quo, irgendwie der Server Ausführung, wenn man da auf Performance und auch eine gewisse Sicherheit irgendwie gesetzt hat. Ja, zwei kleine Fragen habe ich noch, dann darfst du auch mal eine stellen. Jojo. Erste Frage, du hast damals gesagt, das war so ein bisschen ihr wolltet die ganzen Entwicklungsumgebung auch irgendwie umschreiben. Ist das heute alles in Kottland geschrieben? Nein, ist es nicht. Das ist aber auch beabsichtigt. Also das ist auch ja so ein bisschen die Philosophie von Kottland. Das ist anders als andere oxidierende Sprachen, ist unsere Aussage nicht re-writet in Kottland, sondern man kann es in Kottland neu schreiben, aber wenn man eine existierende Codebase hat, wäre es ein unglaubliches und ein unnötiges Risiko, die komplette Codebase umzuwandeln, neu zu schreiben und so weiter. Stattdessen hat eben Kottland diese Philosophie von dieser 100% Java Interop. Also wenn man ein existierendes Java Projekt hat, dann wird ohne groß Adapter schreiben oder sonst was, kann man da Kottland Klassen mit einbauen oder neue Features mit Kottland bauen und die fügen sich in das System ganz genauso ein, wie man das halt erwarten würde. Das ist eben der große Vorteil. Also ja, viele von unseren neuen, von unserenneuen Features werden alle in Kottland gebaut. Aber die Kern Sachen, die Battle testet sind, die schon lange erprobt sind, die sind in Java und ich meine, wir haben keinen Grund sie wirklich zu ändern. Ja, vielleicht müssen wir noch mal kurz erklären, warum das so einfach möglich ist, aus einem Kottland Programm auf der Java Virtual Machine auch JavaScript Code anzusprechen. Der Grund dafür ist ja, dass ja Kottland Code eigentlich in die gleiche Zwischensprache übersetzt wird, also diesen Java By Code. Das heißt, eigentlich ist sozusagen für mich Kottland nur sozusagen diese Programmier Ebene, was drunter rauskommt, aber ist etwas, was eigentlich genauso aussieht wie das, was eigentlich aus Java dann erzeugt wird. Genau, also die JVM, also die tatsächliche virtuelle Maschine, die führt den Code, der aus Kottland kommt, genauso aus wie der, der aus Java kommt. Und wenn man das eben kombiniert mit einem Sprachdesign, was auch wirklich darauf abzielt zu sagen, wir wollen halt Kompatibilität haben zwischen den Sprachen, dann kriegt man eben so was wie die Entwicklungs-Experience, die wir in Kottland haben, wo es halt wirklich ist, hier, ich habe eine Java-Klasse, wie instanziiere ich die in Kottland? Die Antwort ist genauso wie ich eine Klasse in Kottland halt auch instanziieren würde. Da gibt es keine Adapter oder sonst irgendwelche irgendwelche Zwischendinge. Es ist wirklich am Ende dann praktisch ein und dasselbe. Man kann sogar umgekehrt, das ist immer ganz schön, zu lernen. Man kann sich einen Kottland Code Snippet nehmen, kann das Compilen und dann geht man mit IntelliJ mit dem Dekompiler hin und die Compilt es wieder zu Java, zu schauen wie wäre es dann gewesen, hätte ich das in Java geschrieben? Was läuft denn da? Also für Leute, die jetzt irgendwie so Performance irgendwie optimieren wollen oder so, schauen wollen, wie viele Allocations passieren da jetzt so unter der Haube, kann man halt auch so mit drunterschauen. Am Ende ist es auch alles nur Java. Bringt das aus deiner Sicht Nachteile mit sich? Welcher Part? Dass das gekoppelt ist zu der JVM und weiß ich nicht, also das ist ein Java-Bit-Code, das heißt, da sind vielleicht Optimierungen irgendwie nur in begrenztem Maße irgendwie möglich und nicht so wie wenn man an einem Reißbrett eine neue Programmiersprache hat und nicht ein vorgefertigtes Setting, in das das reinpassen muss? Es ist eine zweischneidige Sache. Ähmwir können mal mit den wir fangen mal kurz mit den positiven Sachen an. Die JVM wird nicht umsonst als das achte Weltwunder bezeichnet. Das Ding ist ja, das ist der Wahnsinn, was man mit was man aus so Software rausholen kann, wenn man einfach Milliarden an Dollar dagegen wirft, was Performance angeht und so weiter. Also man muss wirklich dazu sagen, so eine so eine JVM, die ist halt ziemlich zügig, die hat sehr gute Performance und so weiter. Und Kottland kriegt das Ganze halt einfach kostenlos. Das ist wie wir müssen uns nicht hinsetzen und müssen ein ein ein Just in time Compiler schreiben, irgendwie unsere eigene VM irgendwie schneller zu machen oder was auch immer. Das ist praktisch alles alles for free schon so out of the box. Das ist definitiv was Positives. Auf der anderen Seite muss man natürlich sagen, ein paar Design Entscheidungen von der Sprache sind tendenziell ein bisschen problematischer, weil man natürlich, wenn man mit, wenn man auf Kompatibilität aus ist, dann muss man eventuell die ein oder andere Eigenheit von dem, mit dem man kompatibel ist, halt auch irgendwie wieder mit implementieren. Klassisches Beispiel dafür in Kopland wären zum Beispiel Arrays. Also Arrays sind so eine Thematik, die verwendet man tendenziell relativ wenig, weil die haben die genau dieselbe Semantik wie die aus Java und die ist meistens gar nicht das, was man haben will. Also so Sachen wie das Equality auf Arrays, ist jetzt vielleicht schon ein bisschen tief rein, aber Equality of Arrays auf der JVM ist immer by reference, selbst mit Equals, selbst mit der Equals-Methode, was ein bisschen Counter-intuitiv ist, aber das ist dann Quork, der einfach, also das ist halt einfach so und das können wir in Kottland halt nicht brechen. Aber unsere Antwort darauf ist halt einfach, wenn man Arrays hernimmt, dann ist eventuell sogar so schon was falsch. Wir haben eine breite Bibliothek an Collection Types für Listen und mutierbare Listen und was auch immer, die da einfach bevorzugt werden sollen. Also ja, an einigen Stellen natürlich. Man muss, man muss kleine Abstriche machen. Ich würde sagen, im Alltag ist es nicht etwas, was einem jetzt irgendwie regelmäßig sauer aufstößt. Cool. Ja, ich glaube, bevor wir in den technischen Teil einsteigen, wird mich so noch interessieren, wie sozusagen der Rahmen ist, in dem Kottlin jetzt entwickelt ist. Du hattest ja schon ausgeführt, Kottlin wurde initial von ChatBrain entwickelt. Ist es auch so, dass es heutzutage letztendlich der Haupt-Kontributor irgendwie zum Kottlin Sourcecode gibt? Oder gibt es da auch noch andere große Parteien, die sich daran beteiligen? Also zum einen ist es ja so, dass ja eigentlich für die Android Entwicklung ja Kottland inzwischen eigentlich als Sprache favorisiert wird, also auch offiziell im Google Announcment so formuliert ist, dass man, wenn man Android Code entwickelt, irgendwie Kottland dafür nutzen sollte anstatt Java. Ist es auch so, dass Google sich dann auch an der Kottlin Entwicklung beteiligt? Oder sind es auch viele Open Source Contributoren, die sich daran beteiligen? Ja, also es ist eine Mischung. Also dazu kann man erst mal am Anfang sagen, eine Sache, die uns besonders wichtig war, war, dass es eben nicht eine eine Chat-Brain-Sprache ist. Also das ist natürlich, es ist die Sprache, die wir entwickeln und wir stecken da sehr viele Ressourcen mit rein. Aber wir wollten jetzt also nicht so eine Situation haben, wo die ganzen Trade Marks irgendwie alle zu Chat-Brain gehören und wir dann volle diktatorische Kontrolle über die Sprache haben. Weil wie sich auch in der JVM Welt bereits zuvor schon mal gezeigt hat mit anderen Problemen, ist das grundsätzlich nichts, was man unbedingt haben möchte, wenn man so Richtung Richtung Vendor Lock in und so schaut. Deswegen gehört praktisch die die Kottland Sprache selbst und die die Trademarks dafür, gehören einer Foundation, die separat ist von ChatBrands. Als ChatBrands ist da mit drin. Google ist da mit drin. Da sind auch noch Leute von der University of Jackson in Boston, glaube ich. Also es sind auch Leute aus Akademie da noch mit drin, aus dem Hochschulbereich, die die Entwicklung der Sprache und vor allem inkompatible Änderungen an der Sprache kontrollieren, damit es nie so ist, dass das ChatBrainz irgendwie hergeht und sagt für unsere IDE Entwicklung wäre es aber besser, wenn wir jetzt diese ganze Sprachkonzepte einfach mal aufbrechen und ihr könnt schauen, wo ihr bleibt mit eurem Code. Das wird also bei uns nicht passieren. Dann zum Thema Contributor. Also ChatBrainz ist definitiv der Haupt Contributor. Also wir stellen über 100 Leute Vollzeit an, an Kottlan und dem Ecosystem zu arbeiten. Alles von Compiler bis Tooling bis Libraries, die eben ansprechend dafür sorgen, dass das Kottlin auch da weiterhin wächst und sich weiterentwickelt. Wir haben aber auch von der Community also Input. Das gibt sowohl in Form von Feedback und Diskussionen. Wir haben unsere unsere Kottlin Evolution und Enhancement Process, KIP, das ist das Äquivalent von RFC in anderen Sprachen, wo Leute praktisch diskutieren, wie sich die Sprache weiterentwickelt. Aber auch Leute, die einfach Pull Requests an unsere GitHub Repositories senden und da neue Features in die Sprache einbauen oder die Bild Systeme an gewisser Stelle irgendwie angenehmer zu verwenden machen und so weiter. Also es gibt definitiv auch externe Leute, die da dran mitarbeiten. Und natürlich haben wir in Kottland auch unser eigenes Library Ecosystem, Sachen, die in Kottland geschrieben sind und nicht nur nicht nur in Anführungszeichen Java Library sind, die wir halt irgendwie auch mitnehmen können. Und da gibt es natürlich auch unglaublich viele Unternehmen und Individuen, die da Sachen bauen und halt als Open Source zur Verfügung stellen, unter anderem auch Google und andere größere Player. Und was ist da so ein bisschen der Business Case für. Drip. Brains? Weil es ist ja Open Source. Jeder kann Kottland nutzen. Ja, also wie schon gesagt, auf der einen Seite, wir haben Kottland aus Eigennutz gebaut, weil wir haben die Sprache ja gebraucht. Wir sind aber auch relativ offen darüber, wir sind eine Tooling Firma und wir wollen natürlich, dass die Leute die beste Entwicklungserfahrung in unseren Tools haben und hoffentlich da dann natürlich auch in die die Alte mit Versionen investieren, die dann kostenpflichtig sind. Genau. Aber ja, also das letztendlich würde ich mal sagen, ist das so aus Business Perspektive das, wo es so hingeht. Und. Das war dann sozusagen im zweiten Schritt auch dadurch, dass es dann in Android Studio integriert war, da schon relativ früh, glaube ich, in der Version 3 ja schon irgendwie ein Kottlands Support irgendwie bestand, dass sich das so entwickelt hat, dass das dann auch in der Android Welt irgendwie so zu der de facto Standard Programmiersprache wurde. Weil das war ja initial nicht so absehbar, dass letztendlich auch in diesem ganzen Android Java Umfeld letztendlich diese Bedeutung gewinnt. Also erst mal war sozusagen eure Idee okay, damit können wir auch den Vertrieb unserer Ultimate Editions von IntelliJ irgendwie ankurbeln oder das irgendwie da zur Verfügung stellen. Und jetzt hat es natürlich noch den Effekt, dass man natürlich da noch einen weiteren großen Use Case natürlich bekommen hat, der das mit unterstützt. Ja, natürlich. Also ich meine Android Studio, also da verdienen wir jetzt nichts dran, logischerweise, weil das ist also das baut ja auf unserer Open Source Plattform, also der IntelliJ Plattform, die ist ja Apache Tool lizenziert, baut es auf. Aber es ist natürlich super, dass Google gesagt hat: „Hey, wir machen jetzt Android Entwicklung, Kottland first, was nicht nur für die Entwickler super ist, sondern natürlich auch für uns als Kottlandsprache, weil es halt einfach die Adoption wirklich stark nach oben getrieben hat. Also wenn man sich die Adoption irgendwo anschaut, wenn man da so einen Graph findet, dann sieht man da so einen Knick drin an der Stelle, wo Google gesagt hat: „Wir machen jetzt, wirunterstützen es. Und dann noch mal, als sie gesagt haben: „Wir machen Kottland first, also zwei so Knicks in unserer Wachstumskurve, definitiv. Wir entwickeln ja auch viel Flutter und das ist jetzt auch so, dass vor kurzem Google jetzt angefragt hat, die ganzen Templates zusagen für die nativen Android Teile in Kottland bereitzustellen. Weil vorher war das immer Java. Vielleicht gibt es noch einen weiteren Knicker. Nein, Quatsch. Aber ja, auch da ist es inzwischen so, dass es halt einfach die renommierte oder die propagierte Programmiersprache ist und ist ja auch gut nachzuvollziehen. Du. Willst jetzt bestimmt technisch tiefer werden. Was hältst du davon, wenn wir jetzt kurz diesen Fragenkatalog einbauen? Das ist doch mal ein schöner Break, oder? Machen wir. Das machen wir. Okay, pass auf. Mit Untermalung. Mit Untermalung. Sebastian, folgende entweder oder Fragen, die du einfach aus der Hüfte rausschießen darfst. Es geht dich als Person. Hunde oder Katzen? Katzen. Tee oder Kaffee? Abwechselnd. Auto oder Fahrrad? Auto. Java oder JavaScript? Java. Ja, ja, ja, aber gut. Mac oder Windows? Mac. Ios oder Android? Ios. Büro oder Remote? Remote. Frontend oder Backend? Backend. Funktional oder objektorientiert? Beides. Genau. Multiparadigmen. Ich sage mal funktional. Funktional. Sehr gut. Native oder Web? Native. Teamwork oder Individualist? Teamwork. Was war deine erste Programmiersprache? Free Basic. Sehr gut. Wie bist du generell zur Entwicklung gekommen? Ich glaube, ich habe irgendwie so als Zehnjähriger oder so den Film War Games gesehen und war irgendwie fasziniert von der ganzen Ästhetik und bin dann da irgendwie so halt in den Zaubertrank gefallen. Und von da aus ging es dann irgendwie immer weiter. Cool. Was war dein erster Computer? Ein ausgemustetes Thinkpad von einem Arbeitskollegen von meinem Vater, bei dem der Bildschirm kaputt war. Das heißt, ich hatte so einen 15 Zoll Röhren Monitor, der tiefer war als breit. Genau das waren gute Erfahrungen. Sehr gut. Die Frage kann ich für dich beantworten. Was ist da die liebste Programmiersprache? Codland. Sehr gut. Was ist dein liebstes Frontend Framework? Ich mag React. Ich bin da relativ Basic. Und zu guter Letzt hast du eine Lieblings App? Ich mag Telegram. Ich bin ein Fan. Sehr gut. Dann danke dir für die Fragen. Und Jojo, jetzt darfst du ein bisschen tiefer ins Technische abtauchen. Okay. Wir haben ja vorhin so ein bisschen schon mal ausgeführt. Du hattest ja gemeint, es gab halt damals zuerst diese Bindung an die JVM. Aber das ist ja inzwischen letztendlich und auch relativ früh war es ja so, dass man irgendwie Kottland nicht nur irgendwie zur JVM Ausführung nutzen könnte, sondern der JavaScript Support, also die Kompensierung von JavaScript war ja relativ zu Beginn eigentlich schon auch verfügbar. Ist das etwas, was auch so eine praktische Anwendung hat? Also wir haben immer überlegt, unsere Frontends in Kottland zu schreiben. Es hat sich nie so ganz durchgesetzt, dass wir uns dazu durchreden konnten. Also ja, vielleicht kannst du ein bisschen was darüber erzählen, wie das funktioniert und ob es da auch wirklich Anwendungsfälle gibt, sagst du, Frameworks, die das nutzen, diesen Ansatz. Ja, also wir können, wir können es. Ich fang mit dem letzten Teil jetzt mal als erstes an zum Thema, wo das eingesetzt wird. Also wir setzen es intern ein. Wir haben bei ChatBrain eine ein Team Tool, das nennt sich ChatBrain Space. Das kombiniert so alles, was man so irgendwie aus der normalen Team Tool Umgebung kennt. Also da ist so ein Chat mit drin, den man vielleicht von Slack kennt, da ist irgendwie CICD, da sind Container Registries mit drin, da die ganzen Git Repositories sind mit drin, issue Tracking, interne Blogs, Human Resources Kram und so weiter, so eine all in one Plattform. Und die ist also Web First. Und da ist das Backend in Kottland geschrieben und das Frontend in der Web App ist auch in Kottland geschrieben, zusammen mit React. Also das ist Kottland. Js plus React. Also wir sind der größte Use Case, den ich jetzt kenne und der größte Use Case, über den ich jetzt reden kann, ohne dass ich eventuell irgendwelche NDAs breche. Wir kennen auch, also ich kenne noch einige andere Unternehmen. Man muss aber ganz klar dazu sagen, also im Vergleich zu den anderen Plattformen, die die Kottler noch mit anbietet, ist es definitiv ein kleinerer Prozentbereich. Ja, also man ahnt es schon, dass es irgendwie wieder so ein bisschen aus Eigenbedarf entstanden für uns. Wir sind uns ist eben aufgefallen, dass auch die Frontend Entwicklung eventuell mal ein bisschen von statischen Typen und irgendwie modernen Sprachkonzepten profitieren könnte. Muss man sich jetzt mal, dass man zeitlich immer ein bisschen einordnen. Das war in so einer Zeit, da war TypeScript noch nicht wirklich so ein Ding. Genau. Und deswegen haben wir halt uns gedacht, eigentlich sind relativ viele von den Kottland Sprachkonzepten komplett unabhängig von der JIVM. Das sind einfach moderne Sprachkonzepte und die würden halt auf anderen Zielplattformen ganz genauso funktionieren. Und dann haben wir eben da entsprechend die ersten Prototypen geschrieben, haben das dann irgendwann über die Jahre stabilisiert und nutzen es also bis heute noch. Cool. Und der zweite oder dritte große Bereich ist natürlich auch jetzt irgendwie die Kompilierung zum nativen Code. Und gerade in letzter Zeit hat man ja gefühlt da mehr drüber gehört. Dieses ganze Konzept von Kodle Multiplattform-Mobil ist etwas, was irgendwie immer noch ein Betastatus ist, ich bin mir nicht ganz sicher, aber natürlich sehr stark irgendwie propagiert wird, was sehr spannend aussieht. Also das war schon immer letztendlich ein Anwendungsfall für Kodnen oder hat sich das auch über die Zeit entwickelt, dass man auch wirklich mit Kodnen dann nativ Android und iOS dann schreiben konnte oder vielleicht auch andere Plattformen wirklich da adressieren konnte. Ja, also das hat sich auch wieder so Stück für Stück entwickelt. Muss man ganz klar sagen. Also native Binaries zu erzeugen ist natürlich ein großer Vorteil auf iOS, weil es da jetzt irgendwie mit der JVM doch relativ dünn ausschaut auf den ganzen Apple Geräten, hilft aber natürlich auch in ganz vielen anderen Konzepten. Also wenn man sich jetzt mal so Sachen anschaut wie Serverless Entwicklung oder so, da ist JVM Sprachen sind da von Natur aus ein bisschen benachteiligt. Also eine JVM, die hat, die muss erst mal starten, dann muss die sich tendenziell ein bisschen aufwärmen, bis irgendwie die Git und das ganze Hot Spotting und so, die das Ganze entsprechend performend kriegt. Also da ist es natürlich dann schöner, wenn man einfach eine kleine Binderie hat, die halt zügig startet, die AHEADF Time kompiliert ist und die dann tatsächlich sofort nativ ausführt. Das ist so ein bisschen das Gesamtkonzept zum Thema native. Ios als als Use Case ist natürlich noch mal ein bisschen was Besonderes, weil mit dem, dass Kottland sehr populär geworden ist bei Android Entwicklern, haben wir uns halt gedacht, dass es sinnvoll wäre, wenn man anstatt Code mehrmals für unterschiedliche Plattformen zu schreiben, es doch sinnvoll wäre, wenn man diese Implementierungen teilen könnte. Das hat auch wieder entsprechend angefangen. Wir können wieder mal ganz kurz zu dem ChatBrain Space Case zurückkommen. Wenn der Client oder deine Website in derselben Sprache geschrieben ist wie dein Backend, dann lässt sich also weitaus einfacher zum Beispiel so DTOs, so Data Transfer Objectives, lassen sich einfacher teilen, weil die schauen halt auf beiden Seiten gleich aus. Da muss man nicht irgendwelche Adapter schreiben oder irgendwelche Zwischensprachen mit einfügen und so weiter. Auf Mobile ist es damit praktisch genauso. Im ersten Schritt, wenn man die Businesslogik halt teilen kann, dann kann man seine Zeit damit verbringen, die UI's schön nativ für jede Seite zu gestalten, dass das ausschaut wie eine richtige Applikation oder wie eine native Applikation und kann dann unten drunter die Funktionalität praktisch recyceln zwischen den unterschiedlichen Plattformen. Das ist auf jeden Fall immer ein spannender Ansatz. Das stellen wir natürlich auch fest. Wir haben jetzt gerade ein Projekt, wo wir Flutter mit Daten als Sprache und Framework nutzen und da haben wir auch jetzt inzwischen das gesamte Backend auch in DATE überführt und haben genau die Situation, dass wir alle DTOs zwischen Frontend und Backend irgendwie teilen können und nicht mehr jetzt irgendwie OpenAPI brauchen, jetzt mal ein Interface oder eine API zu definieren, auf der anderen Seite wieder zu importieren, daraus die Modelle zu generieren, sondern dass man das halt einfach so out of the box mitbekommt und einfach in einem Mono-Report sehr schön verwalten kann. Klar hat sich natürlich in der JavaScript/TypeScript-Welt mit Node. Js da auch ein bisschen was getan, aber gefühlt ist da immer noch so ein gewisser, ich will ich sagen, Dis Connect, also dass man das doch nicht so intensiv nutzt, da vielleicht so auch die gleiche Sprache auf beiden Ebenen zu führen und zu nutzen. Und man hat gefühlt auch immer dadurch einfach einen geringeren Mental-Low, einfach dadurch, dass man die gleiche Programmiersprache hat, da gar keinen Kontext Switch hat und irgendwie auch mit Sprachkonzepten dann durcheinander gerät. Und das sehen wir auch als wirklich enormen Vorteil, einfach da einfach auf beiden Ebenen, auf beiden Plattformen die gleiche Programmiersprache nutzen zu können. Ja, ich meine, das kommt natürlich da noch mal mit dazu. Die andere Sache ist natürlich die, wenn man jetzt zum Beispiel in dem in dem Kottlin Multi-Plattform-Case sich das Ganze anschaut, dann hat man natürlich auf einer Seite immer noch eine SWIFT-Applikation oder so. Das heißt, da versucht Kottland einfach den Leuten so weit wie möglich aus dem Weg zu gehen. Also wenn man jetzt nur nur Business Logiks mit mit Kottland Multiplattformen teilt, dann schaut es von der Seite des SWIFT Entwicklers einfach nur so aus, als wenn er eine Library hernehmen würde. Das sind ganz normale Header und ganz normale Strukturen, die dann inEx Code genauso jetzt hergenommen werden können, wenn man das möchte. Was tendenziell den Leuten ein bisschen dabei hilft, sich eventuell, die sich eventuell so ein bisschen ekeln vor Android oder vor den JVM Sprachen, die sagen Nee, ich will in meiner schönen iOS-Welt bleiben, sich so ein bisschen das einzugewöhnen oder die so ein bisschen damit anzufüttern. Ja, aber das kann natürlich auch helfen, wirklich, wie du es ja genannt hast, diese Business Logik nur einmal entwickeln zu können. Wir haben es ja über Jahre hinweg gemacht, dass wir halt Android und iOS-Applikationen eigentlich komplett parallel entwickelt haben. Dann haben wir einzelne Versuche gemacht, wo wir mit zentralen Code in C geschrieben haben oder C++, der dann über die Java native Bridge oder das Interface dann angesprochen wird, aus SWIFT angesprochen wurde. Aber es war irgendwie keine Programmiersprache natürlich dann in C++ und hätte es damals natürlich schon so Ansätze mit Kottland Multiplattformen gegeben, wäre das natürlich deutlich interessanter gewesen. Ja, das ist auch so ein bisschen der klassische Case. Ich glaube Dropbox war das, die irgendwie ihren Artikel geschrieben oder die mehrere Artikel geschrieben haben zum Thema. Wir haben jetzt Cross Plattform mit C++ gemacht und dann haben sie gesagt: So, wir machen jetzt kein Cross-Plattform mit C++. Das war doch nicht so eine gute Idee. Da hat Kottland halt den großen Vorteil. In Java würdest du es oder so in Kottland schreiben. Auf Android würdest du es sogar so in Kottland schreiben. Das heißt, da ist man so oder so schon in Anführungszeichen nativ unterwegs. Man kann es einfach in Anführungszeichen halt recyceln. Man kann es nochmal hernehmen, ohne jetzt zu sagen ich habe noch eine dritte Sprache im Bunde, die nochmal komplizierter ist und ich schreibe dann wieder 17 Adapter aus allen Richtungen. Ist dieses Multi-Plattform Ding jetzt vor allen Dingen Android und iOS oder gibt's da noch viele oder irgendwelche anderen Plattformen? Also die also unter Kottland Multi Plattform Mobile speziell verstehen wir natürlich das Teilen zwischen Android und iOS. Kottland Multi Plattform als Technologie hat als Targets Kottland für JVM, Kottland für native auf unterschiedlichen Plattformen, also Linux, Mac OS, Windows, iOS, dann Kottland. Js als eins der Web Targets und dann jetzt noch neu mit dazu Kottland for Web Assembly. Das ist aktuell noch so in der Prototypenphase. Das wird aktuell gebaut. Ich glaube, das ganze Thema ist auf jeden Fall super spannend. Ich glaube, wir haben im Rahmen dieses Podcasts nicht Zeit, jetzt auf jede dieser Teils einzugehen, weil ich glaube, wir auch noch ein bisschen uns die Sprache anschauen müssen, was sie einem als Vorteile an Sprachkonstrukte so bieten kann. Und wir gucken mal, vielleicht müssen wir das noch mal in einer weiteren Folge vertiefen. Das ist mal ein bisschen die Sprache angucken. Das ist nämlich auch super spannend, was uns da Kottnen alles bietet. Ich glaube, Coroutine gucken wir uns am Ende noch mal an. Wie funktioniert überhaupt asynchrone Programmierung mit Kottnen, was auch super spannend ist. Der entscheidende Vorteil, den wir natürlich in Kottnen gesehen haben, ist, dass wir dieses Null Pointer Exceptions Problem von Java einfach loswerden können. Weil das ist, ich meine auch der Entwickler von dieser Null Pointer Problem hat es mal sein Billion Dollar Müsli genannt, weil er gesagt hat, er hat das, glaube ich, damals eingeführt, 1997, das war bei Algold, genau in der Programmiersprache Allgoll. Und es hat natürlich inzwischen über die Jahre so viele Probleme verursacht. Was ist das Problem eigentlich in Java mit den Null-Pointern? Das müssen wir vielleicht mal kurz aufklären. Ja, also das Problem ist, dass der Compiler kein wirkliches Konzept hat von Null Ability im Allgemeinen. Also so eine Variable, so eine Referenz in Java, die kann halt einfach null sein und man hat dann seit praktisch der Einführung, also bzw. Und das Problem dabei ist dann, wenn die zur Laufzeit tatsächlich null ist und man das nicht erwartet hat, dann knallt es und zwar ordentlich. Dann fliegt halt einfach eine eine Exception, die nicht gefangen wird, eine eine Null Pointer Exception. Und im schlimmsten Fall stürzt dann die ganze App ab oder der Server Prozess oder was auch immer oder zumindest schlägt dann die die Anfrage fehl, obwohl man eventuell hätte man gewusst, dass es sich dabei einen Null Wert gehandelt hätte, hätte man es eventuell sogar irgendwie handeln können oder irgendwie recovern können. Genau. Und die Versuche, das Ganze irgendwie so zu beheben, haben halt immer noch dasselbe Problem praktisch von der von diesem darunter, von der darunterliegenden Annahme, dass halt so eine Variable einfach null sein kann. Also man hat in Java das Konzept von einem optional. Das Problem ist nur in dem optional kann halt trotzdem ein null drin sein. Also der Compiler kann einen nicht dazu zwingen, dass in diesem optional dann tatsächlich ein Wert drin ist. Es ist eineMan behilft sich dann eventuell mit irgendwelchen so anderen Sachen wie Nullability Annotations oder so, wo man dann so ein bisschen halt Hints gibt und irgendwie so Hinweise von wegen so ja, das hier ist halt nicht Nullable oder da kommt was nicht Nullable zurück und dann kann man eventuell mit einer guten ID, wie IntelliJ. Idir kriegt man dann so statische Analyse mit rein, die einem dann halt sagt so Hey, da steht irgendwie dran, das ist halt Nullable und du nutzt es hier einfach. Also kann dir das halt potentiell die Ohren fliegen. Aber das ist halt alles irgendwie so oben aufgesetzt und im Nachhinein und benötigt viel manuelles Denken. Und gefühlt ist es auch immer sehr aufwendig, wenn du gerade sagst, die Annotation irgendwie mitzuschleifen. Also es ist dann doch schon etwas, was du machen musst, was aufwendig ist, was Zeit kostet. Und wie hat jetzt, wenn die Sprache keine Werkzeuge mitbringt, wirklich damit zu arbeiten, sorgt es auch einfach dafür, dass man einen sehr Boiler-Plat-lastigen Code bekommt, indem man halt so ganz standardmäßig, okay, man kriegt eine Variable rein, jetzt schauen wir erst mal ist die Null. Wenn ja, dann überlegen wir uns, was machen wir da jetzt? Und das machen wir für alle Parameter und müssen dann eben praktisch das immer schauen, ohne dass jetzt die Sprache irgendwie große Features oder Shortcuts mitgibt, jetzt zu sagen, wir können das schnell oder einfach behandeln. Und wie hat jetzt Code denn dieses Problem gelöst? Ja, also man kann es schon ein bisschen vermuten von dem, wie ich es vorher gesagt habe. Der Kottland Compiler hat einfach ein Konzept von Null Ability mit eingebaut. Also der weiß, wann eine eine Variable null sein kann. Das ist in Kottland Code, kriegt die dann hinten ein Fragezeichen dran. Das heißt, hierbei handelt es sich eine potenziell, also eine Variable, die entweder diesen Typ hat oder null. Und dementsprechend ist der Compiler dann knallhart und sagt Wenn du diese Variable hernehmen willst, dann machst du eine von zwei Sachen. Entweder du zeigst mir, dass diese Variable du in Anführungszeichen du beweist mir, dass diese Variable in diesem Fall nicht Null ist, also entweder mit einem Check oder eben mit einem von den den tollen Unwrap Funktionen, die wir haben, diesen Scope Funktionen. Oder du haust zwei Ausrufezeichen dahinter und du sagst mir ist egal was du meinst oder was du meinst, ob die Null ist oder nicht. Und dann knallt es auch wieder zur Laufzeit. Aber dann kann der Compiler sagen, das war deine Schuld. Da hast du dich absichtlich jetzt auf dünnes Eis begeben. Also der Ansatz ist einfach, dass man sagt, man hat einfach dieses zusätzliche Zeichen. Das macht ganz klar eindeutig. Welche Referenzen sind irgendwie Nullable, welche sind nicht Nullable? Das zieht sich irgendwie so durch den Code durch. Das kann der Compiler, der Lintar, alle Tools einfach so verarbeiten, so checken, sodass ich schon meine IDI, dann eine genaue Aufschlüsselung habe. Muss ich hier jetzt was prüfen? Und ich habe auch ganz viele letztendlich Operatoren, die mir die Sprache mitbringt. Also du hast ja eben jetzt schon einen genannt, diesen Double Bank Operator nenne ich den oftmals. Aber man hat ja auch einfach diese Fragezeichen, diesen Safe Call Operator, wo ich dann einfach Sachen verketten kann, zu sagen okay, vielleicht ist die Variable Nullable, der macht intern wahrscheinlich trotzdem diese Prüfung unter der Haube, aber ich kann es einfach so schreiben, als ob ich dann in dem Fall eben damit umgehen kann und eventuell vielleicht sogar auch mit diesem Elvis-Operator sage: „Okay, falls das sozusagen Null ist, dieser Wert. Ich mache zwar diese ganze Verkettung von Operationen, die ich auf dieser Null-Referenz ausführe, aber wenn das eben nicht einfach Gesetz ist, dann nehme ich mir die Fall-Parameter oder für was anderes aus. Und das finde ich so das Schöne, was man bei Kottland gefühlt dann noch mitbekommt, dass man zu diesem Konzept auch sehr viel Operatoren, sehr viel außen rum bekommt, was es einem sehr einfach macht, letztendlich mit diesem Konstrukt zu arbeiten und das zu vertragen, sodass immer noch sehr kompakter, übersichtlicher und verständlicher Code entsteht, der aber dieses Sicherheitskonzept eben dann mit sich bringt und einschließt. Ja, also eine von den anderen Sachen, die zum Beispiel auch in der Sprache mit integriert sind, sind so Smart Casts. Also das heißt, wenn der Compiler sieht, ich habe, ich habe diese Variable schon mal getestet, ob sich dabei ein Null handelt oder nicht, dann muss ich nicht explizit noch mal irgendwie jetzt sagen okay, jetzt ist die Variable wirklich null, wirklich Non Nullable, sondern der Compiler sieht das und er sagt okay, gut, du hast das geprüft. Ich weiß, dass dieser Code nur ausgeführt wird, wenn es sich eine Non Null Variable handelt. Also kannst du sie genauso verwenden, als wenn sie immer halt Non Nullable gewesenwäre. Sind halt eben so die ganzen kleinen Features, die irgendwie so zusammenspielen, einfach eine ergonomisch mit diesen Null Werten umgehen zu können und eben sicher. Cool. Ihrokay, du hast zwar hier auf deinen Notizen so ein paar Sachen niedergeschrieben, die du gerne noch behandeln möchtest als Sprache. Ich will dir auch gleich noch die Möglichkeit dazu geben. Aber wenn wir hier jemanden sitzen haben, der sagt, er hat sich in die Sprache verliebt, würde ich vielleicht Sebastian dich noch mal jetzt explizit fragen. Was sind die Sprach-Features von Kottlin, die dafür dazu gesorgt haben, dass du dich in diese Sprache verliebt hast? Und dann gucken wir mal, was noch übrig ist, was wir vielleicht trotzdem noch zusätzlich ansprechen möchten. Ja, also für mich, das Großartigste an Kottland ist die Standardbibliothek. Muss ich ganz klar so sagen. Das ist also sämtliche Collection Types und so weiter, die wir in Kottland haben und die gesamten Operationen, die darauf definiert sind, machen mir mein Leben so viel einfacher als in anderen Sprachen. Das ist also ich. Ich bin teilweise immer noch manchmal am Staunen. Also das, was mir tatsächlich aufgefallen ist, seitdem ich angefangen habe, Kottland zu schreiben, bin ich weitaus weniger auf Stack Overflow unterwegs, weil ich die offensichtlichen Sachen nicht mehr googeln muss. Als ich JavaScript geschrieben habe, habe ich mir die Frage gestellt: „Wie ziehe ich jetzt ein zufälliges Element aus diesem Array? Und dann ist es okay. Da gibt es nichts in der JavaScript Standardbibliothek. Also I guess, generiere ich eine random Zahl, flore die, multipliziert die mit der Länge von dem Array und nimmt dann halt Index dann in das Array rein und was auch immer. Also muss ich schon 17 logische Schritte ausführen oder muss es mir ergoogeln, überhaupt die Sachen rauszufinden. In Kottland ist es halt so, ich habe meine Liste oder meine Collection. Wie ziehe ich da jetzt halt einen random Element raus? Ja, probieren wir mal, Punkt random. Ja, gibt's. Wunderbar. Fertig. Ende. Das ist so ein bisschen für das. In Kotlin Code hat so ein bisschen diese Tendenz dazu, den Intent, den man hat, irgendwie so auszustrahlen. Also anstatt zu beschreiben was, was mache ich, ist es so ein bisschen eher so, warum mache ich das Ganze? Ich sage nicht, ich will eine random Zahl generieren und die dann in den Access Operator stecken, sondern ich will einen random Element aus meiner Liste haben. Solche Sachen finde ich unglaublich cool. Auch so Sachen wie keine Ahnung, ich will dann eine Liste shuffeln. So was, was man halt teilweise einfach mal machen möchte oder was man halt mal braucht, was aber irgendwie nicht in allen Sprachen so ganz so einfach möglich ist. In Kottland, da gibt es halt einfach in der Standardbibliothek eine Shuffelfunktion, die ist da drin. Das ist wunderbar. Also Kottland hat ein sehr schönes, standardisiertes Vokabular, was halt eben auch in allen Projekten verfügbar ist. Das ist das Besondere. Es ist nicht irgendeine Third Party Library, es ist einfach immer da, wenn man in Kottland unterwegs ist, was mir so den Alltag irgendwie jedes Mal so versüßt. Das ist immer, immer wenn ich irgendwo rangehe und ich muss eine kleine Aufgabe machen, denke ich mir okay, ich kenne zwei oder drei eingebaute Funktionen, mit denen ich das machen könnte, wo ich in anderen Sprachen sieben, zwölf, was auch immer unterschiedliche Sachen kombinieren müsste, dasselbe zu erreichen. Den Punkt von Sebastian will ich auch gerade noch unterstreichen, weil das auch für mich auch wirklich so diesen positiven Eindruck unterstützt hat, also dass man da wirklich diese sehr umfängliche Standardbibliothek hat, wo ich auch sage, auch in DATEV habe ich was ähnliches. Aber jedes Mal, wenn ich zu JavaScript gekommen bin, habe ich genau diesen Prozess, dass eben nichts vorhanden ist. Entweder habe ich etliche Packages, die ich mir einbaue, das zu erhalten oder ich muss es halt, wie du es eben beschrieben hast, irgendwie googeln und gefühlt ist es so halt in Kottlin oder DATEV. Man hat einfach einen sehr schnellen und dadurch auch einen sehr produktiven Zugang zu der Sprache mit diesen Funktionen. Ich bin leider nicht so tief in so vielen Programmiersprachen drin, dass ich jetzt gut den Vergleich ziehen könnte. Aber da gibt es doch bestimmt auch Leute, die irgendwie die Meinung vertreten, das ist doof. Es hat irgendwelche Nachteile, wenn so viel in der. Standardbibliothek ist. Wir müssen Adam mal dazu befragen, wie. Das geht. Das ist richtig, Adam. Oder vielleicht auch ich weiß nicht, ist nicht Go auch so, dass sie irgendwie verzichten, möglichst viel, also einfach es möglichst simpel halten und nicht so... Du hast doch bestimmt aus der Community Sebastian ein paar dieser Stimmen, oder? Gibt es da nichts Negatives? Ich muss sagen vergleichsweise wenige. Also bei uns ist es also tendenziell von Leuten, die in der Kottland Community wirklich unterwegs sind, die wollen... Die wollen meistens eher noch mehr. Also die wollen tendenziell dann noch irgendwelche extra Features oder noch anstatt irgendwie Pairs und Tripples irgendwie noch Generic Tupels bis 26 Tupels oder so, irgendwelche Sachen zu returnen oder irgendwelche anderen Generic Types. Nee, also viele in der Community haben das wirklich einfach gesehen als ein Feature, was ihnen wirklich, wirklich gut, was sie wirklich gut finden. Diesen Minimalismus und dieses Not Invented here, das gibt es irgendwie in der Koppeln Community, muss ich sagen, tendenziell eher weniger. Generics hast du gerade schon genannt. Das heißt, dass es ein Feature ist, was mit dabei ist, was von Anfang an dabei war und breit eingesetzt wird? Ja, halt an den Stellen, wo es halt sinnvoll ist. Aber gerade so was wie Collections, was du angesprochen hast, ist ja super sinnvoll. Also da hat man volle Unterstützung für Generics. Also ja, von Anfang an dabei und sehr sinnvoll. Exakt. Also für Datenstrukturen und so weiter. Wir haben auch das Konzept von Re-Affined Generics, was einem noch ein bisschen dabei hilft, die Problematiken, die man normalerweise auf der JVM hat, nämlich mit Typ-Erasher, die irgendwie so ein bisschen zu umschiffen. Wir haben auch die Konzepte von halt Co-und Contra-Variants in der Sprache. Das ist so eine Thematik, die, wenn da jetzt die Leute sagen Oh nein, das klingt irgendwie spooky, man muss sich nicht damit beschäftigen. Aber wir haben es auf jeden Fall, das, was dann auch noch mal eben dabei hilft, mit den generischen Typ Hierarchien richtige Semantiken zu spezifizieren, wenn man das möchte. Oder man nimmt einfach das, was schon gebaut ist und da stehen, da stehen die ganzen Annotation alles schon richtig dran. Dann muss man sich damit gar nicht auseinandersetzen. Ja, du hast glaube ich den wesentlichen Punkt schon genannt. Ich glaube, wir können noch so ein paar weitere coole Features von Kottin eingehen. Oder Sebastian Fragen. Oder Sebastian Fragen. Also was ich zumindest von vielen höre, was viele auch bei TypeScript gut finden, dass du keine Semikolons brauchst. Für viele ist das wohl sehr wichtig, dass du dieses zusätzliche Zeichen sparen kannst und einfach sagst okay, irgendwie ein End of Line Charret Return ist irgendwie genug Informationen für den Compiler, das zu machen, ist für mich nicht das starke Kriterium. Aber ich kenne viele Entwickler, die da irgendwie sehr darauf pochen und sagen das ist super cool, dass Kotton das unterstützt, wenn man das nicht braucht. Ich glaube, so ein Punkt, den man noch als größeres Konzept ja auch nutzen kann oder nennen kann, ist ja die Typ-Inferenz, also dass man da man nicht immer den Typ explizit definieren muss, sondern wenn es in einem Kontext eindeutig genug definiert wird, dass man dann eben auf die Typ Definition verzichten kann, was halt Code oftmals irgendwie ja nicht so redundant gefühlt irgendwie macht. Ja, also da wird der Code einfach ein gutes Stück schlanker, sage ich mal. Das ist halt, das ist angenehm, weil damit schreibt sich so ein bisschen eher so ein bisschen wie eine dynamische Sprache, aber halt eben mit der Sicherheit dann tatsächlich von einer statisch typisierten Sprache. Das ist also meiner Meinung nach das Beste aus beiden Welten. Hast du noch andere Sachen, wo du sagst Hey, das findest du irgendwie cool an der Kottland Programmiersprache? Was sind sozusagen was dein zweitliebstes Feature, was die Sprache so mitbringt. Als Sprachkonstrukt? Da sind es eher der Semikolons. Also ich bin ein riesengroßer Fan von unseren Seeld Hierarchies. Also in Kottland kann man so Vererbungshierarchien oder auch Interfaces kann man mit dem Schlüsselwort Seald markieren. Und was das dann letztendlich bedeutet, ist, dass der Compiler damit garantiert der Compiler, dass alle Fälle oder alle Subklassen zur Compile Zeit bekannt sind. Also die kann nicht erweitert. Werden einfach. Genau, exakt. Oder auch jetzt nicht von Third Party Library oder so nicht erweitert werden. Und das ist wieder schön, weil das gibt nochmal extra Sicherheit. Wenn ich so ein Wenn Statement habe, also das Äquivalent von so einem Switch Statement und ich gehe über meine meine fünf Subklassen drüber, dann kann der Compiler die Aussage treffen. Hierbei handelt es sich ein Exostive Statement. Also alle alle Cases werden tatsächlich getroffen. Es gibt keinen Fall, wo wir, wo wir keinen von den unterschiedlichen Branches treffen. Und das ist halt super hilfreich im Fall von zum Beispiel Refactoring oder so, wenn man jetzt keine Ahnung, man baut irgendwie einen Parser oder was auch immer, man fügt eine neue Subklasse für eine Expression ein und auf einmal ist halt der gesamte Code rot überall, weil der Compiler sagt Okay, hier an der Stelle schaust du dir das an und du behandelst diesen Fall nicht. Hier behandelst du nicht, da behandelst du nicht und so weiter. Das ist als erstes vielleicht ein bisschen nervig, aber man wird dadurch dazu gezwungen, halt wieder richtigen Code zu schreiben. Und man vergisst nicht aus Versehen in 17 Dateien weiter unten oder weiter oben da vielleicht noch einen Case zu handeln, der dann wieder zur Runtime explodiert. Also das ist eines von den wirklich großen Punkten, würde ich mal sagen. Besonders schön ist, wir haben auch so eine Serialization Bibliothek für so Json Kram und die funktioniert auch mit so Seared Hierarchies. Das heißt, ich kann an der einen Seite so einen Object Graph reinstecken, der fällt dann auf der fällt dann irgendwie Json raus. Und wenn ich dann in meiner anderen Cut and Client Applikation das deserialisiere, dann weiß ich wieder, welche Subklassen ich da auch praktisch poly-morp wieder zurückbekommen kann. Das sind halt einfach relativ nette, nette, coole Features, die irgendwie alle so als, als Folge von den grundsätzlichen Sprachkonzepten so fast als glücklicher Zufall irgendwie so mit bei rausfallen. Das ist so, muss ich wirklich sagen, das ist gefühlt das, was mich an Kottlan immer so fasziniert hat, ist die die grundlegenden Konzepte, auf denen die Sprache aufbaut. Die. Sind so durchdacht, dass die als Puzzlestücke einfach so gut zusammenpassen. Also wenn wir später noch über Coroutine reden oder so, kann man das auch noch mal ansprechen. Aber es ist der Wahnsinn, was man mit sehr einfachen Abstraktionen kreativ kombiniert für Verhalten oder für komplexe Programme schreiben kann, die trotzdem verständlich bleiben. Ja, ich. Glaube, ich würde einfach noch gerne zwei weitere Sachen nennen, die ich auf jeden Fall immer sehr gerne nutze. Das sind zum einen letztendlich Extention Functions, also dass ich die Möglichkeit habe, jede bestehende Klasse irgendwie mit weiteren Funktionen auszustatten. Zum Beispiel, dass ich sage, ich brauche eine Bestell-Operation, String umzuwandeln in ein anderes Format oder da was zu machen. Und ich will mir nicht jedes Mal eine Funktion schreiben, eine Klasse schreiben. Und manchmal ist es auch so, dass ich auch solche Standardobjekte wie String zum Beispiel nicht mehr ableiten kann oder auch vielleicht nicht ableiten möchte, weil es eine externe Bibliothek ist. Und das mit einer externen Function, ich jederzeit die Möglichkeit habe, das einfach zu erweitern, ich dann glaube ich mit this, also eigentlich so auf der gleichen Referenz dann arbeite und dann letztendlich mir selbst Funktionalität schaffe, mir Dinge vereinfachen zu können. Das macht es halt oftmals sehr einfach, sich solche Utility Funktionen zu schaffen, mit denen ich mir einfach dann Code Stöcke irgendwie vereinfachen und verallgemeinern kann. Das zweite, was ich auch noch sehr cool finde, ist irgendwie so dieser ganze alles, was mit anonymen Funktionen natürlich möglich ist oder auch Object Declarations, also dass ich die Möglichkeit habe, weil man hat sehr oft letztendlich gerade im Backend von solche Singleton Objekte, die baue ich einmal auf und in vielen anderen Sprachen wie da zum Beispiel auch. Ich brauche letztendlich eine Klassendefinition, aber ich brauche noch eine weitere Instanz davon, die halt dieses Singleton Objekt dann irgendwie global zur Verfügung stellt. Und da gibt es halt in Kottlam mit diesen Object Declaration die Möglichkeit, das eigentlich gleich zusammen zu schreiben. Es gibt sozusagen eine Instanz, die wie eine Klasse schreibe, die ich aber genauso irgendwie als instanziierte Instanz eigentlich adressieren kann und mit der ich arbeiten kann. Und dass es so als Sprachkonstrukt eigentlich direkt bereitgestellt wird, ist sehr, sehr cool. Also haben wir sehr viel bei der Server Implementierung eigentlich verwendet. Ja, das Structuring ist auch ein sehr, sehr cooles Thema, dass man sagen kann, man kann sich ja direkt sozusagen Inhalte aus einzelnen Objekten irgendwie rausziehen, das auf Variablen schreiben hat lange Zeit, also da zum Beispiel gefehlt. Da muss man irgendwie auf die einzelnen Sachen zugreifen. Die haben jetzt auch erkannt, dass es ein sehr sinnvolles Feature ist und dass es kommen wird. Das habe ich aber auch sehr, sehr intensiv immer genutzt und hat, finde auch den Code immer sehr kompakt gemacht. Das ist das, was man sehr schnell feststellt, wenn man da Code schreibt. Man kann viele Dinge, die vorher sehr komplex waren, in JavaScript oder auch in Java sehr kompakt schreiben und dass sie trotzdem irgendwie noch verständlich sind. Das meinte er vermutlich gerade. Kottland und nicht und nicht Daten. Jetzt habe ich mich auch. Wieder. Vertan. Okay, das gerade Daten. Ja, aber richtig. Ja. Okay. Das sind deine Lieblings Features. Lass uns noch mal kurz über Coroutine, weil wir es zweimal angesprochen haben. Ja, genau. Als Programm der asynchronen Programmierung. Da haben wir verschiedene Programmiersprachen, die unterschiedlichen Konzepte. Ich glaube, das, was ich sehr weit verbreite, hat, also ich glaube C# nutzt es, TypeScript JavaScript und auch inzwischen natürlich da ist Async erwähnt. Und das ist ja in Kottland ein bisschen anders. Also kannst du mal drauf eingehen, wie asynchrone Programmierung in Kottland funktioniert, was gedacht ist? Ja, also ich. Ich muss persönlich sagen, ich. Ich finde das super, super faszinierend, weil ich habe auch ich habe C# und was auch immer halt eine Zeit lang auch irgendwie so nebenbei geschrieben. Ich muss zugeben, ich habe so wirklich so asynchrone und Concurrent Programmierung irgendwie nicht wirklich verstanden, dass ich das Ganze in Kottland gemacht habe, weil für mich war die Abstraktion von Async erwähnt war, es hat einfach mit mir nicht geklickt. Ich habe nicht verstanden, warum, wenn ich Async wohinschreibe, warum oder wenn ich erwarte wohin schreibe, warum dann meine Funktion Async sein muss und umgekehrt. Also warum sind das zwei unterschiedliche Keywords? Warum? Wie? Wie hängen die zusammen? Das ist irgendwie fand ich alles immer ein bisschen komisch. In Kottland haben wir ein Konzept und das ist das Konzept von Suspend. Und Suspend ist einfach, dass man sagt Okay, an dieser Stelle kann eine Funktion praktisch pausieren. Also die kann den die Kontrolle dann an irgendeinem anderen Threat oder eine Fiverr oder wie auch immer man es nennen möchte, an eine andere Coroutine, kann sie praktisch die Kontrolle abgeben. Und das ist letztendlich das gesamte Konzept. Was dabei rauskommt ist, dass Kottland Code, der asynchron geschrieben ist, schaut genauso aus wie Kottland Code, der einfach Sequentiell geschrieben ist. Das sind ganz normale Funktionen letztendlich, die alle nur den Suspend Modifier mit dran haben. Die einzige Regel, die man beachten muss, ist eine Suspend Funktion, also eine Suspend Funktion kann nur aus einer weiteren Suspend Funktion aufgerufen werden. Und das hat für mich sofort geklickt. Das war so okay. Diese Funktion kann pausieren. Das bedeutet, eine Funktion, die diese Funktion aufruft, kann logischerweise transitiv auch pausieren. Und auf einmal. Ich weiß nicht, ob es wirklich nur das war. Aber durch das, dass es nur ein Keyword ist und ein Konzept, war das auf einmal für mich alles viel klarer. Da ist dieses, da hat es auf einmal geklickt mit dieser Idee von Function Coloring auch so zum Thema. Wenn ich eine Suspendfunktion aufruf, dann ist meine Funktion ist dann praktisch angemalt in der Farbe von wegen diese Funktion pausiert. Das heißt, ich kann die nur aus Funktion derselben Farbe dann irgendwie wieder aufrufen, die eben auch pausieren. Genau das ist so das, was so ein bisschen das grundlegende Konzept. Ja, interessant. So habe ich das noch nie gesehen. Aber da ist schon völlig recht. Dassagen wir mal, diese initiale Zugänglichkeit zu diesem Asicawait Konzept vielleicht nicht ganz so verständlich ist und dass letztendlich einfach nur diese Information, weil es ist implizit so, wenn ich natürlich auch eine asynchrone Funktion auch im TypeScript jetzt irgendwie aufrufe, muss ich die in einen anderen asynchronen Kontext eigentlich einbetten. Oder sie läuft halt einfach natürlich asynchron in diesem Kontext, ohne gefangen zu werden oder irgendwas anderes. Und das ist bei Kottling natürlich viel klarer ist, dass ich eine Suspendfunktion dann so weiter reichen muss und dann verwenden kann. Also wir haben auch dieses Konzept, lustigerweise. Also wir haben das Konzept von Async erwähnt, auch in der in der Kottland Sprache. Aber das handelt sich dabei eine Library Funktion. Also das ist nicht in den Compiler eingebaut oder sonst was. Und für mich hat es auch da wieder sofort geklickt, weil es ist also okay, erwähnt ist halt eine Suspend Funktion, weil ein Wait pausiert potentiell das Programm. Also das ist ja das einzige Konzept dahinter. Das heißt Async. Okay, wunderbar startet halt irgendwie einen Block, der läuft halt irgendwo anders, müssen wir uns nicht mit beschäftigen. Und wenn ich dann ein Wait aufruf, dann weiß ich okay, das ist das Spend. Das heißt, die Funktion, die das wieder aufruft, muss auch wieder sein. Das heißt, und das ist für mich sofort wieder klarer. Wait Suspend, das heißt meine Funktion ist das Spend. Wohingegen wenn ich sage, ich rufe eine ein, ich habe ein Keyword erwähnt und das muss ich immer paaren mit Async oben in der Funktion. Das hat für mich irgendwie nie geklickt. Das, was du schon erwähnt hast, ist halt auch das Interessante, dass es halt auch für Kottland einfach halt dieseLibrary Funktionen gibt, wie Async, Aweight, dass dann natürlich auch so ein Konstrukt wie halt ein Promis dann irgendwie auch Einzug erhält mit die Firm. Aber du arbeitest schon mit den gleichen Konstrukten, aber sie sind halt anders verpackt und das ist halt eher das, was man versteht, dass eigentlich das Eigentliche halt dieses Pausieren der Funktion ist und das eigentlich nur in anderen Konstrukten verpackt ist, wie du dann damit arbeitest und die Sachen aufrufst. Ist das denn alles auch Plattform unabhängig möglich? Also gibt es das jetzt nur für die JVM oder ist das dann mal etwas, was das Compiler Framework, also Codling als Sprache bereitstellen, so dass es auf allen Plattformen eigentlich übergreifend genutzt werden kann? Also unsere gesamte Standardbibliothek für Codlan ist in, wir nennen das Ganze, Common Codlan Code geschrieben. Das heißt, dass ist purer Codlan Code und purer Codlan Code hat immer die Eigenschaft, dass er auf allen Plattformen kompiliert werden kann. Also wir, das ist, es sind zwar ein paar Mikro-Optimierungen, also eventuell ist die die Hasch Map oder so, die du auf der JVM jetzt hernimmst, das ist halt die Original Hasch Map untendrunter, die halt irgendwie Java bereitstellt. Aber vom Interface her bieten wir Implementierungen immer für alle Plattformen an. Und Coroutine sind da eben nicht anders. Ja, Coroutine ist ja so als Konstrukt ja auch nichts Neues. Es gab es ja in vielen anderen Programmiersprachen vorher schon. Der Grundgedanke von der Coroutine ist ja, ich gehe jetzt nicht irgendwie auf einen Prozessor Threat irgendwie, dann meine asynchronen Operationen zu machen, sondern ich habe eher so eine Art Microthreats, also sehr kleine atomare Bestandteile, die dann auf einem Threat irgendwie verteilt dann laufen. Darum muss ich mich gar nicht kümmern. Ist einfach eine kleinere Einheit, die viel einfach mit weniger Overhead, weil Threat halt zu kreieren hat ja immer letztendlich entsprechende Implikationen, dass ich ihn nie brauche. Darum muss ich mich alles nicht kümmern, sondern ich sage einfach ich habe hier ein Stück Code, der muss irgendwie asynchron laufen, wie das letztendlich die JBM die Sprache macht. Das ist etwas, was sozusagen dann in der Plattform irgendwie vom Kottlinge kapselt und bereitgestellt wird. Ja, also das ist ja immer derDer klassische Marketing Blub ist natürlich, dass wir probieren, wir starten mal 1000 Threats und schauen mal, wie unsere Memory und CPU Usage ausschaut, wie lange das Ganze dauert. Und jetzt starten wir mal eine Million Coroutinen und die laufen natürlich, ohne dass die JVM überhaupt ins Husten kommt oder so. Also das ist einfach durch das, dass es sich letztendlich bei diesen Coroutinen so kleine State Maschines handelt, die also praktisch ja letztendlich vom vom Compiler in regulären Java Code übersetzt werden oder je nach Target in den regulären Ziel Code übersetzt werden, ohne dass da jedes Mal dann zur Laufzeit neue Threats tatsächlich gestartet werden müssen, ist halt der große Vorteil. Und es sorgt dafür, dass das Ganze halt doch einiges zügiger funktioniert, sag ich mal. Gut. Jetzt hast du noch eine letzte Chance zu Sebastian, noch irgendwas zu droppen, was dir wichtig ist, rund Top Ten, Kottlin. Wunderbar. Ja, ich würde an der Stelle tatsächlich noch mal bei bei Coroutinen bleiben, weil ja, wie du gesagt hast, Coroutinen sind jetzt eigentlich gar nicht so das krass neue Konzept. Unsere Freunde, die GO Developer haben natürlich ihre Go Routinen, LUA Entwickler haben auch irgendwie so ein Konzept von Coroutinen und so weiter. Das gibt es in ganz vielen Sprachen. Kottland kombiniert das Ganze aber halt auch noch mit der Idee von Struktur Konkurrenz. Das heißt zusätzlich dazu, dass man eben halt leichtgewichtige Abstraktionen hat, Sachen parallel oder eben konkurrently asynchron ausführen zu können, gibt die Kottland Sprache auch die Mechanismen mit, sinnvoll praktisch zu handeln, wie diese, wie diese Coroutinen strukturiert sind, z. B. So Sachen aufzustellen wie eine Parent-Kind-Beziehung zwischen Sachen, die dann unter anderem darüber entscheidet, wenn jetzt eine Coroutine fehlschlägt, was soll denn dann passieren? Das ist das Problem, wenn man eine Sprache hat, in der man einfach bunt irgendwelche Background Prozessor starten kann, dann ist das immer nicht so klar. Wenn ich jetzt hier 10 Requests starte im Hintergrund und eine schlägt fehl, was ist jetzt das richtige Verhalten? Will ich die anderen 9 Stück noch ausführen? Will ich die anderen 9 Stück canceln, weil ich sie nicht mehr brauche, weil es keinen Sinn mehr macht? Und so weiter. Kottland bietet da eben entsprechend die Funktion sogenannte Scope aufzumachen, indem man praktisch diese Beziehungen einführen kann und dann eben auch unterschiedliche Strategien anwenden kann, zu sagen entweder ja, ich bin an Teilergebnisse noch interessiert, ich cancel die ganzen Sachen oder ich schmeiß dann einfach alles weg. Oder auch einfach, dann in interaktiven Applikationen so Sachen zu unterstützen, wie der Nutzer sagt, ich brauche das eigentlich gar nicht mehr. Den aktuellen Prozess können wir, können wir stoppen. Und das dann alles sinnvoll und einfach praktisch wieder rückwärts aufzuwickeln, ohne groß mit Memory Leaks unterwegs zu sein oder so, sind alles Sachen, die eben Kottland mit seinen Coroutinen sehr schön lösen kann. Cool, dass du darauf noch eingegangen bist. Das war eine Frage, die ich mir notiert habe. Du hast es noch mal sehr schön erklärt, wie das mit den Scope funktioniert bei den Co-Routinen und was für Vorteile sie bringen. Super. Sehr schön. Dann haben wir noch unsere. Pick of the Days. Und ja, ich wollte sagen, natürlich haben wir es ein paar Teile bei Kottland aufsparen müssen. Du hattest ja im Vorfeld schon genannt und wir haben es auch gemerkt, das ist wirklich ein sehr umfassendes Thema. Ich glaube, der Anspruch, eine ganze Programmiersprache in einer Stunde zu erklären, ist wahrscheinlich schon ein recht großer, aber ich glaube vom Eindruck. Ja. Mal gucken. Haben wir schon einiges mitbekommen. Das stimmt. Aber vielleicht kommen wir noch mal darauf zurück. Vielleicht können wir noch mal die eine oder andere, denDen Deep Dive noch ein bisschen. Tiefer machen. Also ich finde es auf jeden Fall sehr spannend, was alles im Kottland Multi Platform Mower passiert. Das ist ein sehr spannendes Feld, was sich da irgendwie auftut, was sich da entwickelt. Ja, ich weiß auch nicht. Also ich weiß nicht, wann die Episode rauskommt. Aber also vielleicht auch noch mal einen Blick darauf halten, wer an Neuerungen im Kottland Multi Platform Bereich interessiert ist. Also Kottland Konf ist dann Mitte April, wo dann eventuell auch noch mal neue interessante Sachen vorgestellt werden. Wer weiß. Kann man auf jeden Fall mal ein Auge draufhalten. Wird kurz vorher sein, die Ausstrahlung. Das passt sehr gut. Ja, cool. Dann kommen wir zu den Pics of the Day. Hast du dir einen ausgedacht, Jojo? Ausgedacht. Hast du einen mitgebracht? Ich bin noch mal ein bisschen in mich gegangen und das, was ich in letzter Zeit viel nutze und mache, ist gar kein Tool für Entwickler, sondern eigentlich für Designer, was es mir aber inzwischen sehr angetan hat. Ich bin auch sehr Design-affin, habe früher auch selber sehr viel gezeichnet, habe jahrelang vor allem letztendlich die Adobe Tools genutzt und seit einiger Zeit gibt es bei uns hier in der Firma die Bewegung hin zu Figma, was ein Design Tool ist, was ja wirklich cool von der Verwendung ist, weil es sehr viele Funktionen einfach sehr gut gebündelt hat, sehr gute Zugänglichkeit bietet, auf das, was man wirklich braucht. Man kann natürlich nicht das alles machen, was man jetzt zum Beispiel mit Illustrator machen kann, aber schon sehr, sehr, sehr viel. Aber in einer sehr zugänglichen Umgebung und was auch die Zusammenarbeit zwischen Entwicklern und Designern sehr gut verbessert. Deswegen ja, falls ihr in diesem Bereich arbeitet, auch Interesse daran habt oder irgendwie auf eure Designer sich so ein bisschen beschweren, dass sie mit ihren Design Tools unzufrieden sind, dann könntet ihr vielleicht einen Blick mal ins Herz legen. Mich hat das auf jeden Fall begeistert und deswegen wollte ich das hier mal droppen. Sehr gut. Danke dir. Dann mache ich gleich weiter. Ich kriege bestimmt wieder Kritik für mein Pick of the Day. Und zwar weil ich selbst noch nicht ausprobiert habe. Aber ich glaube, es ist trotzdem gut. Es geht eine Erweiterung von Microsoft Teams, und zwar in dem Premium Tier. Wir nutzen leider …. Das kann schon nicht mal gut sein. Wir nutzen es intern nicht, deswegen können wir selbst wenig putzen. Aber sie haben sehr viel von der Magic, von ChatGPT, also mit dem GPTC.5 Modell da reingebracht. Und es ist so, dass die jetzt, wenn du in Meetings bist, sie praktisch Zusammenfassungen nach dem Meeting haben, wo sie genau auch sagen können, wer hat was gesagt, dass du dazu noch mal Nachfragen stellen kannst. In der Aussicht, dass beispielsweise automatisch Termine erstellt werden, wenn du sagst Hey Jojo, lass uns noch mal bald darüber sprechen. Dann wird ein Vorschlag gemacht für einen Termin, der danach kommt. Also wirklich dieses Meeting Game noch mal auf ein sehr anderes Level hebt. Hört sich super spannend an und wenn wir hier auf Microsoft Teams wären, dann würde ich auf jeden Fall mal versuchen auszuprobieren. Aber von daher der Tipp an all die, die sowieso in diesem Universum drin sind. Guckt euch das mal an und guckt, was ihr davon aktivieren könnt und gebt gerne mal Feedback-Tipps dazu, ob das wirklich so cool ist, wie es sich anhört. Sebastian, was hast du mitgebracht? Ich habe heute ein Buch mitgebracht, Buch von James Bug. Das nennt sich Mezus for Programmers Code your own twisty little Passages. Und dabei handelt es sich ein Buch, das so ein bisschen erforscht, was es für unterschiedliche Algorithmen gibt, Labyrinthe zu zeichnen. Das finde ich super, weil ich unglaublich gerne, vor allem früher Sachen programmiert habe, einfach nur mal was zu programmieren und ein bisschen Spaß zu haben. Und das Buch hat so ein bisschen dieses Gefühl wieder entfacht für mich. Also ich habe da keinerlei Ansprüche, als dass ich das jemals in meinem Beruf hernehmen würde oder dass ich damit die nächste Industrie revolutioniere, sondern es ist wirklich einfach nur, ein bisschen Spaß zu haben. Man lernt ein bisschen was über Pathfinding, was immer gut ist, wenn man irgendwie bei Advents of Code oder so auch mal mitmacht. Und es ist ein schönes Buch in voller Farbe, also mit vielen bunten unterschiedlichen Mases in unterschiedlichen Formen. Macht also sehr viel Spaß, da zuzuschauen. Oderund das auch mit ein bisschen mitzubasteln. Es sind Rubi tatsächlich die Textbeispiele, die Code-Beispiele, lässt sich aber relativ einfach auch in Kottland übersetzen. Sehr schön. Cool. Sebastian, vielen, vielen Dank, dass du heute Gast hier in der Programmierbar warst. Glaube auf jeden Fall ein sehr, sehr guter Einstieg, jemand mit der Liebe zu Kottland über Kotteln sprechen zu lassen. Und ja, hat Lust auf mehr gemacht, zumindest bei mir ein bisschen noch hier und da einzusteigen in ein paar der Themen, die wir dort haben. Von daher vielen Dank. Danke dir, Jojo. Dass du da warst und an unsere Hörer*innen wie immer die Bitte Feedback zu dieser Folge oder anderen Folgen schreib uns gerne einen Podcast, einvierfach. De, von mir. Bar. Würden uns riesig freuen. Sebastian, schön, dass du da warst. Dankeschön. Mach's gut.