Los asesinos de C++ (No tú, Rust)

Evolución de C++, ABI y estandarización

• Varios comentarios sostienen que el comité de C++ está limitado por una fuerte postura de “no romper la ABI”, lo que bloquea mejoras de rendimiento y de bibliotecas (por ejemplo, tipos std, cambios en intmax_t).
• Otros señalan que el estándar no define una ABI, pero reconocen que el comité ha votado explícitamente evitar rupturas de ABI y que las propuestas a menudo se rechazan por ese motivo.
• Este conservadurismo se contrasta con cambios que sí rompen compatibilidad, como el paso de los literales UTF‑8 a char8_t en C++20, obligando a los compiladores a añadir opciones para desactivarlo.

Seguridad, lenguajes con “correa” y gestión de memoria

• Un sector ve lenguajes más nuevos (Rust, Go, etc.) como valiosos precisamente porque restringen el comportamiento inseguro y reducen la carga cognitiva y clases de errores (especialmente seguridad de memoria y seguridad informática).
• Los críticos argumentan que estos lenguajes sobrelimitAN a los desarrolladores, reducen la expresividad y representan garantías estáticas “autoritarias”; los defensores responden que no son más que una aplicación automatizada de buenas prácticas ampliamente aceptadas, con salidas de emergencia explícitas.
• Se debate si el C++ moderno ya desalienta la gestión manual de memoria mediante RAII y punteros inteligentes; algunos dicen que aún deja demasiados puntos peligrosos en comparación con el modelo de seguridad por defecto de Rust.

Simplicidad frente a expresividad

• Algunos afirman que los lenguajes más simples son intrínsecamente mejores; otros replican que “simple” es un término mal definido y que a menudo solo traslada la carga a los programadores.
• Se comparan ejemplos (C, Lisp, Python, Rust, C++) para argumentar que “menos expresivo” a menudo se confunde con “más simple”, y que la complejidad oculta (UB, reglas implícitas) hace que C sea menos simple de lo que parece.

El papel de C++ y sus perspectivas a largo plazo

• Varios comentarios presentan C++ como un “lenguaje de último recurso” para dominios bare‑metal, embebidos y de alto rendimiento, mientras que lenguajes de nivel más alto se imponen en interfaces gráficas, aplicaciones de escritorio y sistemas en la nube.
• Algunos esperan que Rust y otros lenguajes de sistemas de nicho vayan recortando terreno a C++ en áreas críticas para el rendimiento, pero creen que C/C++ seguirá profundamente arraigado durante décadas debido al código existente y a los ecosistemas ya establecidos.

Comportamiento indefinido y minucias

• La discusión toca miembros no inicializados, reglas de promoción de enteros (ejemplo de aritmética con uint16_t) y lo fácil que es introducir UB en C/C++.
• Los participantes discrepan sobre si dominar esas minucias es motivo de orgullo porque permite un control preciso, o una carga innecesaria que perjudica la calidad general del software.

Notas técnicas específicas del artículo y temas laterales

• Los comentaristas señalan errores en ejemplos del artículo (expresión incorrecta con uint16_t, polinomio de seno ineficiente) y sugieren técnicas óptimas conocidas (Horner/Estrin).
• Breves menciones de herramientas y proyectos (Numba, Julia, Spiral, ForwardCom, lastre de memoria de Go) ilustran un interés más amplio en la optimización específica de dominios y en la generación de código consciente del hardware.