Live data from Hacker News

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

risingwave-labs.com

41–50 of 307 posts

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

#41

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

> unreadable coding style

And, again, people talk about it as if it was a real thing and they knew how to measure it...

Also, C++ and Rust are very similar in appearance. So, I struggle to see how jumping ship here would be a big win.

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

#42
post #36

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.

[dead]

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

#43

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

It depends on your use case. For example, Postgres will hit limitations for large streams of time series data on the ingestion side, and the standard SQL language of Postgres may make it challenging to navigate a dataset by time: sampling the data, time intervals, time-series joins (ASOF join), and these kinds of things are not easy or possible to do on Postgres. Why not combine Postgres for OLTP workloads alongside…

TimescaleDB

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

#44

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

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

#45

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

It depends on your use case. For example, Postgres will hit limitations for large streams of time series data on the ingestion side, and the standard SQL language of Postgres may make it challenging to navigate a dataset by time: sampling the data, time intervals, time-series joins (ASOF join), and these kinds of things are not easy or possible to do on Postgres. Why not combine Postgres for OLTP workloads alongside…

Any thoughts on Timescale?

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

#46

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

I'm quite nooby in both Rust and C++, but for the little interactions I had, I felt like Rust had a much clearer path forward than C++ when I was in doubt, and "how to write in good style" was more obvious. This leads me to the assumption that building a Rust culture is probably easier than building a C++ culture, because it is easier to get junior developers and those coming from other languages up to speed.

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

#47
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 safe default anyway and (b) it was fixed almost immediately.

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

#48

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

The argument for Rust is rarely that C++ cannot do the same task, it's that Rust provides better guardrails.

Unreadable code is not a C++ specific problem, but does Rust make it easier to write readable code? Probably. Same for memory leaks and other similar problems.

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

#49

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

I'm quite nooby in both Rust and C++, but for the little interactions I had, I felt like Rust had a much clearer path forward than C++ when I was in doubt, and "how to write in good style" was more obvious. This leads me to the assumption that building a Rust culture is probably easier than building a C++ culture, because it is easier to get junior developers and those coming from other languages up to speed.

I’m always fretting I haven’t written good code no matter what language I write in. But the Rust compiler + linter (clippy) make me fret a bit less.

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

#50
post #33

Earlier quoted context omitted.

> since C++11 there is no reason for not using smart pointers There are many reasons for not using smart pointers, first amongst them for me being performance. Smart pointers do allow you to remove a large class of memory bugs from your code (albeit not memory leaks) in the same way that Rust's safe references do. However C++ smart pointers impose a run time performance penalty on your code, whereas in Rust the check…

> However C++ smart pointers impose a run time performance penalty on your code. i'm not sure if this is the case. unique_ptr doesn't really do much other than use the type system to ensure that only one instance of the pointed-to value exists at once. as far as i understand, it doesn't strictly do anything at runtime.

unqie_ptr have overhead. It need to run its dtor etc.

https://www.youtube.com/watch?v=rHIkrotSwcc

At 18 min.

Post reply on HN