Entretien avec le président de la conférence RubyRussia Godfrey Chan

Bonjour à tous! Le 6 octobre, Moscou accueillera la conférence RubyRussia - le bon vieux RailsClub, mais avec un nouveau nom. Les conférenciers de cette année: Aaron Patterson, Charles Nutter, Godfrey Chan, Maciej Mensfeld, Markus Schirp et plus encore. Et bien sûr, 600 participants, les meilleures entreprises avec des stands dans le hall et un feu après la fête.

Traditionnellement, avant la conférence, nous parlons des sujets les plus pertinents dans Ruby and Rails. Aujourd'hui, nous vous présentons Godfrey Chan - une ancienne équipe de base de Rails, travaillant à Tilde, où il est partagé entre la création d'un profileur intelligent Rails Skylight , travaillant sur Ember.js et développant JavaScript sur TC39. Tim Leader d' Evrone Dmitry Matveev a posé des questions importantes à notre invité.




Commençons par quelques questions sur votre rapport sur RubyRussia?

Je ne veux pas révéler tous les secrets! Mon rapport s'intitule «Chute dans le métal». Je vais vous expliquer comment écrire du code Rubu plutôt étrange en utilisant la métaprogrammation pour créer quelque chose de similaire à JavaScript. Bien sûr, nous ne serons pas en mesure d'écrire un analyseur JavaScript et un runtime à part entière, mais je vais montrer de la magie qui fera exécuter un morceau de code de type JavaScript dans Ruby en utilisant le runtime Ruby natif. C'est amusant, au moins je l'aime vraiment. Il s'agit de la même technique avec laquelle vous pouvez écrire des choses comme rspec, rake ou d'autres DSL dans Ruby. Je vais montrer aux élèves comment Ruby analyse et exécute votre code, et quels crochets vous pouvez utiliser. Je pense que le rapport sera non seulement amusant, mais enseignera également des choses utiles sur la métaprogrammation en Ruby.

Cool! Autrement dit, il y aura des conseils pratiques, non?

Je ne suis pas sûr qu'il sera possible de se concentrer sur eux, mais je pense que ces 30 minutes vous permettront d'apprendre quelque chose d'utile.

Super! Je pense que le rapport sera intéressant pour les programmeurs expérimentés et les débutants. Non?

Je l'espère. Au moins j'essaierai.

Soit dit en passant, j'ai lu hier votre article sur Medium sur la refonte de l'éducation en informatique. L'article est très intéressant et je suis d'accord avec les réflexions sur les différences entre l'enseignement universitaire classique et les cours modernes pour programmeurs. Au fait, pourquoi avez-vous décidé de devenir programmeur?

Juste un coup de chance, je n'avais jamais prévu de travailler en tant que programmeur, pour moi c'était un peu un hobby. J'ai vraiment aimé jouer avec les ordinateurs, il était facile de trouver quelque chose à faire - supprimer accidentellement des fichiers système ou creuser plus profondément dans le registre Windows. Ensuite, je voulais quelque chose de plus. Après l'école, j'ai commencé à suivre des cours sur le développement de sites Web. J'ai été ravi de pouvoir créer quelque chose de nouveau sur l'ordinateur. Mais je me suis vite rendu compte que cela ne me suffisait pas. Je pouvais créer une sorte de jeu informatique en HTML, mais cette boîte à outils était assez limitée. Un jour, mon professeur m'a donné un livre sur PHP. J'ai tout lu et, de façon inattendue pour moi, j'ai découvert un tout nouveau monde de possibilités, qui donne bien plus que du HTML et du CSS. C'était très cool, après ça j'ai commencé à lire de plus en plus de livres sur ce sujet. La langue suivante que j'ai apprise était Java. Une fois que j'ai lu sur Ruby dans le Linux Magazine (en fait pas sur Ruby, mais sur Rails, bien sûr), et j'ai pensé que ce serait formidable de l'apprendre. De là, tout a commencé et, comme une boule de neige, roule jusqu'à ce jour.

Et donc vous êtes passé à Ruby, non?

