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

Building a Cloud Database from Scratch: Why We Moved from C++ to Rust (2022)

risingwave-labs.com

Post reply on HN
Print view View original

61–70 of 307 posts

Re: Building a Cloud Database from Scratch: Why We Moved from C++ to Rust (2022)

#61

Post by crabbone »

threeseed wrote: post #47
gizmo wrote: post #18

The popular databases we use today such as Postgres and Mysql are pretty terrible. Backups are extremely complicated to set up, and restoring from backups is hard. Multimaster setups almost work, but not completely. You want a geo-distributed high availability database? Forget about it. The popular databases today just don't do the things every web startup wants from a database. So I totally get why people want to ma…

> MongoDB is the only new database that managed to break through Snowflake, Cassandra, DuckDB, Clickhouse, Redis, InfluxDB, DynamoDB, BigQuery etc. There are many databases that have broken through they just are far more niche focused. > but it would still regularly eat your data No it didn't which is why it became so popular. The whole fsync saga was always overblown because (a) every client that shipped set it a sa…

I would love to hear more about "fsync saga" if you have any references.

I know that PostgreSQL had "problems" with fsync(), but they never ended. They just accepted defeat, but so would everyone else who relies on filesystems to store their data. It's even more ingrained than that. The way hardware works, and, especially, the communication protocols around it (eg. SCSI or NVMe) are structured, fsync() is always going to be a problem.

Re: Building a Cloud Database from Scratch: Why We Moved from C++ to Rust (2022)

#63

Post by ejb999 »

andrewstuart wrote: post #2

Building a database is brave or stupid or both. Over the last 15 or 20 years I’ve tried lots of databases of all flavors and every time come back to Postgres. What can’t it do. And like Linux it’s written in C. Not that means much. “Never bet against Postgres”.

>>Over the last 15 or 20 years I’ve tried lots of databases of all flavors and every time come back to Postgres.

Almost the same here, have tried just about everything that comes along, and sooner or later I end up swapping out the database de jour and go right back to sql server in almost all use cases (for the type of projects I do).

I feel like db's are pretty much a solved problem, and can't imagine trying to build and market a brand new one these days. Almost as hard as trying to come up with a new operating system and convincing people to switch.

I wish good luck to anyone that tries, but talk about pushing a boulder up a mountain; definitely doesn't seem like the easy path to success.

Re: Building a Cloud Database from Scratch: Why We Moved from C++ to Rust (2022)

#64

Post by menaerus »

yagni_dev wrote: post #38

>But as more and more engineers joined us, some shortcomings of C++ came to bite us: unreadable coding style, memory leak, segmentation fault, and more. - Seasoned devs but they never heard of clang tidy/format - Memory leaks on a new db codebase where each component should have clear ownership of data or pass to the next pipeline/stage - you dont even need smart poirters here, just a half decent design. - I am not e…

A glance over their repo and pull request discussions discover everything but the "seasoned" devs, even more so 10+ of them.

Re: Building a Cloud Database from Scratch: Why We Moved from C++ to Rust (2022)

#65

Post by yagni_dev »

crabbone wrote: post #44
yagni_dev wrote: post #38

>But as more and more engineers joined us, some shortcomings of C++ came to bite us: unreadable coding style, memory leak, segmentation fault, and more. - Seasoned devs but they never heard of clang tidy/format - Memory leaks on a new db codebase where each component should have clear ownership of data or pass to the next pipeline/stage - you dont even need smart poirters here, just a half decent design. - I am not e…

In my experience, segfaults are often a result of using C libraries in C++. In the project I work on, OpenSSL integration supplies a constant trickle of segfaults (it's not my general area, I'm just witnessing those and report to whoever works on it). This is especially true if you are trying to use those libraries in multi-threaded environment.

Segfaults happen, you run valgrind/asan/tsan etc. As long as the codebase is not horrendous its easy to fix. Third party packages complicate things, have to choose/use wisely/appropriately

Re: Building a Cloud Database from Scratch: Why We Moved from C++ to Rust (2022)

#66

Post by bobajeff »

pjmlp wrote: post #36
smallstepforman wrote: post #17

Author quoted C/C++, I immediately knew what conclusions I’d find. If on the other hand they had seasoned C++ devs (instead of C/C++), they might have had a different outcome.

That is the current issue with most C++ codebases nowadays, I only see modern C++ on conference slides, when I look into codebases even from ISO C++ members, it is always C++ full of C idioms no matter what. I bet most candidates to C++ job offers end up discovering the hardly reality of existing code.

That's a fundamental C++ problem. That and all the other idioms it supports. C++ is really like 10 languages and you always have find a mentor to show you the specific one you're working with in a codebase.

Re: Building a Cloud Database from Scratch: Why We Moved from C++ to Rust (2022)

#67

Post by gpderetta »

hdhrufjdi wrote: post #53
gpderetta wrote: post #26

Earlier quoted context omitted.

What's the overhead of an unique_ptr vs the equivalent rust pointer (yes yes, I know that the Itanium ABI has non optimal calling convention for unique ptrs, but I would be surprised if you can measure it)?

Just a thought: null pointer check before deallocation

delete of a null pointer is well defined.

Re: Building a Cloud Database from Scratch: Why We Moved from C++ to Rust (2022)

#68

Post by menaerus »

hdhrufjdi wrote: post #53
gpderetta wrote: post #26

Earlier quoted context omitted.

What's the overhead of an unique_ptr vs the equivalent rust pointer (yes yes, I know that the Itanium ABI has non optimal calling convention for unique ptrs, but I would be surprised if you can measure it)?

Just a thought: null pointer check before deallocation

Aside from you being completely uninformed because free(nullptr) or, for that matter, delete nullptr does absolutely nothing and is well defined operation so you don't need to check for that condition in the first place.

But even if you had to, what implications would it have, if you care to explain?

Re: Building a Cloud Database from Scratch: Why We Moved from C++ to Rust (2022)

#70

Post by pdimitar »

pjmlp wrote: post #32
mzimbres wrote: post #11

> But as more and more engineers joined us, some shortcomings > of C++ came to bite us: unreadable coding style, memory leak, > segmentation fault, and more. * unreadable coding style: This is not a C++ problem. * memory leak: Memory leak is an old C++ problem, since C++11 there is no reason for not using smart pointers. The only point that could be attributed to C++ is the segfaults perhaps, due to its lack of safet…

> ....since C++11 there is no reason for not using smart pointers. Sadly there is, lack of security culture and plenty of devs won't allow them on a PR.

Not allowing these in PRs is a thing?!

Wow. Genuinely surprised.

Post reply on HN