Entrevista con el orador de la conferencia RubyRussia Godfrey Chan

Hola a todos! El 6 de octubre, Moscú será el anfitrión de la conferencia RubyRussia , el antiguo y antiguo RailsClub, pero con un nuevo nombre. Ponentes de este año: Aaron Patterson, Charles Nutter, Godfrey Chan, Maciej Mensfeld, Markus Schirp y más. Y, por supuesto, 600 participantes, las mejores empresas con puestos en el vestíbulo y una fiesta después del incendio.

Tradicionalmente, antes de la conferencia, hablamos sobre los temas más relevantes en Ruby and Rails. Hoy te presentamos a Godfrey Chan , un ex equipo central de Rails, que trabaja en Tilde, donde se debate entre crear un perfil inteligente de Rails Skylight , trabajar en Ember.js y desarrollar JavaScript en TC39. Tim Leader de Evrone Dmitry Matveev le hizo a nuestros invitados preguntas importantes.




Comencemos con un par de preguntas sobre su informe sobre RubyRussia.

¡No quiero revelar todos los secretos! Mi informe se llama "Descenso al metal". Hablaré sobre cómo escribir código Rubu bastante extraño usando metaprogramación para hacer algo similar a JavaScript. Por supuesto, no podremos escribir un analizador y tiempo de ejecución de JavaScript completo, pero mostraré algo de magia que hará que una pieza de código similar a JavaScript se ejecute en Ruby usando el tiempo de ejecución nativo de Ruby. Es divertido, al menos me gusta mucho. Esta es la misma técnica con la que puedes escribir cosas como rspec, rake u otras DSL en Ruby. Les mostraré a los estudiantes cómo Ruby analiza y ejecuta su código, y qué ganchos puede usar. Creo que el informe no solo será divertido, sino que también enseñará algunas cosas útiles sobre la metaprogramación en Ruby.

Genial! Es decir, habrá consejos prácticos, ¿verdad?

No estoy seguro de que sea posible concentrarse en ellos, pero creo que a partir de estos 30 minutos aprenderá algo útil para usted.

Genial Creo que el informe será interesante tanto para programadores experimentados como para principiantes. Derecho?

Eso espero. Al menos lo intentaré.

Por cierto, ayer leí tu artículo sobre Medium sobre el replanteamiento de la educación en informática. El artículo es muy interesante, y estoy de acuerdo con las ideas sobre las diferencias entre la educación universitaria clásica y los cursos modernos para programadores. Por cierto, ¿por qué decidiste convertirte en programador?

Solo por casualidad, nunca planeé trabajar como programador, para mí fue un pasatiempo. Realmente me gustó jugar con las computadoras, fue fácil encontrar algo que hacer: eliminar accidentalmente los archivos del sistema o profundizar en el registro de Windows. Entonces quise algo más. Después de la escuela, comencé a tomar cursos sobre desarrollo de sitios web. Me encantó la oportunidad de crear algo nuevo en la computadora. Pero pronto me di cuenta de que esto no era suficiente para mí. Podría crear algún tipo de juego de computadora en HTML, pero este kit de herramientas era bastante limitado. Un día, mi maestra me dio un libro sobre PHP. Lo leí todo y, inesperadamente para mí, descubrí un mundo completamente nuevo de posibilidades, que ofrece mucho más que HTML y CSS. Fue genial, después de eso comencé a leer más y más libros sobre este tema. El siguiente idioma que aprendí fue Java. Una vez leí sobre Ruby en la revista Linux (en realidad no sobre Ruby, sino sobre Rails, por supuesto), y pensé que sería bueno aprenderlo. A partir de ahí, todo comenzó y, como una bola de nieve, rueda hasta el día de hoy.

Y entonces cambiaste a Ruby, ¿verdad?

