
Software of Unknown Provenance (SOUP) in Medical Devices
In the projects we deliver at Somco for medical device manufacturers, the topic of SOUP almost always comes up. Whether […]

As systems grow more complex and reliability becomes mission-critical, developers face an old but still unsolved dilemma: should you build in C++, continue your C++ development, or is it finally time to switch to Rust?
Both languages promise high performance code without compromise — but they approach memory safety guarantees, control, and developer experience in profoundly different ways.
In this interview, our CTO Adam Sowa shares his honest view based on years of experience leading engineering teams and building real-world software.
We’ll dive into:
At Somco we support teams end to end — from technology decisions to software development and hardware consulting. Contact us to discuss your next project.
Whether you’re a C++ veteran skeptical of Rust hype, or a Rust enthusiast curious about system-level trade-offs — you’ll find insights here worth your time. Let’s get started.
A: That’s a great question. Rust was originally created by Mozilla — the same organization behind Firefox — with a very specific mission in mind: to solve the memory management problems that have haunted C++ for decades. You could say Rust was designed to be a better C++, one that offers the same low-level control but guarantees memory safety.
In C++, developers are responsible for allocating and freeing memory manually. That’s where the trouble starts. It’s easy to make mistakes — freeing memory twice, or trying to use it after it’s already been released. Both of these cases often lead to crashes, and they’re notoriously difficult to detect in large applications. Rust was designed precisely to eliminate this class of bugs altogether.
Instead of letting programmers manage memory by hand, Rust enforces a strict ownership model. That means every piece of data has a single, clearly defined owner, and when ownership is transferred, the compiler tracks it. This system ensures that Rust always knows when memory can be safely used or released — no garbage collector required, and no random pauses in execution like in Java or Python.
In short, Rust’s entire philosophy is about providing the safety of high-level languages with the performance of C++. It’s not just a technical choice — it’s the very reason the language exists.
Adam pauses for a moment before adding:
If you think about it, that’s what sets Rust apart. It’s not just another programming language — it’s an answer to decades of pain points in systems programming. It solved what C++ could never completely fix – the endless memory bugs that plague other languages at the system level.
A: That’s a tricky one. I’d say — yes, in theory, Rust can match C++ when it comes to performance. But, as always, it depends on what exactly you’re testing. The truth is, performance comparisons between programming languages are rarely black and white.
In practice, you’d have to look at benchmarks — side-by-side tests where the same program is implemented in both languages and then executed to compare speed and efficiency. I haven’t followed the latest benchmarks closely, but from what I’ve seen, Rust can absolutely keep up with C++ in many cases.
That said, real-world projects are much more complex than synthetic tests. I remember seeing a case where someone rewrote a C program in Rust — and the Rust version ended up running sixteen times slower. But that doesn’t necessarily mean Rust is slower as a language. More often, it means the rewritten code wasn’t as well optimized as the original one.

So, when you compare languages like this, you need to separate the language from the implementation. If you take an old C++ project and simply rewrite it — even in C++ itself — there’s a good chance it’ll run faster, just because you now have a clearer understanding of the system and can make better architectural decisions. The same logic applies when rewriting something in Rust.
Adam adds thoughtfully:
So, yes — Rust can match C++ in high performance scenarios, but context matters. When people say something is faster or slower, they often ignore the human factor — how well the code was written, and how much the developer actually understands the problem.
Adam concludes:
Rust gives you the tools to be as fast as C++. But speed isn’t just about the compiler — it’s about craftsmanship.
Independent benchmarks confirm this point — Rust’s performance is often on par with C++, and sometimes even slightly ahead, depending on the workload (“Is Rust C++-fast?” (arXiv, 2022),Benchmarks Game)
A: Honestly, Rust can be quite challenging at first — the language has a famously steep learning curve. For someone coming from C++, it can feel like programming with your hands tied behind your back. Rust enforces a completely different mindset — one that demands you think explicitly about ownership, lifetimes, and borrowing.
In C++, you have a lot of freedom — maybe too much. You can do almost anything with memory, but that’s also where the most dangerous bugs come from. Rust doesn’t let you take shortcuts. At the beginning, that frustrates many developers, because the compiler rejects things that would compile fine in C++.
But that strictness is exactly what makes Rust so powerful. Its borrow checker — the part of the compiler that enforces memory safety rules — is like a very strict teacher. It won’t let you get away with anything, but it also prevents entire classes of bugs that are notoriously hard to find in other languages. Every time you try to “bend the rules,” Rust stops you — and in doing so, it trains you to write safer, more disciplined code.
The payoff comes later. Once developers internalize Rust’s rules, they start to appreciate how much cognitive load disappears. During code reviews, you no longer have to wonder if someone accidentally freed memory twice or left a dangling pointer — those errors simply can’t happen.
Everyone complains about the borrow checker in the beginning. Then, six months later, they realize it saved them from a dozen bugs they never even noticed.
And the surprising thing? Many developers who learn Rust end up becoming better C++ programmers too. They start thinking more consciously about memory management and ownership, even when the C++ compiler doesn’t force them to. Rust can be a tough teacher — strict and sometimes unforgiving. But in the end, it makes you a stronger engineer.

