"Microservice" architecture is good alternative

Posted Sep 25, 2025 21:04 UTC (Thu) by simlo (guest, #10866)
Parent article: Comparing Rust to Carbon

You don't do calls into another language, but build your system in several processes, each process can be written in a language of choice. Using protobuf or similar should help in avoiding implementing parts of the communication in all languages, but parts of the overall state of the system must be replicated into the various language, so the cost of adding a new language to such a system won't be zero.

Large monolith programs are in itself a bad idea - especially in memory unsafe languages. So splitting all that C++ code i to smaller programs might be a sane approach, and then add new ones in Rust - or Python or ...

"Microservice" architecture is good alternative

Posted Sep 29, 2025 8:23 UTC (Mon) by mort (guest, #132348) [Link]

I have some projects with a WebRTC video call component. The way I've found to work with that is to use C++ for a "helper" video call process which uses Google's WebRTC library, and then the rest of the system (be it written in Rust, or Go, or maybe even that too is C++) communicates with the WebRTC helper process via IPC (typically line delimited JSON via stdin/stdout, maybe shared memory or DMA buffers for decoded video frames).

But because WebRTC is complicated, this C++ helper process still ends up being quite large. It would've been nice if that code too could've been written in something nicer. Carbon is interesting for that.

And then of course we all call into C libraries all the time, either directly or indirectly through a wrapper.