Descubrí a Ruby cuando comencé a estudiar Ciencias de la Computación en la universidad, así que al mismo tiempo también estudiaba Java, C ++, Haskell y no solo aprendía muchos lenguajes de programación a la vez. Como parte de nuestros estudios, no teníamos asignaciones de Ruby, y realmente me caía bien, así que siempre traté de usarlo en aquellas clases donde podía elegir la tecnología usted mismo. Bueno, también en sus proyectos de terceros. Cuando me gradué de la universidad, decidí buscar un trabajo relacionado con Ruby. Era simple, porque Rails estaba en la cima de la popularidad: muchas nuevas empresas usaban esta tecnología. Entonces el interés se ha convertido en mi trabajo.

¿Ahora usa Ruby como su herramienta principal? ¿O estás trabajando con otra cosa?

En mi trabajo actual de Tilde, no escribo tanto Ruby como antes. Diría que mi trabajo es un cóctel de JavaScript / TypeScript, Rust, Ruby y, a veces, Java. Pero, de todos modos, todo el trabajo que hago está relacionado con Ruby.

El producto principal en Tilde es Skylight. No todos los componentes están escritos en Ruby: el frontend está en JavaScript y Ember, el backend está en Rails, pero todo el procesamiento de datos entrantes es Java y Rust. Pero Skylight en sí es una herramienta de monitoreo de rendimiento para aplicaciones Rails. En este sentido, todo el trabajo que hago todavía está relacionado con Ruby.

Genial Yo mismo me registré en Skylight hace unos días para uno de los proyectos, ahora lo estoy probando. Parece interesante, y desde el principio está claro cómo funciona todo. Todavía no he profundizado mucho, pero planeo comenzar a usarlo con mucha fuerza la próxima semana. Espero poder solucionar algunos problemas con él.

¡Genial, sería genial escuchar comentarios!

Es interesante comparar Ruby con otros idiomas. Por ejemplo, con Rust. Ruby es muy expresivo y está diseñado para hacer que el código sea legible. Si lo compara con Python o con C ++, C #, Java, en mi opinión, no son tan fáciles de leer como Ruby. ¿Qué opinas de esto?

Estoy de acuerdo Hay dos formas de "aprender" un nuevo idioma. La primera es bastante superficial: estudio los conceptos básicos de la sintaxis, juego con ejemplos y luego me olvido de ella. Fue así con Go. Lo hice el fin de semana, luego durante un par de semanas escribí pequeños proyectos sobre él. Pero entonces no tenía ninguna razón para continuar programando en Go. Solo lo estudié por curiosidad, y rápidamente lo olvidé.

Por otro lado, hay JavaScript / TypeScript, Rust y Ruby, que uso todo el tiempo. Cada uno de estos idiomas me ha abierto nuevas oportunidades, es una gran motivación.

Por ejemplo, cuando comencé a trabajar con Ruby, me atrajo la expresividad. Ningún otro idioma te ha permitido hacer locuras como método_missing. La metaprogramación, la expresividad y la legibilidad del código son las cosas clave que me encantan de Ruby. Sería genial si otros idiomas pudieran.

Pero en ellos puedes hacer cosas que son imposibles en Ruby. Por ejemplo, JavaScript. Todo era completamente diferente con él que con Ruby, del que me enamoré a primera vista. Comencé a usar JavaScript según fuera necesario, necesitaba escribir el código del navegador. Nos guste o no, no hay forma de alejarse de JS. Si desea escribir una aplicación de navegador interactiva, como Skylight (justo lo que me interesaba en ese momento), entonces JavaScript es la única salida.

Quería transferir las ideas que me gustaban en Ruby a JavaScript, así que al final comencé a trabajar con Ember. Esto, a su vez, me llevó a TypeScript. Cuando escribes un gran framework, como Ember, en JavaScript, tener tipos y un compilador para verificar errores realmente ayuda. JavaScript y TypeScript me ayudaron a entender esto.

