Earlier quoted context omitted.
Because they are grasping for reasons not to learn Rust.
Their reasoning is reasonable. And besides, when your existing team is already proficient in Cpp, arguing that "they should learn X instead" seems very risky and unwise.
Why we develop EloqDB mainly in C++
51–60 of 94 posts
Re: Why we develop EloqDB mainly in C++
#52These articles can always be surmised down to "because we wanted to". Rarely is there some real reason.
As Richard Restak postulates in his book “The Naked Brain”[0]: the limbic system provides a gut feeling (usually from comfort) and we rationalise our way backwards from that without being able to really pinpoint “why”; usually the “why” is secondary and only added as justification for the feeling post-decision. [0]: https://www.amazon.com/Naked-Brain-Emerging-Neurosociety-Cha...
Re: Why we develop EloqDB mainly in C++
#53Re: Why we develop EloqDB mainly in C++
#54Earlier quoted context omitted.
The "I drive an H-pattern manual transmission" of programming language discussions.
Is this like a dig? Does anyone disagree that manual is much more fun?
Re: Why we develop EloqDB mainly in C++
#55I 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 t…
Re: Why we develop EloqDB mainly in C++
#56[flagged]
Re: Why we develop EloqDB mainly in C++
#57Earlier quoted context omitted.
Is this like a dig? Does anyone disagree that manual is much more fun?
I get your point and I like driving a manual car, but there’s a reason the whole world has switched to automatic
Re: Why we develop EloqDB mainly in C++
#58Earlier quoted context omitted.
The "I drive an H-pattern manual transmission" of programming language discussions.
Is this like a dig? Does anyone disagree that manual is much more fun?
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.
Re: Why we develop EloqDB mainly in C++
#59Earlier quoted context omitted.
Is this like a dig? Does anyone disagree that manual is much more fun?
I suspect the H pattern they mean is where the gear shift is on the steering column, not on the floor. I long ago owned a 1945 Dodge truck with that shifting setup.
(I've been stuck on planes for 20 hours with little sleep, so ignore it if it doesn't make too much sense lol)
Re: Why we develop EloqDB mainly in C++
#60As 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…
It is not. Rust will, for example, prevent the following memory-safety issue from compiling:
std::vector meow;
T &x = meow[i];
meow.push_back(...); // Oops, x is now dangling, maybe!
x.a = ...;
(This sort of pattern is responsible for nearly 100% of the C++ memory safety issues I know I've committed in the past several years.)