J'ai découvert Ruby à l'époque où j'ai commencé à étudier l'informatique à l'université, alors en même temps, j'étudiais également Java, C ++, Haskell et j'apprenais non seulement de nombreux langages de programmation à la fois. Dans le cadre de nos études, nous n'avions pas de missions Ruby, et je l'aimais vraiment, alors j'ai toujours essayé de l'utiliser dans les classes où vous pouviez choisir la technologie vous-même. Eh bien, dans leurs projets tiers aussi. Quand j'ai obtenu mon diplôme universitaire, j'ai décidé de chercher un emploi lié à Ruby. C'était simple, car Rails était alors au sommet de sa popularité: de nombreuses startups utilisaient cette technologie. L'intérêt est donc devenu mon métier.

Utilisez-vous maintenant Ruby comme outil principal? Ou travaillez-vous avec autre chose?

Dans mon travail actuel chez Tilde, je n'écris pas autant de rubis qu'auparavant. Je dirais que mon travail est un cocktail de JavaScript / TypeScript, Rust, Ruby et parfois Java. Mais de toute façon, tout le travail que je fais est lié à Ruby.

Le principal produit de Tilde est Skylight. Tous les composants ne sont pas écrits en Ruby: le frontend est en JavaScript et Ember, le backend est en Rails, mais tout le traitement des données entrantes est Java et Rust. Mais Skylight lui-même est un outil de surveillance des performances pour les applications Rails. En ce sens, tout le travail que je fais est toujours lié à Ruby.

Super! Je me suis inscrit il y a quelques jours à Skylight pour l'un des projets, maintenant je le teste. Cela semble intéressant et dès le début, il est clair comment tout fonctionne. Je n'ai pas encore beaucoup approfondi, mais je prévois de commencer à l'utiliser très étroitement la semaine prochaine. J'espère que je pourrai résoudre certains problèmes.

Super, ce serait génial d'entendre des commentaires!

Il est intéressant de comparer Ruby avec d'autres langues. Par exemple, avec Rust. Ruby est très expressif et conçu pour rendre le code lisible. Si vous le comparez avec Python ou avec C ++, C #, Java, ils ne sont pas, à mon avis, aussi faciles à lire que Ruby. Qu'en pensez-vous?

Je serai d'accord. Il existe deux façons «d'apprendre» une nouvelle langue. Le premier est assez superficiel: j'étudie les bases de la syntaxe, je joue avec des exemples, puis je l'oublie immédiatement. C'était comme ça avec Go. Je l'ai fait le week-end, puis pendant quelques semaines, j'ai écrit de petits projets dessus. Mais je n'avais alors aucune raison de continuer à programmer sur Go. Je l'ai juste étudié par curiosité et j'ai vite oublié.

D'autre part, il y a JavaScript / TypeScript, Rust et Ruby, que j'utilise tout le temps. Chacune de ces langues m'a ouvert de nouvelles opportunités, c'est très motivant.

Par exemple, lorsque j'ai commencé à travailler avec Ruby, j'ai été attiré par l'expressivité. Aucune autre langue ne vous a permis de faire des choses folles comme method_missing. La métaprogrammation, l'expressivité et la lisibilité du code sont les éléments clés que j'aime chez Ruby. Ce serait cool si d'autres langues le pouvaient.

Mais en eux, vous pouvez faire des choses qui sont impossibles dans Ruby. Par exemple, JavaScript. Tout était complètement différent avec lui qu'avec Ruby, dont je suis tombé amoureux au premier regard. J'ai commencé à utiliser JavaScript au besoin, j'avais besoin d'écrire du code de navigateur. Que cela nous plaise ou non, il est impossible de s'éloigner de JS. Si vous voulez écrire une application de navigateur interactive, comme Skylight (ce qui m'intéressait à l'époque), alors JavaScript est la seule issue.

Je voulais transférer les idées que j'aimais dans Ruby vers JavaScript, donc j'ai finalement commencé à travailler avec Ember. Cela, à son tour, m'a conduit à TypeScript. Lorsque vous écrivez un énorme framework, comme Ember, en JavaScript, avoir des types et un compilateur pour vérifier les erreurs aide vraiment. JavaScript et TypeScript m'ont aidé à comprendre cela.