Las ideas que Rust me enseñó son muy similares a TypeScript. Es bueno poder compilar todo el programa y estar seguro de que funciona. Para mí, es simplemente increíble. He trabajado con lenguajes compilados anteriormente: con Java y C. También debe esperar en ellos hasta que se compile el código, pero esto no es de mucha utilidad, porque el sistema de tipos en estos lenguajes no detecta muy bien los errores. Pero en Rust, el compilador puede garantizar que el programa no causará problemas de memoria, y que durante su ejecución no habrá errores de segmentación (segfault). Una de las cosas más difíciles de hacer en la programación en C son los problemas de memoria, que son muy difíciles de evitar. La característica principal de Rust para mí es la capacidad de hacer programación de bajo nivel sin preocuparse por ello.

Por cierto, mi interés en Rust estaba relacionado con Ruby. Empecé a trabajar en Tilde y sabía que la gema Skylight estaba escrita en Rust. Pensé que sería genial aprender a escribir extensiones nativas para Ruby de la misma manera. Quería aprender a escribir en Rust para no preocuparme por romper los procesos de corte personalizados, como sucede cuando los punteros se desreferencian incorrectamente en C. Por lo tanto, el objetivo principal de aprender Rust para mí era, de hecho, escribir extensiones nativas para Ruby.

Justo esta mañana, estaba trabajando en un proyecto con Peter Wagenet de Tilde y Sean Griffin del equipo de Shopify y Core Rails. Sean está trabajando en una nueva versión de Active Record escrita en Rust para acelerar las partes lentas. Y justo antes de esta entrevista, estaba trabajando en un proyecto en Rust llamado libcruby-sys, que le permite escribir extensiones nativas para Ruby in Rust.

Al final, podemos decir que todos los idiomas están conectados. Los idiomas que aprendo y programo son solo herramientas que me permiten crear lo que tengo en mente.

Muy interesante! Es genial que ActiveRecord sea mucho más rápido. Hasta donde entiendo, la idea de ActiveRecord no cambiará. Quiero decir, ¿será el mismo ActiveRecord, y no algo así como un Data Mapper?

El registro activo en Ruby, por supuesto, no irá a ninguna parte, se está desarrollando activamente, se usa. En el caso de JRuby, esta es la primera opción. La implementación de Sean es 100% compatible con la API nativa. Las partes internas se reescriben en Rust, por lo que todo funciona más rápido, pero la API no cambiará para el usuario final.

Lo mismo con el proyecto en el que he estado trabajando durante los últimos años. Se llama Helix , y está asociado con mis experimentos con Rust para crear extensiones nativas para Ruby. Fue muy difícil comenzar debido a un montón de problemas de seguridad de la memoria que debían abordarse. Helix le permite concentrarse simplemente en escribir código en Rust, él se encarga de compilarlo en Ruby-extension.

Creo que muchos usaron gemas JSON en Ruby. De hecho, hay dos implementaciones diferentes de esta gema. Hay una implementación pura de Ruby y una extensión C que implementan la misma API. Esto no se nota, pero si escribe `require json`, lo más probable es que se cargue la versión C. Si la plataforma actual no es compatible, será una versión ruby. Pero, nuevamente, la API se usa exactamente de la misma manera en ambos casos. La única diferencia es que los componentes internos de uno de ellos se implementan en C, por lo que funciona más rápido. Además de un mayor rendimiento, no hay diferencias. Este es el objetivo de todos estos proyectos: poder usar el Ruby que amamos, pero obtener los beneficios de rendimiento del código nativo cuando sea necesario.

Es genial que Ruby sea más rápido. Aunque existe la opinión de que la velocidad de ejecución no es demasiado importante para los programas de Ruby, estoy seguro de que todos estarán contentos si aumenta el rendimiento.

