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

71–80 of 307 posts

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

#71

Post by adev_ »

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.

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

Technically it is correct, it causes an extremly light overhead due to the inability of the compiler to optimise a part of it.

In practice, even in HPC, I never notice it to have an impact ever.

And as an advise for any new C++ programmers: Please JUST use unique_ptr, everywhere, all the time...

Trying to manage the lifetime manually with new/delete in modern C++ is not worth the cost in 99.99% of the case. If the impact of unique_ptr is noticeable in your program, you are very likely in a realm where you should not even doing memory allocation anyway.

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

#72

Post by dilawar »

bakuninsbart wrote: post #46
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 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.

Same here. Clippy and rust compiler made me switch to Rust from c++. Now after experiencing cargo, I find python to be insufferable (tooling, not the language).

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

#73

Post by andreidd »

Tamschi wrote: post #59
lionkor wrote: post #21

Earlier quoted context omitted.

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

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

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

#74

Post by pdimitar »

gpderetta wrote: post #28
fooker wrote: post #4

Earlier quoted context omitted.

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.

>Rust is not difficult because of lifetimes, it just gets in the way of freely prototyping what you want. I'm not a rust programmer, but I guess that's an issue if you come from a dynamic language, not from c++.

Yeah, sadly it is. With e.g. Elixir I can literally get into a REPL and prototype my solution in minutes, right there on the spot, and then just copy a few lines from it and have the solution be 90% done (minus tests, of course).

With Go and Rust I have to make a dedicated function somewhere and then have it be called after starting the program. Ain't exactly rocket science but the difference in time to do it and the convenience is still very stark.

I love working with Rust for the stability and speed it gives me but the value proposition and daily coding flow are VERY different compared to a dynamic language. With Elixir I am mostly just brain-dumping and stuff happens extremely quickly and fluidly, with Rust I kind of sigh and accept that the next 10 minutes I'll just be writing and writing. Might even zone out and make a dumb mistake because I have to spend more keystrokes and more time to do something I'll do in a minute in Elixir.

Maybe it's time to look for snippets support in my editor. Or start asking ChatGPT for them.

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

#75

Post by hdhrufjdi »

menaerus wrote: post #68
hdhrufjdi wrote: post #53

Earlier quoted context omitted.

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?

The implications would be checking if it is null before performing the deallocation of the memory, which is a runtime overhead.

Stack overflow says "delete" would check for null before deallocation: https://stackoverflow.com/questions/4190703/is-it-safe-to-de...

Happy to be educated

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

#76

Post by flohofwoe »

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 rewriting everything (this is then usually when the desperate search for a silver bullet like a "high performance memory allocator" starts).

(not that Rust is necessarily better in that regard when people start to work around borrow checker restrictions with Box and Rc...)

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

#77

Post by imron »

berkut wrote: post #56
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.

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…

There are settings you can place in .gdbinit to avoid stepping in to internals of anything you don’t want to step into, be it std library classes/functions or your own code.

Much nicer than hacky ifdefs.

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

#78

Post by pdimitar »

flumpcakes wrote: post #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+…

As a guy who is writing Rust and found it a true value-add in his career, I agree with this and it's my #1 worry. Rust can already be very arcane to decipher sometimes, especially when you start getting errors from async libraries.

My entirely egotistical opinion is that the maintainers of the language have to take a very good and critical look of the current status quo and start systematically killing off any complexity they can.

Personally I don't want C++ 2.0. Tire people enough and they'll just move to another language again. I know I have, several times in my career, and will do so again if I have to.

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

#79

Post by CoolGuySteve »

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…

Decent test coverage and ASAN should be all you need to never have a memory leak in C++. ASAN will even tell you what backtrace allocated the thing in the first place.

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

#80

Post by josephg »

bakuninsbart wrote: post #46
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 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 performance by 10-100x.

That said, most code isn’t a hot path. Performance doesn’t matter in most programs. And if you’re a veteran C++ programmer, none of this will come as a surprise.

Post reply on HN