Everything is C

The abstraction layers of modern programming languages often obscure the fact that, at the execution level, almost all high-level code eventually flows through a runtime written in a systems language like C, C++, or Rust. Whether it is the Java Virtual Machine (JVM), the V8 engine, or the Python interpreter, these “engines” act as the bridge between human-readable logic and the machine instructions processed by the CPU. Understanding this bridge is essential for understanding performance bottlenecks and optimization strategies.

Execution Architecture

Java Code 
 → javac 
 → Java Bytecode 
 → JVM (C++) 
     → Interpreter + JIT (HotSpot)
     → Machine Code

JavaScript Code
 → V8 (C++) 
     → Parser → Abstract Syntax Tree  
     → Ignition (Interpreter) → Generates V8 Bytecode -> Executes V8 Bytecode 
     → TurboFan JIT → Machine Code (optimization)
     → Machine Code → TurboFan → ByteCode (deoptimization) - necessary in dynamically typed language

Key Insights

Virtual CPUs: The V8 “Ignition” interpreter is essentially a virtual CPU written in C++. It utilizes a register-based architecture to execute bytecode similarly to how a physical CPU executes assembly.
The JVM Model: Java follows a similar trajectory. .java files are compiled to bytecode, which serves as the “machine code” for the JVM. The JVM (written in C++) is a stack-based virtual machine that executes instructions such as load or add.
Memory and Profiling: Beyond execution, the VM manages memory allocation, deallocation, and Garbage Collection (GC). It also maintains a “profile” of the running application to identify “hot” code paths for JIT (Just-In-Time) compilation.
The JIT Advantage: Since the VM is written in a compiled language, it can make direct calls to machine code. The VM uses a machine code generator at runtime to compile code directly to machine code and stores it in memory. Every time it encounters that bit of code, it calls it directly. This allows languages like Java to rival C++ in performance at many workloads.

Technical Comparisons

Why is Java generally faster than JavaScript?

Despite Java using a stack-based VM (historically considered less efficient than register-based VMs), it typically outperforms JavaScript for several reasons:

Predictability: Java is statically typed and lower-level, making it more predictable for the JIT compiler.
Speculation Penalties: JavaScript is dynamic; V8 must “guess” types. When those guesses are wrong, the engine hits a “deoptimization” penalty to revert to bytecode.
~~Java is however heavier, consumes way more ram and cpu in general, because of the plethora of dynamic runtime features built into the spec.~~
- Correction: While Java’s runtime features like reflection and class loading add complexity, the “heaviness” in RAM is largely due to the JVM’s memory management strategy (heap allocation) and object overhead, rather than the dynamic features themselves.

Node.js vs. Bun

Runtimes: Both are runtimes that handle the event loop, async/await, scheduling, filesystem, and networking.
Node.js: Uses the C++ library libuv for its underlying asynchronous operations, requiring a “glue” layer between JS and C++.
Bun: Written in Zig, which is designed for extreme performance and low-level control.
Scope: Bun functions not just as a runtime, but also as a package manager, library, and build tool (comparable to esbuild).

Python

Interpreted Nature: Standard Python (CPython) is interpreted without a built-in JIT, which is why it is generally slower than JavaScript.
CPython: The most widely used implementation; it runs a stack-based interpreter written in C.
Performance Frameworks: Fastapi is built on Starlette, which typically uses the Uvicorn implementation. Major components of these stacks are written in C to handle requests efficiently.
Type Safety: Pydantic integrations allow for type safety and automatic OpenAPI documentation generation. In recent versions, Pydantic’s core has been rewritten in Rust to further bridge the performance gap.

Conclusion

The evolution of these languages shows a converging trend: high-level developer ergonomics (Python/JS) supported by increasingly complex low-level engines (C++/Zig/Rust). As JIT compilers and runtimes become more sophisticated, the performance gap between “interpreted” and “compiled” languages continues to shrink, though the fundamental constraints of dynamic vs. static typing remain the primary differentiator in execution speed.

sidequests

Table of Contents