Decoupling from C++

[AlexanderYastrebov]

Hello. I am wondering if it is possible to implement Tachyon in such a way that language libs do not depend on C++ and thus do not require CGO, FFI, etc which require a C++ compiler.

The idea is to define shared memory setup and access "protocol" that relies on syscalls and atomics only and then translate it (maybe (semi)automatically using LLM) into each supported language.

[riyaneel]

Hello,

To answer your question directly: no, this is not possible without completely destroying the performance and reliability guarantees of Tachyon.

This proposal, while understandable from a deployment perspective, fundamentally goes against the core philosophy of this project.

Tachyon is not just a generic high level wrapper. Under the hood, it relies on an incredibly tight integration between the code and the hardware. Removing the C++ core, specifically the engine located in arena.cpp and shm.cpp, just to avoid a compiler dependency would break that integration. The requirement to use CGO, FFI or FFM across the respective bindings/ directories is not a design flaw, it is the fundamental reason I can squeeze every drop of performance out of the CPU.

The whole point of a shared memory IPC is to stay entirely away from the operating system kernel. Syscalls are terrible for latency because they force context switches. I have spent a massive amount of time optimizing the hot path to have exactly one syscall (futex for Linux or __ulock for MacOS), and even then, it only triggers under two very specific conditions. You can see this strictly enforced at the kernel level by the Seccomp profile in contrib/seccomp. Building a protocol that explicitly relies on syscalls for synchronization defeats the entire purpose of a zero copy architecture and would ruin the latency.

Then there is the validation and memory safety aspect. Lockless concurrency and shared memory are incredibly unforgiving. The current C++ core is battered with continuous fuzzing, It is also strictly validated against ASan, UBSan, TSan, and MSan to ensure it does not corrupt memory. Throwing away a heavily tested and sanitized core to let an LLM guess atomic operations and memory barriers natively across bindings is a massive stability risk. A single data race or memory model bug in just one of those native ports would silently corrupt the shared arena and take down every single connected process.

I am keeping the centralized C++ core. The friction of installing a compiler is the price to pay for bare metal performance and actual reliability. I am not going to compromise a mathematically sound and hardware optimized architecture just to make a CI pipeline slightly easier to configure.

[AlexanderYastrebov]

Hi, thank you for detailed answer.
I did not mean to use syscalls for synchronisation, only for setting up shared memory.
After some thought, the compiler requirement is not really an issue as its possible to build the application in the container with the fixed and tested version of the compiler.