Les idées que Rust m'a enseignées sont très similaires à TypeScript. C'est bien de pouvoir compiler tout le programme et d'être sûr que ça marche. Pour moi, c'est juste génial. J'ai déjà travaillé avec des langages compilés: avec Java et C. Vous devriez également y attendre jusqu'à ce que le code compile, mais cela n'est pas très utile, car le système de type dans ces langages ne détecte pas très bien les erreurs. Mais dans Rust, le compilateur peut garantir que le programme ne causera pas de problèmes de mémoire, et que lors de son exécution il n'y aura pas d'erreurs de segmentation (segfault). L'une des choses les plus difficiles à faire en programmation C est les problèmes de mémoire, qui sont très difficiles à éviter. La principale caractéristique de Rust pour moi est la possibilité de faire une programmation de bas niveau sans se soucier de cela.

Au fait, mon intérêt pour Rust était lié à Ruby. Je viens de commencer à travailler chez Tilde et je savais que le bijou Skylight était écrit en rouille. J'ai pensé que ce serait génial d'apprendre à écrire les extensions natives pour Ruby de la même manière. Je voulais apprendre à écrire dans Rust afin de ne pas m'inquiéter de casser les processus de coupe personnalisés, comme cela se produit lorsque les pointeurs sont mal référencés en C. Par conséquent, l'objectif principal de l'apprentissage de Rust pour moi était, en fait, d'écrire des extensions natives pour Ruby.

Ce matin même, je travaillais sur un projet avec Peter Wagenet de Tilde et Sean Griffin de Shopify et de l'équipe Rails. Sean travaille sur une nouvelle version d'Active Record écrite en Rust pour accélérer les parties lentes. Et juste avant cette interview, je travaillais sur un projet à Rust appelé libcruby-sys, qui vous permet d'écrire des extensions natives pour Ruby in Rust.

Au final, on peut dire que toutes les langues sont connectées. Les langues que j'apprends et programme ne sont que des outils qui me permettent de créer ce que j'ai en tête.

Très intéressant! Cool que ActiveRecord sera beaucoup plus rapide. Pour autant que je comprends, l'idée d'ActiveRecord ne changera pas. Je veux dire, sera-ce le même ActiveRecord, et pas quelque chose comme un Data Mapper?

Active Record sur Ruby, bien sûr, n'ira nulle part, il se développe activement, il est utilisé. Dans le cas de JRuby, c'est le premier choix. L'implémentation de Sean est 100% compatible avec l'API native. Les composants internes sont réécrits dans Rust, donc tout fonctionne plus rapidement, mais l'API ne changera pas pour l'utilisateur final.

Même chose avec le projet sur lequel je travaille depuis quelques années. Il s'appelle Helix et est associé à mes expériences avec Rust pour créer des extensions natives pour Ruby. Il a été très difficile de démarrer en raison d'un tas de problèmes de sécurité de la mémoire qui devaient être résolus. Helix vous permet de vous concentrer simplement sur l'écriture de code en Rust, il s'occupe de le compiler en extension Ruby.

Je pense que beaucoup utilisaient la gemme JSON en Ruby. En fait, il existe deux implémentations différentes de ce joyau. Il existe une implémentation Ruby pure et une extension C qui implémentent la même API. Ce n'est pas visible, mais si vous écrivez `require json`, alors la version C sera probablement chargée. Si la plate-forme actuelle n'est pas prise en charge, alors ce sera une version ruby. Mais, encore une fois, l'API est utilisée exactement de la même manière dans les deux cas. La seule différence est que les composants internes de l'un d'entre eux sont implémentés en C, donc cela fonctionne plus rapidement. En plus de performances supérieures, il n'y a pas de différences. C'est l'objectif de tous ces projets - être en mesure d'utiliser le Ruby que nous aimons, mais obtenir les avantages de performance du code natif lorsque cela est nécessaire.

C'est super que Ruby soit plus rapide. Bien qu'il y ait une opinion que la vitesse d'exécution n'est pas trop importante pour les programmes Ruby, mais je suis sûr que tout le monde sera content si les performances augmentent.

Pour la plupart, je suis d'accord. En général, c'est le cas. Mais, ayant sérieusement augmenté la productivité, nous pouvons faire des choses qui étaient auparavant tout simplement impossibles sur cette plate-forme. Comme je l'ai dit, j'ai appris JavaScript parce que je voulais écrire des programmes pour le navigateur, et il est impossible de faire autrement. Je pense que c'est la même chose pour la performance. Je me fiche que le code soit 20% plus rapide. C'est bien, mais ce n'est pas si important. Mais lorsque le code s'exécute 10 fois plus rapidement, cela ouvre de nouvelles possibilités.

