C frente a Rust, Zig y C++

Las comparaciones de lenguajes suelen ser tribales e inútiles porque comparan sintaxis. La comparación que sirve mide otra cosa: dónde vive la seguridad, cuánto cuesta la complejidad, qué garantiza el ecosistema y quién define la frontera binaria. Medido así, la posición de C en 2026 es a la vez más débil y más sólida de lo que sugiere el ruido.

Los cuatro ejes que importan

Cualquier comparación seria se reduce a cuatro preguntas. Todo lo demás es preferencia personal.

Léelo con cuidado: ningún lenguaje gana los cuatro ejes, y los dos primeros están en tensión directa. Rust obtiene su garantía introduciendo un sistema de tipos que expresa propiedad y tiempos de vida; ese sistema es exactamente el origen de su complejidad. C conserva su simplicidad renunciando a la garantía. No es una contradicción de nadie: es la relación de canje que define este espacio de diseño.

El cuarto eje es el que más gente pasa por alto y el que más decisiones condiciona en la práctica. Una frontera binaria estable significa que puedes publicar una biblioteca compilada, que otro la enlace años después con otro compilador y que siga funcionando. C lo garantiza porque su modelo de tipos y su convención de llamada son la referencia de la plataforma; los demás lo consiguen únicamente cuando aceptan expresarse en ese vocabulario.

Conviene además desactivar dos falacias que contaminan casi todas estas discusiones. La primera es comparar rendimiento: los cuatro lenguajes compilan a código nativo con optimizadores maduros y las diferencias reales dependen mucho más del algoritmo, del acceso a memoria y del diseño de datos que del lenguaje. La segunda es confundir seguridad de memoria con seguridad a secas: un programa en Rust puede tener errores lógicos, filtrar datos o bloquearse; lo que elimina es una familia concreta de fallos, que resulta ser la que domina las vulnerabilidades explotables de forma remota.

Rust: la alternativa que sí cambió el terreno

Rust es la única de las tres que ofrece algo cualitativamente distinto y no una versión mejorada de lo mismo. Su sistema de propiedad y préstamos verifica en tiempo de compilación la ausencia de uso después de liberar, de doble liberación y de carreras de datos, sin recolector de basura y con un rendimiento comparable. Eso no es una mejora incremental: elimina por construcción la familia de fallos que domina las estadísticas de vulnerabilidades graves.

En 2026 esa posición está institucionalizada: hay controladores de Rust en el núcleo de Linux, componentes de sistema en las principales plataformas de escritorio y móvil, y recomendaciones explícitas de organismos de seguridad para migrar a lenguajes con seguridad de memoria en código nuevo expuesto a entradas no confiables.

Lo que de verdad cambia es dónde vive la invariante. Observa el mismo error escrito en los dos lenguajes:

/* C: compila sin un solo aviso y el error aparece en tiempo de ejecucion */
char *construir(void)
{
    char buf[64];
    snprintf(buf, sizeof buf, "hola");
    return buf;              /* devuelve un puntero a memoria que ya no existe */
}

En C, la invariante que se viola —el objeto no debe sobrevivir a su ámbito— existe únicamente en la cabeza del programador; el compilador puede avisar en casos evidentes como este, pero deja de poder hacerlo en cuanto el puntero pasa por una estructura o por otra función. En Rust, la misma invariante está codificada en el tipo mediante tiempos de vida, y el programa sencillamente no compila. Esa es la diferencia entera, y es enorme.

Los costes reales, sin suavizar:

• Curva de aprendizaje pronunciada. El verificador de préstamos obliga a modelar los tiempos de vida explícitamente, y estructuras de datos triviales en C requieren un rediseño o un bloque no seguro.
• Las islas inseguras siguen ahí. Todo lo que toca hardware, memoria mapeada o interfaces externas vive en código no seguro, donde reaparecen exactamente las obligaciones de C.
• Sin frontera binaria propia. Rust no define una ABI estable; para exponer una biblioteca a terceros se serializa por la de C.
• Cobertura de arquitecturas y cualificación. Depende de una única infraestructura de compilación, y la cualificación para sectores críticos existe pero es mucho más joven que la de C.

De esos cuatro costes, el segundo es el que más se malinterpreta. Las islas de código no seguro no son un defecto de Rust ni una trampa: son el reconocimiento explícito de que alguien tiene que sostener las invariantes que el verificador no puede demostrar. Dentro de un bloque no seguro, el programador contrae exactamente las mismas obligaciones que en C —validez de punteros, ausencia de aliasing conflictivo, alineación correcta— con el agravante de que ahora debe además preservar las garantías del que el resto del programa depende. La diferencia decisiva es cuantitativa: en C esa zona es el programa entero, y en Rust está acotada, marcada y es auditable de forma dirigida.

Zig y C++: los otros dos vecinos

