Interview mit dem Sprecher der RubyRussia-Konferenz, Godfrey Chan

Hallo allerseits! Am 6. Oktober wird in Moskau die RubyRussia- Konferenz stattfinden - der gute alte RailsClub, aber mit einem neuen Namen. Die diesjährigen Redner: Aaron Patterson, Charles Nutter, Godfrey Chan, Maciej Mensfeld, Markus Schirp und mehr. Und natürlich 600 Teilnehmer, die besten Unternehmen mit Ständen in der Lobby und einem Feuer nach der Party.

Traditionell sprechen wir vor der Konferenz über die wichtigsten Themen in Ruby und Rails. Heute stellen wir Ihnen Godfrey Chan vor - ein Ex-Rails-Kernteam, das in Tilde arbeitet und zwischen der Erstellung eines intelligenten Rails-Profilers Skylight , der Arbeit an Ember.js und der Entwicklung von JavaScript auf TC39 hin- und hergerissen ist. Tim Leader von Evrone Dmitry Matveev stellte unseren Gästen wichtige Fragen.




Beginnen wir mit ein paar Fragen zu Ihrem Bericht über RubyRussia.

Ich möchte nicht alle Geheimnisse preisgeben! Mein Bericht heißt "Auf das Metall fallen". Ich werde darüber sprechen, wie man mit Metaprogrammierung ziemlich seltsamen Rubu-Code schreibt, um etwas Ähnliches wie JavaScript zu erstellen. Natürlich können wir keinen vollwertigen JavaScript-Parser und keine Laufzeit schreiben, aber ich werde etwas Magie zeigen, mit der ein Teil des JavaScript-ähnlichen Codes in Ruby unter Verwendung der nativen Ruby-Laufzeit ausgeführt wird. Es macht Spaß, zumindest gefällt es mir sehr gut. Dies ist die gleiche Technik, mit der Sie Dinge wie rspec, rake oder andere DSLs in Ruby schreiben können. Ich werde den Schülern zeigen, wie Ruby Ihren Code analysiert und ausführt und welche Hooks Sie verwenden können. Ich denke, dass der Bericht nicht nur Spaß machen wird, sondern auch einige nützliche Dinge über die Metaprogrammierung in Ruby lehren wird.

Cool! Das heißt, es wird praktische Tipps geben, oder?

Ich bin mir nicht sicher, ob es möglich sein wird, sich auf sie zu konzentrieren, aber ich glaube, dass Sie in diesen 30 Minuten etwas Nützliches für sich selbst lernen werden.

Großartig! Ich denke, der Bericht wird sowohl für erfahrene Programmierer als auch für Anfänger interessant sein. Richtig?

Ich hoffe es Zumindest werde ich es versuchen.

Übrigens habe ich gestern Ihren Artikel über Medium über das Umdenken in der Informatik gelesen. Der Artikel ist sehr interessant, und ich stimme den Gedanken zu den Unterschieden zwischen klassischer Universitätsausbildung und modernen Kursen für Programmierer zu. Warum haben Sie sich übrigens entschieden, Programmierer zu werden?

Nur ein Zufall, ich hatte nie vor, als Programmierer zu arbeiten, für mich war es ein Hobby. Ich habe es wirklich gemocht, mit Computern herumzuspielen. Es war einfach, etwas zu tun - versehentlich Systemdateien zu löschen oder tiefer in die Windows-Registrierung einzudringen. Dann wollte ich etwas mehr. Nach der Schule nahm ich an Kursen zur Website-Entwicklung teil. Ich war begeistert von der Möglichkeit, etwas Neues auf dem Computer zu erstellen. Aber bald wurde mir klar, dass mir das nicht genug war. Ich konnte eine Art Computerspiel in HTML erstellen, aber dieses Toolkit war ziemlich begrenzt. Eines Tages gab mir mein Lehrer ein Buch über PHP. Ich habe alles gelesen und unerwartet für mich eine ganz neue Welt der Möglichkeiten entdeckt, die viel mehr bietet als HTML und CSS. Es war sehr cool, danach fing ich an, immer mehr Bücher zu diesem Thema zu lesen. Die nächste Sprache, die ich lernte, war Java. Einmal habe ich im Linux-Magazin über Ruby gelesen (eigentlich nicht über Ruby, sondern natürlich über Rails) und dachte, es wäre großartig, es zu lernen. Von da an fing alles an und rollt wie ein Schneeball bis heute.

