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)

#131

Post by globuous » Fri, Feb 10, 2023, 1:32 PM UTC

jjgreen wrote: post #45

nhourcard wrote: post #6

Earlier quoted context omitted.

It depends on your use case. For example, Postgres will hit limitations for large streams of time series data on the ingestion side, and the standard SQL language of Postgres may make it challenging to navigate a dataset by time: sampling the data, time intervals, time-series joins (ASOF join), and these kinds of things are not easy or possible to do on Postgres. Why not combine Postgres for OLTP workloads alongside…

Any thoughts on Timescale?

Unfortunately, you cannot install timescale on an rds, or I believe , other managed Postgres services : https://stackoverflow.com/a/67712962.

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

#132

Post by spoiler » Fri, Feb 10, 2023, 1:33 PM UTC

pdimitar wrote: post #78

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

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 so slow might be due to how the decision making and work is structured; it's very open, but also slow.

Stuff like GATs took ages to design and implement, and yeet and parts of async are similar. These are done very carefully and they also let decisions marinate for a while before further action.

It's not a critique, since I think it's good and wouldn't know a recommendation to speed it up.

So, it's getting better, but slowly

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

#133

Post by graboid » Fri, Feb 10, 2023, 1:34 PM UTC

josephg wrote: post #80

bakuninsbart wrote: post #46

Earlier quoted context omitted.

I'm quite nooby in both Rust and C++, but for the little interactions I had, I felt like Rust had a much clearer path forward than C++ when I was in doubt, and "how to write in good style" was more obvious. This leads me to the assumption that building a Rust culture is probably easier than building a C++ culture, because it is easier to get junior developers and those coming from other languages up to speed.

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.

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

#134

Post by dhbradshaw » Fri, Feb 10, 2023, 1:35 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…

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.

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

#135

Post by jasonhansel » Fri, Feb 10, 2023, 1:36 PM UTC

yagni_dev wrote: post #38

>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. - Seasoned devs but they never heard of clang tidy/format - Memory leaks on a new db codebase where each component should have clear ownership of data or pass to the next pipeline/stage - you dont even need smart poirters here, just a half decent design. - I am not e…

Ownership is great! Which is why you should use a language that actually supports it, instead of one where it is just a semi-enforced convention.

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

#136

Post by hdhrufjdi » Fri, Feb 10, 2023, 1:36 PM UTC

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.

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

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

#137

Post by sidlls » Fri, Feb 10, 2023, 1:37 PM UTC

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.

Non-trivial Rust code can be just as unreadable as code one would write in any other language. In fact, some of Rust's features (e.g. lifetime identifiers, functional-ish constructs that people use to create huge call chains with closures everywhere) arguably make it easier to write unreadable code than one might find in other languages.

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

#138

Post by flumpcakes » Fri, Feb 10, 2023, 1:40 PM UTC

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…

I think GATs in Rust are really cool. Just like template meta programming in C++ is really cool (despite the countless articles on why it shouldn't be used by mere mortals in production code--it's too powerful and unwieldy!). I worry that Rust will become just as arcane as C++ but will look better at a surface level because it has modern and sane defaults and not 40 years of baggage.

Perhaps I'm worried I'm just not smart enough to be a Rust programmer.

Off topic: I also find the Rust community unwelcoming and very clique-ish, I get the very strong "you're not apart of the cool gang" vibes and I'm too old to care to navigate this.

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

#139

Post by karterk » Fri, Feb 10, 2023, 1:40 PM UTC

pjmlp wrote: post #36

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.

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.

Can you give some examples of problematic C idioms in C++?

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

#140

Post by dxuh » Fri, Feb 10, 2023, 1:41 PM UTC

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…

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 and not trouble themselves with C++. I think Rust is the easier language to learn and probably just as powerful, but C++ just gets in your way less. It's not as hard to use correctly as people pretend it is (though I admit that years of experience and studying are required) and if you can use it relatively well you can write safe code without much trouble and you can also have a very high (higher than Rust) level of control seamlessly at the same time. I don't know many people with similar preferences, but most of them do game development, if that helps to contextualize a bit. There safety is not as important and development speed is much more important than for other applications.