«Rust no tiene miedo de ser imperfecto, siempre que publiquemos algo útil»

Introducción

Steve Klabnik es miembro del equipo principal de Rust, un activo colaborador en proyectos de código abierto y autor de libros como «The Rust Programming Language», «Rails 4 in Action» y «Designing Hypermedia APIs». En 2012 y 2016, invitamos a Steve como ponente en la conferencia RailsClub (ahora conocida como RubyRussia). Desde entonces, Steve ha trabajado intensamente en Rust, ha conseguido muchas cosas interesantes y nos hemos dado cuenta de que nos encantaría volver a entrevistarle.

Nos reunimos con Steve para conocer de primera mano cuáles son sus actividades profesionales en este momento, el éxito del diseño de Rust, un poco sobre el entusiasmo por el desarrollo de «pila completa» y cómo evitar quemarte en el trabajo.

La entrevista

Evrone:  Además de tus contribuciones de código abierto, ¿cuáles son tus actividades profesionales en este momento?

Steve: Trabajo en Oxide Computer Company, donde escribo un montón de código de Rust.

Evrone:  ¿Hay otras tecnologías distintas de Ruby y Rust que te parecen interesantes?

Steve:  En este momento, estoy centrado principalmente en Rust, pero también me interesa el auge de los «CMS sin interfaz» y JAMstack.

Evrone:  Has dedicado mucho tiempo a buscar las bestias de matemática del juego para crear una documentación de primera calidad para los desarrolladores de Rust. Al analizar en retrospectiva la evolución del lenguaje, ¿cuál crees que es el principal éxito de diseño que dio un mayor impulso a la popularidad del lenguaje?

Steve:  Lo más importante es querer ser útiles. Intentamos resultar familiares en la medida de lo posible para que unas pocas nuevas ideas puedan recibir la atención necesaria. Rust no tiene miedo de ser imperfecto, siempre que publiquemos algo útil.

Evrone:  ¿Cuál es tu conjunto de herramientas de software favorito para el trabajo diario?

Steve:  Uso Visual Studio Code con el complemento de Vim.

Evrone:  ¿Cuál crees que es la formación adecuada para un desarrollador de software? ¿Hay que estudiar «teoría de la informática» para convertirte en programador? ¿O tenemos que aprender a convertirnos en «autores de software», como afirma DHH?

Steve:  Tengo un grado, pero he aprendido mucho más fuera. Me ha resultado útil, pero conozco a un gran número de excelentes programadores que no han tenido una formación oficial.

Evrone:  Yukihiro Matsumoto afirmó una vez que «al elegir el lenguaje, también eliges los proyectos que harás para tu trabajo diario y cómo los desarrollarás». ¿Qué tipo de proyectos y cultura laboral pueden esperar principalmente los desarrolladores de Rust?

Steve:  Muchos de los trabajos de Rust se encuentran en el ámbito de infraestructuras; es decir, cosas como sistemas operativos, servidores web, herramientas de DevOps, bases de datos y dispositivos insertados. También hay algunas aplicaciones web, y parece que eso está aumentando bastante recientemente.

Evrone:  Recientemente, se introdujeron los nuevos conceptos y sintaxis de «async/await» Rust y otros lenguajes. Como alguien que escribe documentación sobre el lenguaje y enseñas a la gente a usarlo, ¿qué podrías contarnos sobre la curva de aprendizaje y los comentarios de los desarrolladores en relación con estas nuevas características?

Steve:  Rust tiene una reputación de ser difícil de aprender, y eso es cierto en parte porque se han usado muchos otros lenguajes como inspiración. Por lo tanto, si no has probado algunos de los lenguajes de los que se obtuvo esa idea, te puede resultar complicado. Sin embargo, a veces es similar a algo que ya has probado y te puede resultar más fácil. Eso quiere decir que el concepto de fácil y difícil es distinto para cada persona. Un programador de JavaScript podría decir «ah, sí, async/await, es fácil», mientras que un programador de C podría pensar «¿qué es eso?». Pero, en relación con los punteros, el programador de C diría «lo tengo controlado», mientras que al programador de JavaScript le resultaría más difícil.

Evrone: ¿Piensas que hay una «afinidad natural» hacia el desarrollo de software, al igual que hay personas a las que se les da bien tocar un instrumento musical o dibujar?

Steve:  Puede ser. Sin embargo, incluso si existe cierta afinidad, no creo que sea un requisito para ser buen programador. Puede que resulte más fácil, pero no es necesario.

Evrone:  ¿Cuáles crees que son los competidores del lenguaje de programación Rust ahora mismo y en qué áreas?

