Why we develop EloqDB mainly in C++(eloqdata.com) |
Why we develop EloqDB mainly in C++(eloqdata.com) |
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.
Even if you do, you still will. Just less often.
> I actually have no idea how big teams work on large C++ codebases... You can change one part of the code, and it will introduce bugs in the whole project because of how the memory is handled
Part of it is lots of tests, sanitizers, assertions, etc.
Part of it is keeping things modular and avoiding spooky action at a distance to the extent possible.
Part of it is unavoidable, and that's why people are moving to safer languages.
They choose a memory management strategy and stick to it. Of course, the problem, relative to something like rust, is the compiler doesn't enforce it. You can use linting tools and/or reviews.
> 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
That's not a problem with C++ specifically. That's a problem with organization. It's probably best know as the "Big Ball of Mud" architecture[1]. Rust has no particular defense against it, nor other languages that I am familiar with. If you don't see it as much with rust it's only because it takes time to develop. (counter-intuitively, it's an impressively successful architecture -- so many long-lived projects use it).
Well yeah, you don't. Most people who comment on these sorts of threads don't, which obviously colors their bias in favor of the solution they do understand.
Why would it do that?
There are still logical holes in the borrow checker, but they're mostly irrelevant.
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.
Not really for "purity" issues, but rather due to the fact that memory speeds and main memory latency patterns that started to emerge as problems in the early 00s only got worse over time and having the erasing generics kind of cemented the memory access patterns.
The Java teams has done some truly amazing things in terms of GC research, but much of it is needed simply because the Java and JVM memory model (while "simple") is very allocation-heavy compared to C# that went for value types very early.
Take a peek at the QuestDB source code(Java) for heavy data-manipulation tasks, it's not really written in an idiomatic Java style to avoid GC costs (strongly reminicent of the way some people coded for JavaME back in the early 00s), a C# port would not be entirely idiomatic either but far more so than the existing code.
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.
They attract people truly interested in programming, not those going through the motions at a job. I have heard this same thing with Haskell, Lisp, and many other languages out of the mainstream Java/C#/Javascript/Ruby.
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
Rust has become fairly big now, no? Is there some objective metric that can show Rust is a "smaller" language (I bet it is, but I don't think it's by a lot)?
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?
This is our code. That is their code. Depend only on the interface of their code and not the implementation. You can look at their code for curiosity but don't depend on the implementation of their code in our code.
Then you don't care what subset of the language their code is written in.
This is a very interesting approach to marketing a new database
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.
Another factor to consider is that, if one is indeed trying to reuse code from existing databases (regardless of the reason for doing so), code from projects like Sqlite and FoundationDB is simply far less likely to contain serious bugs than any newer Rust-based option. There are way more mistakes one can make when writing a database than just memory safety mistakes, and the mistakes tend to be extremely subtle. Code having been run in production for long periods of time under significant amounts of load is basically a fundamental prerequisite for it to make any sense to trust the data of your users to it.
[0]: https://www.amazon.com/Naked-Brain-Emerging-Neurosociety-Cha...
One, C/C++ interop is a priority since they will interoperate with a large variety of C/C++ APIs (sounds like one of the main points of their project is to integrate things that are largely implemented in C/C++).
Two, they say their aim is "building a lasting system that will support decades of continued improvements." You want confidence that 99.9% of the code you write today remains just as good 20, 30, 50 years from now. I don't think rust is quite there yet (or maybe it is but hasn't yet proven it).
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?
It is not. Rust will, for example, prevent the following memory-safety issue from compiling:
std::vector<T> meow;
T &x = meow[i];
meow.push_back(...); // Oops, x is now dangling, maybe!
x.a = ...;
Running sanitizers and such is quite expensive too. It burns a lot of cycles to run msan, asan, tsan, valgrind, etc.
Whereas catching these bugs at compile time saves everyone a lot of time and money.
TBH I don't find the reasons in the article particularly compelling. Rust has a lot of industry backing now and is pretty clearly the way forward to systems programming. Writing Rust wrappers over the various libraries they use is largely a one-and-done issue, and they can publish them to Cargo and share the load of keeping them updated. If ISO or various governments get their act together with a real software liability regime or cyber security requirements, companies with big legacy C++ code bases will be in a tough spot. Second best time to start writing safe code in your project is now.
this is one of my biggest gripes, too. that alone has been enough to cause me to avoid Rust for projects wherefore it would otherwise be a good fit. you can pull in "one" dependency and find yourself downloading hundreds of gigabytes of zillions of tiny dependencies, sometimes the same one at multiple versions. it's by no means a problem exclusive to Rust, but that's no excuse.
it's been a while, but my other major gripe was the way so many crates would require the nightly. the rust devs have done a good job maintaining backward compatibility between stable releases, but afaik there isn't any guarantee regarding the nightly. keeping up with the nightly is infeasible when each compiler release and all your dependencies needs to be vetted by your security team.
i also long found myself disappointed by the lack of a real specification, but that one is relatively minor. less of a frustration.
You'll be swimming up against the stream. But arguably it makes sense for certain kinds of projects. I'd classify OS kernel and DB internals development as being those kinds of projects, TBH. Keep your dependency set extremely minimal, vendor it, and avoid crates.io entirely.
I don't actually run into nightly requirements... ever? These days.
Progress on language specification is good https://github.com/rust-lang/fls
There are good reasons the standards committee doesn't make those sacrifices on your behalf, because ultimately there are tradeoffs there that the programmer is supposed to understand and have control over. However, there is an argument to be had about what the default "safety setting" should be and whether C++ makes a good choice. IMO that's actually the main difference between safety in Rust and C++, since you can make Rust just as unsafe as C++ if you want, only you need to explicitly mark your code as unsafe.
Also, I believe the C++ standards committee does care about this, which is why Profiles [1] are being considered.
They’re arguing that they’ve found a sufficiently safe subset, which if true would be the first.
It would be a waste of time to relitigate the many programmer-hostile, unsafe decisions the committee has made over the years. I think your programmers who are supposed to “understand and have control over” C++’s arsenal of footguns are more or less fictional and a language designer shouldn’t take them as intended audience.
https://robert.ocallahan.org/2017/07/confession-of-cc-progra... (2017)
> Also, I believe the C++ standards committee does care about this, which is why Profiles [1] are being considered.
It was discussed at length why this proposal is insufficient: https://news.ycombinator.com/item?id=45234460
But that's kinda... not a bloggable topic, frankly.
This, so much this!
The trade-off between compile-time and run-time checking depends in large part on the time needed to address the issue. It's not really black and white. People just don't want to wait forever for static verification - I think that's kind of why clang-static-analyzer isn't used as much as clang-tidy.
Rust interop to the libraries they list is not an issue.
If you are good at c++ and want to continue building software in c++ it is fine. Just be honest about it.
Do you have a source for this claim? Rust is a fine language (though its advocates can be a bit belligerent sometimes). But, as a matter of fact, Rust was not designed for a easy interoperability with C++ or to make gradual rewrites easy.
It turns out that this kind of interop with C++ directly is extremely difficult, and so it isn’t super smooth right now. Interop with C was prioritized and you get zero overhead there. And various projects ease Rust <-> C++ via the C ABI.
I feel you're objecting to the wrong comment. sebstefan appropriately specified "the people who came to interview for the Rust roles of my company [...]", and was giving it as a counterpoint to the previous comment's broad generalization.
> there's a lot of Java developers because there's a lot of Java jobs, universities teach it, and it's been around a fairly long time when compared to Rust, at least... i.e. there's a lot of forces pushing people to using Java, and once you learn a language and get a job in such language, there's a lot of inertia that will keep most people on that same language for a long time.
The fact that one language is the mainstream default taught in many schools, whereas the other requires going out of your way to pick up, could well be a factor in the latter having more knowledgeable average applicants - in the same way I'd expect Gentoo users to be more technologically competent than Windows users on average.
> Yes, they can eventually choose something else, but only if that's a thing in your region, which may not be the case at all...
I presume the majority of Rust programmers learn it online.
Not at all. His comment was worse in that it generalized a whole lot of people based on the minor evidence he's been able to collect. Unless he's had several dozen, at least, Java applicants, as well as dozens of Rust applicants, I assume he's just using the exact same plain old discriminatory thinking people used to employ when comparing, among many things, race and nationalities. It's incredibly hard to generalize anything about people honestly.
> whereas the other requires going out of your way to pick up, could well be a factor in the latter having more knowledgeable average applicants
I disagree. It's much more likely, in my view, that newer languages will appeal to people who value the wrong things in a business, like which language they want to use for the excitment of being in the cutting edge (not to mention technically as well - we've tried for so long to create languages that make software engineering better, but anyone with a long experience in trying things will know that language is very low in the list of things that help: many studies have shown that over the years)... which also tends to correlate with people who will leave the job as soon as something new catch their eye.
Except in extremely niche cases, the language is not that important. The only things that really help writing software are static types and tests... and that doesn't mean the more the better either: there's a diminishing return with both. That's why Haskell is NOT the pinnacle of software engineering, despite what some fanatics will try to tell you (proof of which is that almost no important software is written in Haskell or languages like it - I think the most successful type-rich language so far is actually Rust!).
> I presume the majority of Rust programmers learn it online.
What I meant is that in their region, there's a good chance that learning another language is useless to find a job because all jobs are in Java or C#/C++.
But I do advise younger people to learn many languages anyway because of the fact that it really helps them think better and not get stuck with a particular approach to software engineering when there's many.
The only statement sebstefan made specified "the people who came to interview for the Rust roles of my company" and likewise for Java applicants - groups they presumably have first-hand experience with. It was jhoechtl's previous comment that generalized to "the Rust workforce".
> I disagree. It's much more likely, in my view, that newer languages will appeal to people who value the wrong things in a business, like which language they want to use for the excitement [...]
Whether your views on people who learn Rust are positive or negative, you do still seem to agree that there are factors that can cause people with different levels of experience or attitudes to programming to choose different languages.
> anyone with a long experience in trying things will know that language is very low in the list of things that help [...] The only things that really help writing software are static types and tests...
Not necessarily the syntax of the language - but languages will have design decisions and ecosystems build up around them and that can make them better suited for particular purposes. Rust's borrow checker is very effective at reducing memory safety bugs without losing performance to GC or reference counting, for instance.
The reason we shun it for race and nationalities is because you can't pick those, you're born with it.
All generalizations are not the same ; your job, your hobbies, your programming language of choice: these assumptions might yield to incorrect results in the exact same way for the exact same reasons, but they are not on the same moral ballpark
(and in this scenario you’re also usually sharing the car with other people so driving automatic would make everyone’s lives easier)
I'm noting that C++ vs Rust is basically this: every article that someone writes which goes over "we're still choosing C++" has the same vibe as people who choose manual transmissions in 2025. There's no real reason to do so at this point, other than if you want to.
I worked on one recently.
I learned on stick and I still feel a nostalgic appeal, sure. I test drove a used hothatch Volvo C30 T5 Polestar edition last fall before ultimately settling on an electric performance car (Polestar 2) to feed my midlife indulgences. And I have to admit a certain ... thrill... from the turbo lag and the process of shifting.
But it all seems a bit silly when compared to instant torque at any RPM.
When an EV actually has a suspension setup and overall weight that doesn't feel like I'm piloting a boat at sea, then I'll probably care. Porsche & co seem like they're still aiming for it so I've got some hope we get there.
They refuse to take 'I do it because I like it' as an answer.
(I've been stuck on planes for 20 hours with little sleep, so ignore it if it doesn't make too much sense lol)
People eating, drinking and using mobile phones .. I think the luxury of having a hand free with automatic transmission is a contributing factor.
Stick shift requires a certain level of attention/engagement that might actually make for safer driving IMO.
For one thing, manual transmissions require physical activity and coordination. That's not true with programming languages...
I almost had a panic attack driving an _automatic_ up Lombard. (Sadly an old minivan with bad-lish tires).
In stop and go traffic (is there any other traffic in SFO?) it moved so much backwards and spun so hard every time I tried to move forward/upward.. I swore never to return. I haven't been back on that road since.
As a motorcycle rider, inattentive car drivers are a sore subject.
As for C++, I agree with your last comment. I guess without the gravitation pull of a large existing C++ code base or an existing team of experts or as essential library, there is not much incentive to start new projects in C++.
I too am a firm believer in multiple layers, each possibly using different language/paradigm. I find the functional core with controlled and imperative edges approach very appealing.
Personal preference is the most valid reason, lol
But people seem to take offense if someone doesn't follow what is common wisdom (according to them) !