A: That’s a really good question — and, I’d say, yes, there are still a few. Most of them come down to specific, low-level needs or simply to ecosystem maturity.
For instance, if you’re writing something that interacts very closely with hardware — like device drivers or embedded systems — C++ still offers total, unrestricted control over memory and system resources. Rust can do that too, but only if you mark certain sections of code as unsafe, which effectively disables the language’s built-in safety checks. Once you do that, you’re back in C++ territory — with all its flexibility, but also all its risks.
So technically, there’s almost nothing you can’t do in Rust that you can do in C++, but the key difference is how much the language lets you “bend the rules.” C++ will let you do anything; Rust makes you justify it.
Then there’s the question of maturity. C++ has been around for nearly forty years. That means decades of libraries, frameworks, and production-tested code that developers rely on. Some of these — like the Qt framework, for example — are incredibly rich and have no real equivalent in Rust. You can integrate Qt with Rust using bridges or wrappers, and some companies are experimenting with that, but it’s still not the same level of stability or native support.
So yes, Rust ecosystem is catching up quickly, but C++ simply has a head start of several decades. And for many projects, that legacy — all those existing tools, libraries, and engineers — still matters a lot.
Adam pauses, then adds with a grin:
I’d say Rust is the future, but C++ is the foundation we’re still standing on. It’s not going away anytime soon.
A: Technically, yes — it’s absolutely possible to integrate Rust with C or C++ code. There are libraries and tools that make this bridge work quite well.
So from a purely technical perspective, the integration is doable. But philosophically — that’s where things get interesting. Because the moment you connect Rust code to C++ code, you essentially lose Rust’s main advantage: memory safety.
Rust’s entire model is built on the idea that the compiler guarantees your program can’t make dangerous memory mistakes. But once you call into C++ code, the compiler can no longer enforce those guarantees. The C++ part can still do whatever it wants — allocate, free, or overwrite memory however it pleases — and Rust can’t stop it.
That’s why I often compare it to having a top-notch home security system, but leaving one door unlocked so your cat can go outside. Sure, 90% of your house is secure, but that one door means the whole system isn’t really airtight anymore.
So yes, Rust and C++ can work together — and in some cases, that’s even the most practical solution. But when you do it, you have to accept that you’re stepping out of Rust’s safety zone. You’re mixing two worlds: one that’s guaranteed safe, and one that still trusts you not to make a mistake.
Adam adds:
It’s a trade-off. You gain compatibility, but you lose Rust’s strongest promise — complete protection from memory errors. Sometimes that’s worth it, sometimes it isn’t.
A: Actually, yes — and in some ways, it might even be better. Both Rust and C++ are inherently cross-platform languages, but the way Rust handles it feels a bit smoother.
In C++, building for multiple platforms often requires a lot of manual configuration. You have to manage different compilers, dependency paths, and build scripts. It’s all very powerful, but it also means more time spent tweaking things just to make them work everywhere.
Rust, on the other hand, was designed with modern tooling and a cohesive Rust compiler from the start. Its build system — Cargo — is really well thought out. It handles dependencies, compilation, and platform targeting in a much more unified way. So for many developers, getting a project to build and run on multiple operating systems is just easier and faster in Rust.
Now, of course, C++ still has the advantage of maturity. There are decades of cross-platform libraries already written in it, and if you’re working with legacy code, you’ll probably stick to C++. But if you’re starting a new project from scratch, Rust’s tooling makes cross-platform development far less painful.
A: Well, Rust definitely has its strengths. It’s being used more and more in areas like WebAssembly, blockchain, and parts of systems programming — especially where safety and concurrency are critical. But when it comes to something like kernel development, I wouldn’t go as far as to say Rust is taking over.
Take Linux, for example. A few years ago, there was a big push to make it possible to write parts of the Linux kernel in Rust. Linus Torvalds, the original creator of Linux, even approved the idea. The expectation was that it would attract a wave of new contributors and speed up development.
But that didn’t really happen. The adoption has been minimal. The existing kernel developers still write in C, and very few new people have joined just because of Rust. So in practice, the kernel is still written almost entirely in C, despite the hype.
That, I think, illustrates the bigger picture. Rust enthusiasts are very loud online — you’ll often hear “rewrite everything in Rust, it’s safer, it’s faster” — but reality looks different. Large, established projects are not suddenly switching languages. And developers who’ve been writing C++ for years aren’t migrating en masse either.
Rust is growing, yes, but it’s still a niche compared to C++. And being fair, that’s perfectly fine — it’s still young, and it’s doing many things right. You also see big companies, like Microsoft, experimenting with Rust in some Windows components. They even wrote a small text editor for the console in Rust recently, which is a nice step forward.
And we solemnly swear we had absolutely nothing to do with the recent Windows Kernel vulnerability (see: Check Point Research’s 2025 report on Rust code in the GDI component) — the fact that our interview just happens to coincide with its disclosure is, of course, purely coincidental.
A: Honestly, I don’t think Rust will replace C++ — at least not anytime soon. It’s definitely growing, and it’s an impressive language, but the idea that everyone will suddenly rewrite their codebases in Rust is more fantasy than reality.
Rust’s community is passionate, and its advocates are very vocal online — sometimes even a bit evangelical about it. You’ll often hear claims like, “rewrite everything in Rust, it’ll be faster and safer.” But when you look at what’s actually happening, that massive wave of adoption just isn’t there.
Large, established projects — especially in systems software — aren’t rewriting their cores in Rust. Most C++ developers aren’t switching careers to become Rust programmers. Rust is being used successfully in new projects, yes, but it’s not displacing C++ in existing ones.

