Live data from Hacker News

Rewriting a high performance vector database in Rust

pinecone.io

71–80 of 157 posts

Re: Rewriting a high performance vector database in Rust

#71
post #27

Earlier quoted context omitted.

Assuming there is even a Rust library replacement to start with. People keep forgetting C++ has 30 years of being deployed in production. Rust is 2022 is like using C++ in 1990's in terms of ecosystem.

The C++ IDEs available up until about 10 years ago were complete garbage. C++ still doesn't even have a good package manager . All the build systems are pure chaos. The largest C++ package manager has 1500 packages. In comparison, rust's package manager and build system are way easier to use and already have 94,000 packages available to users. That's not exactly fair to C++ because entire categories of dev tools (lik…

Another one that never used Borland, Apple, IBM IDEs.

Where is the Rust IDE that is half as capable as C++ Builder, MPW/Metrowerks, Visual Age, Zortech?

Considering all features they offered across the board in the box, not only code completion.

Re: Rewriting a high performance vector database in Rust

#72
post #61
post #51

Earlier quoted context omitted.

Despite Rust's steep learning curve, it's also paradoxically easy to add novice Rust programmers to a project. This is because inexperienced Rust programmers are relatively harmless. Noob mistakes won't compile, rather than running into dangerous gotchas. You can tell noobs not to use `unsafe` (and there are ways to enforce that), and mostly they'll just write inefficient or non-idiomatic code, but the code will be f…

Memory sanitizers, address sanitizers, leak sanitizers, threading sanitizers, undefined behaviour sanitizers. The visual studio core guidelines checker. The clang-tidy core guideline checker. I could go on but my point is, the landscape does not really look like how you've painted it.

I know about these, but there is a marked difference between Rust and these tools.

Static analysis tools have much harder job analyzing C++ (aliasing and escape analysis are way harder, and static analysis of thread-safety is basically impossible due to lack of thread-safety info in the type system). The results are a trade-off between being sparse or having false positives.

The sanitizers only catch issues they can observe at run time, and that relies on having sufficient test and fuzz coverage. Some data races are incredibly hard to reproduce, and might depend on a timing difference that won't happen in your test harness.

OTOH Rust proves absence of these issues by construction, at compile time.

It's like a difference between dynamically-typed and statically-typed languages. Sure, you can fuzz type errors out of JS or Python, but in statically-typed languages such errors are eliminated entirely at compile time. Rust extends this experience to more classes of errors.

Re: Rewriting a high performance vector database in Rust

#73
post #5

Glanced through the article, and I see no comparisons on how performance of the DB is in Rust versus their current C++ implementation, no mention of if maintaining the Rust code is easier than their C++ codebase, no stats on how devs are ramping up and how it's tackling their "hard to find a dev who knows both C++ and Python well" issue.

The next paragraph they state: We looked at and compared several languages - Go, Java, C++, and Rust. We knew that C++ was harder to scale and maintain high quality as you build a dev team; that Java doesn’t provide the flexibility and systems programming language we needed; and that Go is also a garbage collected language. This left us with Rust. With Rust, the pros around performance, memory management, and ease of…

> but that's functionally impossible: nobody is rewriting their application twice to see what rewrite is better.

Agreed, and hypothetically the 2nd rewrite should still be better than the first. So the language would have to make it significantly worse to outweigh the yet again experience in improving things.

To be clear though i'm not stating that every rewrite is assured to be better. However a carefully considered rewrite has a much easier time making decisions learned from any warts discovered in previous implementations. God knows there's always some warts.

As a Rust fanatic, i wouldn't expect Rust itself to be due to the performance gains. It's not expected to be faster than C/C++ typically. Just comparable.

Re: Rewriting a high performance vector database in Rust

#74
post #32

Earlier quoted context omitted.

The minimum bar for a language has moved up significantly since the 1990s. It isn't enough to just have a neat new idea, you need to ship with nearly-best-of-breed JSON serialization, a web server, a huge standard library with not just strings but things like compression and a lot of networking, and a laundry list of other things (give or take a few things) just to make it to the "barely viable alternate choice" poin…

Well, Rust checks all of those boxes. Yes, it's a problem for that language you plan on creating (try specializing into a niche). But it's not something that should impact Rust's adoption.

With various levels of completeness.

Re: Rewriting a high performance vector database in Rust

