Cassandra Rewritten In C++, Ten Times Faster

urdak writes: At Cassandra Summit opening today, Avi Kivity and Dor Laor (who had previously written KVM and OSv) announced ScyllaDB — an open-source C++ rewrite of Cassandra, the popular NoSQL database. ScyllaDB claims to achieve a whopping 10 times more throughput per node than the original Java code, with sub-millisecond 99%ile latency. They even measured 1 million transactions per second on a single node. The performance of the new code is attributed to writing it in Seastar — a C++ framework for writing complex asynchronous applications with optimal performance on modern hardware.

Comments

Re:Because it was written in Seastar or C++

[narcc]

Not sure why people learning Pascal, assembler, or Lisp first would be better at OO. There's nothing OO about any of those. I would turn that around and say that 95% of programmers are bad at OO programming, period, regardless of what language they started with.

For the Lispers at least, they'll, hopefully, understand the absurdity of the OO landscape. (They giggle when they see GoF "design patterns", and wonder how things went wrong.) It is, quite possibly, the worst trend, in history, to hit software development. OO is poorly defined, failed to fullfill any of the promises made by the great OO hype machine, and resulted in monstrously over-engineered products.

It's difficult to criticize OOP as no matter what you say about it, someone will come along and claim "that's not OO!". The worst part about that, of course, is that no matter your criticism, they're right. No one agrees on what constitutes OOP. What applies to Java doesn't necessarily apply to C++, Smalltalk, Python, ECMAScript, CLOS, C#, etc.

You've even fallen for the trap:

A class should be a mostly self-contained.

Are classes essential? "Obviously not!" say the Self folks,"They're extremely limiting! Even harmful!". "They're absolutely essential!" scream the Java lobby "It's impossible to do without them!". With perfectly reasonable arguments following from each side.

You said 95% of people are terrible at it, but I think that's an underestimate. I'd say it's closer to 100%. (Ask anyone and they'll tell you that you're doing it wrong, I'm doing it wrong, that guy over there is doing it wrong... The only one not doing it wrong is the person you asked. Ask someone else, and they'll tell you the first guy is doing it wrong!)

Either way, the promise that OOP was going to revolutionize software, making our lives easier, our programs more reliable, easier to change, and faster to develop has not only not been fulfilled, it's actually done the exact opposite. It's made our software less reliable, more difficult to change, and significantly increased the time it takes to deliver.

Worse, it's slowed progress on other approaches to development, and heaped countless distractions designed to ease the pain of OOP. From bloated IDE's to snake-oil "development methodologies" for leading your harried team through another over-designed project that follows the latest "best practices" from whatever trade-rag hit your supervisors desk that morning.

That ball-of-yarn dependency diagram and impossibly deep class hierarchy you see every day isn't a result of the applications inherent complexity. The OOP hype machine, coupled with the save-OO-at-all-costs consultancy industry, are to blame. Billions upon billions of dollars have been wasted chasing the empty promises made by marketing departments in the 90's. We're like the citizens of Idiocracy repeating "It's what plants crave!" despite the overwhelming evidence that it's all been a horrible mistake. Still, even conscientious developers, like yourself, defend it.

The LISP guys got a lot of stuff right. That's why they've endured and we're finally seeing a move toward functional programming. Here's hoping that we get the good parts, and not merely the superficial bits. (I'm hoping against hope, I know.) I'm no purist, don't get me wrong. Functional languages just aren't a practical choice for most modern development. That said, a healthy dose of functional influence just might save us from the OOP hell we've suffered from for the last 20+ years.