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

11–20 of 307 posts

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

#11

Post by mzimbres »

> 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 safety. But your other two points made me skeptical about Rust bringing you much benefit. I am specially concerned about throwing away months worth of code. Rewriting everything from scratch is what newbies love to do and will most likely get you in the same mess you were in. Try to learn with the error of others [1]. And btw, the problem is usually who writes the code and not which language is used.

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

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

#13

Post by planede »

foxbee wrote: post #9

"The STL library lacks support for some modern programming tools, for example, native co-routine support. As a result, developers must rely on many community projects, and most lack long-term support." I couldn't agree more with this comment. As great as the community is, there's a lot of projects that are just not maintained. I wish this was different.

Boost ASIO has some coroutine support. I would not call it a hobby project either.

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

#14

Post by bayesian_horse »

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…

When rewriting a codebase there's a difference between 6 month's worth and a couple of years' worth.

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

#15

Post by bsaul »

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…

i don't think joelonsoftware points apply here.

- Their product is still relatively new (7 months of coding isn't that much) and not even released,

- they picked a technology specifically designed for the problems they've identified on their existing codebase.

- they completed the rewrite (and weren't stuck having to maintain the old codebase), and are happy with the result.

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

#16

Post by ahachete »

Interesting journey.

> C/C++ is undoubtedly one of the most popular programming languages for building database systems. Most well-known database systems, including MySQL, PostgreSQL, Oracle, and IBM Db2, are created in C/C++.

Considering C and C++ to be the same language is quite a stretch. They are fundamentally different.

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

#18

Post by gizmo »

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 make better database software, but at the same time, I don't understand how startups think the "move fast break things" approach will work here.

The value of a buggy, incomplete, poorly documented database is 0, and the value of a database system that actually works is infinite. It's totally discrete.

How this is not going to end up like every other database startup? Funding gets cut eventually because they can't demonstrate traction, but they can't demonstrate traction until the database product is actually way way better than the old dogs. Which will take 10 years if not 20.

MongoDB is the only new database that managed to break through, and it was a single-threaded document store without proper ACID properties. For a database, it was simple, but it would still regularly eat your data. Today, something like MongoDB would never get traction.

I wish these rising wave guys luck, but I don't see any indication they understand the obstacles they're facing.

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

#19

Post by dzogchen »

ahachete wrote: post #16

Interesting journey. > C/C++ is undoubtedly one of the most popular programming languages for building database systems. Most well-known database systems, including MySQL, PostgreSQL, Oracle, and IBM Db2, are created in C/C++. Considering C and C++ to be the same language is quite a stretch. They are fundamentally different.

It is not a stretch it is just plain wrong. C++ has good C interoperability (most C is even valid C++) and most compilers that support compiling one also support the other, but I can't take seriously anyone that refers to "C/C++" as one language.

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

#20

Post by steeleduncan »

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

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 checks happen at compile time leading to better runtime performance.

Post reply on HN