Por qué aprender C te hace mejor programador de JavaScript (y de otros lenguajes)

JavaScript, Python, Go o Java te abstraen de la memoria: no declaras punteros, no liberas bytes a mano, no piensas en el stack y el heap a diario. Eso acelera el desarrollo, pero también oculta qué está pasando debajo. Cuando tu app de React se come 2 GB de RAM o un proceso Node se dispara en memoria, entender punteros y gestión de memoria te da el mapa para no solo arreglar el síntoma, sino razonar sobre él.

En este artículo explico por qué aprender lenguajes de bajo nivel como C te hace mejor programador en lenguajes de alto nivel: no para escribir todo en C, sino para entender qué ocurre cuando no los controlas.

Lo que C te obliga a ver

En C no hay recolector de basura. Tú pides memoria (malloc, calloc) y tú la liberas (free). Si no lo haces, hay fuga. Si liberas dos veces o usas memoria ya liberada, hay corrupción o crash. Eso te obliga a pensar en:

Dónde vive cada dato: stack (variables locales, vida corta) vs heap (memoria dinámica, vida que tú decides).
Quién es dueño de la memoria: qué función asigna, qué función libera, qué función solo “usa” sin tocar.
Tamaño real de las estructuras: cuántos bytes ocupa un struct, alineación, padding. En JS o Python eso es invisible hasta que el rendimiento o la memoria te golpean.

Ese modelo mental —stack vs heap, ownership, tamaño en bytes— es el mismo que usan por debajo los intérpretes y los runtimes. JavaScript no tiene malloc en tu código, pero el motor (V8, SpiderMonkey) sí. Cuando creas objetos, arrays, closures, el motor pide y libera memoria. Si no entiendes el concepto, “por qué mi app consume 2 GB” es una caja negra.

Punteros: qué son y por qué importan en lenguajes “sin punteros”

Un puntero es una variable que guarda una dirección de memoria: “dónde está” un dato, no el dato en sí. En C lo ves explícito (int* p). En JavaScript no escribes punteros, pero las referencias (objetos, arrays, funciones) se comportan como “apuntar a” algo en memoria: no copias el objeto al pasarlo, pasas una referencia. Si modificas ese objeto en una función, quien lo tenga por referencia ve el cambio. Eso es el mismo concepto que “puntero” en C, solo que el lenguaje no te deja hacer aritmética de punteros ni liberar a mano.

Cuando alguien dice “en JS todo es referencias (salvo primitivos)”, está diciendo: “casi todo lo que tocas son punteros a estructuras en memoria”. Aprender C te hace ver eso de forma clara: qué es una copia, qué es un alias, por qué mutar un objeto “en otro sitio” te cambia el tuyo. Eso reduce bugs de “¿por qué cambió mi estado?” y te ayuda a razonar sobre inmutabilidad y copias en React o en cualquier lenguaje.

Por qué tu app de React (o Node) consume tanta RAM

Sin modelo mental de memoria, “la app pesa 2 GB” suena a “JavaScript es malo” o “React es pesado”. Con él, puedes desglosar:

Objetos y arrays que no se liberan: referencias que mantienen vivo un árbol de componentes, cachés que crecen sin límite, listeners que no se desregistran. El GC no puede reclamar lo que todavía “se usa” desde algún sitio.
Duplicación de datos: clonar estructuras enormes “por si acaso”, guardar el mismo dato en varios sitios. En C verías “estoy pidiendo el doble de memoria”; en JS es “tengo más referencias a cosas grandes”.
Fugas “de lógica”: no es que olvides free, sino que guardas algo en un closure, en un estado global o en un módulo, y ese algo arrastra consigo un montón de datos. El GC no los libera porque técnicamente siguen alcanzable. En C el equivalente sería guardar punteros en estructuras de larga vida sin liberarlos después.

Aprender C no hace que JavaScript gestione la memoria por ti, pero te hace preguntar: “¿quién mantiene vivo este dato? ¿realmente lo necesito vivo?”. Eso es la mitad del camino para bajar el consumo de RAM y para diseñar estructuras de datos más limpias.

Stack y heap en lenguajes de alto nivel

En C distingues stack (automático, rápido, tamaño limitado) y heap (dinámico, más lento de gestionar, más flexible). En JavaScript casi todo lo que tocas como objeto vive en un “heap” gestionado por el motor; el stack se usa para llamadas a funciones y algunos valores. Pero la idea es la misma: lo que vive poco (variables locales de una función) no debería convertirse en algo que vive para siempre (referencias en un singleton o en un estado global). Saber que existe esa diferencia te ayuda a no “elevar” innecesariamente datos a ámbitos de larga vida y a entender por qué ciertos patrones (por ejemplo, crear muchos objetos pequeños en un bucle) pueden presionar al GC o al heap.

Concurrencia y memoria

En C, si dos hilos tocan la misma memoria sin sincronización, tienes data races y comportamiento indefinido. En JavaScript tienes un solo hilo de ejecución, pero con async (promesas, async/await) y con workers compartes estado o mensajes. Entender “quién escribe y quién lee” y “qué memoria es compartida” es el mismo tipo de razonamiento que en C con hilos: ownership, compartido vs copia. Los lenguajes de alto nivel te dan herramientas más seguras (por ejemplo, mensajes en workers en lugar de memoria compartida), pero el mapa mental de “qué se comparte y con qué vida” lo construyes igual: C te lo enseña de forma cruda y explícita.

No se trata de escribir todo en C

El objetivo no es volver a escribir tu frontend en C. Es tener un modelo mental de memoria, referencias y coste que te permita:

Desglosar por qué una app consume mucha RAM o por qué un proceso se dispara.
Diseñar estructuras de datos y flujos de datos que no retengan más de lo necesario.
Leer documentación de motores (V8, etc.) o de lenguajes compilados (Go, Rust) sin que “heap”, “stack”, “pointer” o “allocation” suenen a magia.
Elegir entre “copiar” y “referenciar” con criterio, no por intuición vaga.

Un poco de C (o de algo como Rust, que explicita ownership sin malloc/free) te da ese fundamento en unas semanas o meses. No hace falta ser experto: basta con haber tocado punteros, structs, malloc/free y quizá un poco de multihilo para que el resto de tu carrera en JavaScript, TypeScript, Python o Go tenga otra capa de claridad.

Mi perspectiva personal

Aprender C (o un lenguaje que te obligue a pensar en memoria y punteros) no es un desvío: es una inversión. Cuando debugueas “por qué mi app de React consume 2 GB” o “por qué este proceso Node se queda colgado”, tener la idea de referencias, ownership y ciclo de vida de la memoria te permite formular hipótesis concretas (¿qué está manteniendo vivo este objeto? ¿dónde se duplica este dato?) en lugar de probar cosas al azar. No hace falta escribir C en el día a día; hace falta haberlo escrito lo suficiente para que, cuando trabajes en lenguajes de alto nivel, sepas qué está pasando bajo el capó y tomes mejores decisiones de diseño y de depuración.