Live data from Hacker News

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

risingwave-labs.com

51–60 of 307 posts

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

#51

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

Rewriting stuff is actually quite good and expected of a startup.

As the system grows, you realize all that was wrong with your previous version, and can write a new better one.

That doesn't mean you need to switch to another language to do it though.

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

#52
post #37

Every time I read of memory leaks in C++ codebase, I get no idea why RAII didn't work in those cases. Even if the codebase was huge and complex. Circular references? Some special cases why one can't use RAII? Forget unique pointer or smart pointers. People had been coding in C++ far before that without fearing memory leaks by following RAII principals.

Unless you are very deep in system / embedded, most of the code that constitutes your program is not your code -- it's various libraries, frameworks, code generated by utilities etc. Often times this is the source of both unsafe interfaces and misunderstanding of the functionality on the part of the developer writing the code.

Second to it is, probably, concurrency. RAII isn't going to save you here either.

Then there's also input processing where you may run into a situation that causes resources not being de-allocated because you never anticipated a particular shape of the input.

RAII works for very local and very well-defined things, it's not a good answer to dynamic situations or resources with complicated ownership.

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

#53

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…

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

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

#54
I really like Rust. I like C, and C++ too. I find a lot of C++ and C detractors are nit-picking and over-promising the-new-shiny-thing, or are probably not great engineers to begin with and are blaming the tool. In this instance, I'm leaning towards the latter.

Although Rust is an improvement in many ways, I actually think it is becoming more C++ like with every release. I think it has a good chance of over-taking C++'s complexity, even if it has a much better user story around build & package/module/library management.

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

#55

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

> What can’t it do.

Async I/O.

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

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

For unique_ptr, in a release build, no: but in a debug build there's overhead, and more to the point, stepping into the deference in gdb/lldb at least in my experience requires stepping through the internals, to the point some of the code we use with them is #ifdeffed hackily to use raw ptrs in some cases to avoid this annoyance.

For shared_ptr, the atomic ref counting can cause surprising overhead due to contention in multi-threaded scenarios, even if just accessing the pointer, depending on how the shared_ptr is passed through functions...

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

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

Rust doesn't have support for native co-routines. You rely on community project for that (Tokyo).

At first I even thought it was an argument against Rust, not in favor...

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

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

Projects going stale is a cross-language problem really. Rust will also encounter this at some point.

No, because they'll just rewrite them in the latest Rust.

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

#59
post #21
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.

C++20 comes with coroutines, no?

They aren't strictly comparable. While the heap allocation may be optimised out, there is no way to use native C++ coroutines as guaranteed zero-cost construct due to the automatic heap allocation in the API.

Rust's coroutines currently have practical optimisation issues related to instance size (because the compiler isn't smart enough yet in a few places), and the more powerful generator API very much isn't ready yet, but they give you considerably more control over the memory management. It's easy to stack- or pool-allocate coroutines there if necessary for performance, while in C++ you wouldn't be able to use the native language feature where frequent or unmonitored heap allocations from fine-grained coroutine use would be a problem. (Apparently this makes them unsuitable for AAA game development, for example.)

Library-provided coroutines may be more versatile.

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

#60

> 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: This is not a C++ problem.

I would argue that it is, after a few years of Rust. My style in C++ was formed by my exposure to other people's code. I guess this is true for most people.

Certainly, in C++, as well as in any language, Rust included, there are a myriad of ways to express yourself when solving a problem. Is my C++ coding style unreadable? I don't think so. But I used that language for 30+ years. Let's say I only used it for five years -- what then? I would have much less exposure to other people's code and hence to well written/readable code.

Rust has rustfmt (a code formatter) and clippy (a very opinionated linter). And they get used lots. Most Rust CI now includes `cargo fmt --check` and `cargo clippy` runs than need to come out clean.

This goes a long way in making code canonical. Clippy's amazing suggestions also made me a much better Rust developer in a much shorter time.

Are rustfmt & clippy part of "Rust the language"? No. But in a way they are since there is nothing else they compete with for opinion on how Rust code should be formatted and written.

When you onboard new people and they have adapted the pov that this makes lots of sense, it goes a long way in avoiding code being produced that is difficult to read for others.

And because of this, I do indeed think that it is a problem of a programming language, in 2023, if the default tooling does not include such utilities. And a strong incentive through the community, pretty much all the available learning materials and repos in the wild, encouraging their use.

Post reply on HN