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

61–70 of 94 posts

Re: Why we develop EloqDB mainly in C++

#61

Post by Klonoar »

cmrdporcupine wrote: post #14
almostgotcaught wrote: post #10

Earlier quoted context omitted.

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

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 hope we get there.

Re: Why we develop EloqDB mainly in C++

#62

Post by whizzter »

almostgotcaught wrote: post #10
Klonoar wrote: 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?

Think of it as, I'm a good driver and like fun so i chose a manual Ferrari as one of two family cars, then I borrow the car to one of my kids (junior dev) that doesn't have experience with high powered manual cars and crashes.

Re: Why we develop EloqDB mainly in C++

#63

Post by TimorousBestie »

cmrdporcupine wrote: post #30
rapsey wrote: post #25

Earlier quoted context omitted.

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.

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.

Re: Why we develop EloqDB mainly in C++

#64

Post by rileymat2 »

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

Isn't that pretty common in all languages that are not big?

They attract people truly interested in programming, not those going through the motions at a job. I have heard this same thing with Haskell, Lisp, and many other languages out of the mainstream Java/C#/Javascript/Ruby.

Re: Why we develop EloqDB mainly in C++

#65

Post by chihuahua »

noworriesnate wrote: post #56
meindnoch wrote: post #44

[flagged]

If Rust was like Communism, there would be dozens of examples of massive codebases that ported to Rust and ended up with massive infighting, culminating in 20% of the developers being assassinated by the moderation team.

and then someone would excuse that by saying "that wasn't real Rust"

Re: Why we develop EloqDB mainly in C++

#66

Post by TimorousBestie »

WCSTombs wrote: post #26
TimorousBestie wrote: post #3

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

> The article isn't claiming there is a "one true modern subset" of C++ that they use.

They’re arguing that they’ve found a sufficiently safe subset, which if true would be the first.

It would be a waste of time to relitigate the many programmer-hostile, unsafe decisions the committee has made over the years. I think your programmers who are supposed to “understand and have control over” C++’s arsenal of footguns are more or less fictional and a language designer shouldn’t take them as intended audience.

https://robert.ocallahan.org/2017/07/confession-of-cc-progra... (2017)

> Also, I believe the C++ standards committee does care about this, which is why Profiles [1] are being considered.

It was discussed at length why this proposal is insufficient: https://news.ycombinator.com/item?id=45234460

Re: Why we develop EloqDB mainly in C++

#67

Post by brabel »

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

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... 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. 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... and in any case, why would you go out of your way to change? Java used to be pretty terrible, but these days, it's a decent language. I can do Rust, but I still would pick Java for most projects given the choice, unless it was something where performance mattered more than the easiness of hiring Java developers and finding Java libs (though I admit Rust is catching up, there's a lot of libs now! However, one missing lib and you may be stuck for months having to port or implement something yourself - while in Java, or C++ for that matter, chances are slim you'll be in that situation).

Re: Why we develop EloqDB mainly in C++

#68

Post by brabel »

systems wrote: post #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…

> that being said C++ being a big language

Rust has become fairly big now, no? Is there some objective metric that can show Rust is a "smaller" language (I bet it is, but I don't think it's by a lot)?

Re: Why we develop EloqDB mainly in C++

#69

Post by steveklabnik »

brabel wrote: post #68
systems wrote: post #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…

> that being said C++ being a big language Rust has become fairly big now, no? Is there some objective metric that can show Rust is a "smaller" language (I bet it is, but I don't think it's by a lot)?

There’s not really any metric of a language being objectively “big” or “small” but I could point at several features where the Rust feature is significantly less complex than the C++ one. Additionally, C++ has more features that Rust doesn’t than the reverse.

Re: Why we develop EloqDB mainly in C++

#70

Post by on_the_train »

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?

Post reply on HN