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

81–90 of 307 posts

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

#81

Post by cesaref »

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'm not so sure.

I've a feeling it's easier to write decent Rust than decent C++.

The post contains comments about how difficult they found it to keep coding style consistent and language feature use consistent. This suggests to me an inexperienced team without the skills to manage a project of the size and complexity they need.

Now whether with the right team they could produce a better solution in C++ or Rust, i've no idea, but if this is the team they have, then it sounds like Rust might be the right choice for them.

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

#82

Post by pjmlp »

pdimitar wrote: post #70
pjmlp wrote: post #32

Earlier quoted context omitted.

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

See Orthodox C++.

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

#83

Post by gpderetta »

flohofwoe wrote: post #76
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. Smart pointers lure you into a dark alley where each tiny object lives in its own tiny heap allocation, and before you know it you have so much memory management sprinkled decentralized all over your code base that the memory management overhead becomes a performance problem, but at the same time it's too late to do anything about it because it would mean…

I don't understand. Smart pointers replace dumb pointers not normal stack/inline object placement.

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

#84

Post by Tamschi »

andreidd wrote: post #73
Tamschi wrote: post #59

Earlier quoted context omitted.

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

Not entirely true. You can pool allocate a C++ coro.

Ah, you're right, I missed it because it's callee-controlled in C++. (See Heap Allocation and Promise on https://en.cppreference.com/w/cpp/language/coroutines , for those curious.)

Rust coroutines evaluate to opaque value types instead of handles, for comparison, so the caller gets to decide what to do with them. Currently they're a bit unwieldy though, until naming (aliasing) their types becomes possible. The unstable documentation for that is here: https://rust-lang.github.io/impl-trait-initiative/explainer/...

(Edit: Sorry, I'd grabbed the wrong second link. Fixed.)

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

#85

Post by kubb »

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…

In Rust you can allocate small structs on the stack while being confident that the plain pointer passed down the stack will be valid throughout the function execution.

In C++, you need to use a plain pointer or a unique pointer. The former makes the function leak when passed a pointer to heap.

The latter requires a heap allocation and free for the struct contents.

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

#87

Post by [deleted] »

flohofwoe wrote: post #76
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. Smart pointers lure you into a dark alley where each tiny object lives in its own tiny heap allocation, and before you know it you have so much memory management sprinkled decentralized all over your code base that the memory management overhead becomes a performance problem, but at the same time it's too late to do anything about it because it would mean…

[deleted]

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

#88

Post by hamilyon2 »

fooker wrote: post #4
hdhrufjdi wrote: post #3

> Rust is easy to learn. For seasoned C++ programmers, Rust is easy to learn. When they first start out, Rust learners usually spend most of their time making sense of ownership and lifetime. Even if they don't explicitly express these concepts in code, experienced C++ engineers always keep these two concepts in mind when programming in C++. Finally somebody understands this.

I disagree. Rust is not difficult because of lifetimes, it just gets in the way of freely prototyping what you want. This situation is slowly improving with the compiler getting better and better. Then there is some annoying macro usage. Some Rust code looks truly alien.

Is rust code heavily seasoned with unsafe keyword really that hard to prototype in?

Is it meaningfully harder than c++ in this regard?

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

#89

Post by [deleted] »

rightbyte wrote: post #50
foxhill wrote: post #33

Earlier quoted context omitted.

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

[deleted]

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

#90

Post by ZephyrBlu »

josephg wrote: post #80
bakuninsbart wrote: post #46

Earlier quoted context omitted.

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.

Yep. The one big beginner “mistake” I see people make in rust is overusing Box / String / Vec. Rust code that allocates everywhere can be even slower than javascript. The reason? Malloc is slower than you think. Slower than short allocations in V8 or Go. If you want performance, make friends with &str, &[], >, bumpalo, SmartString and SmallVec. (Or similar crates). Removing allocations from the hot path can improve p…

I slightly disagree. Using heap allocated types is perfectly fine. The biggest thing I have to keep reminding myself coming from higher level languages is to re-use data structures, and to architect things in a way that this is possible.

Allocating a new String/Vec every single time you do something is killer for performance, but if you do it once up front then clear the data structure for the next use it should be performant enough.

Post reply on HN