Live data from Hacker News

Why we develop EloqDB mainly in C++

eloqdata.com

21–30 of 94 posts

Re: Why we develop EloqDB mainly in C++

#21
post #4

These articles can always be surmised down to "because we wanted to". Rarely is there some real reason.

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

Re: Why we develop EloqDB mainly in C++

#22
post #9

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

This seems like a bit of selection bias; people who learn it are more likely to be the type who anticipate enjoying it, and people who don't find learning it appealing probably wouldn't enjoy it if they did. I haven't driven in over a decade partially due to disliking it, and I have to assume that I'd dislike driving manual even more.

Re: Why we develop EloqDB mainly in C++

#23
post #21
post #4

These articles can always be surmised down to "because we wanted to". Rarely is there some real reason.

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.

Re: Why we develop EloqDB mainly in C++

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

Re: Why we develop EloqDB mainly in C++

#25

> In particular, the most harsh arguments against using C++, i.e. memory unsafeness, can be significantly mitigated when developing with a certain modern subset of the C++ language. 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 to…

Because they are grasping for reasons not to learn Rust.

Re: Why we develop EloqDB mainly in C++

#26

> In particular, the most harsh arguments against using C++, i.e. memory unsafeness, can be significantly mitigated when developing with a certain modern subset of the C++ language. 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 to…

The article isn't claiming there is a "one true modern subset" of C++ that they use. It's merely pointing out that you can significantly mitigate the main criticisms of C++ by making certain sacrifices, which is pretty much true.

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

Re: Why we develop EloqDB mainly in C++

#27
I think, that complexity cannot be eliminated, but it can be hidden and distributed, using the right abstraction

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

Re: Why we develop EloqDB mainly in C++

#28
post #25

> In particular, the most harsh arguments against using C++, i.e. memory unsafeness, can be significantly mitigated when developing with a certain modern subset of the C++ language. 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 to…

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.

Re: Why we develop EloqDB mainly in C++

#30
post #25

> In particular, the most harsh arguments against using C++, i.e. memory unsafeness, can be significantly mitigated when developing with a certain modern subset of the C++ language. 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 to…

Because they are grasping for reasons not to learn Rust.

Rewriting an existing working codebase rather than committing to its incremental improvement is usually a sign of bad decision making. So I'd be concerned if a team that had an existing mature codebase in C++ and a team of engineers hired on that path were taking on such a venture.

But that's kinda... not a bloggable topic, frankly.

Post reply on HN