That said, I don’t mean that as a criticism. Rust fills a very valuable niche. It proves that safety and performance can coexist, and it’s pushing the entire industry forward. In fact, some of Rust’s best ideas — like ownership semantics and stricter memory guarantees — are already influencing modern C++ standards. Features inspired by Rust are appearing in C++23 and are expected to evolve further in C++26, showing that the languages are learning from each other rather than competing outright.
If you’re interested in how modern C++ continues to evolve, check out our articles Modern C++ in Finance and Is C++ Still Relevant in 2025? — both explore how today’s C++ adopts the best practices of newer languages like Rust while keeping its unmatched performance and ecosystem.
Adam smiles and adds with a reflective tone:
So no, Rust isn’t killing C++. But it’s making C++ better. You could say Rust is the challenger that keeps the veteran sharp.
A: I’d say — absolutely, learn it. It’s worth it. But the reason might not be what you expect.
If you’re a programmer who already knows C++, learning Rust won’t just teach you a new syntax. It will teach you a new way of thinking about memory, ownership, and safety — things that will actually make you a better C++ developer. Once you understand how Rust enforces its rules, you start writing cleaner, safer C++ code, even though the C++ compiler doesn’t force you to.
And if you’re new to systems programming altogether, Rust is a great way to start. Both Rust and C++ belong to the family of system languages — the kind you use to build operating systems, browsers, or performance-critical applications. They give you low-level control that higher-level languages like Python or JavaScript simply can’t.
At the same time, I don’t think anyone should worry that C++ will disappear. There’s too much code written in it, too many critical systems built on it. The world can’t just throw that away. C++ will be around for decades, and there will always be work for good C++ developers.
Adam smiles, concluding with a balanced tone:
So yes — learn Rust. It will sharpen your understanding of how computers really work. But don’t think of it as replacing C++. Think of it as expanding your toolbox — and making you a better engineer.
Let's face it? It is a challenge to get top Qt QML developers on board. Help yourself and start the collaboration with Somco Software - real experts in Qt C++ framework.
Discover our capabilities
In the projects we deliver at Somco for medical device manufacturers, the topic of SOUP almost always comes up. Whether […]

As applications get more complex and performance expectations rise, multithreading becomes essential. In my experience, Qt provides a powerful — […]

Robot Operating System (ROS) is an open-source framework that has become the de facto standard for robotics software development. Modern […]