En su mayor parte estoy de acuerdo. En general, esto es así. Pero, habiendo aumentado considerablemente la productividad, podemos hacer cosas que antes eran simplemente imposibles en esta plataforma. Como dije, aprendí JavaScript porque quería escribir programas para el navegador, y es imposible hacerlo de otra manera. Creo que lo mismo es cierto para el rendimiento. No me importa si el código se ejecuta un 20% más rápido. Esto es bueno, pero no es tan importante. Pero cuando el código se ejecuta 10 veces más rápido, esto abre posibilidades completamente nuevas.

Por ejemplo, si se dedica al aprendizaje automático, debe hacer muchos cálculos complejos. Lo más probable es que no pueda implementar esto en Ruby, porque Ruby es demasiado lento. Pero si hay una interfaz para interactuar fácilmente con las bibliotecas nativas de aprendizaje automático, puede trabajar con ML incluso en Ruby. Puede escribir código para orquestar todos los procesos con cálculos en Ruby, con toda su expresividad y ecosistema de gemas. Para mí, el rendimiento es una herramienta para traer nuevas características.

Esto es absolutamente cierto! He luchado muchas veces con programas Ruby de bajo rendimiento. Tuve que escribir una gran cantidad de código SQL para acelerar las cosas, para transferir parte de la lógica al lado de la base de datos, porque funciona cientos de veces más rápido.

Así es, pero preferiría mover el código problemático a las extensiones nativas en lugar de reescribirlo como un microservicio en Go o Haskell. Creo que es bueno poder escribir tanto código Ruby como sea posible y mover partes críticas para el rendimiento a algún lugar con el que pueda interactuar fácilmente en Ruby. La oportunidad en sí es maravillosa.

Sí, debería ser más rápido y más fácil, más eficiente en términos de tareas comerciales. No es necesario contratar programadores con diferentes habilidades y pilas, ya que todo se puede escribir en Ruby. Eso suena prometedor. ¿Qué opinas del futuro de Rails? Cada año, hay rumores de que Rails está muriendo ...

Soy parcial porque trabajo para una empresa cuyo producto principal es una herramienta de supervisión del rendimiento en Rails. Personalmente, no creo que se estén muriendo, pero Rails definitivamente se ha vuelto más maduro, "madurado". Para muchas personas en la comunidad, esto es algo fundamentalmente nuevo. Muchos de nosotros nos unimos a la comunidad de Rails y Ruby cuando Rails era un tema exagerado. Hubo mucho entusiasmo, muchas innovaciones. Aunque, muchas de nuestras "innovaciones" eran comunes en otros ecosistemas más adultos. Mucho era imposible entonces, porque el ecosistema aún era inmaduro.

Fue un momento muy emocionante. Todos los lunes, esperaba un nuevo episodio de RailsCasts. Nueva joya cada semana. Por ejemplo, esta semana creamos archivos PDF, la próxima semana cargamos un archivo, y luego aparece algo fundamentalmente nuevo, como un paquete, por ejemplo. Fue un momento de nuevas ideas, emocionante, todos tenían mucha energía. Mucha gente piensa que Rails o Ruby están muriendo porque estas emociones se han ido.

Y en mi opinión, el ecosistema acaba de madurar y volverse más estable. Ya hemos experimentado con 5 formas completamente diferentes de cargar archivos, y no necesitamos hacerlo todas las semanas. En términos de emociones, definitivamente extraño esos momentos. Pero no creo que sea peor ahora. Podemos decir esto: “ok, pasamos por todas estas aventuras, probamos diferentes enfoques, obtuvimos lecciones. Y ahora hemos elegido la mejor opción que todos usarán ". Creo que es genial

Una parte de mí definitivamente echa de menos ese impulso, la constante sensación de cambio y progreso que había en la comunidad de Ruby en ese momento. Ahora lo veo en la comunidad Rust. Allí puedo experimentar las mismas emociones. Sí, en Ruby, las pasiones disminuyeron. Pero desde el punto de vista de la productividad y el trabajo real, todo es bastante bueno. Entiendo que una persona a la que le gusta aprender constantemente cosas nuevas necesita esas emociones. Los busco y los encuentro en otros ecosistemas. La comunidad está madurando y hay menos cambios. Pero personalmente me conviene.