Und so bist du zu Ruby gewechselt, oder?

Ich entdeckte Ruby ungefähr zu der Zeit, als ich anfing, Informatik am College zu studieren. Gleichzeitig studierte ich auch Java, C ++, Haskell und lernte nicht nur viele Programmiersprachen gleichzeitig. Im Rahmen unseres Studiums hatten wir keine Ruby-Aufgaben, und ich mochte ihn sehr, deshalb habe ich immer versucht, ihn in den Klassen zu verwenden, in denen Sie die Technologie selbst auswählen konnten. Nun, auch in ihren Projekten von Drittanbietern. Als ich das College abschloss, entschied ich mich, einen Job im Zusammenhang mit Ruby zu suchen. Es war einfach, denn Rails war damals auf dem Höhepunkt der Popularität: Viele Startups verwendeten diese Technologie. Das Interesse ist also mein Job geworden.

Verwenden Sie jetzt Ruby als primäres Werkzeug? Oder arbeitest du mit etwas anderem?

Bei meinem aktuellen Tilde-Job schreibe ich nicht mehr so ​​viel Ruby wie zuvor. Ich würde sagen, dass meine Arbeit ein Cocktail aus JavaScript / TypeScript, Rust, Ruby und manchmal Java ist. Trotzdem bezieht sich meine ganze Arbeit auf Ruby.

Das Hauptprodukt bei Tilde ist Skylight. Nicht alle darin enthaltenen Komponenten sind in Ruby geschrieben: Das Frontend ist in JavaScript und Ember, das Backend in Rails, aber die gesamte Verarbeitung eingehender Daten ist Java und Rust. Skylight selbst ist jedoch ein Tool zur Leistungsüberwachung für Rails-Anwendungen. In diesem Sinne ist meine ganze Arbeit immer noch mit Ruby verbunden.

Großartig! Ich selbst habe mich vor ein paar Tagen bei Skylight für eines der Projekte registriert, jetzt teste ich es. Es sieht interessant aus und von Anfang an ist klar, wie alles funktioniert. Ich habe noch nicht viel vertieft, aber ich plane, es nächste Woche sehr eng zu verwenden. Ich hoffe ich kann einige Probleme damit beheben.

Großartig, es wäre toll, Feedback zu hören!

Es ist interessant, Ruby mit anderen Sprachen zu vergleichen. Zum Beispiel mit Rust. Ruby ist sehr ausdrucksstark und so konzipiert, dass Code lesbar ist. Wenn Sie es mit Python oder mit C ++, C #, Java vergleichen, sind sie meiner Meinung nach nicht so einfach zu lesen wie Ruby. Was denkst du darüber?

Ich werde zustimmen. Es gibt zwei Möglichkeiten, eine neue Sprache zu „lernen“. Das erste ist ziemlich oberflächlich: Ich studiere die Grundlagen der Syntax, spiele mit Beispielen und vergesse es dann sofort. So war es bei Go. Ich habe es am Wochenende gemacht, dann habe ich ein paar Wochen lang kleine Projekte darüber geschrieben. Aber dann hatte ich keinen Grund, weiter auf Go zu programmieren. Ich habe es nur aus Neugier studiert und schnell vergessen.

Auf der anderen Seite gibt es JavaScript / TypeScript, Rust und Ruby, die ich ständig benutze. Jede dieser Sprachen hat mir neue Möglichkeiten eröffnet, es ist sehr motivierend.

Als ich zum Beispiel anfing, mit Ruby zu arbeiten, war ich von Ausdruckskraft angezogen. Keine andere Sprache hat es dir erlaubt, verrückte Dinge wie method_missing zu tun. Metaprogrammierung, Ausdruckskraft und Lesbarkeit des Codes sind die wichtigsten Dinge, die ich an Ruby liebe. Es wäre cool, wenn andere Sprachen könnten.

