Building a Cloud Database from Scratch: Why We Moved from C++ to Rust (2022) • Hacker News Board

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

#161

Post by lr1970 » Fri, Feb 10, 2023, 2:22 PM UTC

From the article:

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

One advantage of Rust of C/C++ that is underreported is the that Rust makes it easier to operate a team with diverse levels of experience/expertise. One or two senior engineers set up the tone, design and coding standards. Junior folks try to follow but if they screw up Rust offers more checks and guard rails limiting the blast radius. Many bugs simply do not make past the borrow checker and type system. This also helps when churn and attrition happens in the team. I witnessed quite a few horror stories when aspiring but not-yet competent C++ coders wrecked havoc in C++ code-base when seniors were busy with something else.

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

#162

Post by simiones » Fri, Feb 10, 2023, 2:24 PM UTC

foxhill wrote: post #33

steeleduncan wrote: post #20

Earlier quoted context omitted.

> since C++11 there is no reason for not using smart pointers There are many reasons for not using smart pointers, first amongst them for me being performance. Smart pointers do allow you to remove a large class of memory bugs from your code (albeit not memory leaks) in the same way that Rust's safe references do. However C++ smart pointers impose a run time performance penalty on your code, whereas in Rust the check…

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

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

#163

Post by JBits » Fri, Feb 10, 2023, 2:26 PM UTC

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.

A few years ago I met up with someone who just graduated and who's only experience with programming was MATLAB during his degree. To my surprise he'd been hired to use Rust and was telling me how great the recently released async was.

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

#164

Post by StreamBright » Fri, Feb 10, 2023, 2:29 PM UTC

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 always a gamble. Different arch? You need to install different packages to compile the C/C++/Fortran code if the library author did not care about WHL. Starting up an application always a gamble, do we have all the deps? Did we miss some?

And so on. With Rust + Cargo I have confidence that the executable runs. Yes, the compilation is an extra step, but I would have that trade every single time for extra safety and reliability.

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

#165

Post by serverholic » Fri, Feb 10, 2023, 2:39 PM UTC

pdimitar wrote: post #147

serverholic wrote: post #146

Earlier quoted context omitted.

See this is what I’m scared about in my current job. We have some people who want to use dynamically typed languages and some who want to use static. I don’t think being able to brain dump code is a good thing and it leads to an unmanageable mess when you have a large codebase. Types are essential as far as I’m concerned, but I constantly have to get into arguments with the dynamic type fans because their “flow” Is b…

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…

Yes and then someone comes along and makes a change that breaks something seemingly unrelated and it’s less likely to be caught because there is no type system.

And please don’t say tests solve that because they don’t. They help but they don’t solve it.

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

#166

Post by kupfer » Fri, Feb 10, 2023, 2:40 PM UTC

pdimitar wrote: post #74

gpderetta wrote: post #28

Earlier quoted context omitted.

>Rust is not difficult because of lifetimes, it just gets in the way of freely prototyping what you want. I'm not a rust programmer, but I guess that's an issue if you come from a dynamic language, not from c++.

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…

Is it just about a REPL? There is the evcxr hack, though I'm not sure how far you can take it.

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

#167

Post by epage » Fri, Feb 10, 2023, 2:43 PM UTC

smallstepforman wrote: post #17

Author quoted C/C++, I immediately knew what conclusions I’d find. If on the other hand they had seasoned C++ devs (instead of C/C++), they might have had a different outcome.

What is with the modern C++ community treating "C/C++" as a shibboleth to gatekeep over? I'm a seasoned C++ dev (using it before C++98 was available, kept up with trends) and I've never seen this before until the last year or so. I've never had a problem with it as I see my C++ skills being tranferrable to C.

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

#168

Post by exDM69 » Fri, Feb 10, 2023, 2:45 PM UTC

imron wrote: post #77

berkut wrote: post #56

Earlier quoted context omitted.

For unique_ptr, in a release build, no: but in a debug build there's overhead, and more to the point, stepping into the deference in gdb/lldb at least in my experience requires stepping through the internals, to the point some of the code we use with them is #ifdeffed hackily to use raw ptrs in some cases to avoid this annoyance. For shared_ptr, the atomic ref counting can cause surprising overhead due to contention…

There are settings you can place in .gdbinit to avoid stepping in to internals of anything you don’t want to step into, be it std library classes/functions or your own code. Much nicer than hacky ifdefs.

> There are settings you can place in .gdbinit to avoid stepping in to internals of anything you don’t want to step into, be it std library classes/functions or your own code.

This is exactly what I need. For both, C++ and Rust smart pointers.

Can you share any more info on how to set this up?

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

#169

Post by jen20 » Fri, Feb 10, 2023, 2:49 PM UTC

andrewstuart wrote: post #2

Building a database is brave or stupid or both. Over the last 15 or 20 years I’ve tried lots of databases of all flavors and every time come back to Postgres. What can’t it do. And like Linux it’s written in C. Not that means much. “Never bet against Postgres”.

> What can’t it do.

Fail over without downtime or operator intervention.

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

#170

Post by lelanthran » Fri, Feb 10, 2023, 2:55 PM UTC

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++ or C, often simply claiming that fewer bugs is worth the tradeoff from switching to Rust.

I literally saw a comment on HN this past week complaining that OSes are not switching to Rust, almost completely ignoring the fact that any rewrite of a 3 decades old codebase is going to introduce more bugs than it is going to prevent, even if you have perfect memory safety (which you won't, in an OS).

In all honesty, Rust would have been adopted orders of magnitudes faster had Rust evangelists been welcoming, and not accused of being defensive or hostile.

I mean, look through this very page full of comments, and be honest, how many of the comments talking about C++ developers are welcoming to C++ developers?