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

151–160 of 307 posts

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

#151

Post by batty_alex »

spoiler wrote: post #105
pharmakom wrote: post #93

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.

I could be wrong, but I think there's few big camps of people. The camp that thinks Rust is just unnecessary fuss because "you can do it all" in C++ already. They pride themselves with knowing C++ esoterica, and don't like that Rust lowers the entry barrier to writing similar software. They want an exclusive club. They also see ownership as a nuisance. They know you can be equally reckless in Rust too, but they don't…

Ultimately, I'll use what I have to use. I, personally, don't like Rust's syntax and will miss the static inheritance of templates. There's a lot I won't miss, on the other hand

My biggest issue with most Rust posts is that they set up strawman C++ arguments (that are usually just C code targeting a C++ compiler). I'm sold on all the idea behind Rust and making sure that programmers can't just easily drop down to insecure parts of a language - I just don't think we should be shaming good C++ codebases because we want Rust to "win."

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

#152

Post by menaerus »

hdhrufjdi wrote: post #136
menaerus wrote: post #120

Earlier quoted context omitted.

Extra branch which is going to be taken 99.99999% of the time is not going to present any runtime overhead. CPU BP unit handles it for us. That said, if this really had been an overhead, virtually every language out there would suffer from it, including Rust. Every language out there at some point needs to call into the libc.

A bit of research revealed that you don't have to call into libc. You may use alternatives or even use sys calls directly, like Go apparently did: https://stackoverflow.com/questions/41720090/does-go-depend-... PS: small overhead is technically still overhead; yet, I am not saying you should worry about it

Yes, you can write your own runtime ... which will have to rely on the OS internals to do any meaningful work, and in case of memory allocation or deallocation it will have to rely on brk/mmap and then you will be back to square one.

Overhead is almost purely theoretical and it cannot be avoided and is not anything common or specific to unique_ptr's.

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

#153

Post by hdhrufjdi »

menaerus wrote: post #152
hdhrufjdi wrote: post #136

Earlier quoted context omitted.

A bit of research revealed that you don't have to call into libc. You may use alternatives or even use sys calls directly, like Go apparently did: https://stackoverflow.com/questions/41720090/does-go-depend-... PS: small overhead is technically still overhead; yet, I am not saying you should worry about it

Yes, you can write your own runtime ... which will have to rely on the OS internals to do any meaningful work, and in case of memory allocation or deallocation it will have to rely on brk/mmap and then you will be back to square one. Overhead is almost purely theoretical and it cannot be avoided and is not anything common or specific to unique_ptr's.

Rust could avoid it through the Box abstraction that afaik assumes not having a nullptr

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

#154

Post by pdimitar »

dhbradshaw wrote: post #134
pdimitar wrote: post #74

Earlier quoted context omitted.

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…

Try using a test -- can stick anywhere and just run code there (push of a button with analyzer in vscode). Almost like embedding a repl into a module for experimentation.

Haven't tried but definitely will, thank you!

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

#155

Post by simiones »

menaerus wrote: post #120
hdhrufjdi wrote: post #75

Earlier quoted context omitted.

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

Extra branch which is going to be taken 99.99999% of the time is not going to present any runtime overhead. CPU BP unit handles it for us. That said, if this really had been an overhead, virtually every language out there would suffer from it, including Rust. Every language out there at some point needs to call into the libc.

While I agree with your point overall, it's important to note that libc is definitely not a must on some platforms. On Linux in particular, the Kernel user-space ABI is stable, so you can write your own system calls in whatever language you want.

Also, even if you chose to use some libc for system calls, there is no reason to use malloc()/free(). You only need mmap() or similar, and then your own language runtime can write their own user-space memory manager.

As a side-note, on Windows, libc isn't even a system library. The official way to execute system calls is using win32, and things like malloc()/free() are simply wrappers around HeapAlloc() and HeapFree().

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

#156

Post by ZephyrBlu »

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.

I don't know what you're programming, but it's pretty hard to not use more complex structures like Vecs and HashMaps without them being mutable.

Also, that is exactly what Rust's borrow-checker is there for. It doesn't allow you to mutably borrow the same data structure multiple times.

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

#157

Post by pizza234 »

graboid wrote: post #133
josephg wrote: post #80

Earlier quoted context omitted.

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…

Does anyone know of any guide/tutorials/books about how to avoid common Rust performance issues. Like real world examples, "instead of doing X, do Y". I am maybe beginner to intermediate in Rust, but I think I'm still very susceptible to those things.

I've observed some level premature optimization in the Rust community, surely coming from being performance oriented.

I received a review comment some time ago about changing a line of code in order to spare one allocation, for a call that was executed _once_ in the whole lifetime of a program. That was not the only time I've observed this attitude.

I think starting with being handy with profiling and only after measurement, thinking about solutions, rather than starting with the idea that certain patterns are harmful per se.

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

#158

Post by menaerus »

hdhrufjdi wrote: post #153
menaerus wrote: post #152

Earlier quoted context omitted.

Yes, you can write your own runtime ... which will have to rely on the OS internals to do any meaningful work, and in case of memory allocation or deallocation it will have to rely on brk/mmap and then you will be back to square one. Overhead is almost purely theoretical and it cannot be avoided and is not anything common or specific to unique_ptr's.

Rust could avoid it through the Box abstraction that afaik assumes not having a nullptr

It would not. Rust needs ASAN/UBSAN/TSAN/MSAN sanitizers for a reason.

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

#159

Post by margorczynski »

pharmakom wrote: post #93

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.

Well it will suck out a lot of potential jobs from the C++ market, at least in the longer time horizon. And many people invested almost their whole lives into doing C++.

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

#160

Post by simiones »

dxuh wrote: post #140
spoiler wrote: post #105

Earlier quoted context omitted.

I could be wrong, but I think there's few big camps of people. The camp that thinks Rust is just unnecessary fuss because "you can do it all" in C++ already. They pride themselves with knowing C++ esoterica, and don't like that Rust lowers the entry barrier to writing similar software. They want an exclusive club. They also see ownership as a nuisance. They know you can be equally reckless in Rust too, but they don't…

I don't fall into any of the camps you mentioned specifically. I have been using C++ as my main programming language for a good 15 years and am a big fan of modern C++. I tried Rust for a month (every day) and I just feel like it gets in my way too much and it's just not worth the extra friction. A friend of mine (using Python as a physicist) wanted to try system programming recently and I told them to just try Rust…

> It's not as hard to use correctly as people pretend it is (though I admit that years of experience and studying are required)

The original statement and the one in parens are directly at odds with each other. If every C++ dev requires years of experience and studying to use correctly, it follows that they have left years worth of code that is not done correctly in their wake. Also, no other (non-esoteric) language requires this high a barrier to write correctly.

> if you can use it relatively well you can write safe code without much trouble

And yet there isn't a single large C++ project that doesn't suffer from violations of memory safety - the one class of bugs that we know how to eliminate completely, if using a proper runtime system.

Post reply on HN