Dónde vive C en 2026

Preguntar si C sigue vivo es la pregunta equivocada. La pregunta correcta es qué capa del sistema ocupa, y la respuesta incomoda: C ya casi no es el lenguaje en el que se escriben aplicaciones, pero es el lenguaje en el que está escrito casi todo aquello sobre lo que se ejecutan las aplicaciones. Vive debajo, y debajo no se cambia con facilidad.

El sustrato: núcleos y sistemas operativos

Todo sistema operativo de propósito general que uses en 2026 tiene un núcleo escrito mayoritariamente en C. Linux ronda las decenas de millones de líneas; el núcleo NT de Windows, el XNU de macOS y iOS, y los BSD comparten el mismo linaje técnico. Por debajo del escritorio, los sistemas de tiempo real que gobiernan maquinaria industrial y automoción siguen la misma regla.

La entrada de Rust en el núcleo de Linux es real y significativa —hay controladores en producción y el soporte está consolidado—, pero conviene leerla con precisión: Rust entra en las hojas, no en el tronco. El planificador, el gestor de memoria, el subsistema de interrupciones y la capa de arquitectura siguen siendo C, y lo seguirán siendo durante décadas, porque reescribirlos no es un problema de lenguaje sino de riesgo acumulado.

Esa asimetría define la posición de C hoy: no compite por el código nuevo, ocupa el código que no se puede volver a escribir.

Merece la pena precisar por qué el tronco es tan resistente. Un núcleo no es una aplicación grande: es un programa sin biblioteca estándar por debajo, que se ejecuta sin red de seguridad, que debe respetar contratos binarios con el hardware y que mantiene invariantes globales entre subsistemas escritos por miles de personas a lo largo de treinta años. Sustituir una pieza de ese tejido no aporta seguridad si la pieza vecina sigue asumiendo las reglas antiguas.

Embebido y tiempo real: donde no hay alternativa

En microcontroladores el argumento cambia de naturaleza. No es inercia: es que el resto de opciones a menudo no existe sobre ese silicio.

Hay además una razón estructural que se ve mejor con código. En un microcontrolador, hablar con un periférico consiste en escribir en una dirección física concreta; C expresa eso directamente, sin capa intermedia ni permiso de nadie:

#include <stdint.h>

/* Registro de control de un periferico, mapeado en memoria */
#define GPIO_BASE   0x40020000u
#define GPIO_ODR    (*(volatile uint32_t *)(GPIO_BASE + 0x14))

void led_encender(unsigned pin)
{
    GPIO_ODR |= (1u << pin);   /* volatile: el compilador no puede eliminar ni reordenar */
}

El calificador volatile es la pieza clave: le comunica al optimizador que ese acceso tiene efectos observables fuera del modelo abstracto del lenguaje. Sin él, una escritura cuyo valor nunca se lee sería eliminada como código muerto, con toda la razón formal del mundo y con consecuencias desastrosas en el dispositivo.

El matiz honesto: las ventajas de las tarjetas anteriores son de ecosistema, no del lenguaje en sí. A medida que otras cadenas de herramientas obtienen cualificación y cubren más arquitecturas, este territorio se estrecha. Pero se estrecha en años, no en trimestres, porque cada paso exige rehacer evidencia de certificación que ya estaba pagada.

El runtime de todos los demás

Aquí está el dato que más desconcierta a quien viene de lenguajes de alto nivel: muchos lenguajes que se perciben como alternativas a C son, en su implementación de referencia, programas escritos en C.

• El intérprete de referencia de Python, el de Ruby, el motor de PHP y el de Lua son ejecutables en C.
• La biblioteca de entrada y salida asíncrona que sostiene buena parte del ecosistema JavaScript de servidor está escrita en C.
• Bases de datos y servidores que sostienen internet: el motor embebido más desplegado del mundo, los principales gestores relacionales, los almacenes en memoria, los servidores web de alto rendimiento.
• La infraestructura invisible: la biblioteca de compresión que usa casi todo formato, las pilas criptográficas, los códecs multimedia, el cliente HTTP que está dentro de casi cualquier dispositivo.

