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

91–100 of 307 posts

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

#91

Post by nu11ptr »

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'm sure it is the same for C++, but in my Rust code things that are put in a Box/Arc etc. are carefully considered and typically my top level business objects. I even wrote my own inline String struct a while back (flexstr) to ensure I don't do allocations for strings smaller than 22 bytes. I don't use allocations "all over the place" without thought and like any language feature, design and placement is important.

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

#92

Post by qwertox »

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 used to code primarily in C++ around 12 years ago, then moved over to Python. I've now started with Rust and I really love it. I find myself constantly fighting with the compiler, it telling me what it won't allow me to do.

In C++, threading was my only way to execute parallel tasks, Python 3 showed me a about coroutines, which I've really started to love.

So in Rust I'm experimenting a lot with Tokio right now, and I'm trying to duplicate what I've made in Python. I often think about how good this compiler is that it won't let me do things which I clearly would have done in C++ either to cut corners or, more importantly, out of lack of understanding the consequences.

I was creating this WebSocket server which would serve as a bridge to a MQTT broker, all in async code, all in one big file. I was constantly fighting with the compiler about reusing variables or handing them over to tasks.

When I then attempted to refactor the code by splitting it into several files, the core of the server in main.rs, some WebSocket-related stuff in websocket.rs, all WebSocket-stuff related to the communication with the clients into websocket_handler.rs and all MQTT stuff in mqtt.rs, all my fighting against the compiler fell together. In my inner eye I could see how the variables were handed over to which file during execution, and that this was the reason why I was no longer allowed to use them in the previous file. So much logic, so clear, and the compiler forced me to do it that way.

Then there's the ease of integrating external libraries, which, at least in Windows back then used to be non-trivial in C++.

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

#93

Post by pharmakom »

Fascinating how defensive C++ lifers can be. Rust builds on the knowledge of decades of C++ programming. It’s basically a compiler enforced set of C++ best practices. It’s strange how hostile some in the C++ community are to Rust.

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

#94

Post by bestouff »

virtualritz wrote: post #60
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…

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

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

#96

Post by ThePhysicist »

What's often neglected is the excellent tooling around Rust, that alone is reason enough to switch from C++, where you have a really fragmented tooling ecosystem and you're often required to deal with complex Makefiles or build config as well as download dependencies manually. Most of that just disappears with Rust, unless you're developing code that interfaces with existing C/C++ libraries.

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

#97

Post by flohofwoe »

gpderetta wrote: post #83
flohofwoe wrote: post #76

Earlier quoted context omitted.

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

Yes, but people need to be aware that "auto obj = make_unique..." or "auto obj = make_shared..." should be a very rare thing and not the norm (and I've seen plenty code bases like that). There needs to be a proper memory management strategy with the goal of minimizing heap allocation in random places in the code. E.g. automatic memory management doesn't resolve you from thinking just as much about memory management than doing it manually in the first place.

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

#99

Post by zaphar »

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…

The point of safer languages is that it can protect you from the person writing the code. Sometimes that person is someone else. Sometimes that person is you. But no matter who the person is they will eventually have a bad day and some of those bad days will not be caught by a C++ compiler and linter. So your last point is I think probably not correct. The truth is that you need both a competent coder and also a language that catches when you are a little off your game. Rust is one of the compilers that help to catch when you are off that game.

Your point that a rewrite is very risky is well made regardless though.

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

#100

Post by quectophoton »

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

I also really like Rust, and I see it as a good replacement of C++, except for one reason: the monoculture around it.

You are expected to use one specific compiler. And there's very little (apparent) interest in actually writing a spec, so that other people can actually try to implement their own compilers with a working borrow checker, compilers capable of compiling rustc without sacrificing soundness (so far the compilers I've seen are lacking borrow checker, for example).

My only remaining hope rests on the Ferrocene people.

So I can see why Rust is being used for user applications, but until that monoculture issue is fixed, I don't really see it replacing C, C++, much less SPARK, as a language for critical systems.

It is my sincere hope that having Rust in the Linux kernel, and in GCC, results in Rust getting an actual spec, so that we can finally know what is expected compiler behavior and what is a bug in rustc, other than "what the rustc from this specific repository does".

Like, for example, Rust 2018 edition is frozen (AFAIK), so that would be a good target for a baseline spec. Could be a more recent edition, even; it doesn't really matter as long as it's something.

Post reply on HN