Par exemple, si vous êtes engagé dans l'apprentissage automatique, vous devez faire beaucoup de calculs complexes. Très probablement, vous ne pourrez pas l'implémenter sur Ruby, car Ruby est trop lent. Mais s'il existe une interface pour interagir facilement avec les bibliothèques natives d'apprentissage automatique, vous pouvez travailler avec ML même sur Ruby. Vous pouvez écrire du code pour orchestrer tous les processus avec des calculs en Ruby, avec toute son expressivité et son écosystème de gemmes. Pour moi, la performance est un outil pour apporter de nouvelles fonctionnalités.

C'est absolument vrai! J'ai lutté à plusieurs reprises avec des programmes Ruby peu performants. J'ai dû écrire beaucoup de code SQL pour accélérer les choses, pour transférer une partie de la logique du côté de la base de données, car cela fonctionne des centaines de fois plus rapidement.

C'est vrai, mais je préfère déplacer le code problématique vers les extensions natives plutôt que de le réécrire en tant que microservice sur Go ou Haskell. Je pense qu'il est bon de pouvoir écrire autant de code Ruby que possible et de déplacer des parties critiques pour les performances dans un endroit où vous pouvez facilement interagir avec Ruby. L'occasion en soi est magnifique.

Oui, cela devrait être plus rapide et plus facile, plus efficace en termes de tâches commerciales. Pas besoin d'embaucher des programmeurs avec des compétences et des piles différentes, car tout peut être écrit en Ruby. Cela semble prometteur. Que pensez-vous de l'avenir de Rails? Chaque année, il y a des rumeurs selon lesquelles Rails est en train de mourir ...

Je suis biaisé parce que je travaille pour une entreprise dont le produit principal est un outil de suivi des performances dans Rails. Personnellement, je ne pense pas qu'ils meurent, mais Rails est définitivement devenu plus mature, «mûri». Pour de nombreuses personnes dans la communauté, c'est quelque chose de fondamentalement nouveau. Beaucoup d'entre nous ont rejoint la communauté Rails et Ruby lorsque Rails était un thème de battage médiatique. Il y avait beaucoup d'enthousiasme, beaucoup d'innovations. Bien que bon nombre de nos «innovations» soient monnaie courante dans d'autres écosystèmes plus adultes. Beaucoup était alors impossible, car l'écosystème était encore immature.

Ce fut une période très excitante. Chaque lundi, j'avais hâte de voir un nouvel épisode de RailsCasts. Nouveau bijou chaque semaine. Par exemple, cette semaine, nous créons des fichiers PDF, la semaine prochaine nous téléchargeons un fichier, puis quelque chose de fondamentalement nouveau apparaît, comme bundler, par exemple. C'était une période d'idées nouvelles, passionnantes, tout le monde avait beaucoup d'énergie. Beaucoup de gens pensent que Rails ou Ruby meurent parce que ces émotions ont disparu.

Et à mon avis, l'écosystème vient de mûrir et de devenir plus stable. Nous avons déjà expérimenté 5 façons complètement différentes de télécharger des fichiers, et nous n'avons tout simplement pas besoin de le faire chaque semaine. En termes d'émotions, je manque définitivement ces moments. Mais je ne pense pas que ce soit pire maintenant. Nous pouvons dire ceci: «ok, nous avons traversé toutes ces aventures, essayé différentes approches, pris des leçons. Et maintenant, nous avons choisi la meilleure option que tout le monde utilisera. » Je pense que c'est génial.

Une partie de moi manque définitivement ce dynamisme, le sens constant du changement et du progrès qui était dans la communauté Ruby à l'époque. Maintenant, je le vois dans la communauté de Rust. Là, je peux vivre les mêmes émotions. Oui, chez Ruby, les passions se sont apaisées. Mais du point de vue de la productivité et du travail réel - tout n'est pas mal du tout. Je comprends qu'une personne qui aime constamment apprendre de nouvelles choses a besoin de telles émotions. Je les cherche et les trouve dans d'autres écosystèmes. La communauté mûrit et il y a moins de changements. Mais personnellement ça me convient.

