I guess the Rust workforce is tiny, opinionated and mentally demanding.
Why we develop EloqDB mainly in C++
31–40 of 94 posts
Re: Why we develop EloqDB mainly in C++
#32As 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
Re: Why we develop EloqDB mainly in C++
#33One 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 espe…
> I actually have no idea how big teams work on large C++ codebases.
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).
Re: Why we develop EloqDB mainly in C++
#34From 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 conventi…
> the rather chaotic and unprofessional (and potentially insecure) nature of the way Cargo project dependencies explode into a hard-to-reason-about mess.
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.
Re: Why we develop EloqDB mainly in C++
#35One 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 espe…
> If you don't do C++ on a daily basis, you will silently introduce problems 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 av…
Your post reminds me of the old runtime vs compile time language debates of old (for me). Some would argue duck typing is all that we need, and that lots of tests can cover the missing types/etc. Eventually i realized that i'm just manually implementing compile time typing by way of robust tests to cover interface requirements.
Re: Why we develop EloqDB mainly in C++
#36I 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…
The by far biggest issue for Java is that they still haven't gotten their act together on value-types (project Valhalla), going back in time, the one thing someone should have told the designers was to not to release the erasing generics in Java 1.5 and go for something like C# did with value type structs.
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.
Re: Why we develop EloqDB mainly in C++
#37> memory unsafeness, can be significantly mitigated when developing with a certain modern subset of the C++ language. 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?
Encapsulation.
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.
Re: Why we develop EloqDB mainly in C++
#38From 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 conventi…
> the rather chaotic and unprofessional (and potentially insecure) nature of the way Cargo project dependencies explode into a hard-to-reason-about mess. 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…
It's worth pointing out that you can absolutely use Rust without Cargo and crates.io and the culture that comes with.
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
Re: Why we develop EloqDB mainly in C++
#39Earlier quoted context omitted.
> If you don't do C++ on a daily basis, you will silently introduce problems 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 av…
Your post reminds me of the old runtime vs compile time language debates of old (for me). Some would argue duck typing is all that we need, and that lots of tests can cover the missing types/etc. Eventually i realized that i'm just manually implementing compile time typing by way of robust tests to cover interface requirements.
> Eventually i realized that i'm just manually implementing compile time typing by way of robust tests to cover interface requirements
This, so much this!
Re: Why we develop EloqDB mainly in C++
#40As 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…
You can easily introduce memory-related issues in the "modern C++" and the compiler won't say a word even with pedantic checks.