El por qué de mi rechazo técnico visceral e innegociable a Python.

El por qué de mi rechazo técnico visceral e innegociable a Python.

Quiero que quede claro de entrada, porque se puede llegar a malinterpretar, mi punto de vista: mi rechazo a Python no es filosófico.
A este nivel, Python es una idea excelente: un lenguaje accesible de alto nivel, legible, bastante sencillo, que le abre la puerta a que cualquiera (un pibe, un docente, un biólogo, un aficionado) pueda escribir su primer programa y contribuir. Eso está bien. Eso está, en realidad, mucho más que "bien": la democratización de la posibilidad de programar es algo que celebro sin reservas. El problema no es la idea. El problema es la ejecución, y de buenas ideas mal llevadas a cabo está lleno el mundo.

A nivel técnico, Python es un desastre, y lo es por razones concretas, medibles, demostrables, no por gusto ni por apego ni pertenencia a otra parroquia.
Primero: es lerdo y tosco. Es un intérprete lento por diseño, que para hacer cualquier cosa seria termina llamando a librerías escritas en C -porque el propio Python no da la talla- y encima se cuelga de un árbol de dependencias monstruoso para lograrlo. Estamos hablando de cientos de miles de paquetes para servir para algo. Y no es que Python sea el único que arrastra dependencias como un chancho arrastra barro: Rust hace exactamente lo mismo. Pero hay una diferencia que lo vuelve mucho peor.

Segundo, y esto es lo central: esas dependencias no solo son miles, sino que son inestables entre sí. Inestables respecto a su propio desarrollo, a su propio mantenimiento, y -lo más grave- respecto a los programas estables que pretenden manipular. Un paquete de Python se actualiza y rompe a otros 3. Una versión menor del intérprete deja obsoleto medio ecosistema. Un "binding" que funcionaba hasta ayer (o hasta hace 2 horas), ahora tira una "excepción" porque el proyecto de arriba movió una coma. Es un castillo de naipes en donde cada naipe está sostenido por otro que también se está cayendo, y un ejemplo de manual de algo concreto con lo que me tocó lidiar es con Selenium y Firefox. Tengo un proyecto hecho en Python, y la cantidad de veces que vi que esa yunta se rompía sola (no porque Firefox fallara, sino porque la capa de Python que pretendía manejarlo iba siempre atrasada, siempre desincronizada, siempre parcheándose para alcanzar a un objetivo que se movía), fue de mucho más que "mal gusto". Python, berretísimamente, pretende no solo manipular a un programa estable, sino que además no puede parar de romper el flujo de ejecución en el intento.
Este es mi proyecto en Python (BurocraTux), para que veas que sé muy bien de lo que hablo:

BurocraTux es un programa que automatiza el ingreso de clases en la plataforma SIGED de gestión educativa. Su objetivo es ahorrarte tiempo y evitar el burocrático y tedioso proceso de ingresar datos de forma manual, guiándote paso a paso a través de 11 preguntas simples. 

https://codeberg.org/entropiabinaria/BurocraTux

