Se usa bastante asyncio... sirve bastante bien... tiene la limitación de que la cancelación de tareas es edge-triggered (no level-triggered), pero en realidad no es tan común escribir código que sea consciente de la cancelación de tareas y lo maneje de forma elegante; más bien, el problema más grande es que el event loop mantiene referencias débiles a las tareas, así que pueden desaparecer por el GC... pero eso se resuelve con structured concurrency.
Para casi cualquier trabajo importante relacionado con I/O no hay problema para encontrar librerías con soporte para asyncio...
¿El GIL? No tiene mucho que ver... de por sí, la idea de usar asyncio para paralelizar trabajo intensivo de CPU es algo rara... si el GIL mejora, entonces sí será útil para multithreading intensivo de CPU... async se trata de aprovechar al máximo los tramos con cuello de botella de I/O...
En fin, la conclusión... aunque hay algunos problemas de diseño, lo estamos usando bien en producción sin mayores inconvenientes para cumplir el objetivo.
Por supuesto, una razón más importante podría ser que, debido al GIL, el beneficio que se puede obtener desde un principio es menor en comparación con otros entornos.
Creo que decir que, sin el GIL, se podría generar sinergia es casi engañoso. Si a un corredor al que le falta una pierna le pones una prótesis para que, aunque sea con incomodidad, pueda correr, ¿eso es "sinergia"?
El problema de asyncio no es la dificultad de la programación asíncrona, sino su baja calidad. Un diseño que tira por la borda la consistencia y la universalidad no es algo raro en Python, pero cosas como ProactorEventLoop todavía tienen bugs que provocan caídas del servicio y que fueron reportados hace 5 años.
Para quienes estamos obligados a usarlo, es bastante difícil tomarse a la ligera un texto como este.
Es difícil generalizar, pero en general, muchas personas en roles de PO, PM y diseño parecían tener la perspectiva de que los avances de la IA han abierto más oportunidades para quienes trabajan como PO y PM.
En cambio, muchos desarrolladores parecían esperar que, gracias a los avances de la IA, puedan desarrollar productos mejor por su cuenta, sin necesidad de PO, PM ni diseñadores.
Habrá que ver cómo evoluciona esto en adelante jaja
Es libre de odiarlo, pero el autor también está viviendo en la era de la IA. Es probable que este texto del autor ya haya sido recopilado en los macrodatos de la IA.
¿Cuál es el criterio para decir si algo es malo o bueno? Incluso expresiones como “tonto útil” existen porque tienen un contexto adecuado para usarse. No te confundas pensando que este mundo está rebosando de un amor color de rosa.
Si algo me resultaba incómodo, era el concepto mismo de variables/funciones en PHP; nunca me ha molestado en absoluto la notación con $.
¿No eran más bien bromas esos comentarios de que no se puede usar por culpa del signo de dólar, ~~que los que usan el signo de dólar ganan mucho dinero, que no es dólar estadounidense sino dólar zimbabuense y por eso no ganan tanto~~...?
Aunque con Node.js y Rust, bueno...;; en mi caso, como en PHP se sigue usando $ y cosas así, siento que debe ser incómodo escribir código. ¿La gente que lo usa bien no suele sentir tanta incomodidad?
Se propuso vAttention para complementar las limitaciones de gestión de memoria de PagedAttention.
El artículo relacionado puede consultarse aquí: https://arxiv.org/pdf/2405.04437
Pensándolo un poco, si funcionara así como aquí, también da la impresión de que esto es algo para lo que realmente hace falta una persona.
Da la sensación de que quizá un Product Engineer con IA podría hacerlo.
Se usa bastante
asyncio... sirve bastante bien... tiene la limitación de que la cancelación de tareas es edge-triggered (no level-triggered), pero en realidad no es tan común escribir código que sea consciente de la cancelación de tareas y lo maneje de forma elegante; más bien, el problema más grande es que el event loop mantiene referencias débiles a las tareas, así que pueden desaparecer por el GC... pero eso se resuelve con structured concurrency.Para casi cualquier trabajo importante relacionado con I/O no hay problema para encontrar librerías con soporte para
asyncio...¿El GIL? No tiene mucho que ver... de por sí, la idea de usar
asynciopara paralelizar trabajo intensivo de CPU es algo rara... si el GIL mejora, entonces sí será útil para multithreading intensivo de CPU... async se trata de aprovechar al máximo los tramos con cuello de botella de I/O...En fin, la conclusión... aunque hay algunos problemas de diseño, lo estamos usando bien en producción sin mayores inconvenientes para cumplir el objetivo.
Por más que haya sido un ataque MITM, ¿cómo lograron descifrar la comunicación HTTPS? ¿Soy el único que no lo sabía?
Me pregunto qué tan rápido será en comparación con Biome.
Yo solo usaré joblib.
Por supuesto, una razón más importante podría ser que, debido al GIL, el beneficio que se puede obtener desde un principio es menor en comparación con otros entornos.
Creo que decir que, sin el GIL, se podría generar sinergia es casi engañoso. Si a un corredor al que le falta una pierna le pones una prótesis para que, aunque sea con incomodidad, pueda correr, ¿eso es "sinergia"?
De los lugares donde se describe el tema relacionado, este es el documento mejor organizado.
El problema de
asynciono es la dificultad de la programación asíncrona, sino su baja calidad. Un diseño que tira por la borda la consistencia y la universalidad no es algo raro en Python, pero cosas comoProactorEventLooptodavía tienen bugs que provocan caídas del servicio y que fueron reportados hace 5 años.Para quienes estamos obligados a usarlo, es bastante difícil tomarse a la ligera un texto como este.
Es difícil generalizar, pero en general, muchas personas en roles de PO, PM y diseño parecían tener la perspectiva de que los avances de la IA han abierto más oportunidades para quienes trabajan como PO y PM.
En cambio, muchos desarrolladores parecían esperar que, gracias a los avances de la IA, puedan desarrollar productos mejor por su cuenta, sin necesidad de PO, PM ni diseñadores.
Habrá que ver cómo evoluciona esto en adelante jaja
Parece que se está volviendo algo parecido a cómo ha ido cambiando JavaScript.
Es libre de odiarlo, pero el autor también está viviendo en la era de la IA. Es probable que este texto del autor ya haya sido recopilado en los macrodatos de la IA.
Es bien sabido que AI Overview no es muy confiable, pero esto ya es bastante grave.
¿Cuál es el criterio para decir si algo es malo o bueno? Incluso expresiones como “tonto útil” existen porque tienen un contexto adecuado para usarse. No te confundas pensando que este mundo está rebosando de un amor color de rosa.
Si algo me resultaba incómodo, era el concepto mismo de variables/funciones en PHP; nunca me ha molestado en absoluto la notación con
$.¿No eran más bien bromas esos comentarios de que no se puede usar por culpa del signo de dólar, ~~que los que usan el signo de dólar ganan mucho dinero, que no es dólar estadounidense sino dólar zimbabuense y por eso no ganan tanto~~...?
Esto amerita una demanda, ¿no...?
Aunque con Node.js y Rust, bueno...;; en mi caso, como en PHP se sigue usando
$y cosas así, siento que debe ser incómodo escribir código. ¿La gente que lo usa bien no suele sentir tanta incomodidad?Se propuso vAttention para complementar las limitaciones de gestión de memoria de PagedAttention.
El artículo relacionado puede consultarse aquí: https://arxiv.org/pdf/2405.04437
Pensándolo un poco, si funcionara así como aquí, también da la impresión de que esto es algo para lo que realmente hace falta una persona.
Da la sensación de que quizá un Product Engineer con IA podría hacerlo.
¿Dónde comenzó ese exceso de autoconciencia que cree que los humanos son especiales?
Creo que Namuwiki no es una fuente adecuada.
Qué pena..