Superficialmente, la cantidad de líneas de código (LOC) también importa. En términos de productividad, no es lo mismo leer y entender una página que leer y entender 3 líneas.
Claro, yo también uso asyncio hasta el cansancio en producción, pero la experiencia de uso actual no me deja lo suficientemente satisfecho como para decir que "lo estoy aprovechando bien".
El asyncio actual está diseñado asumiendo el GIL y, visto de algún modo, es una estrategia para esquivarlo, así que el GIL no interactúa directamente con asyncio.
Pero, si lo vemos desde la perspectiva de toda la programación concurrente que funciona sobre asyncio, creo que decir que el GIL no tiene relación termina sonando como “como es Python, es obvio que no se puede”.
Estoy de acuerdo en que no podemos esperar que la dirección actual respecto al GIL llegue a ser tan buena como para no quedar en desventaja frente a "otras alternativas".
Pero decir que hay que adoptar otra alternativa en lugar de Python no debería llevar a un tono de que no hay problema, sino más bien a un tono de que sí hay un problema.
Esta vez, solo por interés personal, probé hacer desarrollo web, un área totalmente distinta de la que originalmente desarrollaba. Hice un foro con next.js v15 app router, pero cada vez que veo textos así... siento que se me van las ganas de probar algo nuevo del lado web. ¿Por qué el ecosistema es tan inestable? ¿Y luego cuando salga otra cosa nueva todos van a correr en masa hacia allá, la van a usar un poco y después la van a criticar mientras buscan otra cosa? El desarrollo web sí que debe ser difícil.
El poder y el dinero sí son lo que impulsa a mantener los proyectos.
No hay forma de evitar suspirar cada vez que veo una página web que no funciona correctamente si no es con Chromium.
Sinceramente... probablemente no haya otra empresa aparte de Google que pueda mantener Chrome más o menos a este nivel. Además, aunque no sea tanto como en los semiconductores, el dominio del mercado de navegadores web también es un área que EE. UU. no querrá ceder.... Creo que seguirá permitiendo cierto grado de monopolio.
No está explícitamente indicado con claridad en el texto principal, pero ¿podría significar también que cuando el código se escribe con IA, al resultar menos familiar en comparación con el escrito directamente por una persona, termina convirtiéndose en deuda?
Vaya, yo también era usuario de pago jaja
Revisando el historial de la App Store, veo que pasó a ser gratis desde la versión 1.51.
Para mí es una herramienta indispensable porque la configuración del monitor de mi MacBook cambia según el lugar donde la use.
Siento que lo del GIL sale un poco de la nada... Incluso si se elimina el GIL,
si quieres usar multithreading tanto en casos I/O bound como CPU bound,
quizás sería mejor adoptar otra alternativa que no sea Python...
También me da la impresión de que a quienes se meten a fondo con Python no les gusta mucho asyncio.
Creo haber escuchado seguido la opinión de que gevent debería haberse vuelto la opción principal.
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.
Gracias.
https://github.com/kelseyhightower/nocode
Superficialmente, la cantidad de líneas de código (LOC) también importa. En términos de productividad, no es lo mismo leer y entender una página que leer y entender 3 líneas.
Claro, yo también uso
asynciohasta el cansancio en producción, pero la experiencia de uso actual no me deja lo suficientemente satisfecho como para decir que "lo estoy aprovechando bien".El
asyncioactual está diseñado asumiendo el GIL y, visto de algún modo, es una estrategia para esquivarlo, así que el GIL no interactúa directamente conasyncio.Pero, si lo vemos desde la perspectiva de toda la programación concurrente que funciona sobre
asyncio, creo que decir que el GIL no tiene relación termina sonando como “como es Python, es obvio que no se puede”.Estoy de acuerdo en que no podemos esperar que la dirección actual respecto al GIL llegue a ser tan buena como para no quedar en desventaja frente a "otras alternativas".
Pero decir que hay que adoptar otra alternativa en lugar de Python no debería llevar a un tono de que no hay problema, sino más bien a un tono de que sí hay un problema.
Esta vez, solo por interés personal, probé hacer desarrollo web, un área totalmente distinta de la que originalmente desarrollaba. Hice un foro con next.js v15 app router, pero cada vez que veo textos así... siento que se me van las ganas de probar algo nuevo del lado web. ¿Por qué el ecosistema es tan inestable? ¿Y luego cuando salga otra cosa nueva todos van a correr en masa hacia allá, la van a usar un poco y después la van a criticar mientras buscan otra cosa? El desarrollo web sí que debe ser difícil.
El poder y el dinero sí son lo que impulsa a mantener los proyectos.
No hay forma de evitar suspirar cada vez que veo una página web que no funciona correctamente si no es con Chromium.
Sinceramente... probablemente no haya otra empresa aparte de Google que pueda mantener Chrome más o menos a este nivel. Además, aunque no sea tanto como en los semiconductores, el dominio del mercado de navegadores web también es un área que EE. UU. no querrá ceder.... Creo que seguirá permitiendo cierto grado de monopolio.
Lo confirmé tarde.
¡Muchas gracias por tu respuesta tan detallada!
Aunque se sienta incómodo, ¿no te acostumbras rápido después de usarlo un tiempo?
Los seres humanos somos animales de adaptación.
No está explícitamente indicado con claridad en el texto principal, pero ¿podría significar también que cuando el código se escribe con IA, al resultar menos familiar en comparación con el escrito directamente por una persona, termina convirtiéndose en deuda?
Vaya, yo también era usuario de pago jaja
Revisando el historial de la App Store, veo que pasó a ser gratis desde la versión 1.51.
Para mí es una herramienta indispensable porque la configuración del monitor de mi MacBook cambia según el lugar donde la use.
No es como si estuvieras escribiendo un artículo académico, pero bueno...
Siento que lo del GIL sale un poco de la nada... Incluso si se elimina el GIL,
si quieres usar multithreading tanto en casos I/O bound como CPU bound,
quizás sería mejor adoptar otra alternativa que no sea Python...
También me da la impresión de que a quienes se meten a fondo con Python no les gusta mucho
asyncio.Creo haber escuchado seguido la opinión de que
geventdebería haberse vuelto la opción principal.Gracias por presentar una buena app.
Lo escribí adicionalmente.
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.