Aber in ihnen können Sie Dinge tun, die in Ruby unmöglich sind. Zum Beispiel JavaScript. Bei ihm war alles ganz anders als bei Ruby, in den ich mich auf den ersten Blick verliebt habe. Ich habe angefangen, JavaScript nach Bedarf zu verwenden. Ich musste Browsercode schreiben. Ob es uns gefällt oder nicht, es gibt kein Entkommen von JS. Wenn Sie eine interaktive Browseranwendung wie Skylight schreiben möchten (genau das, woran ich damals interessiert war), ist JavaScript der einzige Ausweg.

Ich wollte die Ideen, die mir in Ruby gefallen haben, auf JavaScript übertragen, also begann ich am Ende mit Ember zu arbeiten. Dies führte mich wiederum zu TypeScript. Wenn Sie ein großes Framework wie Ember in JavaScript schreiben, hilft es wirklich, Typen und einen Compiler zum Überprüfen von Fehlern zu haben. JavaScript und TypeScript haben mir geholfen, dies zu verstehen.

Die Ideen, die Rust mir beigebracht hat, sind TypeScript sehr ähnlich. Es ist schön, das gesamte Programm kompilieren zu können und sicher zu sein, dass es funktioniert. Für mich ist es einfach großartig. Ich habe bereits mit kompilierten Sprachen gearbeitet: mit Java und C. Sie sollten auch in ihnen warten, bis der Code kompiliert ist, aber dies ist nicht sehr nützlich, da das Typsystem in diesen Sprachen Fehler nicht sehr gut abfängt. In Rust kann der Compiler jedoch garantieren, dass das Programm keine Speicherprobleme verursacht und dass während seiner Ausführung keine Segmentierungsfehler (Segfault) auftreten. Eine der schwierigsten Aufgaben bei der C-Programmierung sind Speicherprobleme, die nur sehr schwer zu vermeiden sind. Das Hauptmerkmal von Rust ist für mich die Fähigkeit, Low-Level-Programmierung durchzuführen, ohne sich darüber Gedanken zu machen.

Mein Interesse an Rust hing übrigens mit Ruby zusammen. Ich habe gerade bei Tilde angefangen und wusste, dass das Skylight-Juwel in Rust geschrieben wurde. Ich dachte, es wäre großartig zu lernen, wie man native Erweiterungen für Ruby auf die gleiche Weise schreibt. Ich wollte lernen, wie man in Rust schreibt, damit ich mir keine Sorgen darüber mache, dass Benutzer-Ruby-Prozesse unterbrochen werden, wie dies der Fall ist, wenn Zeiger in C falsch dereferenziert werden. Daher bestand das Hauptziel des Lernens von Rust für mich darin, native Erweiterungen für Ruby zu schreiben.

Erst heute Morgen habe ich mit Peter Wagenet von Tilde und Sean Griffin vom Shopify- und Core Rails-Team an einem Projekt gearbeitet. Sean arbeitet an einer neuen Version von Active Record, die in Rust geschrieben wurde, um die langsamen Teile zu beschleunigen. Und kurz vor diesem Interview habe ich in Rust an einem Projekt namens libcruby-sys gearbeitet, mit dem Sie native Erweiterungen für Ruby in Rust schreiben können.

Am Ende können wir sagen, dass alle Sprachen miteinander verbunden sind. Die Sprachen, in denen ich lerne und programmiere, sind nur Werkzeuge, mit denen ich das erstellen kann, was ich vorhabe.

Sehr interessant! Cool, dass ActiveRecord viel schneller ist. Soweit ich weiß, wird sich die Idee von ActiveRecord nicht ändern. Ich meine, wird es der gleiche ActiveRecord sein und nicht so etwas wie ein Data Mapper?

Active Record auf Ruby wird natürlich nirgendwo hingehen, es entwickelt sich aktiv, es wird verwendet. Im Fall von JRuby ist dies die erste Wahl. Die Implementierung von Sean ist zu 100% mit der nativen API kompatibel. Die Interna werden in Rust neu geschrieben, sodass alles schneller funktioniert, die API für den Endbenutzer jedoch nicht geändert wird.

Das Gleiche gilt für das Projekt, an dem ich in den letzten Jahren gearbeitet habe. Es heißt Helix und ist mit meinen Experimenten mit Rust verbunden, um native Erweiterungen für Ruby zu erstellen. Der Start war sehr schwierig, da einige Probleme mit der Speichersicherheit behoben werden mussten. Mit Helix können Sie sich einfach auf das Schreiben von Code in Rust konzentrieren. Er kümmert sich um das Kompilieren in Ruby-Erweiterung.

