<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mié., 4 mar. 2020 a las 1:09, Jesus Cea (<<a href="mailto:jcea@jcea.es">jcea@jcea.es</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">La reflexión me parece perfecta y la mando aunque sea algo offtopic<br>
porque me parece de valor:<br>
<br>
<a href="https://tech.slashdot.org/comments.pl?sid=15887404&cid=59789568" rel="noreferrer" target="_blank">https://tech.slashdot.org/comments.pl?sid=15887404&cid=59789568</a><br>
<br></blockquote><div><br></div><div>Y python es un gran ejemplo de herramienta para hacer bloatware de forma rápida. Algunos ejemplos que me he encontrado:</div><div><br></div><div>"Es tontería usar hilos por el GIL, así que hacemos todo con procesos y nos evitamos problemas de thread safety". Un proyecto que efectivamente no era thread safe y había crecido a 120 módulos/procesos de 60Mb cada uno (haced el cálculo de RAM). Una máquina de 1 core normalito y 512Mb de RAM sobraba para la versión thread-safe con hilos de todos esos módulos que seguían creciendo en número.</div><div><br></div><div>"Las imágenes python de docker son demasiado grandes, migraremos a XXX lenguaje compilado". Si, es un problema real. Python lleva un montón de baterías incluidas, con un montón de librerías asociadas y te vas a tener que comer el intérprete de python para ejecutar tu código; pero solo en un layer compartido por todas tus imágenes con ese runtime de python. Otra cuestión es que necesites 20 build dependencies en la imagen final porque no te has molestado en separarlas de las runtime dependencies. Montar un sistema de CI que guarde paquetes binarios en un mirror de pypi es demasiado complejo a corto plazo, aunque luego en cada build ahorres tiempo y espacio en disco.<br></div><div><br></div><div>"Python es lento, así que es normal que la aplicación vaya lenta". Vale, antes con los disco rígidos daba igual si programabas en python o en assembler, estabas esperando a los datos igual. Ahora con los discos nve un par de órdenes de magnitud más rápidos se nota más la diferencia entre un lenguaje rápido y lento. Pero gran parte del código python que usamos llama a librerias en C y python es un mero lenguaje de pegamento. Muchas veces no se hace un profiling (amo py-spy y snakeviz) para ver que evitando el problema de queries N+1 a bbdd, metiendo un par de índices en la BBDD, usando re.compile (o sacándolo de ese bucle donde está metido) y haciendo un par de cambios tontos ya no hay problemas de lentitud. Otras veces hay que rediseñar la arquitectura de la aplicación o cambiar algún algoritmo o generar un paquete en c para algo muy simple que se usa mucho o... y python, aun siendo más lento, deja de ser lento.<br></div><div><br></div><div>Seguro que a alguien se le ocurren otras escusas en las que se culpa a alguna característica de python como causa erronea del bloatware generado. Seguro que alguno más conoce más ejemplos de estos y de como evitarlos aprendiendo un poquito más de python.</div><div><br></div><div>Un saludo,</div><div><br></div><div>Javi<br></div></div></div>