Zig no compite por la seguridad garantizada sino por la legibilidad del coste. Su propuesta es un C limpio: sin preprocesador, con metaprogramación mediante evaluación en tiempo de compilación, sin flujo de control oculto, con los asignadores pasados explícitamente como parámetro y con manejo de errores en el sistema de tipos. Su interoperabilidad con C es la mejor del mercado: puede compilar C directamente y funciona como cadena de compilación cruzada de una sola pieza, hasta el punto de que muchos proyectos en C lo usan solo por eso.

Su idea más exportable es el asignador explícito: en Zig ninguna función reserva memoria a tus espaldas, porque el asignador viaja como parámetro. Eso hace visible en la firma quién puede asignar y con qué política, algo que en C puedes adoptar hoy mismo sin cambiar de lenguaje:

/* El asignador como parametro: politica de memoria visible en la interfaz */
typedef struct {
    void *(*alloc)(void *ctx, size_t n);
    void  (*free)(void *ctx, void *p);
    void  *ctx;
} asignador;

/* El llamante decide si es el del sistema, uno de arena o uno de pool */
nodo *arbol_insertar(arbol *a, clave k, const asignador *al);

Ese patrón es el estándar de facto en motores, núcleos y sistemas embebidos, y resuelve en la práctica lo que a menudo se atribuye al lenguaje: hace auditable la gestión de memoria y permite sustituirla por completo en pruebas.

Los límites de Zig también son claros: sigue sin ser seguro en memoria —detecta bastante en tiempo de ejecución en los modos de depuración, pero no impide el uso después de liberar—, el lenguaje aún introduce cambios incompatibles entre versiones y su ecosistema de bibliotecas y de personal cualificado es una fracción del de los otros tres.

Conviene además deshacer un malentendido persistente antes de hablar del cuarto: C++ no es un superconjunto de C. Lo fue aproximadamente en los años ochenta y hace mucho que dejó de serlo. Hay programas válidos en C que C++ rechaza y otros que compila con significado distinto, y las dos normas evolucionan en comités separados con criterios propios. Tratar un fuente en C como si fuera C++ es una fuente clásica de sorpresas en proyectos mixtos.

C++ parte de otra estrategia: no reducir el poder de C sino envolverlo. La gestión de recursos ligada al ámbito, los punteros inteligentes, los contenedores y las plantillas eliminan en la práctica una gran parte de los errores manuales de memoria, y su ecosistema es enorme y maduro. Pero paga dos peajes serios: una complejidad que casi ningún equipo domina por completo —hasta el punto de que casi toda organización trabaja sobre un subconjunto acordado del lenguaje—, y no eliminar el comportamiento indefinido, que sigue exactamente donde estaba. Un iterador invalidado o una referencia colgante son tan indefinidos en C++ como en C, con la diferencia de que las capas de abstracción hacen más difícil ver dónde se produjo. A cambio, su frontera binaria es notoriamente frágil entre compiladores y versiones —el nombre decorado de un símbolo depende de la firma completa, de las plantillas y de la implementación de la biblioteca estándar—, razón por la cual las bibliotecas destinadas a ser consumidas por terceros siguen exponiendo interfaces en C.

flowchart TD
Q[Codigo nuevo de sistemas en 2026] --> A[Procesa entradas no confiables]
A -->|si| R[Preferir Rust]
A -->|no| B[Requiere arquitectura exotica o cadena cualificada]
B -->|si| C1[C sigue siendo la respuesta]
B -->|no| D[Debe ser consumido por otros lenguajes]
D -->|si| E[Interfaz publica en ABI de C]
D -->|no| F[Elegir por equipo y ecosistema]
style R fill:#a6e3a1,color:#11111b
style C1 fill:#89b4fa,color:#11111b
style E fill:#f9e2af,color:#11111b

Cuándo C sigue siendo la respuesta y cuándo ya no

A esas cuatro conviene añadir una quinta, de otro orden: aprender cómo funciona la máquina. Ningún otro lenguaje deja el mecanismo tan a la vista, y ese conocimiento se transfiere entero a los demás. Quien ha gestionado memoria a mano entiende por qué existe la propiedad; quien ha depurado un fallo de alineación entiende qué protege un tipo.

Ya no es la elección correcta cuando escribes código nuevo que analiza datos procedentes de la red o de un usuario; cuando el equipo es grande y rota, de modo que la corrección no puede depender de disciplina individual sostenida en el tiempo; cuando la concurrencia es intensa y con estado compartido; y cuando una vulnerabilidad de memoria tendría consecuencias existenciales para el producto o para sus usuarios.

En esos casos, insistir en C significa trasladar a la revisión humana de código un trabajo que un sistema de tipos hace gratis, exhaustivamente y sin cansarse. Y conviene decirlo sin rodeos: la evidencia acumulada por los grandes proyectos que han medido esta transición apunta en la misma dirección —la mayoría de las vulnerabilidades graves se concentran en el código nuevo, de modo que escribir lo nuevo en un lenguaje con seguridad de memoria reduce el riesgo mucho más rápido que reescribir lo viejo.