A pesar de la gran cantidad de materiales sobre el tema de la optimización de monolitos, a menudo quiero alejarme del estudio profundo del problema e intentar adivinar cómo hacer que la aplicación sea más rápida o más compacta. La buena noticia: el principio de Pareto funciona aquí. En la conferencia de
RubyRussia el 28 de septiembre,
Julian Pokrovsky hablará sobre las técnicas necesarias. Un par de teasers estarán en esta entrevista con Julian y
Grigory Petrov .
¿Qué haces en el mundo de TI, Ruby, tus intereses, experiencia?Yo trabajo en Cupill. En el proyecto, escribí en Ruby y en el backend de Rust para buscar, reservar y comprar boletos de avión. Estoy interesado en una amplia gama de lo que está sucediendo en TI: desde compiladores hasta sistemas distribuidos. No estoy realmente interesado en el aprendizaje automático y el front-end, pero tal vez algún día yo también llegue allí.
¿De qué trata tu informe?Contaré sobre nuestra experiencia en la optimización de un monolito de 8 años y mostraré que es muy simple y beneficioso para todos. Y existe la oportunidad de asignar tiempo para esto en el sprint. Puede obtener un aumento de rendimiento mirando solo algunos trucos y herramientas simples que no requieren Rails y que son adecuados no solo para una aplicación web. Te contaré sobre los materiales que nos guiaron para resolver nuestros problemas. Veamos stackprof, rbspy, heapy, y también por qué los cambios triviales en la configuración del sistema operativo, el cambio del asignador, pueden traer beneficios increíbles. ¿Y por qué es malo aplicar consejos de Internet sin tomar medidas en su aplicación?
Existe una leyenda tan urbana que si comparamos los lenguajes de los Cuatro Grandes (Ruby, Python, JavaScript y PHP), en primer lugar tenemos JS, porque aguardan y jit, en el segundo PHP, Python y Ruby toman el honorable 4to. lugar ¿Qué dices, es así?No me inclino a negar que Ruby no funciona bien en muchos puntos de referencia. Pero definitivamente no es correcto decir que en cualquier situación estará en el último lugar. En términos más generales, Ruby es un estándar de lenguaje. Podemos hablar sobre TruffleRuby, sobre JRuby, sobre MRI, sobre problemas de rendimiento. Estas son cosas muy individuales. Todo depende de cómo escribió el código y de lo que quería obtener. En algunos casos, Ruby será más rápido que nadie, en algunos Python, no sin razón es popular en ciencia de datos, a veces JavaScript será el más rápido.
¿En qué medida el ecosistema de Ruby ahora ofrece formas rápidas y nativas para resolver problemas populares?Puedo interpretar la pregunta de manera diferente. Puedes hablar sobre cómo están las cosas con las extensiones C en Ruby ahora mismo. Si reducimos la pregunta a esto, entonces todos sabemos: OJ para la serialización JSON, PostgreSQL Driver, Ruby Driver para MySQL y muchas otras cosas están escritas en C. La pregunta es qué tan bueno o malo es para mí personalmente. Para que los compiladores jit, que pueden ser el futuro de Ruby, optimicen bien el código, necesitamos escribir más en Ruby y usar menos extensiones. Para que el compilador pueda hacer esto. TruffleRuby tiene un enfoque diferente a esto. Por lo que recuerdo, te permite hacer una optimización entre diferentes idiomas, por lo tanto, se llama polyglot vm. Nuevamente, cuán exitosamente hace esto, no estoy listo para decirlo. Y TruffleRuby en sí sigue siendo un proyecto bastante joven.
¿Qué avances hay en el mundo Ruby para la programación asincrónica?En mi opinión, no se ha producido un movimiento de masas reciente hacia Ruby asincrónico. Hay algunos proyectos separados: tanto el proyecto probado EventMachine como el proyecto Sam Williams,
asíncrono , o más bien todo un grupo de proyectos en los que se realiza una nueva implementación asincrónica sobre la base de
nio4r , que es más simple que EventMachine o Celluloid. Pero, en general, la historia, aunque no se detiene, camina en un pequeño círculo. Y hasta ahora nada ha ido más allá. Veamos que pasa después.
Todavía veo mucho uso concurrente basado en hilos de rubí. Esta no es una opción tan mala para un lenguaje con un tiempo de ejecución moderadamente productivo: utilice secuencias que liberen GVL (bloqueo global) y le permitan realizar solicitudes HTTP paralelas u otras operaciones de E / S al mismo tiempo. Tal vez la fibra en el futuro sea más popular. Ahora formaron la base de la biblioteca del grupo de efectos secos y secos. Esto solo le permite hacer algunas operaciones paralelas basadas en fibra. No sincrónicamente, pero no completamente asincrónicamente, ya medio asincrónico.
Matsumoto-san, el autor de Ruby, vuela a la conferencia. ¿Qué crees que sería interesante para ti discutir con él mientras tomas una taza de café o un vaso de sake en la fiesta?Ya vi a Matsumoto en Moscú en 2016. Recuerdo que luego dijo que si la conferencia continúa llamándose RailsClub, no volvería otra vez.
Sí, y pasó a llamarse RubyRussia, este es un nombre más amplio. Y nos está visitando de nuevo.Entonces pensé quién ganaría, él o RailsClub. Matsumoto derrotado. Preguntaría cómo logró plantear la pregunta de tal manera que cambiaron el nombre del evento Ruby más grande en Rusia.
Creo que tendrá todas las oportunidades para hacer esta pregunta personalmente. ¿Cuál es el futuro de Ruby? ¿Qué te falta en lenguaje, ecosistema?Predecir el destino de un lenguaje de programación es una tarea ingrata, porque hasta ahora nadie ha adivinado cómo se desarrollarán los eventos para cualquier lenguaje. Podría estar equivocado, pero Ruby no es la opción más popular para nuevos proyectos en este momento. Muchos han escuchado "Ruby está muerto, pero Rails está en desuso": es lento, no asíncrono, no es paralelo y tiene muchos problemas. ¿Afecta esto el número de nuevos proyectos de Ruby? En mi opinión, definitivamente sí. Se están volviendo más pequeños y se volverán aún más pequeños. Pero los viejos proyectos permanecen. En mi opinión, de esta manera Ruby necesita herramientas para soportar aplicaciones complejas y masivas. En tales situaciones, es una buena idea mirar adiciones como el sistema de tipos. Muchas personas prefieren admitir aplicaciones grandes y desarrollarlas, como podemos ver en JavaScript con Flow y TypeScript, hacia la escritura, lo que facilita un poco la refactorización y el monitoreo de una situación en un proyecto complejo. Quizás necesite crear un ecosistema más rico de bibliotecas que necesite usar de forma independiente, como dry-rb. Donde una persona puede elegir lo que necesita validar, qué construir efectos en algún subsistema. Quizás necesite
contenedores de inyección de dependencia que resuelvan ciertos problemas. El ecosistema debería moverse en esta dirección. En la dirección del desarrollo empresarial y el soporte de sistemas grandes y complejos.
Discutir en RubyRussia!Ven y tú, el
registro aún
está abierto.
No solo habrá informes, sino también puestos de empresas geniales:
Organizador -
EvroneSocio general -
ToptalGold Partner -
GettSocios de plata:
Valarm ,
JetBrains ,
Bookmate y
CashwagonSocio de bronce -
InSales