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

121–130 of 307 posts

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

#121

Post by gpderetta »

jstimpfle wrote: post #110
gpderetta wrote: post #83

Earlier quoted context omitted.

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

It's not about what you use to point to the thing. It's about how you allocate the thing in the first place. Smart pointers are like a free pass to do things without consideration: they allow you to make progress without caring how your things are allocated, because they ease the pain that results from just allocating stuff on the global heap, lacking a systematic approach. Note that while smart pointers ease pain in…

I don't subscribe to the 'it is expensive so it should be painful' line of thought. That's how you end up with cstrings, strcpy, strdup and friends.

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

#122

Post by criddell »

pjmlp wrote: post #82
pdimitar wrote: post #70

Earlier quoted context omitted.

Not allowing these in PRs is a thing?! Wow. Genuinely surprised.

See Orthodox C++.

In the context of this thread, why would somebody starting a new project be choosing between Orthodox C++ and Rust?

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

#123

Post by jstimpfle »

gpderetta wrote: post #121
jstimpfle wrote: post #110

Earlier quoted context omitted.

It's not about what you use to point to the thing. It's about how you allocate the thing in the first place. Smart pointers are like a free pass to do things without consideration: they allow you to make progress without caring how your things are allocated, because they ease the pain that results from just allocating stuff on the global heap, lacking a systematic approach. Note that while smart pointers ease pain in…

I don't subscribe to the 'it is expensive so it should be painful' line of thought. That's how you end up with cstrings, strcpy, strdup and friends.

No, strdup uses a general purpose allocator to put a string in a random place on the heap. Quite the opposite of a well-structured approach.

"It is complicated so let's see if there is a simpler approach".

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

#124

Post by usrnm »

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…

> Memory leak is an old C++ problem, since C++11 there is no reason for not using smart pointers.

C++11 did not invent smart pointers, pretty much every C++ project had already been using them long before they were added to the standard. They help with leaks to some extent, but are not a panacea, I can do a memory leak with shared_ptr in just a few lines of code. I've seen this line of reasoning many times before and it needs to stop.

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

#125

Post by mgaunard »

odo1242 wrote: post #113
mgaunard wrote: post #51

Earlier quoted context omitted.

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.

It’s good from a technical perspective but not a business perspective. Startups only get a limited amount of time/money investment in order to prove their profitability. “Writing a better version” can come later, when the startup isn’t trying to come up with a version in the first place.

Startups are tech businesses, they literally live and die by the quality of their tech.

In particular for a product like this which is itself targeting developers.

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

#126

Post by virtualritz »

bestouff wrote: post #94
virtualritz wrote: post #60

Earlier quoted context omitted.

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

Came to say this exactly. C++ encountered coding styles are often a hodgepodge of "personal preferences" and urban legends. Rust coding style is partly enforced by rustfmt and clippy. The former makes you not worry about mixing styles into a project (after 30 years doing C/C++ I love this), the latter has really good suggestions which makes you reflect on your code.

Using a code formatter in C++ (e.g. via githook or the like) seems still the exception in most commercial C++ codebases I got to look at, when consulting in recent years.

I.e. often there is a mix of styles, indentation/line wrap preferences and even the occasional tab in a codebase that otherwise uses spaces. Etc. etc. And that's just the formatting part. Linters seem to be mostly used manually by experienced developers but rarely are part of the commit pipeline or even if they are, their suggestions enforced.

Your mileage may vary. I mostly look at code from a very specific industry. But I can't help but notice these things now, because of my exposure to Rust.

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

#127

Post by School-Cotton »

usrnm wrote: post #124
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…

> Memory leak is an old C++ problem, since C++11 there is no reason for not using smart pointers. C++11 did not invent smart pointers, pretty much every C++ project had already been using them long before they were added to the standard. They help with leaks to some extent, but are not a panacea, I can do a memory leak with shared_ptr in just a few lines of code. I've seen this line of reasoning many times before and…

Indeed, but to be fair, Rust's smart pointers can be used to create memory leaks just as easily as C++'s. (Overall I think Rust is a much better language than C++, though).

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

#128

Post by dizhn »

eminence32 wrote: post #104
dizhn wrote: post #98

"So, using C++ was a no-brain decision." Oooff.

The expression "no brainer" means that some decision is so obvious as to not require any thought. I think this article is saying that using C++ with a team of seasoned C++ developers was such an obvious thing to do that they didn't give it much thought.

It doesn't say no-brainer. I think it should have said "The decision was a no brainer".

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

#129

Post by dxuh »

usrnm wrote: post #124
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…

> Memory leak is an old C++ problem, since C++11 there is no reason for not using smart pointers. C++11 did not invent smart pointers, pretty much every C++ project had already been using them long before they were added to the standard. They help with leaks to some extent, but are not a panacea, I can do a memory leak with shared_ptr in just a few lines of code. I've seen this line of reasoning many times before and…

There was no way to implement a smart pointer in even a halfway usable and reliable way without move semantics, so C++11 is absolutely essential to use them well. Also I fully agree with the general sentiment. I have not produced a memory leak in many, many years in dozens of hobby projects or in a handful of professional C++ use. It's truly is a giant game changer. You can produce a leak with shared_ptr, but only if you do shit that looks dangerous and stinks to high heavens (a bit similar to the unsafe keyword).

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

#130

Post by galangalalgol »

criddell wrote: post #111
ZephyrBlu wrote: post #90

Earlier quoted context omitted.

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…

> re-use data structures That's funny. I've been going mostly the other direction. I'm avoiding mutable structures whenever possible. I have a much easier time reasoning about stuff when I know that things aren't going to change mid-life.

That is certainly true, but if you are talking about things that are too big to stack allocate, the cognitive overhead of reusing heap allocated items is the price for getting back the throughput overhead of memory allocation.
Post reply on HN