Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we develop EloqDB mainly in C++

eloqdata.com

Post reply on HN
Print view View original

41–50 of 94 posts

Re: Why we develop EloqDB mainly in C++

#41

Post by tcoff91 »

guywithahat wrote: post #32

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…

The sanitizers and static analysis tools are not as good as the borrow checker for preventing data races.

Re: Why we develop EloqDB mainly in C++

#42

Post by sebstefan »

jhoechtl wrote: post #31

I guess the Rust workforce is tiny, opinionated and mentally demanding.

I might be biased but I found it that the people who came to interview for the Rust roles of my company were noticeably better (or at least better at interviewing) than the applicants for the Java roles. More knowledgeable on the theory, struggled less on the hard things, more up to date on their tech watch

Re: Why we develop EloqDB mainly in C++

#43

Post by jmull »

rapsey wrote: post #23
jmull wrote: post #21

Earlier quoted context omitted.

They do list specific reasons in the article... 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 writ…

The list of reasons is very weak and no point is actually prohibitive against the usage of Rust.

It's really not clear on what basis you brush away their reasons. Just calling them "very weak" with nothing to support it doesn't mean much.

Re: Why we develop EloqDB mainly in C++

#45

Post by pie_flavor »

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.

Re: Why we develop EloqDB mainly in C++

#46

Post by wavemode »

saghm wrote: post #12

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 r…

I don't think it's quite as circular as you're making it sound. If someone has a prior contraint of needing to move quickly (which is common in startups) it can make sense to choose any arbitrary technology, if it allows them to do so. I don't think someone developing a new game in C++ necessarily has no concerns about C++, that's just the language that all the console SDKs use. I don't think someone doing data science in Python necessarily likes Python, that's just the language that most models and libraries use (and that person probably has a deadline to publish a paper!)

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.

Re: Why we develop EloqDB mainly in C++

#47

Post by rapsey »

jmull wrote: post #43
rapsey wrote: post #23

Earlier quoted context omitted.

The list of reasons is very weak and no point is actually prohibitive against the usage of Rust.

It's really not clear on what basis you brush away their reasons. Just calling them "very weak" with nothing to support it doesn't mean much.

The lasting system bit is very weak. Those old languages are still getting regular releases. Also Rust barely changes from one version to the next, entirely unlike C++!

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.

Re: Why we develop EloqDB mainly in C++

#48

Post by CodeMage »

kccqzy wrote: post #37
raincole wrote: post #24

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

This fails to address the question you replied to. When "our code" is memory-safe and "their code" isn't, it's still "Our Product™" that ends up with a CVE that costs us money and reputation, because users don't care about whose code it was.

Re: Why we develop EloqDB mainly in C++

#49

Post by mempko »

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.

Re: Why we develop EloqDB mainly in C++

#50

Post by wffurr »

guywithahat wrote: post #32

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…

C++ is getting safer, but it has a long way to go to match Rust's safety guarantees. Google is doing a lot with spatial safety with hardened libc++, bounds checks for C-style arrays, and safe buffers; but temporal safety is a lot harder without more information in the source code.

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.

Post reply on HN