Ich denke, viele haben JSON-Edelsteine ​​in Ruby verwendet. Tatsächlich gibt es zwei verschiedene Implementierungen dieses Edelsteins. Es gibt eine reine Ruby-Implementierung und eine C-Erweiterung, die dieselbe API implementieren. Dies fällt nicht auf, aber wenn Sie "require json" schreiben, wird höchstwahrscheinlich die C-Version geladen. Wenn die aktuelle Plattform nicht unterstützt wird, handelt es sich um eine Ruby-Version. Aber auch hier wird die API in beiden Fällen genauso verwendet. Der einzige Unterschied besteht darin, dass die internen Komponenten für eine von ihnen in C implementiert sind, sodass sie schneller arbeiten. Neben der höheren Leistung gibt es keine Unterschiede. Dies ist das Ziel all dieser Projekte - den von uns geliebten Ruby verwenden zu können, aber bei Bedarf die Leistungsvorteile von nativem Code zu nutzen.

Es ist großartig, dass Ruby schneller sein wird. Es gibt zwar die Meinung, dass die Ausführungsgeschwindigkeit für Ruby-Programme nicht allzu wichtig ist, aber ich bin sicher, dass jeder glücklich sein wird, wenn die Leistung steigt.

Zum größten Teil stimme ich zu. Im Allgemeinen ist dies so. Nachdem wir die Produktivität erheblich gesteigert haben, können wir Dinge tun, die auf dieser Plattform bisher einfach unmöglich waren. Wie gesagt, ich habe JavaScript gelernt, weil ich Programme für den Browser schreiben wollte, und es ist unmöglich, etwas anderes zu tun. Ich denke, dasselbe gilt für die Leistung. Es ist mir egal, ob der Code 20% schneller läuft. Das ist gut, aber nicht so wichtig. Wenn der Code jedoch zehnmal schneller ausgeführt wird, eröffnen sich völlig neue Möglichkeiten.

Wenn Sie beispielsweise maschinelles Lernen betreiben, müssen Sie viele komplexe Berechnungen durchführen. Höchstwahrscheinlich können Sie dies auf Ruby nicht implementieren, da Ruby zu langsam ist. Wenn es jedoch eine Schnittstelle für die einfache Interaktion mit nativen Bibliotheken für maschinelles Lernen gibt, können Sie mit ML auch unter Ruby arbeiten. Sie können Code schreiben, um alle Prozesse mit Berechnungen in Ruby zu orchestrieren, mit all seiner Ausdruckskraft und seinem Ökosystem aus Edelsteinen. Leistung ist für mich ein Werkzeug, um neue Funktionen zu bringen.

Das ist absolut wahr! Ich habe viele Male mit Ruby-Programmen mit schlechter Leistung zu kämpfen. Ich musste viel SQL-Code schreiben, um die Dinge zu beschleunigen und einen Teil der Logik auf die Datenbankseite zu übertragen, da sie hunderte Male schneller funktioniert.

Das ist richtig, aber ich würde den problematischen Code lieber in die nativen Erweiterungen verschieben, als ihn als Microservice auf Go oder Haskell neu zu schreiben. Ich denke, es ist gut, so viel Ruby-Code wie möglich schreiben zu können und leistungskritische Teile an einen Ort zu verschieben, mit dem Sie in Ruby problemlos interagieren können. Die Gelegenheit selbst ist wunderbar.

Ja, es sollte schneller und einfacher und effizienter in Bezug auf Geschäftsaufgaben sein. Sie müssen keine Programmierer mit unterschiedlichen Fähigkeiten und Stapeln einstellen, da alles in Ruby geschrieben werden kann. Das klingt vielversprechend. Was denkst du über die Zukunft von Rails? Jedes Jahr gibt es Gerüchte, dass Rails stirbt ...

