Why We Develop Eloqdb Mainly in C++

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.

[1] https://github.com/BjarneStroustrup/profiles

[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).

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.

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.

Why would it do that?

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.

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).

[1] http://www.laputan.org/mud/

There are still logical holes in the borrow checker, but they're mostly irrelevant.

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.

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.

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.

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)?

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.