La consecuencia práctica es fuerte: cuando escribes una extensión nativa para tu lenguaje favorito, cuando depuras una fuga de memoria en producción o cuando lees un volcado de pila que cruza la frontera del intérprete, estás leyendo C, aunque no hayas escrito ni una línea.

Y la frontera es más exigente de lo que parece, porque en ella conviven dos modelos de gestión de memoria incompatibles. El intérprete cuenta referencias o recolecta; tu código en C no. La forma canónica de una función de extensión revela el problema:

/* Firma tipica de una extension nativa: recibe y devuelve objetos del interprete */
static PyObject *mi_funcion(PyObject *self, PyObject *args)
{
    const char *texto;
    if (!PyArg_ParseTuple(args, "s", &texto))
        return NULL;              /* propagar el error del interprete */

    /* aqui mandas tu: memoria manual, sin recolector que te cubra */

    return PyUnicode_FromString(texto);   /* devuelve una nueva referencia */
}

Cada comentario de ese fragmento esconde una obligación contractual: quién posee la referencia devuelta, quién la libera, qué pasa si tu código lanza un error a mitad. Equivocarte ahí no produce una excepción: produce una fuga silenciosa o un fallo de segmentación en un proceso que llevaba semanas en producción.

Por qué es la lingua franca: la ABI

La razón profunda de la permanencia de C no está en su sintaxis ni en su rendimiento, sino en un accidente afortunado: la interfaz binaria de aplicación de cada plataforma está descrita en términos de C. La convención de llamada de un procesador, el formato de los ejecutables, la interfaz de llamadas al sistema del núcleo: todo se documenta con tipos y funciones de C.

Eso convierte a C en el mínimo común denominador de la interoperabilidad. Cuando dos lenguajes cualesquiera necesitan hablarse, la traducción pasa por ahí: la palabra clave de enlace extern "C" en C++, las anotaciones repr(C) en Rust, los mecanismos de invocación nativa de la máquina virtual de Java, las interfaces de plataforma de .NET, los módulos nativos de los intérpretes dinámicos.

flowchart TD
P[Python] --> ABI[ABI de C]
R[Rust] --> ABI
G[Go] --> ABI
J[Java y dotnet] --> ABI
Z[Zig] --> ABI
W[WebAssembly] --> ABI
ABI --> LIB[Bibliotecas de sistema y libc]
LIB --> SYS[Llamadas al sistema]
SYS --> K[Nucleo del sistema operativo]
K --> HW[Hardware]
style ABI fill:#f9e2af,color:#11111b
style K fill:#89b4fa,color:#11111b
style HW fill:#cba6f7,color:#11111b

Fíjate en la forma del diagrama: no es que todo el mundo use C, es que todo el mundo converge en él para cruzar fronteras. C no ganó la discusión sobre lenguajes; ganó la de los protocolos.

Por eso una biblioteca pensada para ser consumida desde cualquier parte se diseña con una forma muy reconocible: tipos opacos, funciones simples, propiedad de la memoria declarada sin ambigüedad.

/* Cabecera pensada como frontera binaria estable */
typedef struct motor motor;              /* tipo opaco: el cliente no ve el layout */

motor      *motor_crear(const char *config);
int         motor_procesar(motor *m, const uint8_t *datos, size_t n);
const char *motor_ultimo_error(const motor *m);   /* propiedad: de la biblioteca */
void        motor_destruir(motor *m);             /* propiedad: la cede el cliente */

Nada de esa cabecera depende de C como lenguaje de implementación: el interior puede estar escrito en C, en Rust o en Zig. Lo que importa es que la interfaz está expresada en el vocabulario que toda la industria sabe leer. Un envoltorio para un intérprete dinámico, un enlace para una máquina virtual o un módulo de otro lenguaje compilado se generan casi mecánicamente a partir de ella.