Steve:  El auténtico desafío ahora son los trabajos. Hay más trabajos de Rust de lo que podría esperarse, pero no es tan sencillo conseguir uno, porque no hay muchos. Esto cambia continuamente, pero aún no hemos llegado a ese punto.

Evrone:  El panorama del sistema de tipos para los lenguajes modernos abarca desde el «tipado dinámico» hasta el «tipado estático», con una amplia gama de variedades, como el nuevo método de «tipado gradual». ¿Cuál crees que es el principal reto con los tipos? ¿Por qué no tenemos aún una estrategia «mejor» que pueda usarse en la mayoría de los lenguajes de programación?

Steve:  No todos los sistemas de tipos se crean por igual. Hay una gran variedad de clases distintas de sistemas de tipos, y algunas son mejores que otras. Y también existe una preferencia personal. Sé que algunas personas nunca usarían un lenguaje de tipado dinámico; sin embargo, aunque prefiero los lenguajes de tipado estático, elegiría un lenguaje de tipado dinámico antes que un lenguaje con un sistema de tipado estático menos consolidado.

Evrone:  Hay una gran cantidad de ejemplos de desarrolladores de código abierto «quemados», eso sin mencionar historias como el reciente enfrentamiento en Actix Web. ¿Qué haces para conciliar la vida laboral y personal sin llegar a quemarte?

Steve:  No creo que se me dé muy bien eso de mantener un equilibrio, ya que no es algo fácil. Hay períodos en los que hago mucho, y otros en los que no hago nada.

Evrone:  El nuevo entusiasmo por la «pila completa» exige a los desarrolladores aprender un gran número de lenguajes y pilas distintas. Dada tu fluidez en ecosistemas tan distintos como Ruby y Rust, ¿crees que es una buena idea que un gran número de desarrolladores añadan distintos elementos a su ámbito de trabajo diario?

Steve:  Aprender nuevas tecnologías siempre es algo bueno y, si tienes el tiempo y la capacidad para aprender más, deberías aprender continuamente cosas nuevas, al menos esa es mi opinión.

Evrone:  ¿Podemos evaluar de forma razonable los conocimientos de un desarrollador de software basándonos en el número de años que ha trabajado como programador?

Steve:  No creo. A veces, la experiencia resulta útil, pero hoy en día es muy fácil quedarse atascado con métodos anticuados.

Evrone:  ¿Crees que WebAssembly podrá reemplazar a JavaScript como plataforma de front-end en el futuro? ¿O piensas que la arquitectura de «área de pruebas» lo limitará para siempre al nicho de «complemento de alto rendimiento»?

Steve:  No creo que sea fácil reemplazar JavaScript, ni tampoco mejorarlo. Creo que se usará mucho más Wasm, pero JavaScript no va a desaparecer.

Evrone:  Hay intensos debates en Internet sobre las arquitecturas de «monolito frente a microservicios», donde algunas grandes empresas dividen sus monolitos en microservicios, mientras que otras agrupan microservicios para formar gloriosos monolitos. Ahora es incluso más complicado, ya que hay una nueva «función como servicio» que ofrecen las principales plataformas en la nube. ¿Podrías dar algún consejo a los desarrolladores sobre cómo tomar una decisión razonable para sus proyectos?

Steve:  Creo que depende de las habilidades de tu equipo. Algunos equipos prefieren una base de código amplia, mientras que otros prefieren trabajar con varios pequeños. Creo que todos puede trabajar bien, y todos pueden fracasar a la vez.

Evrone:  ¿Cómo puede un desarrollador de nivel medio elegir entre «SemVer» y «CalVer»?

Steve:  En mi caso, prefiero SemVer, pero mi opinión está bastante sesgada :)

Evrone:  ¿Es razonable para el código abierto que las empresas contraten a desarrolladores a tiempo completo? ¿O deberíamos elegir servicios como el patrocinio de GitHub, Patreon, etc., para apoyar financieramente a los colaboradores y mantenedores de código abierto?

Steve:  Creo que es bueno que las empresas contraten a desarrolladores a tiempo completo. Todos tenemos que pagar el alquiler y las facturas. Si ese dinero proviene de organizaciones que ganan dinero, con frecuencia es mucho mejor que recibir donativos de otros desarrolladores.

Puedes ver el informe de Steve Klabnik «Exploring Ruby through Rust» en RailsClub (RubyRussia) de 2016:

Estamos encantados de ser amigos de Steve, quien nos inspira a usar Ruby y Rust en una amplia variedad de proyectos. Póngase en contacto con nosotros si necesita ayuda para desarrollar una solución de alta calidad. ¡Estaremos encantados de ayudarle!