#75
post #60

I have no problem with people rewriting their projects in whatever language they see fit. What stood out for me in the article is him saying that it's difficult getting developers with experience in both Python and C++. So, I wonder, if his in-house devs could pick up Rust that they previously couldn't write, why does he think he can not hire a good programmer and charge him to learn the stack the company uses. Why m…

I've written quite a bit of production code in C++, Python and Rust, and currently work on a hybrid Rust/Python system. Here's my experience: - C++ is an unusually large language. And it has many historic footguns, requiring a higher level of vigilance and code review. If I were starting a brand new project today, I wouldn't try to build a team of C++ programmers. - Untyped Python becomes more difficult to refactor a…

"But this also comes with costs: everyone needs to be fairly good at two languages, and switch back and forth."

Why does everyone needs to be good at both languages? You can seperate and have the core people writing efficient low level code - and you have higher level scripting/gluing code.

Re: Rewriting a high performance vector database in Rust

#76

Earlier quoted context omitted.

I honestly feel like rust is boring technology in most senses of the word. It “just works” more than almost any other technology that I’ve used. The ownership system is new and different, but that’s really the only thing.

Rust is not boring technology. There's too much ecosystem churn, and new language features are deployed too often. C++ isn't boring technology, either. If you just want to deliver value, I'd recommend Java.

> There's too much ecosystem churn, and new language features are deployed too often.

Not much of an issue if you stick to the stable subset of the language, and libraries that work within that subset.

Re: Rewriting a high performance vector database in Rust

#77
post #60

I have no problem with people rewriting their projects in whatever language they see fit. What stood out for me in the article is him saying that it's difficult getting developers with experience in both Python and C++. So, I wonder, if his in-house devs could pick up Rust that they previously couldn't write, why does he think he can not hire a good programmer and charge him to learn the stack the company uses. Why m…

I've written quite a bit of production code in C++, Python and Rust, and currently work on a hybrid Rust/Python system. Here's my experience: - C++ is an unusually large language. And it has many historic footguns, requiring a higher level of vigilance and code review. If I were starting a brand new project today, I wouldn't try to build a team of C++ programmers. - Untyped Python becomes more difficult to refactor a…

A brand new project doesn't need legacy C++ footguns. It can use modern C++.

The part of Python (usually) is that you don't need to be "good at it" it you aren't trying to write super polymorphic core that runs super efficient computations like scipy. If you have a fast core engine for the innner loop, a slow Python management layer is plenty fast.

Re: Rewriting a high performance vector database in Rust

#78
post #22

Earlier quoted context omitted.

Which is why old timers eventually learn to just deliver with boring technology.

I honestly feel like rust is boring technology in most senses of the word. It “just works” more than almost any other technology that I’ve used. The ownership system is new and different, but that’s really the only thing.

Honestly, so is Go. I used to use Go, and it's boring as hell. I hate it for a few choices they made, but they definitely achieved their goal. It is quite boring.

I agree with you though, so is Rust. The less boring areas imo these days aren't languages (at least none i see), as all the good languages are boring. Zig for example, is pretty mundane too.

The older i get the more i value confidence in a product. Confidence that it won't crash at runtime. Confidence that i won't be bugged over the weekend. etc

Re: Rewriting a high performance vector database in Rust

#79
post #57

I have no problem with people rewriting their projects in whatever language they see fit. What stood out for me in the article is him saying that it's difficult getting developers with experience in both Python and C++. So, I wonder, if his in-house devs could pick up Rust that they previously couldn't write, why does he think he can not hire a good programmer and charge him to learn the stack the company uses. Why m…

It takes longer to learn how to use C++ to the same level of proficiency and correctness compared to Rust, in my experience. It's harder to write an incorrect program in Rust.

What are the main correctness risks in C++ if you just never use a raw pointer?

Re: Rewriting a high performance vector database in Rust

#80

Earlier quoted context omitted.

I haven't used them much, but sled, ldap3 and thrussh do exist. As Rust gains further in popularity I'd expect more of these to become production ready. Meanwhile there's always C and C++ interop.

Sled and thrussh are not production grade. I don’t particularly want to delve into details as I think the effort is laudable. I can explain my position in private if need be.

OK. I mean they're probably less mature, yeah. But high-quality Rust bindings to libssh2 and RocksDB do exist so shrug
Post reply on HN