RubyRussia 2019. Nikita Shilnikov sobre los efectos algebraicos

Queda muy poco tiempo antes de la conferencia de RubyRussia. Aquellos que no lograron obtener su boleto aún tienen la oportunidad de recoger uno de los últimos en el sitio . Nikita Shilnikov en la conferencia hablará sobre los efectos algebraicos, pero por ahora puede leer la entrevista sobre el tema del informe.



Dime qué haces y cómo está conectado con Ruby.

Trabajo para dos empresas cuyos proyectos están escritos en Ruby. En uno que hacemos facturación, podemos decir que se trata de una semi-empresa, y en otro creamos un servicio SaaS. Dio la casualidad de que hago mucho código abierto. Hace cuatro años, me interesé en un proyecto, encontré fallas de funcionalidad en él, decidí arreglarlo de vez en cuando. Ahora soy un desarrollador principal de dos organizaciones y la comunidad. Todo se puede ver en mi github . Una parte del trabajo se ocupa de las bases de datos rom-rb , y la otra dry-rb es un conjunto de bibliotecas para diferentes ocasiones.

Su informe sobre los efectos algebraicos, dígame qué beneficios le dan a los desarrolladores.

Aquí necesitas una pequeña entrevista. El ecosistema dry-rb está inspirado en la programación funcional. Pero durante su desarrollo, algo obsesionado. Por ejemplo, está desarrollando un servicio SaaS y hay una tarea simple de aislar datos. Todo parece estar claro, hay algún tipo de servicio, las empresas están registradas en él y no deberían tener acceso a los datos de los demás. Puedes resolver de muchas maneras. Pero desde un punto de vista puramente funcional, no pude encontrar una respuesta a cómo hacer esto, excepto por la transferencia explícita de argumentos en todo el código. Se le ocurrió su solución "no funcional" y vivió con él.

A finales de 2018, aparecieron ganchos en React. Cuando vi por primera vez su API, pensé que era imposible hacer tales cosas de manera tan simple. Tengo una buena idea de cómo funciona JavaScript y decidí que obviamente no todo está limpio aquí, se usan variables globales o algo más. En mi idea de cómo funciona el programa, era imposible o se usaba algún tipo de truco sucio. Decidí estudiar el tema.

Resultó que no era la única persona interesada en este tema. Encontré información de que existe tal forma de formalización, es decir, escribir programas que parecen usar variables globales o algún estado general. Sin embargo, aún estarán limpios. El problema era relevante y comencé a profundizar. Como resultado, los efectos algebraicos se convirtieron en la respuesta. Escribí un pequeño prototipo en Ruby y, para mi sorpresa, funcionó. Implementado en producción, lanzado y conducido durante varios meses, luego tomó una decisión para todos.

Me intrigaste directamente con React Hooks. Pensé que había algo muy simple como la pila de llamadas, el cierre, el alcance actual.

Realmente lo es El problema es que tiene algún tipo de artículo que describe la semántica y cómo, desde un punto de vista científico, esto debería funcionar. Si sigue las especificaciones, parece que puede hacer una biblioteca. En el caso de React, esta también es una biblioteca o, por ejemplo, un marco que proporciona algún tipo de API. Si lo usa correctamente, entonces todo funciona bien. Pero si vas hacia la izquierda o hacia la derecha, puede terminar mal. En React, simplemente prohibieron el uso de ganchos en condiciones. Tenían que hacerlo. Esta es una de las limitaciones.

¿Está relacionado de alguna manera con la prueba matemática de la corrección del código?

En realidad no No se trata de la necesidad de probar algo, la cuestión se dirige más a la verificación del programa. De qué se tratan los efectos algebraicos es solo una descripción de la semántica. No se prueba nada allí, pero se muestra cómo debería funcionar. Si esta biblioteca, que implementa efectos algebraicos, no contiene errores en sí misma, entonces al describir la semántica, usted garantiza que su código funcionará según lo previsto.

¿Cómo te sientes acerca de los tipos y lenguajes de programación estáticamente tipados?

Muy positivo Por ejemplo, tenemos un back-end en Ruby y un front-end en algo como ReasonML. Esto es OCaml, pero con una sintaxis diferente. En igualdad de condiciones, hago una elección en la dirección de este tipo de sistema. Es bastante simple y hay varios idiomas en los que una implementación similar o similar. Cuantos más tipos, mejor. Sin embargo, estoy escribiendo un back-end en Ruby y todo está bien conmigo. Soy el desarrollador de las herramientas con las que trabajo y siempre han sido sobre tipos: tipos secos, estructura seca, esquema seco, validación en seco, mónadas en seco . Se trata de describir tipos que provienen de la base de datos, del usuario, de sistemas externos. Así que siempre sabes qué código Ruby funciona para ti. Incluso si no está escrito por sí mismo, puede estar seguro del tipo de variable con la que está trabajando.

Hay rumores de que habrá tipos en Ruby 3. ¿Qué dices sobre esto?

Tengo experiencia con Python. Cuando se trajeron los tipos allí, el tul no estaba muy desarrollado y no me impresionó. Ahora la situación es mejor allí. Puede ir allí y describir todo con tipos y aplicar algún tipo de ajuste, que verificará que su programa sea correcto. Se trata de algún tipo de reemplazo para el compilador, de lo que está haciendo sorbete ahora. Esto tomó varios años para Python. Siempre agradezco el movimiento hacia los tipos, pero no me hago ilusiones.

¿Busca una nueva sintaxis que planea implementar en términos de código Ruby?

Especialmente no jugó, entró en el chat, miró. Pero no tengo opinión sobre cómo vale la pena implementar esto. La sintaxis se puede mejorar, los cambios en el idioma, etc. Ahora han creado la sintaxis habitual compatible con Ruby. No creo que la sintaxis sea un obstáculo aquí, se está afinando un obstáculo y, como ya dije, este es un camino muy largo.

¿Qué más te gustaría ver en Ruby? ¿Cómo ves su desarrollo?

Me interesaría la multitarea cooperativa. Ya tenemos multitarea cooperativa en forma de fibra. Todavía nos falta la capacidad de ejecutarlos en múltiples hilos. Hay opciones sobre cómo se hará esto y no está claro de qué forma. Dado que Ruby, la implementación de C tiene un legado bastante sólido, Matz no quiere romper la compatibilidad con versiones anteriores. Me inclino por una combinación de fibras y varios hilos que se ejecutan simultáneamente. Tal vez algo como Guild funcione.

Este año, Yukihiro Matsumoto, el autor de Ruby, viene a la conferencia. ¿Qué le interesaría discutir con él con una taza de café o un vaso de sake en la fiesta posterior?

Lo mejor que podemos hacer para comunicarnos con los autores de idiomas o incluso bibliotecas es mostrarles cómo usamos este producto en la vida real. Además, incluso como los autores no esperaban. Esto le dará al autor la oportunidad de tener en cuenta dicha experiencia y aplicarla en un mayor desarrollo. Me gustaría mostrar toda la historia con efectos algebraicos. Yo diría: mira, qué cosa se puede hacer en el lenguaje milagroso que creaste. Y tal vez después de eso, nos propondrá algo más.

¡Nos vemos en RubyRussia!

Recordemos que la conferencia ya es este sábado, el registro aún está abierto.

No solo habrá informes, sino también stands de las mejores empresas:

Organizador - Evrone
Socio general - Toptal
Gold Partner - Gett
Socios de plata: Valarm , JetBrains , Bookmate y Cashwagon
Socio de bronce - InSales