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

211–220 of 307 posts

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

#211

Post by pdimitar »

tele_ski wrote: post #177
pdimitar wrote: post #147

Earlier quoted context omitted.

Be a bit more charitable. :) Brain-dumping is simply a way to iterate and figure out what works and what doesn't, quickly. After I do it I take the requisite time to emulate exhaustive pattern matching, and add tests that cover the functionality well. My problem with Rust, and I love the language a lot, is exactly this: I want to quickly find what would work. After that I'm very happy to take the proper time to go th…

I do appreciate that you write tests. I find it's like pulling teeth with most devs to get them to write anything but the most basic of tests. I tend to think more than write code, so usually my first go is reasonably close to what I need. But there are always edge cases you just never think about. I'd rather have a strong debugger than a repl imo

> I find it's like pulling teeth with most devs to get them to write anything but the most basic of tests

You are unfortunately very correct (at least in my 21 years of experience as well). I too feel annoyance when I know that I made a piece of code work well but (a) every now and then I am truly wrong and (b) various pieces of the system in the code interact in sometimes unexpected ways, unveiling inputs to your code that you haven't foreseen.

So even though it often takes a heavy and annoyed sigh out of me, I still roll up my sleeves and add the tests because I've shot myself in the foot too many times, and ignoring past experience is just being a stupido.

As for debugger/REPL, they are not orthogonal; you can have both. I'd more contrast debugger with tests themselves -- both are ways to go step by step through a process that you know is faulty somewhere.

REPL to me is just a way to more quickly sketch a v1.0 of a piece of code, nothing else.

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

#212

Post by pkolaczk »

nu11ptr wrote: post #194
flohofwoe wrote: post #116

Earlier quoted context omitted.

The idea that ref-counting is automatically "better" than a garbage collector is still pretty popular unfortunately (and that's just the tip of the iceberg).

A bump allocator + state of the art compacting GC is MUCH faster on a naïve basis which is why it is important to minimize number of allocations in non-GC langs and use stack based RAII when possible. When building things like trees in a non-GC language, arena allocation should be considered for max performance. This is just another low level vs high level trade off IMO.

> A bump allocator + state of the art compacting GC is MUCH faster

I can see it repeated very often, but can you point me to any evidence for such claim, based on modern low-pause GCs and real data (not simulation)?

I find low pause GCs have pretty substantial overhead and have way lower allocation throughput than old stop-the-world GCs. And the difference between manual memory allocation wasn't that big either (still within 2x).

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

#213

Post by blub »

ZephyrBlu wrote: post #48
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 argument for Rust is rarely that C++ cannot do the same task, it's that Rust provides better guardrails. Unreadable code is not a C++ specific problem, but does Rust make it easier to write readable code? Probably. Same for memory leaks and other similar problems.

As another commenter said: lifetime identifiers and functional constructs. To which I’ll add reference overuse.

The C++ programmers that love over-complicated, read-only code would be right at home in Rust. In fact they’re probably working on it right now :-)

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

#214

Post by pclmulqdq »

spoiler wrote: post #132
pdimitar wrote: post #78

Earlier quoted context omitted.

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

> Rust can already be very arcane to decipher sometimes, especially when you start getting errors from async libraries. For what it's worth, the community, library authors, and most importantly the language design teams are all very aware of this. And there's efforts being made to make all these pain points things more ergonomics and approachable. I think it just a slower process than we'd like. I think in part it's…

For what it's worth, the C++ maintainers are aware of how arcane and indecipherable their language of choice is, too. The process is even slower because there is a lot of C++ code out there that can't take the same level of change whiplash that Rust changes give you.

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

#215

Post by jamincan »

School-Cotton wrote: post #127
usrnm wrote: post #124

Earlier quoted context omitted.

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

You don't even need a smart pointer: `let bar = Box::leak(foo);`

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

#216

Post by blub »

Taywee wrote: post #178
lelanthran wrote: post #170

Earlier quoted context omitted.

> 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, the syntax is alien and new, it doesn't do OO the way 9 out of 10 working developers expect it to, almost all C++ popular design patterns have to be rejected, many of the claims("fearless concurrency") are exaggerated and the Rust evangelists are really really toxic when referring to C…

I've seen an order of magnitude more people complaining about Rust evangelists as I've actually seen Rust evangelists, and they've been significantly more hostile and toxic. The majority of Rust programmers I know were C++ programmers in the past. Many, including myself, use both professionally.

Look and you shall find. Third comment from the top: https://news.ycombinator.com/item?id=34741241

That jumble of ideas is a good example of the arrogance directed not only at C++ programmers, but also Golang and C.

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

#217

Post by pharmakom »

lelanthran wrote: post #170
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.

> 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, the syntax is alien and new, it doesn't do OO the way 9 out of 10 working developers expect it to, almost all C++ popular design patterns have to be rejected, many of the claims("fearless concurrency") are exaggerated and the Rust evangelists are really really toxic when referring to C…

OOP is not C++ best practice these days. For me C++ best practice is:

- Smart pointers

- auto and const references all over the place

- RAII

- Pure data structs

- Free functions

- A little bit of templating but not too crazy

Modern C++ reads a bit like JavaScript strangely!

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

#218

Post by Dowwie »

Rust asyncio is still in its minimum-viable-product stage. My impression is that it will no long be considered MVP when it has structured concurrency. It would be great if authors posted honest insights about the limitations and work-arounds, if such exist.

I would like to know what the core authors of Materialize or InfluxDB-IOX have to say about using Rust for building a database. They've found the dead bodies, if there are any.

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

#219

Post by eddsh1994 »

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

> ...it has a much better user story around build & package/module/library management Cargo sure does, but support for rust outside of cargo is much, much worse than equivalent support for C and C++. It doesn't matter for self-contained projects like simple Makefile ones, but at large scales, moving everything to cargo doesn't seem reasonable right now. Maybe eventually?

This is the one issue I personally have with C++. How do I `pip install boost`?

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

#220

Post by verdagon »

victorvosk wrote: post #173
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.

Hot take, I feel like people that complain Rust is hard typically write bade code in other languages. Rust is just preventing you from making common mistakes or using patterns that make your code hard to reason about and debug later.

As a fellow Rust user, please stop saying this. Not everyone who codes like us is a bad programmer. It's this kind of sentiment that gives us a bad name.

Rust may influence us into patterns that are better in some (likely even most) situations, but not always. Sometimes the situation calls for other approaches, and that's okay.

Post reply on HN