Live data from Hacker News

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

risingwave-labs.com

261–270 of 307 posts

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

#261

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…

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!

> OOP is not C++ best practice these days.

I didn't say it was.

I didn't say anything about best practice, only about familiarity.

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

#262
The more I read the "cons" in this article's C++ section the more I scratch my head. Code style is something that should be uniform and enforced. It's bikeshedding, but unless you're using a language with opinionated formatting (e.g. Go), it's absolutely a must have, and should be one of the first things done even at a startup.

This really looks like a case of not seasoned developers throwing crap at the wall and seeing what sticks. I doubt their Rust implementation will go any better.

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

#263

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

Hot take: your attitude is why people push back on the Rust community when they're in HN so much.

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

#264
post #191

Earlier quoted context omitted.

C++ modules....

Has support for these gotten any better? Last time I was reading about it compiler support was under baked at best. If they get it fully working and stable I agree modules should go a long way to getting rid of it (entirely if you are willing to wrap old header files in modules yourself).

They work well in VC++ (not surprising, since it’s largely Microsoft’s design). I would give it another year for reasonable support in GCC.

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

#265

Earlier quoted context omitted.

Rust doesn't have support for native co-routines. You rely on community project for that (Tokyo). At first I even thought it was an argument against Rust, not in favor...

It's "Tokio". Coroutines in Rust are a native language feature and their API is part of `std`, but the executors indeed come from community libraries. Tokio is one option, but as long as you don't contextually fork (for parallelism) you can in theory run the same coroutines on any other executor, like the ones from async-std. Spawning a sibling task (as opposed to mixed child task polling, which can be macroed inline…

Sorry if I'm missing something important as I have experience with C++ but not rust, but is async/await the right abstraction in Rust vs. the underlying generators which I assume is lower level and closer to C++20 Co-routines in terms of performance ? [1]

In other words, it seems Rust co-routines at the level of Tokio are not as performant as C++ native Co-routines [2] and further down the thread, it's mentioned that once generators are stabilized, it might help build lower cost and performant stackless coroutines in Rust.[3]

[1] https://github.com/rust-lang/rust/issues/43122#issuecomment-...

[2] https://github.com/rust-lang/rust/issues/43122#issuecomment-...

[3] https://github.com/rust-lang/rust/issues/43122#issuecomment-...

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

#266

Earlier quoted context omitted.

Rust isn't a prototyping language.

Says who? I love prototyping things in Rust.

Both viewpoints make sense; whether Rust is good for prototyping depends on the domain.

If it fits the borrow checker well (like in CLI apps, stateless servers, data transformation) then the borrow checker fits beautifully and seamlessly.

In other settings (complex turn-based games, some compilers, GUI), the borrow checker can cause some artificial complexity and prototyping slowdowns compared to other paradigms.

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

#267

Earlier quoted context omitted.

Is rust code heavily seasoned with unsafe keyword really that hard to prototype in? Is it meaningfully harder than c++ in this regard?

I assume they didn't mean compared to C++. If anything, saying prototyping in C++ is easier than Rust is beyond ludicrous even if you're a seasoned C++ developer. I'd have an easier time prototyping in Rust than C++, and I've been writing C++ for 10 years and Rust for a little over a year. However, prototype in something like Ruby (or even TypeScript, and some people mentioned Elixir) is in a different universe compa…

Well there are C++ repls available. Maybe there are rust ones too?

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

#268

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?

I strongly agree with this. Everyone complains about C and C++ build systems, but they were designed to be easy to begin with. Then projects grew in size and there wasn't a "standard" way to do things so people came up with their own systems. We now seem to be standardizing around CMake for better or worse.

On the flip side, Rust makes the usual cause very easy, with the ability to to pull in code with a single line in a config file (I would argue this is probably a double edged sword - I've some some Rust projects that look like they're a javascript project with a thousand dependencies). I think the "simple" case of compiling Rust without cargo is more complicated and has a higher friction.

Perhaps this isn't fair, complaining about Rust's build system when you're off the beaten path because it's difficult with loose footing. C++ doesn't really have a beaten path (Well since C++17 it's slowly become CMake), that's why all the routes are so well trodden...

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

#269
post #178

Earlier quoted context omitted.

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.

> 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. Does this, to you, look like a response that is welcoming to C++ devs? I gave careful and impassive reasons, and you strike back with literal ad hominem attacks. This sort of reply is what makes Rust, as a community, look shallow-minded and tox…

You said Rust evangelists are toxic and exaggerating. I said that I've seen the more of the same in the other direction, and I'm the one striking back with literal ad hominem, and "shallow-minded and toxic"? My response isn't all that difference in tone and content to your own comment, but you've come back way harder at me personally than I was being in general.

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

#270
post #216
post #178

Earlier quoted context omitted.

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.

I'm not saying it doesn't exist. I'm just saying I've seen way more griping about Rust evangelists than I've seen actual Rust evangelists. For every crazy Rust post like that, I've seen at least 5 of people complaining about crazy rust posts like that. I've seen plenty of articles with comments crapping on Rust evangelists when they weren't even in the comments at all.
Post reply on HN