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

221–230 of 307 posts

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

#221

Post by StreamBright »

ghostwriter wrote: post #186
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-lev…

Absolutely not. The last time I have tried Haskell it was failing some pretty basic tasks. The JSON library required to be re-compiled for some reason and it used 20+G of RAM when the build crashed. The community is flat out hostile towards Mac users and a basic request was closed with a comment that Mac is a broken platform and it should not be used. I do not have time for these, Rust offers a much better experience and the community is very helpful even if you are asking silly questions.

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

#222

Post by devinthenull »

blub wrote: post #202

Please do yourself a favor and don’t waste 5m of your life reading this article like I did. It’s about a team of allegedly experienced C++ developers at a start-up that spent seven months building a project only to spend another two months rewriting it in Rust and then a few more months moving from async to Tokio. But those lost months have not been in vain, because they have 1600 stars on Github. They actually bragg…

sounds like a nice lifestyle business to enjoy ones hobbies

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

#223

Post by [deleted] »

sidlls wrote: post #137
ZephyrBlu wrote: post #48

Earlier quoted context omitted.

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.

[deleted]

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

#224

Post by blub »

tw1984 wrote: post #207

You can't revert this trend - C++ is a legacy language being depreciated by more and more projects. C++ and Rust are simply not competing on the same level. You don't need a complicated "enterprise" building farm/cluster to build your project, dependencies are managed by the guys who also write your compiler, there is a growing community that actually listen to your feedback and you don't need to wait 40 years to get…

I’ve noticed that the tone is becoming rougher with each new Rust story. I’d be curious to know what kind of professional would choose to express themselves in this way, it’s pretty embarrassing.

First of all, that blog post - as many Rust-themed blogs from start-ups - is a submarine article attempting to increase the notoriety of their product. Not enough to disqualify it, but a hint that it won’t necessarily be technically solid.

And indeed, on a technical level it’s superficial and doesn’t give any code examples to substantiate its claims. Code is critically important, because as another recent blog showed, some people don’t know why it’s a bad idea to pass non-zero-terminated char buffers to C string functions and then turn this into a big story about the dangers of C++.

The story also has some red flags, such as not being able to enforce coding standards. Code review is a near-mandatory quality control and teaching method that easily handles this. Clang-format and clang-tidy take care of the low-hanging fruit.

Having segfaults is a really bad sign. So is not mentioning the words address sanitizer, valgrind or similar.

Having memory leaks in 2021 is incomprehensible. This is an amateur mistake of the worst kind in modern C++. It means they’re writing C.

I don’t have time to dig more in depth, but there’s a disturbing lack of critical thinking and skepticism in these comments.

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

#225

Post by spoiler »

pdimitar wrote: post #208
flumpcakes wrote: post #138

Earlier quoted context omitted.

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…

50 / 50. I find the Rust Users discourse forum to be generally welcoming, though sometimes it seems people find your question too obvious and nobody ever responds. I found that showing that I made an effort and pointing at my source of confusion increases engagement. But it might be sensitive to timezones or such as well, no idea. Rust's Discord however is AMAZINGLY friendly. I've been contacted in DMs by maintainers…

Ah, I don't mean to generalise, but most of my experiences on Reddit have been a mixed bag, often more negative. Regardless of the community. I think it's because there's "no barrier to entry" (ie no special sign up, it's just a button). And the design in general feels like it's more suited for short form quippy comments than chatting or discussions.

And I 100% agree that their Discord is great. Also recommend it.

I've seen lots of activity on beginner and intermediate questions though.

As well as just chatting to people, or helping someone with an interesting problem.

I've had a really difficult problem ignored on Discord, but I also think the threading UI on there isn't great for lots of concurrent and unrelated discussions. I just found it frustrating to use. So, maybe some questions fall through the cracks?

Managed to resolve it in the end though. However, having typed all this, I realise a wiser thing would've been to ask on StackOverflow instead lol.

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

#226

Post by kupfer »

pdimitar wrote: post #210
kupfer wrote: post #166

Earlier quoted context omitted.

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

Nah, not specifically about the REPL itself, I just need a way to quickly sketch and run a piece of code is all. I know big IDEs support this but I prefer keeping everything in the terminal -- I'll have to go check if Emacs or NeoVim offer something along those lines.

Maybe take a look at evcxr, it runs in a terminal and is REPL like. When I'm dabbling in rust, I use it e.g. to quickly try out library functions and how to work with the result. But I'm just getting started.

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

#228

Post by selfmodruntime »

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…

I love the idea of Elixir, but I just can't get into it because of its weird choice of sigils. |> for pipes and <- for assignments, seriously? I seriously dislike programming languages which choose two character sigils for basic operations. I also heavily dislike |x| in Rust.

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

#229

Post by selfmodruntime »

runevault wrote: post #205
pjmlp wrote: 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).

No. GCC still produces weird output at times.

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

#230

Post by rightbyte »

menaerus wrote: post #103
rightbyte wrote: post #50

Earlier quoted context omitted.

unqie_ptr have overhead. It need to run its dtor etc. https://www.youtube.com/watch?v=rHIkrotSwcc At 18 min.

You're misinformed. Overhead is not about the running the dtor, unless you're willing to leak the memory in your code regardless of the smart ptr usage or not. What the "overhead" of unique_ptr is usually attached to is the inability for a compiler to pass the unique_ptr as a value through a register but will instead have to use the stack (memory). And that even doesn't apply in the general case but _only_ for unique…

Ah ok interesting I need to dig into this.

Ye well I knew the overhead was really small.

Post reply on HN