> In particular, the most harsh arguments against using C++, i.e. memory unsafeness, can be significantly mitigated when developing with a certain modern subset of the C++ language.
So the quest for the one true “modern subset” of C++ continues.
How do developers continue believing in this after a decade of the standards committee proving over and over again that they’re not interested in this and won’t contribute toward it?
I don't know if the stuff about the JVM is even true. I grant that Redpanda is written in C++, but it isn't clear that its performance advantages over Kafka are due to that rather than to the fact that Kafka was implemented in a performance-oblivious way by people who did not know anything about software efficiency. This doesn't reflect on the JVM. You can write a high performing system in Java and the modern JDK is a state-of-the-art toolchain that provides features that many C++ projects struggle with.
One thing I like about Rust is that it prevents you from doing stupid things on the compiler level. I write a little bit of C/C++ and Rust. If you don't do C++ on a daily basis, you will silently introduce problems in the code that are very hard to spot. You just need to have a very good mental model of how to write good C++. It requires constant exercising.
For Rust, you just have to fight the compiler. This is especially useful when you have people on your team with some experience who also want to contribute, but you don't want to constantly point them in the right direction.
I actually have no idea how big teams work on large C++ codebases. Usually, you need to have a good idea of how the whole thing works. You can change one part of the code, and it will introduce bugs in the whole project because of how the memory is handled. Isolated changes are hard. And historically, a lot of C++ codebases lack good test coverage.
From my experience no language bitrots and degrades worse than a C++ codebase.
The language standard has changed so much, the tooling, trendy libraries and the established conventions... It takes a herculean effort to keep a given source tree up to date.
Dive into a C++ repo started even 10-15 years ago and it can be a revolting experience, let alone one from back in the 90s.
And then from company to company conventions and expectations just vary dramatically.
When I was at Google we had a large committee of very smart people who applied monorepository wide modernizations across the whole repository, introduced amazing tooling and analysis tools, and imposed a very strict style guide that kept people fairly disciplined. But that was a herculean effort which most other organizations can't afford.
Rust has all sorts of problems (including specific ones for DB internals or OS development). But what's amazing when I read these articles is they don't actually seem to mention those specific problems that I've encountered in my last 3 years of professional Rust work. Instead they read like rationalizations by people who have a certain hammer they've gotten really skilled at using, and don't want to give it up.
That's fine if it keeps your organization productive, but I see no reason to publish about it?
If I were to make a list of gripes about Rust for this kind of work it would primarily emphasize the continued lack of acceptance/conclusion of the allocator-api (or competing) proposals, and the rather chaotic and unprofessional (and potentially insecure) nature of the way Cargo project dependencies explode into a hard-to-reason-about mess.
But the list they make? io_uring, mimalloc, and performance oriented networking are... not problems to use in Rust, not complicated at all. I assume the same (or better) for Zig.
It sounds like the rationale is that existing database technology is already written in it, and they want to re-use some of it. That's reasonable, but I do think that it only makes sense with the assumption that the flaws in C++ aren't large enough to be worth using something else, at which point there isn't really much need to justify using C++ at all. If someone is concerned about the flaws in C++, the benefit of relying on existing C++ libraries isn't going to seem as compelling to them for the exact same reasons they don't want to use C++ for their own code.
At the end of the day, the choice seems to be a bit circular; if you don't have concerns about C++, you'll find plenty of reasons to use it, and the arguments against it aren't going to be compelling. If you have concerns about it, the reasons to use it won't be compelling, and you'll likely agree with the arguments against it. I have to imagine that whether someone agrees with this choice will be entirely consistent with their existing opinions of C++; it doesn't seem like there are any new arguments left to make on this topic, so debates on the topic will inevitably rehash existing arguments (regardless of which side they come from) and only appeal to the people who already have formed their opinions based on finding those arguments compelling to begin with.
> Over the past several years, the EloqData team has worked tirelessly to develop this software, ensuring it meets the highest standards of performance and scalability. One key detail we’d like to share is that the majority of EloqKV’s codebase was written in C++.
This is a very interesting approach to marketing a new database
I think, that complexity cannot be eliminated, but it can be hidden and distributed, using the right abstraction
that being said C++ being a big language adds complexity (stemming from the language itself, i.e. stemming from the tool)
So you can use a complex tool, to make a complex task simple, or a simple tool and keep the task more complex, requiring more steps etc..
But with C++ its a complex tools, that while it takes some complexity from the task, I think it adds enough complexity, that could outweigh the complexity it reduces
As far as I can tell, modern C++20/23 is as safe (if not safer) than rust. So much of rust compares itself to C++99, where modern C++ doesn't use exceptions, has smart pointers (RAII), improved casting and array management, and has an extensive suite of checking tools and flags. The conversations I've seen at my company for using rust tend to be "well it would be tun to do something different", which just aren't very compelling to me. I worry Rust is going to end up like Haskell in 5 or so years
This lists all the reasons to use Rust, then handwaves about some nonsense, then declares victory for C++. The maturity argument made a lot more sense when Rust was 3 years old, rather than 10; the libraries argument is plain silly because library management is horrible in C++ and all the listed libraries are by comparison essentially one-click to use in Rust; the entire article also seems AI-generated.
The reasons to use C++ over rust in this article are not good. The reason I would have picked is C++ does a better job matching mental models (partly because of it's flexibility) and it's easier to say what you mean. Value semantics by default also make it easier to write functional style code.
Good for them. I like C++. It is a language that supports both being close to the computer and abstraction. I studied Rust a bit but it seems that their rules exclude some perfectly good software designs. If two classes need to work together as equals so class A has a reference to B and class B has a reference to A this is not very well possible. Especially if both A and B have multiple instances that are stored in containers. This is common with the bridge design pattern.
The language is improving and improving. Some years ago it was way too difficult for the speed gain to be worth it.
But it's become more and more easy to write. Many of the safety arguments Rust has are still technically true, but 90% less true than 6 years ago.
The C++ community is also really friendly and open minded.
It's hard to explain but C++ also has this nice relaxing feel when writing it. Like doing a puzzle. Maybe the cognitive load is very evenly spread? Or the header hpp model forces you to think first in data models and interfaces? I have no idea it's mainly a feeling.
20 comments
[ 3.4 ms ] story [ 39.4 ms ] threadSo the quest for the one true “modern subset” of C++ continues.
How do developers continue believing in this after a decade of the standards committee proving over and over again that they’re not interested in this and won’t contribute toward it?
For Rust, you just have to fight the compiler. This is especially useful when you have people on your team with some experience who also want to contribute, but you don't want to constantly point them in the right direction.
I actually have no idea how big teams work on large C++ codebases. Usually, you need to have a good idea of how the whole thing works. You can change one part of the code, and it will introduce bugs in the whole project because of how the memory is handled. Isolated changes are hard. And historically, a lot of C++ codebases lack good test coverage.
The language standard has changed so much, the tooling, trendy libraries and the established conventions... It takes a herculean effort to keep a given source tree up to date.
Dive into a C++ repo started even 10-15 years ago and it can be a revolting experience, let alone one from back in the 90s.
And then from company to company conventions and expectations just vary dramatically.
When I was at Google we had a large committee of very smart people who applied monorepository wide modernizations across the whole repository, introduced amazing tooling and analysis tools, and imposed a very strict style guide that kept people fairly disciplined. But that was a herculean effort which most other organizations can't afford.
Rust has all sorts of problems (including specific ones for DB internals or OS development). But what's amazing when I read these articles is they don't actually seem to mention those specific problems that I've encountered in my last 3 years of professional Rust work. Instead they read like rationalizations by people who have a certain hammer they've gotten really skilled at using, and don't want to give it up.
That's fine if it keeps your organization productive, but I see no reason to publish about it?
If I were to make a list of gripes about Rust for this kind of work it would primarily emphasize the continued lack of acceptance/conclusion of the allocator-api (or competing) proposals, and the rather chaotic and unprofessional (and potentially insecure) nature of the way Cargo project dependencies explode into a hard-to-reason-about mess.
But the list they make? io_uring, mimalloc, and performance oriented networking are... not problems to use in Rust, not complicated at all. I assume the same (or better) for Zig.
At the end of the day, the choice seems to be a bit circular; if you don't have concerns about C++, you'll find plenty of reasons to use it, and the arguments against it aren't going to be compelling. If you have concerns about it, the reasons to use it won't be compelling, and you'll likely agree with the arguments against it. I have to imagine that whether someone agrees with this choice will be entirely consistent with their existing opinions of C++; it doesn't seem like there are any new arguments left to make on this topic, so debates on the topic will inevitably rehash existing arguments (regardless of which side they come from) and only appeal to the people who already have formed their opinions based on finding those arguments compelling to begin with.
This is a very interesting approach to marketing a new database
Right.
> Most existing and popular databases are developed in C/C++, providing a wealth of resources and innovations we could leverage.
Right.
But two rights can make one wrong. How are you enforcing 'good part of C++' when you're interoperating with others' code?
that being said C++ being a big language adds complexity (stemming from the language itself, i.e. stemming from the tool)
So you can use a complex tool, to make a complex task simple, or a simple tool and keep the task more complex, requiring more steps etc..
But with C++ its a complex tools, that while it takes some complexity from the task, I think it adds enough complexity, that could outweigh the complexity it reduces
We need better languages, C++ is not it
The language is improving and improving. Some years ago it was way too difficult for the speed gain to be worth it.
But it's become more and more easy to write. Many of the safety arguments Rust has are still technically true, but 90% less true than 6 years ago.
The C++ community is also really friendly and open minded.
It's hard to explain but C++ also has this nice relaxing feel when writing it. Like doing a puzzle. Maybe the cognitive load is very evenly spread? Or the header hpp model forces you to think first in data models and interfaces? I have no idea it's mainly a feeling.