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

71–80 of 94 posts

Re: Why we develop EloqDB mainly in C++

#71

Post by Ukv »

brabel wrote: post #67
sebstefan wrote: post #42

Earlier quoted context omitted.

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

This kind of generalization is so old. Imagine someone told you that "I've noticed that people of race A are noticeably better than people of race B". If you think it's different, just consider that people don't really have much of a choice in either case: there's a lot of Java developers because there's a lot of Java jobs, universities teach it, and it's been around a fairly long time when compared to Rust, at least…

> This kind of generalization is so old.

I feel you're objecting to the wrong comment. sebstefan appropriately specified "the people who came to interview for the Rust roles of my company [...]", and was giving it as a counterpoint to the previous comment's broad generalization.

> there's a lot of Java developers because there's a lot of Java jobs, universities teach it, and it's been around a fairly long time when compared to Rust, at least... i.e. there's a lot of forces pushing people to using Java, and once you learn a language and get a job in such language, there's a lot of inertia that will keep most people on that same language for a long time.

The fact that one language is the mainstream default taught in many schools, whereas the other requires going out of your way to pick up, could well be a factor in the latter having more knowledgeable average applicants - in the same way I'd expect Gentoo users to be more technologically competent than Windows users on average.

> Yes, they can eventually choose something else, but only if that's a thing in your region, which may not be the case at all...

I presume the majority of Rust programmers learn it online.

Re: Why we develop EloqDB mainly in C++

#72

Post by dataflow »

unshavedyak wrote: post #35
dataflow wrote: post #20

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

Note that duck-typing can still be a compile-time thing: it's basically what you'd get in C++ if you use auto and templates for everything.

The trade-off between compile-time and run-time checking depends in large part on the time needed to address the issue. It's not really black and white. People just don't want to wait forever for static verification - I think that's kind of why clang-static-analyzer isn't used as much as clang-tidy.

Re: Why we develop EloqDB mainly in C++

#73

Post by keanb »

on_the_train wrote: post #70
f311a wrote: post #8

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

> You can change one part of the code, and it will introduce bugs in the whole project because of how the memory is handled Why would it do that?

I suppose because it will start writing in memory that is handled by other parts of the code and corrupting it.

Re: Why we develop EloqDB mainly in C++

#74

Post by cjfd »

sebstefan wrote: post #42
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

Well, now you name something. Java is the most bureaucratic language only a matching personality or a programmer who is not very good would tolerate it.

Re: Why we develop EloqDB mainly in C++

#75

Post by joz1-k »

TimorousBestie wrote: post #63
cmrdporcupine wrote: post #30

Earlier quoted context omitted.

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.

Rust was designed to facilitate incremental rewrites of an existing C++ library, making cross-language testing and validation very ergonomic; why C++ developers rarely take advantage of this (or even account for it as an option in their analysis of alternatives) is an exercise left to the reader.

> Rust was designed to facilitate incremental rewrites of an existing C++ library

Do you have a source for this claim? Rust is a fine language (though its advocates can be a bit belligerent sometimes). But, as a matter of fact, Rust was not designed for a easy interoperability with C++ or to make gradual rewrites easy.

Re: Why we develop EloqDB mainly in C++

#76

Post by reddit_clone »

chuckadams wrote: post #19
almostgotcaught wrote: post #10

Earlier quoted context omitted.

Is this like a dig? Does anyone disagree that manual is much more fun?

Not fun in San Francisco rush hour traffic on Russian Hill.

Lol yes.

I almost had a panic attack driving an _automatic_ up Lombard. (Sadly an old minivan with bad-lish tires).

In stop and go traffic (is there any other traffic in SFO?) it moved so much backwards and spun so hard every time I tried to move forward/upward.. I swore never to return. I haven't been back on that road since.

Re: Why we develop EloqDB mainly in C++

#77

Post by reddit_clone »

nielsbot wrote: post #54
almostgotcaught wrote: post #10

Earlier 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

Perhaps not always for the better?

People eating, drinking and using mobile phones .. I think the luxury of having a hand free with automatic transmission is a contributing factor.

Stick shift requires a certain level of attention/engagement that might actually make for safer driving IMO.

Re: Why we develop EloqDB mainly in C++

#78

Post by reddit_clone »

Klonoar wrote: post #61
cmrdporcupine wrote: post #14

Earlier quoted context omitted.

20 years ago, sure. Now if you want fun torque you drive electric and blink with confusion at manual-snobs. I learned on stick and I still feel a nostalgic appeal, sure. I test drove a used hothatch Volvo C30 T5 Polestar edition last fall before ultimately settling on an electric performance car (Polestar 2) to feed my midlife indulgences. And I have to admit a certain ... thrill... from the turbo lag and the process…

Manual snobs are a tiring bunch, it's not an inherently better transmission or way to drive. That said, instant torque isn't really that special and feels like a novelty after the first few times you've floored it. When an EV actually has a suspension setup and overall weight that doesn't feel like I'm piloting a boat at sea, then I'll probably care. Porsche & co seem like they're still aiming for it so I've got some…

Speaking of snobs, I have had multiple arguments with Automatic snobs, who think I am a bit thick for still driving a manual.

They refuse to take 'I do it because I like it' as an answer.

Re: Why we develop EloqDB mainly in C++

#79

Post by wavemode »

f311a wrote: post #8

One 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

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.

Re: Why we develop EloqDB mainly in C++

#80

Post by steveklabnik »

joz1-k wrote: post #75
TimorousBestie wrote: post #63

Earlier quoted context omitted.

Rust was designed to facilitate incremental rewrites of an existing C++ library, making cross-language testing and validation very ergonomic; why C++ developers rarely take advantage of this (or even account for it as an option in their analysis of alternatives) is an exercise left to the reader.

> Rust was designed to facilitate incremental rewrites of an existing C++ library Do you have a source for this claim? Rust is a fine language (though its advocates can be a bit belligerent sometimes). But, as a matter of fact, Rust was not designed for a easy interoperability with C++ or to make gradual rewrites easy.

One design constraint of Rust was to be able to be incrementally included in a large C++ codebase: Firefox.

It turns out that this kind of interop with C++ directly is extremely difficult, and so it isn’t super smooth right now. Interop with C was prioritized and you get zero overhead there. And various projects ease Rust C++ via the C ABI.

Post reply on HN