Y si querés un verdadero monumento al desastre, mirá el mundo OSINT. Paso por ahí bastante seguido. Sé bien de lo que está hecha la edición más pesada de BlackArch ( https://blackarch.org/index.html ).

Acá es en donde Python saca a relucir con burda meridianidad toda su mediocridad, siendo, increíblemente y contra todo pronóstico sensato el estándar de facto de la disciplina, y el resultado está a la vista: de 3000 paquetes andan 5. El resto está roto, sin mantener, abandonado, o pidiendo una combinación de versiones infernales de dependencias rotas, desactualizadas, o que ya no están mantenidas. ¿Por qué? No es casualidad ni mala suerte. Es porque son Python. No son C, no son Go, no son Pascal. Ni siquiera son Rust, otro lenguaje feo. Un binario en C compilado hace 15 años, todavía corre. Un programa en Go es un binario único, estático, autocontenido, que tirás en cualquier máquina y anda. Un Pascal es sólido como una roca, y dicen que más que C en algunos aspectos. Pero una herramienta OSINT en Python es una bomba de tiempo: la instalás y ya está podrida, porque el ecosistema de abajo se mueve en aguas no solo turbulentas sino inmanejables para una pila de tal pretensión. Y a la primera de cambio, esas aguas se llevan todo puesto. A los 10 minutos, al otro día, a la semana, o al poco tiempo. Toda una disciplina entera -una que depende de que las herramientas FUNCIONEN BIEN (COMO TODO PROGRAMA CONSTRUÍDO EN BASE SÓLIDA), cuando las necesitás- parada sobre el barro movedizo de un lenguaje pantanoso que no garantiza que lo de ayer siga andando mañana.

Eso es lo que me genera "vómito intracraneal". No es el hecho de que "exista": soy un defensor de las "existencias". ¡Todo debería existir, hasta las insanas tentaciones! De otro modo, ¿en dónde quedaría nuestra fuerza de espíritu y nuestro verdadero poder de elección? Tampoco es que la gente lo use. El tema es que sin merecerlo y sin ser bueno para el ecosistema informático, se haya vuelto un ESTÁNDAR de la industria, y esto también aplica a la cloaca digital infecta y promotora de piratería, adoctrinamiento corporativo y analfabetismo digital: Windows.
Python... Algo tan frágil, tan lento, tan poco confiable, que se enseña como la llave de entrada a la programación (así como erróneamente se ofrece el adefesio de Ubuntu "para arrancar con Linux"), que no puede garantizar estabilidad, que a su vez son las únicas propiedades más básicas que uno debe exigirle a cualquier herramienta seria... Un estándar debería ser lo más sólido, no lo más fácil de que reviente. Aunque sea difícil aprenderlo.

Y para terminar, permítaseme aterrizar todo esto sobre el ecosistema de CRUX Linux, en revientes de compilación concretos también sufridos en carne propia, porque no estoy hablando en abstracto: te estoy mostrando y evidenciando mucho más que "mis impresiones". Cuando el monorepo de GStreamer me reventó la compilación, ¿en qué lo hizo? ¿Adivinás justo dónde? En "py3cairo.h", un "binding" de Python que yo no pedí, para una función que yo no necesitaba, colado dentro de un paquete que debería ser C limpio, dentro de una estructura limpia y controlada que al inestable y sinvergüenza de Python le queda ENORME. Cuando libxml2 no compilaba, ¿por qué era? Porque su binding de Python exigía "doxygen", y me obligó a escribir toda una función (asegurar_libxml2_python) para tapar un agujero que Python metió impunemente donde era mejor quedarse quietito y no tocar nada. En un instalador de CRUX -insisto, una distro cuya alma es la simplicidad, el código fuente limpio, el control total y absoluto en manos del usuario, el "compilá y entendé lo tuyo"- Python aparece de parásito, arrastrando su mugrienta y fétida cola de dependencias inestables, para romper builds que sin él funcionarían, y mucho mejor. No es una molestia teórica. Es la causa raíz, con nombre y archivo, de horas de trabajo perdidas en proyectos en los cuales es el programador el que da la cara ante cualquier fallo, no "Python".

Por eso no entra en mi stack. Ni Python, ni su lógica. Lo pesado lo hago en Go -binario único, estático, sin runtime que arrastrar, porque probé a hacerlo en Rust y la verdad, en materia de dependencias es un "Python mejorado"- y la orquestación de todo en BASH, que corre hoy, corría hace 15 años y va a seguir corriendo en 15 años más. No es dogma. Es haber aprendido, a los golpes, quién se banca firme el invierno como milico a la intemperie y quién se engripa con la primera lluvia de verano.

Si me querés hacer la vida más fácil, solo no me preguntes por qué no me gusta Python, y en lugar de eso, leeme. Acá está gran parte de mi justificación. Quiero que esto quede como manifiesto.