Ich bin voreingenommen, weil ich für ein Unternehmen arbeite, dessen Hauptprodukt ein Tool zur Leistungsüberwachung in Rails ist. Persönlich glaube ich nicht, dass sie sterben, aber Rails ist definitiv reifer geworden, "gereift". Für viele Menschen in der Gemeinde ist dies etwas grundlegend Neues. Viele von uns haben sich der Rails and Ruby-Community angeschlossen, als Rails ein Hype-Thema war. Es gab viel Begeisterung, viele Innovationen. Obwohl viele unserer „Innovationen“ in anderen, erwachseneren Ökosystemen alltäglich waren. Vieles war damals unmöglich, weil das Ökosystem noch unreif war.

Es war eine sehr aufregende Zeit. Jeden Montag freute ich mich auf eine neue Folge von RailsCasts. Jede Woche neues Juwel. Zum Beispiel erstellen wir diese Woche PDF-Dateien, nächste Woche laden wir eine Datei hoch und dann erscheint etwas grundlegend Neues, wie zum Beispiel ein Bundler. Es war eine Zeit voller frischer Ideen, aufregend, jeder hatte viel Energie. Viele Leute denken, dass Rails oder Ruby sterben, weil diese Emotionen verschwunden sind.

Und meiner Meinung nach ist das Ökosystem gerade gereift und stabiler geworden. Wir haben bereits mit 5 völlig unterschiedlichen Methoden zum Hochladen von Dateien experimentiert und müssen dies nicht jede Woche tun. In Bezug auf Emotionen vermisse ich diese Zeiten definitiv. Aber ich denke nicht, dass es jetzt schlimmer ist. Wir können das sagen: „Ok, wir haben all diese Abenteuer durchgemacht, verschiedene Ansätze ausprobiert und Unterricht bekommen. Und jetzt haben wir die beste Option ausgewählt, die jeder nutzen wird. “ Ich finde es großartig.

Ein Teil von mir vermisst definitiv diesen Antrieb, das ständige Gefühl der Veränderung und des Fortschritts, das zu dieser Zeit in der Ruby-Community herrschte. Jetzt sehe ich es in der Rust Community. Dort kann ich die gleichen Emotionen erleben. Ja, in Ruby ließen die Leidenschaften nach. Aber im Hinblick auf Produktivität und echte Arbeit ist alles ganz gut. Ich verstehe, dass eine Person, die ständig neue Dinge lernen möchte, solche Emotionen braucht. Ich suche und finde sie in anderen Ökosystemen. Die Community reift und es gibt weniger Veränderungen. Aber persönlich passt es mir.

Ich denke, das ist die natürliche Ordnung der Dinge, und Rails ist immer noch schön. Alles, was passiert, kommt dem echten Unternehmen zugute, das kommerzielle Anwendungen entwickelt. Mir gefällt, dass Rails unterschiedliche Ansätze zulässt. Zum Beispiel können Sie Wegbereiter oder Dry-RB-Edelsteine ​​verwenden, während Sie im Kontext von Rails bleiben. Sie können verschiedene Arten von Abstraktionen in Ihrem Code verwenden, aber letztendlich handelt es sich immer noch um eine Rails-Anwendung. Das gefällt mir.

Ich stimme dir definitiv zu. Ich denke, dass das gesamte Ökosystem wächst. Zu dieser Zeit, die wir heute als „Peak“ von Rails bezeichnen, erschienen viele neue Startups. Niemand kümmerte sich um Stabilität und Stabilität. Dann bekommen Sie einen ständigen Zufluss neuer Emotionen und Energie. Inzwischen sind viele dieser Unternehmen zu großen Unternehmen wie Github oder Shopify herangewachsen und haben begonnen, sich um Stabilität zu kümmern. Dies gilt für viele.

Als Gemeinschaft haben wir gemeinsam beschlossen, Stabilität den Experimenten vorzuziehen. Aus sprachlicher Sicht gibt es noch viel Raum zum Experimentieren, da Ruby gleich bleibt. Der Grund, warum Ruby großartig zum Experimentieren war, ist nirgendwo hingegangen. Die Community hat sich jedoch darauf konzentriert, Dinge zu erstellen, die auf Rails funktionieren, da Rails seit langem aktiv genutzt wird. Wenn Sie einen Edelstein schreiben, werden Sie wahrscheinlich mehrere Versionen von Rails unterstützen, da es viele Unternehmen gibt, die diese verwenden. Infolgedessen werden Rails selbst auch vorsichtiger und brechen ihre API nicht unnötig. Persönlich freue ich mich, Teil dieses Prozesses zu sein.

