C++ Debería Ser C++

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

La rápida evolución de C++ y su creciente complejidad están polarizando a sus usuarios: algunos elogian los estándares modernos por hacer el lenguaje más expresivo y potente, mientras que otros los ven como barrocos, difíciles de aprender y complicados de adaptar a grandes bases de código heredadas. Los comentaristas discuten si C++ debería priorizar ser un lenguaje de sistemas de alto rendimiento, mejorar la ergonomía y la seguridad (posiblemente en respuesta a las expectativas y regulaciones emergentes sobre “seguridad de memoria”), o incluso aceptar que lenguajes más nuevos como Rust, Zig o Go pueden ser más adecuados para muchos dominios. Las carencias de tooling —especialmente en módulos, gestión de dependencias y reproducibilidad de builds— se consideran obstáculos prácticos importantes, independientemente de hacia dónde vaya el lenguaje.

Recepción del C++ moderno

  • Fuerte división: algunos consideran que C++20/23 supone un enorme salto en calidad de vida (p. ej., optional, expected, filesystem, structured bindings, inicialización en if/switch, lambdas) y disfrutan del “C++ moderno”.
  • Otros, especialmente usuarios de larga data, ven los estándares más recientes como barrocos y desagradables, y prefieren “C con clases” o un subconjunto muy pequeño.
  • Muchos desarrolladores, de facto, se limitan a un subconjunto específico de su proyecto, pero esto es más difícil en bases de código grandes y cuando nuevas características (p. ej., move semantics) introducen boilerplate o requisitos sutiles.

Herramientas, módulos y gestión de dependencias

  • Se percibe ampliamente como una debilidad importante: no hay un gestor de paquetes estándar, ni una historia integrada para dependencias, pruebas, logging, etc.
  • Los módulos se ven como prometedores, pero en la práctica inutilizables debido a un soporte desigual de compiladores y herramientas.
  • Se critica a vcpkg por comportamiento frágil, fuentes alteradas y versionado anclado a commits; se mencionan Bazel/Buck y Nix/Guix como respuestas parciales.
  • Algunos equipos recurren a comprobar toolchains en control de versiones o a hacer snapshots de máquinas virtuales.

Modelo de compilación y rendimiento

  • Los tiempos de compilación se consideran uno de los principales puntos dolorosos, a menudo con mayor prioridad que las nuevas funciones de seguridad.
  • Se discuten las causas: análisis repetido de headers, instanciación de templates por unidad de traducción, trabajo extra del linker para eliminar duplicados, y una gramática difícil; hay desacuerdo sobre cuál factor domina.
  • Las comparaciones con Go, Rust, Zig y C destacan cómo el modelo de preprocesado y compilación de C/C++ envejece mal, incluso con headers precompilados o módulos.

Seguridad de memoria, regulaciones y dirección del lenguaje

  • Hay desacuerdo sobre cuánto exigen realmente los usuarios de C++ la seguridad de memoria; algunos dicen que quienes se preocupan ya se han ido, otros sostienen que muchos la quieren pero no mediante herramientas adicionales de pago.
  • La seguridad “a medias” (opt-in, cobertura parcial, costo en tiempo de ejecución) se considera de beneficio limitado.
  • El hilo analiza la presión gubernamental (guías de NSA/CISA, próximas normas de EE. UU./UE) hacia lenguajes seguros en memoria; no hay prohibiciones directas, pero se espera presión en compras y papeleo.
  • Algunos ven el artículo como una reacción defensiva frente a Rust, que muchos consideran un sustituto creíble de C++ para trabajo de sistemas.

Biblioteca estándar, ergonomía y “zero-cost”

  • Hay quejas de que std carece de primitivas de alto rendimiento (allocators especializados, estructuras lock-free/wait-free, IPC, threading de alto rendimiento) y no está ajustada para cargas de trabajo de juegos/BBDD/sistemas operativos.
  • Otros argumentan que eso debe ir en bibliotecas externas y que ningún diseño genérico de alto rendimiento sirve para todas las cargas.
  • Se cuestiona el ideal de “abstracción zero-cost”; el flujo de control oculto (constructores, destructores, copias) y las excepciones pueden tener un costo real si se usan mal o no se optimizan bien.
  • Se ve que nuevas APIs como std::print son más engorrosas que los idioms antiguos (streams) para la personalización, reforzando la percepción de mala ergonomía.

Generalidad, legado y alternativas

  • Hay un debate amplio sobre si “usado por millones” prueba que C++ es un buen lenguaje de propósito general; algunos llaman a esto una falacia, otros dicen que el uso extendido en el mundo real a través de dominios es, de facto, evidencia de idoneidad.
  • El legado y la inercia se citan repetidamente: mucha gente escribe C++ solo porque el código anterior lo hacía; las enormes bases de código existentes hacen impracticables los cambios rompientes o las reescrituras completas.
  • Algunos sostienen que C++ debería redoblar su apuesta por ser el lenguaje de sistemas más rápido; otros piensan que su historia y complejidad lo hacen una mala opción para nuevos programadores frente a Rust o Go.
  • Se mencionan propuestas como Carbon, cppfront y “C con templates” como intentos de empezar de cero, pero existe escepticismo sobre la adopción y sobre la capacidad del comité para hacer cambios radicales y rompientes.