A strong case for C++ and Julia combination - my exploration continues - developing a PID controller using this approach using jluna...

 For a simple simulation or educational demonstration, we can do all of these in Julia. But in real-world applications, it's better to keep the hardware interfacing part written in C++ and the visualization part in Julia. This is a pretty common pattern (Python frontend + C++ backend, MATLAB + generated C, etc.), just with Julia instead of Python/MATLAB.

Below are some of the rational points when this tango of C++ and Julia is a good choice.

Real controller needs C++ strengths: If the “main controller” runs in a hard/soft real-time loop, on embedded hardware, interfaces with drivers/sensors/actuators (serial, CAN, ROS, etc.), or must meet strict latency/determinism guarantees, C++ (or C) is the conventional and safer choice. Julia’s GC, JIT compilation, and runtime make hard real-time harder (though there is recent work deploying Julia controllers on platforms like Raspberry Pi + PX4 or even microcontrollers).

Julia for the interactive layer: Julia excels at numerical work, control-theory tooling (ControlSystems.jl, DiscretePIDs.jl, ModelingToolkit, Dyad/JuliaSim control packages with PID autotuning), and modern interactive visualization (Makie/GLMakie with sliders, Observables, live plots of step responses, Bode/Nyquist, time series, etc.). Building a nice desktop or web-ish dashboard with live parameter sliders and plots is straightforward and productive in Julia.

Clean separation of concerns: Frontend (visualization + interactive tuning of

$K_p, K_i, K_d$K_p, K_i, K_d, etc.) stays in a high-level language good at maths and plotting; the performance-/hardware-critical loop stays in C++. Communication can be via sockets, shared memory, ZeroMQ, files, or (better) a thin C API + ccall / CxxWrap.jl / jluna-style interop. 

Finally, it may look like the following...

Stage 0 : Verifying the basic configuration...