El creador de C++ rebate la advertencia de la Casa Blanca

Seguridad de C++ vs. directrices

• Muchos sostienen que C++ sigue siendo fundamentalmente inseguro: las “directrices” de seguridad son opcionales, se aplican de forma desigual y son difíciles de adaptar al código existente.
• Otros dicen que C++ puede ser “lo bastante seguro” con una disciplina estricta: subconjuntos limitados de características, punteros inteligentes, semántica de valores, sanitizers, el máximo de advertencias y linters alineados con las directrices principales.
• Varios señalan que las funciones más nuevas (por ejemplo, string_view, iteradores) también son fáciles de usar mal y pueden introducir errores sutiles de ciclo de vida.

Debates de rendimiento (C++ frente a otros)

• Un sector afirma que Java moderno y otros lenguajes gestionados a menudo igualan o superan el rendimiento “del mundo real” de C++, especialmente cuando los proyectos típicos en C++ carecen de configuraciones avanzadas de compilación/optimización (PGO, LTO, etc.).
• Los opositores replican que los ámbitos de alto rendimiento (IA/ML, HPC, cargas de trabajo GPU) dependen abrumadoramente de C/C++, y que las restricciones de Java/GC lo hacen inadecuado en esos extremos.
• Algunos subrayan que C++ solo gana de forma fiable cuando expertos gestionan de manera agresiva el diseño de memoria, la asignación y el comportamiento de la caché: un esfuerzo que la mayoría de las bases de código nunca ve.

Bases de código C++ del mundo real

• Se hace una distinción entre el “C++ moderno idealizado” y el código desordenado, heredado y de estilo mixto que domina la industria.
• Los sistemas antiguos de la era C++03 se consideran especialmente difíciles de evolucionar con seguridad; unas pocas empresas de élite lo consiguen, pero muchas otras han fracasado o han migrado.
• Incluso en código “moderno”, quienes contribuyen reportan fallos por peculiaridades de la biblioteca estándar, invalidación de iteradores y UB sutil que el compilador no detecta.

Rust y alternativas seguras para la memoria

• Muchos ven Rust (y en menor medida Go, Java, Swift, etc.) como claramente más seguro por construcción, eliminando grandes clases de errores de memoria.
• Otros argumentan que la brecha de seguridad entre un C++ bien escrito y Rust es pequeña, enfatizando los propios bloques unsafe de Rust y su dependencia de bibliotecas C.
• Se plantean preocupaciones sobre el “coloring” asíncrono de Rust, la madurez del ecosistema y el uso intensivo de crates de terceros (riesgos de cadena de suministro y complejidad).

Orientación gubernamental y respuesta

• Algunos ven el impulso de la Casa Blanca para alejarse de C/C++ como un reconocimiento tardío de que décadas de problemas de seguridad de memoria muestran que el lenguaje en sí es un problema central.
• Otros enfatizan el pragmatismo: C++ está profundamente arraigado (SO, navegadores, robótica, finanzas, embebidos), no puede simplemente abandonarse y debe hacerse más seguro mediante herramientas y perfiles.
• Existe escepticismo sobre que las propuestas de seguridad en curso para C++ (perfiles, “C++ v2”) lleguen o se adopten lo bastante rápido frente a simplemente elegir Rust u otros lenguajes más seguros para proyectos nuevos.