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

Artículo original ↗ Discusión en Hacker News ↗

Las afirmaciones de que los “asesinos de C++” como Rust no aportan una ventaja real abren un examen más amplio sobre qué intentan resolver los lenguajes de sistemas modernos: seguridad, mantenibilidad y adecuación al dominio frente a rendimiento bruto y compatibilidad hacia atrás. Los comentaristas discuten si el conjunto de características en evolución de C++ y la estabilidad de facto de su ABI son fortalezas o desventajas, especialmente dada su ubicua conducta indefinida y su dependencia del conocimiento experto. Muchos concluyen que, en lugar de un único sucesor, C++ está siendo desplazado gradualmente en los márgenes por lenguajes y herramientas más especializados, mientras permanece arraigado en bases de código heredadas, embebidas y de alto rendimiento en el futuro previsible.

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.