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

181–190 of 307 posts

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

#181

Post by humanrebar »

ThePhysicist wrote: post #96

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.

C++ could improve its tooling but systems programming is inherently a bit of a fragmented ecosystem. I'm not sure we can shoehorn cargo into all the situations where C, C++, and Fortran have adapted to already.

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

#182

Post by pjmlp »

bobajeff wrote: post #66
pjmlp wrote: post #36

Earlier quoted context omitted.

That is the current issue with most C++ codebases nowadays, I only see modern C++ on conference slides, when I look into codebases even from ISO C++ members, it is always C++ full of C idioms no matter what. I bet most candidates to C++ job offers end up discovering the hardly reality of existing code.

That's a fundamental C++ problem. That and all the other idioms it supports. C++ is really like 10 languages and you always have find a mentor to show you the specific one you're working with in a codebase.

While I agree, note that it isn't exclusive of C++, most languages of similar age present similar issues.

How many styles do we now have on C#11, Java 20, Python 3.11, PHP 8.2,....?

This is why static analysis and linters are so relevant for keeping teams into a specific way of doing things, it is not like we can always justify start from scratch into simpler languages.

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

#183

Post by qalmakka »

ThePhysicist wrote: post #96

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.

This, also. C and C++'s build model is a train wreck, especially in C++ code gets rebuilt dozens of times due to headers being simply plopped into whatever translation unit you are building. Rust efficiently solves this by defining building abstractions in the language itself, instead of relying on hacks such as #include, PCH, ...

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

#184

Post by pjmlp »

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.

Kind of, as someone that knows C++ since 1993, I can assure that getting Rust right for doing GUI programing wasn't that straightforward.

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

#185

Post by humanrebar »

simiones wrote: post #162
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.

I'm honestly not sure: can unique_ptr be used in place of a T* pointing to a stack-allocated object?

Yes. You can provide a stubbed out deleter or a stack based allocator. But you're then responsible for making sure the unique_ptr doesn't outlive that stack memory. Though that's true for any reference to stack memory.

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

#186

Post by ghostwriter »

StreamBright wrote: post #164

As a hobby software engineer who mostly writes ETL jobs in Python the biggest selling point of Rust is Cargo. I usually use a lot of .clone() in my code and most of my fields are Strings which would make a seasoned Rust/C++ laugh at the code. However, the performance of novice Rust beats 10+ years of experience Python by a factor of 10 (favouring Rust). With Cargo I can build code that just runs. With Python it is al…

> As a hobby software engineer who mostly writes ETL jobs in Python the biggest selling point of Rust is Cargo. I usually use a lot of .clone() in my code and most of my fields are Strings which would make a seasoned Rust/C++ laugh at the code. [...] Yes, the compilation is an extra step, but I would have that trade every single time for extra safety and reliability.

It sounds like you'd be better off with higher-level Haskell for these tasks.

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

#187

Post by pjmlp »

ThePhysicist wrote: post #96

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.

Depends what tooling you care about.

There is plenty of C++ tooling for GPGPU, game engines, IDE, GUI programming, HPC,... that Rust still lacks.

In what concerns cargo, vcpkg and Conan are good enough, and support binary libraries, no need to compile everything from scratch.

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

#188

Post by MuffinFlavored »

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 somebody who could possibly be in the category you described, once I learned about Arc+Mutex, I pretty much write code the same way I used to. That and maybe OnceCell/Lazy?

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

#189

Post by jjnoakes »

lubesGordi wrote: post #144
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 isn't a prototyping language.

Says who? I love prototyping things in Rust.

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

#190

Post by humanrebar »

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.

The headlines these days are definitely hostile, though. C++ is unsafe, a legacy language, etc.
Post reply on HN