Je pense que c'est l'ordre naturel des choses, et Rails est toujours aussi beau. Tout ce qui se passe - profite à la vraie entreprise qui développe des applications commerciales. J'aime que Rails permette différentes approches. Par exemple, vous pouvez utiliser des pionniers ou des gemmes dry-rb tout en restant dans le contexte de Rails. Vous pouvez utiliser différents types d'abstractions dans votre code, mais ce sera finalement une application Rails. Voilà ce que j'aime.

Je suis définitivement d'accord avec toi. Je pense que tout l'écosystème grandit. À cette époque, que nous appelons maintenant le «pic» de Rails, de nombreuses nouvelles startups sont apparues. Personne ne se souciait de la stabilité et de la stabilité. Ensuite, vous obtenez un afflux constant de nouvelles émotions et d'énergie. Maintenant, beaucoup de ces entreprises sont devenues de grandes sociétés telles que Github ou Shopify, et ont commencé à se soucier de la stabilité. Cela est vrai pour beaucoup.

En tant que communauté, nous avons collectivement décidé de préférer la stabilité aux expériences. D'un point de vue linguistique, il y a encore beaucoup de place pour l'expérimentation car Ruby reste le même. La raison pour laquelle Ruby était génial pour l'expérimentation est allée nulle part. Cependant, la communauté a décidé de se concentrer sur la création de choses qui fonctionnent sur Rails, car Rails a longtemps été activement utilisé. Lorsque vous écrivez un bijou, vous êtes susceptible de prendre en charge plusieurs versions de Rails, car de nombreuses entreprises les utilisent. En conséquence, les Rails eux-mêmes deviennent également plus prudents, ne cassent pas inutilement leur API. Personnellement, je suis heureux de faire partie de ce processus.

Du point de vue commercial, la stabilité est très importante. Surtout pour les systèmes fortement chargés. La stabilité des interfaces du framework facilite le travail. Je me souviens des moments où il était très difficile de passer d'une version de Rails à une autre. Par exemple, au moment où l'application a commencé à lancer un tas d'erreurs dues à un encodage incompatible.

Trailblazer est un excellent exemple qui montre l'état actuel de la communauté et de l'écosystème. D'une part, le fait qu'il existe est une assez bonne preuve qu'il y a encore beaucoup de place pour l'expérimentation dans la communauté Ruby. Mais je pense que s'il est sorti il ​​y a 5 ans, il serait beaucoup plus populaire, car maintenant nous avons construit un écosystème beaucoup plus grand autour de Rails, avec beaucoup de joyaux.

En fin de compte, vous vous souciez davantage de ce que vous pouvez faire avec la pile familière. Lorsque vous avez juste besoin d'écrire une application qui peut facturer, créer des fichiers PDF et utiliser des sockets Web, de nombreuses personnes préfèrent utiliser ce que d'autres utilisent déjà - dans ce cas, vous pouvez partager des gemmes, des discussions, trouver des réponses à StackOverflow, etc.

En ce sens, nous pouvons dire qu'une partie de la communauté Ruby est décédée. Il y a 5 à 10 ans, vous faisiez constamment de nouvelles choses, ne vous inquiétiez pas trop de la compatibilité, utilisiez les joyaux les plus récents et les plus cool, car il n'y avait pas de «bagages» derrière votre dos. Maintenant, la plupart des projets dans la communauté des «bagages» se sont accumulés décemment. Et ceux qui aiment l'expérimentation et l'innovation se sont déplacés vers d'autres communautés et écosystèmes.

Je pense que c'est normal.

Ça ne me dérange pas non plus. C'est comme grandir, une autre étape de la vie.

Que pensez-vous de la frappe statique? Est-il possible d'obtenir les avantages de cette approche dans Ruby?

Je l'attends avec impatience car j'ai déjà expérimenté les avantages de cette chose dans l'écosystème JavaScript avec TypeScript. JavaScript est très similaire à Ruby. , , . 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» .

Je vous remercie! , , . , , . , , .

, , 2 . , Rails!

! , .

Je vous remercie! . RubyRussia . ?

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

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

! - , . , . , !

.

!

! ! ! !

! ( :) 6 . , . 8000 .

hype.codes .

, Ruby- :

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