 Schon viel besser. Man hat ja selten die Gelegenheit, seine Einführung zu einmal zu sprechen. Also, ich habe wie gesagt vor kurzem mich hier angemeldet und habe dazu geschrieben, ich könnte auch noch was zu Rust beitragen und meinte dann, na ja, wenn es für einen Stundenvortrag wird, könnte ich was über ein Jahr Rust, ein Jahr nach Veröffentlichung erzählen. Und habe dann zwischendurch festgestellt, na ja, vielleicht ist das doch ganz gut, zumindest mit die abzuholen, die es noch gar nicht kennen. Insofern zerfällt der Vortrag ein bisschen in zwei Teile. Also, kurz zur Rust-Einführung über so die wichtigsten, interessanten Dinge und ein bisschen Rückblick, was wir eigentlich im letzten Jahr so als Projekt gemacht haben und geschafft haben. Das verlangt dann vielleicht an manchen Stellen ein bisschen Vorwissen, ich versuche es aber trotzdem möglichst anfingergerecht zu erhalten. Wer bin ich? Also, wenn ihr kurz ich sein wollt, dann kopiert euch diese Zeilen und pastet sie in euer Bash-Po-File und dann könnt ihr committen und alles, solange ihr meine Schlüssel habt. Ich bin Backend-Entwickler, Großteils. Ansonsten bin ich hobbymäßig Community-Mensch, ich habe die Rust-User-Gruppe Berlin mitgegründet. Ich mache die Search-User-Gruppe in Berlin zu allen Suchtechnologien. Ich bin Ex-Vorstand, dass Ruby Berlin e.V., der einen etwas schlechten Namen hat, weil er eigentlich für ganz Europa da ist und inzwischen komplett europäisch tätig ist. Wir haben uns damals ein bisschen Namen vergriffen. Den Fehler haben wir nicht nochmal gemacht. Wir haben jetzt auch einen Verein zu Rust gegründet. Der heißt jetzt dann auch gleich Rust-Community Europe, kurz Name Rust C. Ich bin Mitglied des globalen Rust-Community-Teams, also ich bin Teil des Rust-Projektes, allerdings halt auf der Community-Seite beschäftigt. Und ich habe verschiedene Konferenzen veranstaltet, unter anderem ist Eurocamp und Djubi-Con für in Berlin, kommt also mehr so aus der Ruby-Community. Und jetzt dieses Jahr das Rust-Fest, was die europäische Rust-Konferenz sein wird. Insofern habe ich viel, viel Empathie für die Probleme dabei der Technik, dass das ehrlich gesagt die große Panik, die ich immer habe, dass irgendwas nicht funktioniert und man nichts lösen kann. Insofern großen Applaus an die Menschen da hinten, das alles möglich machen. Ja, was ist Rust eigentlich? Rust ist eine Programmiersprache, die erfunden wurde von Graydon-Hua. Graydon-Hua war damals beim Musiker-Research beschäftigt, ist aber inzwischen mit dem gesamten Projekt nicht mehr da. Graydon macht jetzt wieder C++-Entwicklungen und irgendwas mit digitalen Währungen. Es basiert auf linearen Typen und das wird das letzte Mal sein, wo ich irgendwas über Typtheorie sage. Lineare Typen sind Typen, die genau tracken, wie häufig sie verwendet werden, nämlich nur genau einmal. Und hat ein regionenbasiertes Speichermenagement, da werde ich auch noch kurz im Detail darauf eingehen. Es wird heutzutage entwickelt von Mozilla und finanziert von Mozilla. Das ist bei Mozilla ja immer so ein bisschen die Frage, es gibt Mozilla-Projekte, die kriegen eigentlich kein Geld von denen, sonst gibt Mozilla-Projekte, die kriegen Geld von denen. Es ist momentan ein Projekt von Mozilla-Research in Palo Alto. Und es wird jetzt in Firefox verwendet. Wenn ihr Firefox 45 verwendet oder höher, also das ist die vorletzte Version, dann habt ihr Rust Code auf eurem Rechner am Laufen. Und es wird insbesondere verwendet für alle Sachen, die parsing sind. Also momentan wurde der URL-Paser in Rust neu geschrieben, weil das eine überraschend häufig angegriffeneste Code ist. Und MP4-Meter-Daten werden in Rust gepasst. Und so werden sukzessive kleine Komponenten von Firefox in Rust neu geschrieben. Wir haben letztes Jahr, am 15. Mai, wurde Rust 1.0 veröffentlicht. Nach insgesamt acht Jahren Arbeit. Da gab es viele, viele Ansätze, wie man das dann alles machen kann. Und die Sprache hat sich sehr, sehr geändert bis zu dieser 1.0. Ich habe angefangen mit Rust 04 vor zweieinhalb Jahren. Das sah schon fast nicht mehr aus wie das, was man heute schreibt. Man kann da nur noch Reste von erkennen. Die Ziele, die Rust hat. Rust möchte eine speichersichere Sprache sein. Aber und das ist der Twist, ohne Garbage Collection. Weil das in ganz vielen Bereichen wieder speichersichere Sprachen ausschließt. Ich kann mir nicht überall ein Garbage Collector mit einer großen Runtime, mit einer JVM, mit was weiß ich sonst leisten. Sie soll unterstützen bei Nebenläufigkeit, weil Nebenläufigeentwicklung heutzutage einfach wichtig ist. Und sie soll eine erwartbare Geschwindigkeit haben. Hier auch wieder das Problem, wenn ich ein Garbage Collector habe, weiß ich immer nicht, wann der zuschlägt. Viele Garbage Kollektoren führen dann zu Pausen. Sowas möchte ich nicht haben. Also das sind so die drei großen Ziele, die wir haben. Sie soll sicher sein, was hat ein statisches Typsystem mit TypInferenz? Also die TypInferenz eher für die Convenience. Aber grundsätzlich, es gibt ein statisches Typsystem, alles ist statisch typisiert. Es gibt keine Null-Pointer und es gibt kein Pointer-Aliaseng. Einfach häufige Quellen von Bugs und häufige Quellen von undefiniertem Fahrer. Nebenläufigkeit wird dadurch unterstützt, dass Mutabilität in Rust ein Konzept erster Klasse ist. Es ist nicht so, wie viele Sprachen heutzutage, dass sie entweder zerfallen in Daten sind mutabel oder Daten sind immutabel, was ja häufig von der Sprache eher nur semantisch forciert wird. Im Hintergrund sind sie dann doch wieder auf irgendeine Art und Weise mutabel. Rust hat dafür entsprechende Anotationen. Das ist mutabel und das nicht. Da gehe ich gleich noch darauf ein. Es gibt keine konkurrierten Zugriffe auf mutable Daten. An keiner Stelle nie, ohne dass ich da irgendwie außenrum irgendeine Art von Moderationen einbaue. Und wichtige Basistypen für Nebenläufigkeit, weil ich auch gleich noch zeigen, sind mitgeliefert. Auf der Geschwindigkeitsseite Rust möchte keine versteckten Allokationen. Das ist manchmal ein bisschen verbost, weil man immer ein bisschen Arbeit machen muss, um auch wirklich was in den Speicher zu legen, insbesondere auf den Hieb. Es gibt erwartbare Deallokationen. Man weiß immer genau, wann die durchgeführt werden. Hier wieder die Sache. Wir haben keinen Gabisch-Collector. Insofern gibt es einfach einen Punkt, an dem was stattfinden wird. Die Sprache bietet Abstraktionen, aber diese sollten nach Möglichkeit keine Laufzeitkosten haben. Also, das von Hand genau zu schreiben, was der Rechner jetzt im Speicher machen soll, soll nicht schneller sein, als das, was was tun würde. Was hat kein Laufzeitsystem? Ich habe ein kleines Sternchen dran. Es hat Stack Unwinding, wie viele andere Systemsprachen auch. Dazu braucht man natürlich eine ganz kleine Runtime Bibliothek. Das ist der letzte Versuch noch optional. Da komme ich noch drauf. Und es hat keinen dynamischen Dispatch. Funktionen werden also immer staatischer aufgerufen. Da habe ich ein Sternchen dran. Es gibt dynamischen Dispatch, für den man arbeiten kann. Wenn man das unbedingt haben möchte, dann kann man sich da wieder hinarbeiten, dass man das an bestimmten Stellen hat. Aber es passiert nicht irgendwie, ohne dass man das nicht angefordert hat. Und das Ziel ist ganz offen C. Endlich mal wieder eine Sprache haben, die sich ernsthaft damit beschäftigt, was C eigentlich gut macht und das mal evolutionär weiterzuführen. Also, was bietet ein kontrollierbares Memory-Layout, kann C-Abi oder Plattform-Abi kompatible Bibliotheken erstellen. Also, ich kann damit meine dynamischen Bibliotheken oder meine staatischen Bibliotheken schreiben. Es hat eben kein Laufzeitsystem. Und es gibt eine optional unsichere Subsprache, in der viele von den Dingen, für die man halt manchmal C verwendet, verschiedenste Pointer-Magie und so weiter und so fort, dann doch wieder erlaubt sind. Das ist insbesondere wichtig, wenn man mit anderen Bibliotheken Interface möchte, die halt nicht in Rust geschrieben sind. Dass es für die Sicherheitsgarantien, die Rust bietet, sind halt einfach unsicher insofern gibt es dafür eine spezielle Subsprache, die ich heute aber nicht vorstellen werde. Ja, wie sieht es denn so aus? Das ist ein Stück Rustcode, das mal einfach der GPN Hallo sagt. Hallo GPN. Es ist eine Sprache mit Curly Braces. Wie man sieht, da sieht man auch gleich schon diese Mutabilitätsanotationen. Haben möchte dieses Stringform hier oben. Das, was ich eben meinte, String, ist der heap-allokierte String. Und damit ich den kriege, kann ich nicht einfach String irgendwo hinschreiben, sondern ich muss ein bisschen ceremoniell ausführen mit diesem String from. Rust hat eine ganze Menge bekannte Konzepte, über die ich in der Zeit jetzt leider nicht in einzelnen drüber gehen kann. Rust hat als Standard-Datentypen Structs, Enoms und Funktionen. Funktionen sind Typen erster Klasse. Ich habe also auch Closures und so weiter, die wird man später kurz sehen. Es hat Typ-Inferenz. Also ich muss nicht immer hier anotieren, dass übrigens Greetings String ist und so weiter. Das erkennt Rust schon selbst. Wichtig ist, die Typ-Inferenz hört an den Funktionssignaturen auf. Signaturen muss ich immer komplett ausschreiben. Das ist eine Designentscheidung, die man getroffen hat. Man möchte das als Grenze haben, an dem man auch wirklich dokumentiert, was man eigentlich rein und raus haben möchte. Für die, die in der Richtung Scala mal was gemacht haben, die Art und Weise, mit denen man generischen Code schreibt, sind in Rust Trades, die über diesen Structs implementiert werden, die ich heute leider auch nicht einführen kann. Und Generics sehen ziemlich aus, wie es ist eine Mischung zwischen Templates in C++ und den Generics in Java. Neue Konzepte sind die vorhin genannte Motabilitätsprüfung, so genannte Borrowing. Das werde ich gleich einführen, Lifetimes und Sharing als Konzept, das in der Sprache selbst verbacken ist. Fangen wir kurz mit den Lifetimes an. Damit flucht man auch immer am Langsten. Wer sieht den Fehler in dem Stuttcode? Das ist ein Stackout-Kilb-Beschlechtung-Freundau-Kilb-Beschlechtung. Genau, Trivialbeispiel, aber irgendwie muss man was auf die Folien kriegen. Rust erkennt solche Fehlerfälle insbesondere. Was an dieser Stelle modelliert, ist halt eben die Lebenszeit von allen Werten, die man in den Programmen verwendet. A ist lokal in FU verwendet. Ich gebe eine Referenz darauf zurück. Rust wird mir sagen, A does not live long enough. Das kann relativ komplex werden. Das Wichtigste darauf ist, Rust verwendet ein Typsystem, in dem an allen Stellen diese Prüfung stattfinden kann. Und darüber wird halt eben diese vorhin genannte Speichersicherheit ohne Laufzeitenunterstützung hergestellt. Nämlich, wenn ich das feststellen kann, dann kann ich nämlich auch feststellen, an welchen Stellen eigentlich auch die Dealokationen von diesen Werten stattfinden müssen. Mutabilität, ich verwende überall Annotationen dafür, ob Daten mutabel sind oder nicht mutabel sind. Insbesondere in Funktionszytenatoren und bei variablen Bindings. Hier zum Beispiel, wenn ich jetzt sage, ich habe eine Struktur und die habe ich noch mal in einer anderen Struktur Data. Ich sage, ich möchte gerne, also ich konstruiere die erst mal hier oben den Speicher und dann sage ich, ich möchte gerne Wahl ändern, dann wird sich was beschweren, dieses Feld ist immutabel. Also das wird forciert durch ganze Objektbäume hinweg. Das kann ich an dieser Stelle umgehen, indem ich diese Variable einfach mutabel mache, weil, gesagt, Trivialbeispiel. Aber wenn ich zum Beispiel eine Funktion habe, die Daten nicht mutabel übernimmt, in der Funktion Signature einfach gesagt, du kriegst Data immutabel, ist bis hin beliebig tief in dieser Aufrufskette garantiert, dass Data niemals mutiert werden wird. Das ist bei großen Systemen sehr, sehr angenehm, weil ich halt einfach wissen kann, okay, ich schmeiß hier jetzt einfach in dieses riesige Stück Bibliothek meine Daten rein. Wenn der Aufruf fertig ist, sind sie immer noch genau dieselben. Wie gesagt, Teil der Signaturen sind rekursiv, also in beliebigen, in beliebtiven Typbäumen, und es wird global durchgesetzt. Ein weiteres Konzept, das neu ist an Rust oder für viele Leute neu ist, für C++ Entwickler, teilweise wenn sie Boost verwenden nicht oder moderne C++ Standard Bibliotheken. Alle Daten in Rust werden exakt einem Code Teil zugeordnet. Der kann den Besitz abgeben, kann dann beliebige Sachen machen, aber in dem Moment in den Besitz abgegeben wird, wird die Variable unverwendbar. Es ist ähnlich der SharePointer Semantik in C++, aber auf Sprachlevel und zur Kompellierzeit forciert. Es gibt da keine One-Time-Komponente. Beispielsweise hier, ich allokiere mir ein Vektor, übergebe den an eine Funktion, die ihn prüntet, aber übergebe sie, übergebe Ownership. Also ich gebe kein Referenz, und ich übergebe das wirklich als Wert. Das heißt, ich kann ihn danach nicht mehr verwenden. In dem Moment, in dem ich versuche, diesen Vektor mal auf die Konsole aufzugeben, werde ich den Fehler kriegen, error of moved value B. Die Begründung ist folgende. In dem Moment, in dem ich ein Vektor ist nicht trivial kopierbar, in dem Moment, in dem ich ein Vektor an eine andere Funktion gebe und sage ich gebe Ownership ab, wird der Rust Compiler jede weitere Verwendung dieses Werts verbieten, solange ich nicht gesagt habe, dass der trivial kopierbar ist, zum Beispiel bei Integers. Wenn ich das aber dennoch tun möchte, oder wenn ich dennoch diese Daten zur Verwendung weitergeben möchte, aber sie weiter besitzen möchte, gibt es darüber das Konzept des Borrowings. Und Borrowing folgt in was relativ simplen Regeln. Ich darf eine unmutable Referenz auf irgendwas übergeben. Ich darf beliebig viele immutable Referenzen auf irgendwas vergeben, aber nicht beides gleichzeitig. Ich darf entweder eine immutable oder beliebig viele Immutable haben, aber nicht eine Immutable und eine Immutable. An der Stelle kommt das erste Mal dieser Concurrency-Gedankerein. Ich komme in Probleme in dem Moment, in dem ich 15 immutable Referenzen auf irgendwas rausgebe, erwartet, dass es immutable, aber ich gebe trotzdem eine immutable Referenz an eine weitere Partei in dem Programm aus, die darin beliebig was ändern darf. Da ist diese Erwartbarkeit weg. Das selbe Code-Example von eben nochmal nur mit diesem schönen Ampercent hier an dieser Stelle. Wenn ich eben einfach Borrow statt einfach meinen Besitz abzugeben, kann ich mehrfach auf diesen Vektor arbeiten, weil in diesem Moment der Besitz nicht abgegeben wird. Referenzen geben den Besitz nicht ab und sind nur temporär gültig. Und auch da ist, wie gesagt, statisch passiert. Nehmen wir ein etwas Komplexeres Beispiel, warum so was Sinn machen kann. Hier zum Beispiel ist es ein bisschen schwieriger. Ich habe zwei Vektoren. Ich möchte die aneinanderbinden. Ich mache das einfach hier wieder mit einer Trivialimplementierung. Ich nehme einfach, ich iteriere über den zweiten und füge alle Elemente an den ersten an. Das ist nicht die effizienteste, aber reicht fürs Beispiel. Die Signatur von Push All ist in dem Moment klar. Ich nehme eine immutable Referenz auf einen Vektor. Nämlich der, von dem ich kopiere und nehme eine mutable auf den, in den ich kopiere. Und ich habe zwei unterschiedliche Vektoren. Der eine ist mutabel, der andere ist immutabel und kann dann in die Richtung kopieren. Schöne Sache funktioniert. Aber was passiert eigentlich, wenn ich von einem Vektor in den anderen kopieren möchte, von dem selben Vektor in sich selbst kopieren möchte? Es häufig bei vielen Collection Bibliotheken nicht erlaubt. Und das kann an der Stelle was auch wieder forcieren und in der Signatur ausspülen drücken, weil da kommt nämlich genau diese Regel. Ich kann nicht den selben Vektor gleichzeitig mutabel und immutabel referenzieren. Und dieser Fall wird in diesem Moment gefangen. Das ist, habe ich mir sagen lassen, von verschiedenen Firefox-Entwicklern gar keine so seltene Sache, dass einem aus Versehen sowas passiert. Das sind 99% aller Fälle, dass unterschiedliche Dinge sind, die man da ineinanderschiebt, während man eine Funktion aufruft und dann passiert in einem ganz seltenen Fall, nämlich genau das, was man nicht möchte. Und das führt dann zu schwer zu findenen Bugs. Die an der Stelle die Sprache komplett verhindert. Schauen wir uns kurz noch die Concurrency-Sachen im Rust an. Fangen wir erstmal an mit Thwets. An dieser Stelle auch wieder ein schönes Beispiel für das Lifetime-Tracking. Hier seht ich, erkläre Rust immer ganz gerne an den Dingen, die nicht kompilieren. Mehr als an den Dingen, die kompilieren. Ich habe hier ein Vektor. Ich spawnen Thwet und möchte ihn in diesem Thwets binden. Das Problem an der Stelle ist, Thwets haben eigenen Stack-Laufen nebenläufig. Es könnte passieren, dass mein erster Thwett, den den zweiten spawnt, sich beendet, bevor der zweite überhaupt dabei ist, das zu tun, was er möchte und unter Umständen diesen Speicherwert abräumt. Das erkennt Rust. Rust erkennt Track diese Lifetimes über Thwettgrenzen hinweg und sagt, ich kann nicht garantieren, dass das, was du in einem einen Thwett allokiert hast, in dem Moment, in dem der andere Code läuft, überhaupt noch da ist. Insofern wird das nicht kompilieren. Es gibt Möglichkeiten und es gibt Primitive, mit denen das geht, mit denen man das fussieren kann. Man kann in Rust zum Beispiel sagen, hier, ich möchte gerne einen Thwett, einen sogenannten Scope Thwett aufmachen. Dieser Thwett garantiert, dass die Aufrufstelle blockt bis zu dem Moment, in dem dieser Thwett zu Ende ist. Das ist ein ganz interessantes Beispiel. Ich hatte überlegt, ob ich es nicht rausschmeiße. Dieses Code-Beispiel hatte ich vor Rust 1.0 geschrieben. Da war das noch eine Standardbibliothekfunktion und war so das, was alle präsentiert haben. Kurz vor Rust 1.0 hat irgendjemand festgestellt, dass es möglich ist, dadurch aus dem Typsystem auszubrechen. Da mussten wir erst mal noch drei Monate Runden machen und gucken, wie das denn geht. Inzwischen ist es jetzt einfach eine Bibliotheksfunktion, deswegen die Verwendung von diesem Crossbeam, was eine Bibliothek ist, die es bereitstellt. Jetzt funktioniert es aber, jetzt funktioniert es auch typisch sicher. Was das, wie gesagt, macht, ist, dass in dem Moment, dass dieser Scopeaufruf nicht zurückkehrt, bevor dieses Wetz nicht zu Ende sind. Entsprechend kann ich damit dann lustig beginnen, komplexe Sachen zu schreiben. Das ist zum Beispiel die komplett übertriebene Art, ein Vektor von drei Zahlen mit drei Swets ins Quadrat zu nehmen. An der Stelle sieht man dann auch, Rust hat funktionale Anteile und Rust verwendet auch sehr, sehr gerne Closures. Eine solche Entplementierung von Rust ist sehr interessant. Da kann ich jetzt nicht genau darauf eingehen, aber sie hat eben diese Eigenschaft, die ich auch vorhin beschrieben habe, dass nach Möglichkeit selbst Dispatch of Closures ohne Funktionspointer auskommt, sondern komplett statisch stattfindet. Hier zum Beispiel wird an keiner Stelle irgendwo ein Funktionspointer verwendet. Es ist üblicherweise so, wenn man sich sowas in Assembly anschaut, kommt man normalerweise bei dem raus, der sehr gut geschriebenen C machen würde, wenn man es effizient machen möchte. Die Begründung daran ist, hinten dran ist, da steckt LVM, hinten dran und LLVM ist bei Optimierung von Iteratoren extrem gut und kriegt im Prinzip diese ganzen Loop-Konstrukte raus. Gut, hier ist die Frage, wie gefährlich ist das alles, das Interessante ist? Es ist möglich, erst Stackdaten zu teilen und das sicher zu tun. Also der Compiler stellt entweder fest, wenn der Stack unter Umständen verschwinden könnte, bevor ich sie verwende, oder er stellt fest, dass die Stackdaten, die ich verwende, so lange leben, wie das, was ich damit tue. Wenn wir bei Concurrency sind, möchte ich noch kurz auf Logs eingehen. Logs sind Teil des Typsystems und das finde ich ziemlich wichtig. Sie arbeiten nämlich auf Daten Hier ein kleines Beispiel auch wieder, ein Vektor, wir versuchen diesen Vektor zu schreiben. Ich hole mir ein Vektor. Ich weppe den in einem Mutex. Ich hätte es vorhin kurz erklärt mit Ownership. In dem Moment, in dem ich Mutex New aufrufe übernimmt, der Mutex den Besitz dieses Vektors. Ich kann ihn also nicht mehr direkt verwenden. Das heißt, um damit irgendwas zu machen, muss ich mir von dem Mutex muss ich dem Mutex sperren, mir ein entsprechendes Objekt holen, über das ich diese Manipulation ausführen kann und dann eben auf diesen Vektor schreiben. Wenn ich zum Beispiel, wenn ich direkt versuchen würde, auf den Vektor zu schreiben, kommt nämlich genau diese Meldung. Ich habe in dem Moment, in dem ich Mutex New aufgerufen habe, den Besitz des Vektors in den Mutex geschoben, in dem Moment, in dem ich nur noch auf diesen Mutex Referenzen arbeite, mit dem Mutex Mutex aufgerufen habe. Das finde ich eine sehr, sehr angenehme Sache, womit so ein statisches Typsystem einem auch wirklich einfach extrem viel helfen kann. Dieses Wrappen von Daten in ihre Zugriffsarten wird extrem häufig verwendet und führt zu extrem hohen, führt dazu, dass man sehr, sehr angenehm, sehr, sehr sicheren Code schreiben kann und wirklich nur noch darauf zugreifen, wenn ich im Mutex arbeite. Das heißt, synchronisierte Daten werden prinzipiell verpackt. Das mehrfache mutable Teilen an dieser Stelle verhindert eben das Typsystem, garantiert mir an jeder Stelle, dass diese, dass nicht mehrere Parteien gleichzeitig mutable Zugriff auf diesen Teil kriegen kann. Und dann kommen dazu noch zwei besondere Typen. Zynk. Alle jedes Stück Daten in Wast sind Zynk oder Keins von Beidem oder beides. Zynk heißt, der Zugriff auf diesen Typ ist synchronisiert. Referenzen darauf sind übers Wettgrenzen sicher. Mutex zum Beispiel ist Zynk. Und alles, was dann in dem Mutex ist, damit automatisch auch. Das heißt, wenn ich jetzt zum Beispiel versuche, irgendwas zu verwenden, das ist unser Reference-Counter, hat sie und versuche, ein Wett zu spawnen und versuche das da drin zu verwenden, dann kommt hier die Meldung cannot be shared between Wetsafely. Das ist ein extrem häufiger Bug und das ist ein extrem seltener Bug in Wast. Einfach Sachen, die nicht Zynk sind, kann ich einfach nicht irgendwo plötzlich in einem anderen Wett verwenden. Das fängt eine extrem große Menge an Fehler an sehr, sehr schnell und auch sehr, sehr klar. Scent ist das Gegenstück. Daten, die Scent sind, können zwischen Wettgrenzen als Wert versandt werden, also im Prinzip ownership abgeben über verschiedene Programmateile hinweg. Scent wird auch automatisch von Compiler festgestellt. Trivialtypen sind meistens Scent. Man kann das auch selbst implementieren und verwendet wird das für klassisches Message Passing. In dem Moment kann ich eben sagen, das ist die sogenannte Move Closure. Die wird dazu führen, dass die Daten bewegt werden. Ich kann also sagen, ich kann ein Stück Daten nehmen. Bewege die Bitte in den Wett. Integers Scent werden einfach rüber bewegt. Fertig. Ich darf sie dann halt in den Original Wett nicht mehr verwenden. Und wenn man diese Sachen einfach anwendet, z.B. Channels, wie man sie aus Go kennt, einfach eine Bibliothek. Solche Sachen werden in was einfach in der Standardbibliothek implementiert oder man verwendet halt eben was anderes, was irgendjemand woanders gebaut hat. Hier nochmal ein Beispiel für dieses Channel Teil Erziehe. An dieser Stelle ist auch nicht Scent. An dieser Stelle wird sich dann der Kompiler auch beschweren. Als kurze Zusammenfassung, was eliminiert klassische Nebenläufigkeitsprobleme. Es ist statisch und ohne Laufzeitunterstützung an dieser Stelle. Das ist das Wichtigste. Das passiert alles zur Kompilierzeit. Und dadurch eignet sich zur Systemprogrammierung und ist dadurch, dass es am Ende, wenn ich möchte, halt einfach eine ganz normale Plattformbibliothek dabei rauskommt, einfach mit FFI. Und damit wir dann so langsam zu dem Review Teil kommen. Was kommt denn erstmal so mit Rust, wenn ich es mir installiere? Also man kriegt erstmal den Kompiler. Das ist Rust C. Und ein Bild- und Paketmanagement-System. Das ist Kago. Für die, die Rubi verwenden, dass das geschrieben von den Menschen die Bandler geschrieben haben. Es hat eine ganze Menge Krankheiten. Die Bandler hat nicht glücklicherweise. Und inzwischen kommt das mit vorkompilierten Standard- und Core-Bibliotheken. Also es gibt 2 wichtige Bibliotheken bei Rust, die man auf jeden Fall... Es gibt eine, die man auf jeden Fall braucht. Das ist Core. Das ist alles, was man braucht, um die Sprachfeatures zum Laufen zu bringen. Und es gibt die Standard-Bibliothek, die mit dem Kompiler gepflegt werden. Und die gibt es inzwischen auch komplett vorkompiliert für eine große Liste von Plattformen. Und es gibt ein Buch. Mozilla hat eine Person fest angestellt, um ein Buch über Rust zu schreiben. Es gibt noch verschiedene, die ein paar Bücher zu Spezialthemen geschrieben haben. Aber man kriegt eine extensive Do-go dazu. So, Plattformen, die unterstützt werden, zum Beispiel sind aktuell Android in allen Varianten, Linux in vielen verschiedenen Plattformvarianten auch und insbesondere Architekturvarianten. Windows insbesondere auch MSVC, also nicht nur den GnuStack, OS X, IOS, 4BSD, verschiedene Arm-Plattformen auch für Embedded-Entwicklung und Micro-Cannels, der BSD-Bump-Run. Da hatte irgendjemand mal totalen Spaß, das mal zu adaptieren, ist inzwischen was offiziell unterstützt. Rust ist ziemlich genießbar, man hat einen sehr informativen Kompiler. Es wird regelmäßig an den Informationen, die der Kompiler gibt, gebaut. Die sind auch sehr gut geschrieben. Es ist an sich ziemlich gut dokumentiert. Es gibt ein paar Ecken, da könnte alles ein bisschen besser werden. Das Buchlesen hilft da sehr. Wir haben einen etwas unüblichen Release-Seikel und zwar, so wie Firefox. Alle sechs Wochen. Alle sechs Wochen wird Nightly zu Beta und wenn in diesen sechs Wochen nichts Besonderes auftritt, wird Beta zu Release. Was dann stabil in der Release-Version bleibt, ist stabil. Es können zwar noch Diplocations auftreten, aber wenn eins in der Versionsnummer steht, dann könnt ihr davon ausgehen, dass ihr euren 1.2-Code auch mit 1.9, 1.10 oder sonst was kompilieren könnt. Wir sind jetzt inzwischen, heute ist 1.9 rausgekommen oder gestern ist 1.9 rausgekommen. Die Versionsnummer springt da relativ schnell nach oben. So, insofern mal ein bisschen Rückblick über, wie das Projekt eigentlich so funktioniert hat die letzten Jahre, das letzte Jahr. Erst mal klappt das auch. Wir haben uns da vor dem Jahr überlegt, wir möchten das so machen, hat das auch funktioniert. Wir haben festgestellt, 96% alle mit Rust 1.0 funktionierenden Bibliotheken bauten mit Rust 1.5. Warum hat man bei Rust 1.5 mal nachgeschaut? Irgendjemand hat natürlich, wie das so ist, nachdem man es veröffentlicht, einen kleineren Bug im Typsystem gefunden, der aber leider eine Änderung der Semantik des Typsystems verlangt hat. Etchcase, etchcase, etchcase, aber wie man das so hat, irgendjemand verwendet den etchcase. Leider, leider. Das waren sicherlich 3% von dieser Breakage. Wie stellen wir so was denn überhaupt fest? Also, erst mal auch kurz noch kurz den Nightly zu dem Trainmodell. Was wir dadurch ermöglichen ist, Verbesserungen sind recht schnell verfügbar. Also, wenn man sieht, ja, da wurde jetzt eine Verbesserung, eine Geschwindigkeitsverbesserung zum Beispiel für MSVC, da sind wir noch immer nicht so schnell, wie wir sein wollen, aber, und man sieht, diese Änderung wurde gemacht, dann dauert's üblicherweise bis zu 12 Wochen, allerdings bis sie da sind. Das hat leider auch einen Nachteil. Es führt dazu, dass Leute häufig sagen, ah, also dieses Nightly-Feature, das ist ja eh bald da. Dann arbeite ich mal noch so lange auf Nightly. Was für Leute, die gerne stabile Software mit dem stabilen Compiler entwickeln, manchmal ein bisschen unangenehm ist. Dafür, wie gesagt, es dauert nie allzu lange, bis irgendwelche Verbesserungen oder neue APIs verfügbar sind. Was wir da am Compiler verändert haben, also, am Compiler haben wir einige Verbesserungen eingeführt. Es gibt jetzt parallele Code-Generierungen, das haben wir bis zum Release einfach nicht geschafft. IDE-Support gab's von einem Jahr auch noch nicht, das ist stark am Beginn. Interessanterweise die Microsoft-Welt bedeuten schneller. Es gibt sehr, sehr gute Plugins für Visual Studio und Visual Studio Code, was ja der Microsoft Atomclone ist. Es gibt Windows jetzt als offizielles Target, das war zur 1.0 noch nicht so. Aber es war ungemein wichtig für Firefox. Ohne Windows geht's halt nicht. Es wurden verschiedene Sprachfeatures eingeführt. Spezialisierung ist 1. Da muss ich vielleicht kurz erklären, das Problem ist, wenn man mit Generics arbeitet, hat man das Problem, man kann immer schöne generische Implementierungen anbieten und dann für irgendwelche Sachen. In diesem Fall zum Beispiel war das klassische Beispiel, ich hab eine Collection und möchte die an eine Collection binden. Da kann ich sehr einfach eine andere Collection anhängen. Da kann ich einen sehr schönen generischen Algorithmus finden. Sehr häufig ist es aber so, dass wenn ich weiß, dass das Memcopy einfach zu schnell ist, was ich gerade machen kann. Das Problem ist, diese Regeln sind nicht ganz klar und lange Zeit war es bei Rust halt auch einfach so, dass Rust gesagt hat, du kannst mir keine 2 Implementierungen für was anbieten, weil ich nicht weiß, welche von den beiden ich wählen soll. Und da hat man sich jetzt ein halbes Jahr lang Regeln überlegt, unter denen der Compiler dann sagt, du kannst mir eine Implementierung für 2 konkrete Typen zum Beispiel anbieten. Dann werde ich die wählen statt der generischen. Da muss man aber sehr aufpassen, wie man diese Regeln zieht. Das war eine ganze Menge Arbeit, das war auch eine ganze Menge konzeptionelle Arbeit und es war vor allem deswegen eine ganze Menge Arbeit, weil man halt auch aufpassen musste, dass man nichts kaputt macht, was da ist. Was jetzt gerade in den letzten Monaten gekommen ist, ist Cross-Compiling nach der Art Download und los. Früher musste man sich Standard-Lip und Call-Lip für die Zielplattform selbst bauen. Das war ein sehr involvierter Prozess. Da hat man ziemlich viel Spaß mit gehabt. Inzwischen gibt es einfach die Möglichkeit, dass man den Last-Compiler hat. Dann sagt man ihm, ich hätte gerne bitte nochmal die Toolchain für Android ARM V7. Und dann lädt er die auch noch runter. Man hat die nicht automatisch dabei. Aber es gibt die jetzt einfach mit im Release-Prozess einzige Sache, die noch fehlt. Man braucht natürlich immer noch den Plattform-Linke und die Lips, weil wir stellen keinen eigenen Linker her und wir stellen auch die Plattform-Lips nicht her. Das ist der nächste Schritt, an dem wir arbeiten möchten. Aber es ist schon bedeutend besser, weil Standard-Lip-Kompilieren bei Rastoch gerne mal zwei Stunden dauert. Es wurde eine ganze Menge APIs stabilisiert. Es wurde insbesondere diese Core-Bibliothek. Also was brauche ich eigentlich, wenn ich ein Was-Programm kompilieren möchte, was brauche ich eigentlich jetzt Minimum? Das war eine Weile nicht klar und noch ein bisschen im Flux. Deswegen wurde diese Core-Bibliothek inzwischen stabilisiert. Also wirklich jede Komponente des Programms, das am Ende bei rauskommt, selbst schreiben, wer man denn möchte. Also Entwicklung eigener Basis-Lips ist da jetzt inzwischen möglich. Das ganze Drumherum hat sich eigentlich ziemlich gut entwickelt. Und zwar hat sich die Strategie, was da ist, funktioniert eigentlich als ganz gut rausgestellt. Es ist nicht alles da, aber es macht für die Leute, die die Sprache nach außen vertreten wollen, viele Dinge einfach bedeuten, einfacher, das ist noch nicht da. Oder das Tool ist da und es funktioniert. So, ja, da musst du noch ein bisschen dran rumbauen und das ist halt alles nicht so schick. Es ist immer schwierig und halt besonders stressig für Leute, die mit der Sprache halt mal anfangen wollen. Also was so da ist, ist zum Beispiel eben diese Versions- und Toolchain-Switcher, mit dem man sich ein Compiler runterladen kann, sich die verschiedenen Bibliotheken verwalten kann für verschiedene Plattformen und für die, die mal Go gemacht haben, es gibt ein Formatierungstool, das ist eine Standardformatierung für Code anbietet. Das heißt dann, das ist eine Go-Format-Kopie und entsprechend heißt das dann Wastformat. Es gibt ein Linker mit dem netten Namen Clippy, der hat auch manchmal so den Ton ist so ein bisschen wie die Klammer aus Word. Ja, wie kriegen wir das eigentlich alles hin? Da komme ich jetzt zu diesem Punkt, dass man halt diese ganze Mengen Sachen überhaupt noch überhaupt grob überblicken kann, was davon eigentlich funktioniert, was nicht funktioniert und wie kriegt man überhaupt raus, dass 96% alles Codes, der geschrieben wurde, überhaupt noch nach einer bestimmten Wast-Videos-Version funktioniert. Viel, viel Tooling, ganz viel Tooling. Das größte Strukturling an der Stelle ist Crater. Bibliotheken heißen in Wast-Crate und irgendjemand hat sich gedacht, das Tool, mit dem ich alle Crates testen, den nicht Crater. Und bei größeren Sprachänderungen wird halt einfach ein Crater Run angefordert. Da muss ich auch ehrlich sagen, das ist halt ein großer Vorteil, wenn man halt bei Mozilla sitzt. Mozilla hat halt eine Rechnerinfrastruktur, da kann man sowas auch einfach mal machen. Das ist für ein kleineres Open Source Projekt natürlich erstmal für den Zähleraufwand und Setupaufwand. Dort fragt man halt einfach mal ob es an, ob man irgendwie ein paar Kisten kriegt. Wir machen das halt nicht immer, weil wir auch nur so grob das Gefühl haben, da könnte was bei kaputt gehen, wird einmal Crater laufen gelassen, nachdem die Änderung gemirkt würde. Ja, man braucht die Ressourcen dazu. Es ist heutzutage nicht mehr ungemein teuer, aber wenn man halt irgendwie 12 Plattformen testen möchte und den ganzen Gepäiler darauf kumpelieren möchte, da ist schon eine ganze Menge Infrastruktur hinten dran. Mein Lieblingstool ist eigentlich High Five. Weil High Five ist total einfach, kann man auch mal in den Nachmittag selbst schreiben und total effizient. Was High Five macht, da hat sich jemand gemeldet und hat ein Pull Request an den Compiler gestellt, weil er einfach eine neue Klasse implementiert. Und als allererstes kommt dann High Five. Es gibt einem High Five, weiß jemanden zu und schreibt noch kurz dazu, hallo, schön, dass du dich gemeldet hast. Alex Quitschten vom Compiler Team wird sich darum kümmern und erklärt noch so ein kleines bisschen wie es dann mit Änderungen ausgeht und so weiter und so fort. Der interessante Trick daran ist eigentlich nur bei ganz vielen Projekten hat man so Tickets, die einfach niemanden gehören und die fallen dann irgendwo runter, weil niemand durch die Tickets geht, die niemanden gehören. Sondern die Leute gehen immer nur durch die Tickets, die ihnen schon zugewiesen sind. Und was High Five einfach macht, sorgt dafür, dass alle Tickets irgendjemanden zugewiesen sind, sogar meistens einfach nur zufällig und die Person kann dann sagen, naja, das ist jetzt nicht mein Spezialgebet, das muss jemand anders machen. Aber zumindest mal die Person, die sich die Person raussucht, die das Review machen soll, ist schon mal klar. Dadurch ist alles einfach irgendjemanden zugewiesen und das funktioniert ungemein gut und wie gesagt, man kann sich das in einem Nachmittag selbst schreiben. Ja, und begrüßt die Leute auch noch. Netzein ist wichtig. Es gibt viel weniger Probleme mit vergessenen Tickets. Es gibt momentan Homo gibt es als Service. Das Problem ist, momentan ist der Maintainer von Homo ist gerade mal wieder verschwunden. Das ist ein bisschen ein Problem. Homo automatisiert Tests und Merging insbesondere. Commits auf den Master Branch von unserem Projekt passieren nur über Homo und nur, wenn der Bild grün ist. Wie es funktioniert ist, man kommuniziert einfach in dem Pull Request auf GitHub mit Tintool verwendet. Kann man mit Homo kommunizieren und kann sagen, ich finde das gut. Kannst du versuchen zu merken. Homo macht einen temporären Branch auf, merkt den Master und den Pull Request. Lässt alle Tests laufen, wenn die Grünen sind, wird das gemirkt. Das Wichtige an der Stelle ist, Homo arbeitet die eins nach dem anderen ab und macht gerade diese Reihenfolge. Man kann sagen, bitte versuche die alle nacheinander in den Master zu merken und Homo meldet sich dann zurück, wenn dabei ein Problem aufgetreten ist. Aber man muss das alles nicht von Hand machen. Die Tools sind alle frei verwendbar. Wenn ihr ein Open Source Projekt habt oder unter einem bestimmten Größe ist, dann melde euch einfach mal, dann können wir einfach mal gucken. Generell noch ein paar Ökosystemsachen. Was hat sich denn da alles gegeben über das letzte Jahr? Es gibt sie immer noch. Es gab es ja auch schon vor der 1.0 und wahrscheinlich haben einige von euch schon mal was davon gehört. Es gibt eine Browser-Engine. Servo ist ein ziemlich, ziemlich großes Projekt. Das ist eine komplette Browser-Render-Engine mit Java, Script und allem. Vor zwei Tagen hat man sich sehr gefreut, dass man auf dem Twitter-Web-Interface jetzt mit Servo auch komplett Twittern kann. Also Login und alles und so weiter funktioniert. Man ist da schon ziemlich weit. Das ist auch, sollte man vielleicht dazusagen. Es gibt eine Spiele-Engine-Invest. Die nennt sich Pisten. Es gibt eine aktive Spiele-Entwicklungskommunity. Die ist ja so ein bisschen ein bisschen eigen. Also es ist so eine Sub-Community so ein bisschen. Und Pisten ist das größte Projekt. Allerdings gibt es eine ganze Menge Leute, die mit allem neuen Kram an der Stelle rumbauen. Es gibt Vulkanbindings. Es gibt verschiedene Versuche, OpenGL-Bindings zu machen, die sicher sind und die vor allem den Krampf aus OpenGL nehmen. OpenGL ja auch diese versteckte State-Machine hat, die man versucht, an der Stelle zu rappen und da auch unter Umständen Lifetime zu verwenden, um halt die Semantik von OpenGL da auch noch ein bisschen stärker in die Sprache zu bringen. Also gerade darf man in OpenGL bestimmte Dinge nicht machen, wenn man bestimmte Vorarbeiten nicht gemacht hat oder umgekehrt. Und die da ein bisschen drüber sein wollen. Ohne Laufzeitkosten. Das ist das Wichtige an der Stelle. Es gibt zwei Bridges, die relativ gut weit entwickelt sind. Das sind Helix und Neon zu Ruby und Node. Die versuchen, das Zeremoniell aus ich baue eine native Bibliothek für diese Sprachen rauszuziehen und vor allem auch dafür sicherstellen wollen, dass man die Bibliotheken schreiben kann in diesen Sprachen, die ja eben dieselbe Eigenschaften haben, die diese Sprachen eben auch haben. Speichersicher und zackvoll sicher. Das ist ja eine der Gründe, warum man da doch nicht so gerne zu C greift. Man hört immer, wenn es halt zu langsam ist, dann schreiben wir es halt in C. Gesehen habe ich es ehrlich gesagt noch nicht, weil wenn die Leute dann sagen, da müssen wir aber auch dafür sorgen, dass es nirgends wo crashed. Also das Gefühl, na ja, dann lassen wir es doch lieber und kaufen doch lieber noch ein Server. Unter Umständen ist was für solche Leute halt einfach auch eine Option an der Stelle. Und die nehmen halt eben das ganze Busywork aus den Binding-Bauern raus. Es gibt Betriebssysteme in Rust. Redox OS ist durchaus ernst zu nehmen. Die boten bis jetzt auch schon in eine grafische Shell, die man verwenden kann. Intermetsource ist von dem, der das Waschbuch schreibt, die Betriebssysteme schreiben. Also es ist mehr so mal zum Anschauen eigentlich, aber halt von Null durchdokumentiert. Genauso macht der Philipp Oppermann, der ja auch aus Karlsruhe stammt, schreibt auch ein ähnliches Betriebssystem, in dem er ganz genau erklärt, wie man dann ein Memory Allocator schreibt und wie man das dann durchoptimieren kann. Das sind sehr, sehr lange Artikel, die sehr interessant sind, wenn ihr euch noch nicht damit beschäftigt habt oder euch damit beschäftigt habt, sind das sicherlich interessante Sachen zum Lesen. Es gibt eine ganze Menge Produktionseinsätze inzwischen. Gerade im Automotive-Bereich haben wir irritierenderweise Leute, die das verwenden. Natürlich, Mozilla, es gibt verschiedene, die es als Plugins verwenden für Ruby halt, um langsame Sachen schneller zu machen. Das ist gerade bei Rails durchaus mal so eine Sache. Wie gesagt, da gibt es eine ständig gedatete Liste. Hier wahrscheinlich auch relativ interessant, wie steht das eigentlich mit den Distros? Wir haben, ich habe hier das Ticket verlinkt, wie ist das eigentlich mit Rust Packaging? Wenn wir sagen, alle sechs Wochen gibt es einen neuen Compiler, dann kann man sich vorstellen, dass die Maintainer bei den ganzen Distros ein bisschen Angst kriegen. Das ist nicht leicht, in Einklang zu bringen, aber die Feststellung an der Stelle ist, frühzeitig reden hilft. Einfach nach außen gehen, mit allen sprechen und sofort bei jeder Plattform jemanden und dann stellt man dann am Ende fest, die Leute bei Debian, die sind da auch sehr gesprächsbereit, solange man halt einfach frühzeitig mit ihnen spricht und es ihnen nicht einfach auf den Tisch klatscht und sagt, so läuft es jetzt. Das größte ausstehende Problem ist an der Stelle, man kann momentan den stabilen Compiler nicht mit dem stabilen Compiler bauen. Das wird in der nächsten Compiler-Version gefixt, aber das ist für viele Distribution einfach nichts, was sie machen wollen, weil sie einfach möchten, dass man halt mit dem, was sie ausliefern, die nächste Version des Pakets bauen kann. Das ist ihnen sehr wichtig und das werden wir dann auch den nächsten herstellen. Im Wald. Wir haben ein ziemliches Community-Wachstum. Wir haben inzwischen 1.523 Computer allein am Compiler. Wir haben 71 Meetups weltweit. Das ist schon etwa so viel wie Go und Go ist ein paar Jahre mehr. Wir haben diesjahr drei Konferenzen und hier in Deutschland jetzt einen eingetragenen Verein oder in Europa. Und wir sind ja sehr kommunikativ. Und das ist ja auch so, wenn ich den Scherz, wenn ich irgendwann mal einen Planet oder einen Blockaggregator für Rust bauere, dann werde ich ihn in this week in this week innen. Bei uns gibt es nämlich eine Tradition, dass alle Projekte einen wöchentlichen Newsletter this week inschreiben, indem sie einfach mal zusammenfassen, was das eigentlich letzte Woche passiert. Wer ist dazugekommen? Üblicherweise werden alle Leute dabei genannt, die neu zu dem Projekt dazugekommen sind. Was sind die Abgaben in Tickets oder was Projekt schreibt das? Servo schreibt das, das Redox Projekt schreibt solche Sachen. Meine Konferenz. Es gibt extra für die Docs eins. Es gibt eine ganze Menge davon. Ich habe vorhin versucht aus dem Subreddit mal rauszugraben. Ich glaube, wenn ich ein bisschen weiter graben würde, würde ich noch ein paar mehr finden. Es ist eine schöne Tradition. Es wird viel geschrieben darüber. Man kann also... Also wie manischt man das? Wir haben seit einem Jahr knapp jetzt ein dediziertes Community-Team. Das ist kurz nach der 1.0 gekommen. Und das war schon sehr hilfreich. Wir machen zum Beispiel so Sachen wie wir finden Produktionshuser. Da gehört einfach dazu, wir lesen einfach mal Twitter und geben dann sagt, oh, ich verwende hier was für irgendwas internes, sondern eigentlich noch, weil sich jemand vom Community-Team daran sagt, oh, möchtest du denn nicht einfach mal direkt mit uns sprechen? Weil die Feststellung ist, dass viele Leute das so ein bisschen versteckt machen und so ein bisschen verschämt sind und dann eigentlich gar nicht mit dem Projekt reden wollen, da drüber. Und sagt, lass uns mal drüber reden. Was wir dann zum Beispiel machen, ist wir führen Interviews. Das macht dann normalerweise irgendjemand von den Compiler-Mentenern direkt zum Beispiel. Wir stecken die zusammen, um auch einfach mal zu fragen, was liegt denn im Argen, was können wir denn besser machen und wo können wir denn in den Zukunft hinschauen. Und da legen wir dann halt die zukünftige Projektstrategie fest. Das mag nicht immer allen Leuten gefallen, in welche Richtung wir da gehen, weil wir können ein bisschen gucken, wo wir unsere Arbeit verwenden, aber es ist immer gut zu wissen, was dann eigentlich gerade im Argen liegt und was man dann eigentlich gerade aufschiebt. Und allein schon mal sagen zu können, wir wissen, wir kennen das Problem, aber wir schieben gerade auf, weil wir haben noch dieses und dieses andere Problem. Wir machen auch solche Sachen wie Meetup-Organisatoren zu Coaching und Konferenzen zu organisieren und generell Ansprechpartner zu sein. Also wenn man halt irgendeine Frage an das Bassteam hat und ich weiß wohin, dann schickt man das als Community-Team, da kommen dann so schöne Sachen bei rum, wie dass man zum Beispiel Personen in Morial kennt und man kennt die Meetup-Organiser in Morial, aber die beiden kennen sich nicht. Und dann kann man die halt zum Beispiel zusammenstecken, dass sie mal einen Vortrag auf den Meetup halten. Es ist viel kleinteilig, aber es macht einen großen Spaß. Das wird in vielen Projekten so nebenher gemacht und ich glaube, das ist ein großes Problem. Viele Projekte organisieren sich einfach um die Technikecke und es lohnt sich, einfach Leute anzuwerben, die Lust haben. Also wenn man halt eben, wenn man sagt, ich habe eigentlich nur Bock auf Code und ich habe eigentlich keinen Bock auf das ganze Gelaber mit den Leuten, dann kann man auch einfach sagen, ich suche mir einfach Leute, die Bock auf das Gelaber haben und lass die einfach mal machen. Das funktioniert an der Stelle sehr, sehr gut. Was auch hilft, ist ein dediziertes Moderationsteam. Man hört ja immer wenig über Rust-Dramas und es liegt daran, dass wir einfach Moderationsteam haben, dass solche Sachen weiterleitet und so weiter und so fort. Wir hatten gerade gestern wieder jemanden, der auf dem Rust-Zug redet, einfach mal schreiben wollte, wie nett er es in dieser Community findet. Und das hören wir häufiger. Das Wichtigste, was das Moderationsteam macht, das Moderationsteam sollte Beleidigungen und persönliche Angriffe unterbinden. Das ist strikt zu trennen, sie sollten keine Konflikte unterbinden. Konflikte sind normal und Konflikte sollten ausgetragen werden, aber halt eben nicht auf, du bist halt einfach Scheiße, ich glaube nicht, dass das fliegt, was du da vorschlägst. Solche Sachen kann ein gutes Moderationsteam gut hinbekommen. Das umfasst zum Beispiel auch Trashing von anderen Programmiersprachen. Bei uns ist, PRP ist halt einfach blöd, nicht erlaubt. Auch Diskussionsablenkungen muss man unsere Feststellung eigentlich unterbinden, weil das häufig dazu führt, dass Leute, die an der Diskussion wirklich teilnehmen wollen und dazu auch was zu sagen haben keine Lust haben, sich den ganzen Kram raus zu filtern, der eigentlich nichts beiträgt. Wir haben ein Subreddit, auf dem Memes verboten sind, einfach deswegen, weil sonst einfach unter jeder Ankündigung, die irgendwie cool ist, erstmal 50 Seiten Memes kommen und dann hat irgendjemand noch was dazu zu sagen. Das hat nichts mit Spielverderbereit zu tun, sondern es hat einfach damit zu tun, dass viele Leute da sind, um sich eigentlich Informationen zu holen und die Signalrate hochzuhalten. Nett sein, muss ich dazu auch sagen, ist ein ziemlicher Growth Hack. Am Ende finden es die meisten Leute auch wirklich ziemlich nett, wenn es nett ist. Wir haben Code of Conduct, das sollt man sagen, den hat Graydon Hoar noch eingeführt, den dürfen wir nicht mehr weg loswerden und wir wollen ihn auch nicht loswerden. Es hat sich einfach als wertvoll erwiesen, einfach mal auch praktisch darüber zu reden, was, wie ist das eigentlich mal eine Community zu führen, die das jahrelang schon hat. Es hilft bei Konflikten auf gemeinsame Grundwerte zurück greifen zu können und es hilft, dass die offen kommuniziert sind. Ansonsten ist nämlich mir die Frage, ja, ist es schön, dass ihr das so haltet, aber habt ihr das mal irgendwo niedergeschrieben? Ja, wir haben das mal irgendwo niedergeschrieben und ich vergleiche das immer so ein bisschen mit dieser schönen Szene aus Wainsworld. Im Code of Conduct steht drin, was bei uns halt einfach überhaupt nicht fliegt und zum Beispiel in Wainsworld gibt es ja die schönen Szene, wo er versucht, seine geliebte Gitarre endlich mal anzuspielen und der spielt natürlich sofort Starway to Heaven und der Musikladenbesitzer weiß hinter drauf hin, dass hier kein Starway to Heaven, da stehen die Sachen drin, die man eigentlich nicht mehr durchdiskutieren möchte an dieser Stelle, ein wichtiger Punkt an dieser Stelle und es hat sich als sehr gut erwiesen, weil zum Beispiel neue Leute, die zum Projekt kommen, da durchaus auch Diskussionen darüber führen, also es ist ein lebendes Dokument, an dem geändert wird, aber die wissen, wo der momentane Stand ist und weiß, in welche Richtung man gehen möchte und da kann man dann auch durchaus darüber reden. Ja, was ist weniger gut gelaufen? Wir wollten eigentlich Anfänger in Workshops anbieten. Ja, hat uns einfach die Zeit und die Kraft gefehlt und wir hatten letztes Jahr dann doch noch einige Sachen zu machen, von die wir nicht erwartet hatten an vielen Stellen. Auch die allgemeine Erarbeiterung von Trainingsmaterialien, da sind wir noch ziemlich hinten dran. Ein bisschen, wieso? Was für Spieleentwicklung ist ein bisschen auch Sparflamme, da gibt es ein großes Interesse auch durchaus, wir hatten mal Leute von Bioware, die angefragt haben und so weiter, aber das Problem ist, es gibt da momentan noch keine guten Toolchains-Hürfen und so Seite. Da haben wir momentan auch einfach nicht die Zeit dafür, wenn sich jemand dafür interessiert so was anzubieten würde, das durchaus gemacht, momentan ist es nicht schlecht, aber es ist noch nicht ganz, also Leute, die sehr kompetent mit C++ umgehen können und Spieleentwicklungen in C++ machen und erwarten das alles, was sie da machen können, weil sie es brauchen, auch in was geht, diesen momentan wahrscheinlich noch nicht ganz zu Hause bei uns. Das Tool, das ich vorhin meinte, was ab für Versionsverwaltung, das ging durch drei verschiedene Iterationen, was dann immer das Problem hat, dass die Leute inzwischen schon gar nicht mehr wissen, ob sie es oder dieses verwenden. Im Zweifel des Neueste, aber das Neuste ist noch in Beta und so weiter und so fort, das kommuniziert sich einfach schlecht und es gibt eine Begründung, warum die ersten beiden weggeschmissen wurden, die waren halt auch nicht so gut, wie man es haben wollte und über den Winter war kurz für sich Communityarbeit kaum möglich, weil verschiedene Leute aus dem Community-Team große Probleme im persönlichen Leben hatten, die sind alle hobbymäßig dabei und das ist halt das Problem, wenn an irgendeinem Projekt Hobbyisten beteiligt sind, muss man halt auch einfach damit zurechtkommen, dass sie zwischendurch sagen, ich habe gerade keine Zeit für das Projekt, mir sehr leid. Wir haben immer noch große Probleme, Rust für Einsteiger zu erklären. Das Problem ist, die Sprache hat eine Lernkurve, bevor sie so richtig angenehm wird. Ich habe mich vorhin so ein bisschen für die Trivialbeispiele entschuldigt und das Problem an den Trivialbeispielen ist, da ist auch wirklich noch nicht so der Rums hinten dran, warum die funktionieren. Es wird einfach richtig interessant, dass man die Sprache hat und dann diese ganzen Features im Zusammenspiel sieht und diese Features werden halt erst in einem großen Programm richtig, richtig mächtig. Also wie gesagt, es wird erst so richtig interessant, wenn mir der Compiler sagen kann, übrigens, du schmeißt da jetzt ein paar Daten in 100.000 Zeilen Code rein und die kommen zurück und sind immer noch dieselben. Das ist relativ langweilig, wenn ich das in fünf Zeilen Code erkläre und das macht es natürlich auch für Leute, die die Sprache haben können zu fangen, weil die Sprache Probleme löst, die sie wahrscheinlich erst nach drei Jahren Erfahrung mit Programmierung haben werden und deswegen auch die Sprache sich häufig im Vergleich mit anderen Sprachen messen muss. Das andere ist, wir schreiben das Buch schon wieder neu. Natürlich mit Großteils von dem alten Text, aber wir organisieren es neu, bauen es neu um, wir bauen Sachen aus. Was wir häufig auch machen, wenn ein Thema schreibt, der einfach sehr detailliert ist, dann übernehmen wir das in die offizielle Doku. Das hat sich als sehr, sehr gut rausgestellt, auch so ein bisschen das, was die Community eigentlich arbeitet, auch einfach mal ein bisschen ins Projekt zurückzuziehen und da dann auch Credit für zu geben. Doku schreiben ist die schnellste Art und Weise, wie man zum Lastprojekt kommenten kann und das ist genauso wichtig wie alles andere auch. Gut, kommen wir zum Ende, kommen wir doch zu einem kurzen Missverständnis zu Last. Yes, alte Thema Go versus Last, das ich immer beantworten muss und bevor die Frage kommt, erkläre es ganz kurz, das eine ist ein Brettspiel, das andere ist ein Programmiersprache. Es gibt ein Problem, als Last vorgestellt wurde, sah es wirklich sehr, sehr aus wie Go, hat eine ganze Menge Sachen so gemacht wie Go und ich glaube, immer noch dran dadurch, dass die Sprachen gleichzeitig fast aufgetaucht sind, aber Go halt damals einfach veröffentlicht wurde und Last halt noch so, weil man halt Sprache beim Museum Research hat es dazu geführt, dass Last in eine ganz andere Richtung gegangen sind. Früher hatte Last noch eine Laufzeit, früher hatte Last noch Channels wie in Go in der Sprachlaufzeit verbacken und so weiter und so fort. Diese Sachen wurden alle ausgebaut. Insofern war das damals wirklich so, dass man Go und Last ziemlich genau Feature to Feature vergleichen konnte. Das Problem ist, das hängt uns immer noch nach, die beiden Sprachen haben eigentlich wenig miteinander zu tun, wenn ihr was vergleichen wollt mit einer anderen Sprache, dann macht es am besten mit C++ und D. Es gibt übrigens online einen sehr guten Vergleich von dem D-Maintenor, der die Sprachen so ein bisschen durchgeht, wo eigentlich die Probleme sind, den fand ich sehr, sehr fair. Da kriegt Last auch ordentlich Fett weg, D aber auch, das sind so die Sprachen, mit denen ihr es vergleichen solltet unter Umständen unter den neuen Sprachen oder mit dem D-Maintenor. Gut. Am Ende habe ich noch ein paar Links. Hier ist also unsere Sprachwebseite und die Deutsche Konferenz. Wir würden uns sehr freuen, wenn man vielleicht ein paar Leute sieht. Es wird ziemlich günstig werden kostenlos, können wir leider nicht machen. Und sollte jemand Trust machen und vielleicht in den nächsten Monaten noch mit dem Vortragsthema aufkommen, du hast gezeigt, dass Rust Locks hat. Gibt es von Rust irgendeine Unterstützung dafür, dass man nicht mit Locks in die Hölle von Deadlocks und was nicht alles einem da erwartet, reinerutscht oder ist man da genauso auf sich allein gestellt wie in allen Sprachen bisher? Ja, Locks sind Speicher sicher, Deadlocks sind Speicher sicher so. Nee, es gibt in Rust kaum Unterstützung dafür, dass Deadlocks passieren. Manchmal fängt die Sprache, aber das ist jetzt nicht unbedingt die Stärke an der Stelle. Gibt es schon konkrete Pläne, so was wie Async Await in Python auch in Rust zu machen, also Koroutinen mit entsprechendem Syntaktikschugga? Nein, kein Syntaktikschugga. Also es gibt Koroutinen an der Stelle, was versuchterbar an der Stelle möglichst wenige von diesen durchaus laufzehmbandischen Dingen zu packen. Es gibt wie gesagt entsprechende Koroutin-Bibliotheken. Im Zweifel, das habe ich nicht erwähnt, weil es eigentlich nicht so mag, Rust hat ein Makro-System, also wahrscheinlich hat irgendwo schon jemanden Makro gebaut, der sowas macht. Zwei Fragen sind zu wenig. Ich habe gesehen, ihr habt so high order Funktionen wie Map und so weiter. Aus der Haskell-Fahrung heraus sind die eigentlich eine Landperformant, wie Sie das machen. Macht ihr das? Und wenn ja, habt ihr das Problem, dass man dann sozusagen keine stabile ABI anbieten kann, weil auch interne Änderungen am Code dafür sorgen kann, dass ich, wenn ich so ein Betrieb veröffentliche, obwohl die ABI gleich bleibt, das Resultat sich ändern muss und deswegen auch kleine Änderungen am Code, der nicht interface ist, dafür sorgt, dass ich abhängige die ABI anbieten kann. Und es gibt da eine Lösung. Also wir haben ein ähnliches Problem. Einmal ist es so, die Darstellung zur Laufzeit von Closures ist meistens verschwinden Sie komplett an der Stelle. Es gibt um genau zu seinen drei verschiedene Arten von Closures in was aus genau der Begründung. Vier verschiedene. Das Problem betritt bei uns insbesondere die generische Implementierung von der Funktion habe, wird die über Bibliotheksgrenzen geinleint und unter Umständen eben halt mit dem konkreten Typ, der verwendet wird, nochmal neu kompliziert, wenn man an der Stelle genau das selbe Problem führt auch dazu, wenn man zum Beispiel halt dieses Vita nutzen möchte, dass man Plattform ABI verwenden kann, kann man zum Beispiel Funktionen mit generischen Typen nicht exportieren an der Stelle. Ja, wir haben dasselbe Problem in einem etwas anderen Anstrich. Eine Frage?