Aus geschäftlicher Sicht ist Stabilität sehr wichtig. Besonders für stark belastete Systeme. Die Stabilität der Framework-Schnittstellen erleichtert die Arbeit. Ich erinnere mich an die Zeiten, als es sehr schwierig war, von einer Version von Rails zu einer anderen zu wechseln. Zum Beispiel in dem Moment, in dem die Anwendung aufgrund einer inkompatiblen Codierung eine Reihe von Fehlern auslöste.

Wegbereiter ist ein großartiges Beispiel, das den aktuellen Zustand der Gemeinde und des Ökosystems zeigt. Einerseits ist die Tatsache, dass es existiert, ein ziemlich guter Beweis dafür, dass es in der Ruby-Community noch viel Raum für Experimente gibt. Aber ich denke, wenn es vor 5 Jahren herauskommen würde, wäre es viel beliebter, denn jetzt haben wir ein viel größeres Ökosystem um Rails herum aufgebaut, mit vielen Edelsteinen.

Am Ende interessiert es Sie mehr, was Sie mit dem bekannten Stapel tun können. Wenn Sie nur eine Anwendung schreiben müssen, die Rechnungen stellen, PDF-Dateien erstellen und Web-Sockets verwenden kann, bevorzugen viele Benutzer das, was andere bereits verwenden. In diesem Fall können Sie Edelsteine, Diskussionen, Antworten auf StackOverflow usw. teilen.

In diesem Sinne können wir sagen, dass ein Teil der Ruby-Community gestorben ist. Vor 5-10 Jahren haben Sie ständig neue Dinge getan, sich nicht zu viele Sorgen um die Kompatibilität gemacht, die neuesten und coolsten Edelsteine ​​verwendet, weil sich hinter Ihrem Rücken kein „Gepäck“ befand. Jetzt haben sich die meisten Projekte in der Community des „Gepäcks“ anständig angesammelt. Und diejenigen, die Experimente und Innovationen lieben, sind in andere Gemeinschaften und Ökosysteme gezogen.

Ich denke das ist normal.

Es macht mir auch nichts aus. Es ist wie aufwachsen, eine andere Lebensphase.

Was halten Sie von statischer Typisierung? Gibt es eine Aussicht, die Vorteile dieses Ansatzes in Ruby zu nutzen?

Ich freue mich darauf, weil ich die Vorteile dieser Sache bereits im JavaScript-Ökosystem mit TypeScript erlebt habe. JavaScript ist Ruby sehr ähnlich. , , . TypeScript — JavaScript , JavaScript . , , , , . TypeScript, JavaScript.

, . TypeScript. Ruby. , TypeScript JavaScript, , JavaScript . . , . , , . JavaScript, , , , - JavaScript. , TypeScript JavaScript, , .

, Ruby, . , , , , , , , , Rails, , , , . , Ruby .

. , . : . , , . , , , , . , .

, , . , TypeScript . . , JavaScript . , - , .

, — . , . TypeScript , . , Ruby. , Ruby , .

, RailsClub . , , . , . , .

, , , , , , , , - .

, , , , .

, . , , Rails, . . - , , Rails. , JavaScript , . , Ember, TypeScript. , , JavaScript . , , . , .

? 5 ?

, . 2 .

-, , «», , . , , . Ruby, , . , Ruby , open source, . . , . , , , .

Medium. , , , — . , , , , , . — , , .

, . , . . , . , . ?

, . . «». - «», . , - , , . , , .

, , . . , Ruby. , , Rust Ruby. . , . , . , , , , , . — .

, ?

, . , — , . , .

, . , Rust . Java Rust. , Rust. , . Rust — , .

, — . -, .

Rust, , . , , , , -, . , , , , . .

, «This Week in Rails» .

Vielen Dank! , , . , , . , , .

, , 2 . , Rails!

! , .

Vielen Dank! . RubyRussia . ?

, , , . , . , , . ? -, ?

-, , , . : , , . ! , , .

! - , . , . , !

.

!

! ! ! !

! ( :) 6 . , . 8000 .

hype.codes .

, Ruby- :

— Toptal
— Gett
— Instamart , UCHi.ru , JetBrains
— Bookmate InSales