Here's the video of a very simple program in which the Julia runtime is embedded inside C++.
Some programming projects begin with a problem.
Some begin with curiosity.
And some begin with a conversation between a father and his son.
This one began with my son.
My son has been exploring programming, graphics, simulation and the fascinating world of computers. As I watched him move from one technology to another—C++, Python, Java, graphics and simulation—I found myself revisiting areas of computer science that I had not touched seriously for years.
And somehow, that journey brought me back to C++.
But not just C++.
It led me to Julia.
And then came an interesting question:
What if C++ and Julia could work together inside the same application?
That question eventually led me to jluna.
Why C++ and Julia?
C++ and Julia come from rather different programming traditions.
C++ is the language I naturally associate with systems programming, performance, memory control, large-scale simulation and real-time applications.
Julia, on the other hand, feels almost purpose-built for scientific computing.
It combines a high-level mathematical syntax with impressive numerical performance.
For someone interested in physics simulation, control systems, computational science and graphics, the combination is rather attractive.
Imagine having the core simulation or controller in C++, while using Julia for:
That immediately opens up some interesting possibilities.
The idea of a bridge
Calling C++ from Julia is already possible through several mechanisms.
But I was particularly interested in the opposite direction:
Embedding Julia inside a C++ application.
The architecture I had in mind was something like this:
C++ Application
│
┌────────┴────────┐
│ │
Simulation / Julia Runtime
Controller │
│ ┌───────┴───────┐
│ │ Visualization │
│ │ Experimentation│
│ │ Data Analysis │
│ └───────────────┘
│
└────────── jluna ──────────┘
This is where jluna became interesting.
Rather than treating Julia as a completely separate program, jluna provides a C++ interface for interacting with an embedded Julia runtime.
And suddenly, the idea of a C++ program calling Julia code didn't feel so exotic.
My first jluna experiment
I decided not to start with a complicated application.
No physics engine.
No PID controller.
No graphics.
Just a tiny experiment:
Can a C++ program start Julia and execute Julia code?
That simple question became the first milestone.
I created a small C++/CMake project and started working through the mechanics of embedding Julia.
There were several pieces to understand:
locating the Julia installation
configuring CMake
linking the C++ application
initializing the Julia runtime
evaluating Julia expressions
passing values between C++ and Julia
The interesting part wasn't simply getting the first program to run.
It was understanding where the boundary between the two languages actually lies.
Crossing the language boundary
Once you start thinking about C++ and Julia as two parts of the same application, a more interesting question appears:
What should belong to C++, and what should belong to Julia?
For example, consider a PID controller.
The controller itself could live in C++:
Sensor
↓
C++ PID Controller
↓
Actuator
But during development, I might want Julia to provide:
Julia
│
┌───────┼────────┐
↓ ↓ ↓
Plot Slider Analysis
│ │ │
└───────┼────────┘
↓
C++
PID Controller
Julia could change Kp, Ki and Kd interactively.
The C++ controller could continue doing the real work.
Julia could plot the response in real time.
Now the bridge becomes much more than a programming curiosity.
It becomes an architecture for experimentation.
The father-son effect
There is something amusing about this journey.
I started exploring C++ and Julia because my son was exploring programming and simulation.
Instead of simply teaching him something, I found myself learning something new as well.
That is one of the unexpected pleasures of being a parent.
Sometimes we imagine that we are introducing our children to technology.
But they quietly introduce us to new technology too.
A question from a young programmer can send a father down a rabbit hole involving CMake, compilers, ABI compatibility, Julia's runtime, C++ templates and foreign-function interfaces.
And suddenly it is midnight and you're reading documentation about jluna.
Why this exploration matters to me
I'm not approaching jluna because I need another language binding for a production application.
I'm exploring it because it sits at an interesting intersection of several things I enjoy:
C++ + numerical computing + simulation + visualization + experimentation.
C++ gives me control and performance.
Julia gives me an expressive scientific environment.
And jluna provides the bridge.
The more I explore this combination, the more interesting the possibilities become.
Perhaps the final project will be a PID controller.
Perhaps a physics simulation.
Perhaps something involving graphics.
Or perhaps it will simply remain another enjoyable rabbit hole in my never-ending journey through computer science.
But that is perfectly fine.
Because sometimes the best projects aren't the ones that solve a business problem.
They are the ones that make you curious again.
And this particular curiosity started with my son.
**He was exploring programming.
I followed him down the rabbit hole.
And somewhere along the way, we discovered a bridge between C++ and Julia.**