Creo que este es el orden natural de las cosas, y Rails sigue siendo hermoso. Todo lo que sucede: beneficia al negocio real que desarrolla aplicaciones comerciales. Me gusta que Rails permita diferentes enfoques. Por ejemplo, puedes usar trailblazer o gemas dry-rb mientras permaneces en el contexto de Rails. Puede usar varios tipos de abstracciones en su código, pero finalmente seguirá siendo una aplicación Rails. Esto es lo que me gusta.

Definitivamente estoy de acuerdo contigo. Creo que todo el ecosistema está creciendo. En ese momento, que ahora llamamos el "pico" de Rails, aparecieron muchas nuevas empresas. A nadie le importaba la estabilidad y la estabilidad. Entonces obtienes una afluencia constante de nuevas emociones y energía. Ahora, muchas de estas compañías se han convertido en grandes corporaciones como Github o Shopify, y han comenzado a preocuparse por la estabilidad. Esto es cierto para muchos.

Como comunidad, colectivamente decidimos preferir la estabilidad a los experimentos. Desde el punto de vista del lenguaje, todavía hay mucho espacio para la experimentación porque Ruby sigue siendo el mismo. La razón por la que Ruby era genial para la experimentación no ha ido a ninguna parte. Sin embargo, la comunidad decidió centrarse en crear cosas que funcionen en Rails, porque Rails se ha utilizado activamente durante mucho tiempo. Cuando escribe una gema, es probable que admita varias versiones de Rails, porque hay muchas compañías que las usan. Como resultado, los Rails también se vuelven más cuidadosos, no rompan su API innecesariamente. Personalmente, estoy feliz de ser parte de este proceso.

Desde una perspectiva comercial, la estabilidad es muy importante. Especialmente para sistemas muy cargados. La estabilidad de las interfaces del marco facilita el trabajo. Recuerdo los momentos en que era muy difícil cambiar de una versión de Rails a otra. Por ejemplo, en el momento en que la aplicación comenzó a arrojar un montón de errores debido a la codificación incompatible.

Trailblazer es un gran ejemplo que muestra el estado actual de la comunidad y el ecosistema. Por un lado, el hecho de que exista es una prueba bastante buena de que todavía hay mucho espacio para la experimentación en la comunidad Ruby. Pero creo que si salió hace 5 años, sería mucho más popular, porque ahora hemos construido un ecosistema mucho más grande alrededor de Rails, con muchas gemas.

Al final, te importa más lo que puedes hacer con la pila familiar. Cuando solo necesita escribir una aplicación que pueda facturar, crear archivos PDF y usar sockets web, muchas personas preferirán usar lo que otros ya usan; en este caso, puede compartir gemas, discusiones, encontrar respuestas a StackOverflow, etc.

En este sentido, podemos decir que parte de la comunidad Ruby ha muerto. Hace 5-10 años, constantemente hacía cosas nuevas, no se preocupaba demasiado por la compatibilidad, usaba las gemas más nuevas y geniales, porque no había "equipaje" a sus espaldas. Ahora, la mayoría de los proyectos en la comunidad de "equipaje" se acumularon decentemente. Y aquellos que aman la experimentación y la innovación se han mudado a otras comunidades y ecosistemas.

Creo que esto es normal.

A mí tampoco me importa. Es como crecer, otra etapa de la vida.

¿Qué opinas de la escritura estática? ¿Hay alguna posibilidad de obtener los beneficios de este enfoque en Ruby?

Lo espero con ansias porque ya he experimentado los beneficios de esto en el ecosistema de JavaScript con TypeScript. JavaScript 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» .

Gracias , , . , , . , , .

, , 2 . , Rails!

! , .

Gracias . RubyRussia . ?

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

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

! - , . , . , !

.

!

! ! ! !

! ( :) 6 . , . 8000 .

hype.codes .

, Ruby- :

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