Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting a high performance vector database in Rust

pinecone.io

Post reply on HN
Print view View original

51–60 of 157 posts

Re: Rewriting a high performance vector database in Rust

#51

Post by pornel »

kaladin_1 wrote: post #41

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…

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 free from data races and memory corruption.

The strictness of the Rust compiler is quite the opposite of something like the C++ Core Guidelines where the majority of the rules aren't enforced by the compiler, and have to be in the programmers' head first.

Noobs make lifetime errors and fight the Rust compiler, but imagine working with a compiler that doesn't tell you when you have lifetime errors.

Re: Rewriting a high performance vector database in Rust

#52

Post by einpoklum »

The authors of this post rewrote _their own_ DBMS in Rust. Which is perfectly ok, but I'm not sure I would trust them to decide that theirs is a "high-performance" DBMS. They don't have any benchmark results except images of their own internal performance measures; they don't offer any way of comparing their performance with other DBMSes (e.g. Vectorwise/Actian Vector, ClickHouse, DuckDB etc. - not to mention Oracle, MS or SAP offerings); and they only have marketing blurb about their numbers: "Up to 10x performance" (with no baseline of course).

So, they took some DBMS (which is probably not so hot in terms of performance) and rewrote it in Rust. Surely possible, possibly useful, but not much to write home about if one is interested in DBMS performance.

Re: Rewriting a high performance vector database in Rust

#53

Post by xani__ »

nicoburns wrote: post #26
pjmlp wrote: 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.

No post body was provided.

Re: Rewriting a high performance vector database in Rust

#54

Post by xani__ »

jerf wrote: post #32
howinteresting wrote: post #30

Earlier quoted context omitted.

This is just plain false. C++ in the 1990s had nothing like serde for example.

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…

No post body was provided.

Re: Rewriting a high performance vector database in Rust

#55

Post by 8jy89hui »

pclmulqdq wrote: post #29
masklinn wrote: post #17

Earlier quoted context omitted.

Anecdotally, a lot of rust-curious people seem to know python. Projects like pyo3 help a lot as they make it much easier (= safe) to build native modules compared to C, let alone C++.

Rust is seen as more approachable by Javascript and Python devs, so they tend to learn it more often than C or C++. It is a lot more similar to JS than C++ is.

> It is a lot more similar to JS than C++ is.

That is strange as I have experienced the opposite. I've written all three languages and I've noticed that JS patterns don't translate well to Rust. Many C++ patterns translate well to Rust (albeit after a bit of borrow checker fighting).

Thoughts?

Re: Rewriting a high performance vector database in Rust

#56

Post by PartiallyTyped »

slt2021 wrote: post #39
mattnewton wrote: post #20

Earlier quoted context omitted.

This might be a difference of semantics- there is a difference between garbage collection as a concept being slow and python's GIL approach. My understanding is that the GIL would almost always make the top 3 reason of why python is slow in practice - it works for a very specific single threaded execution model but can't really take advantage of modern processors.

I think GIL is not the reason for slowness, it just specifies single threaded interpreter execution model. You can always spin up more interpreters to take advantage of multiple cores. The reason for slowness - is the weak dynamic type system of Python. Every single instruction need to be type checked at runtime and thus making everything slow. Compare to C#/Java which have GC but both are amazingly fast, because the…

> I think GIL is not the reason for slowness, it is the weak dynamic types of Python that make it slow.

Python is structurally typed, that makes it dynamic, but it is not weak as there is no type coercion.

> Every single instruction need to be type checked at runtime and thus making everything slow.

This is also wrong, python does not type check anything, not in the "regular" manner of typechecking. It relies on structural typing, if it quacks like a duck, then it is treated like a duck.

In fact, PyPy is an argument against your position as it still allows the same (more or less) behaviour that python has while operating a lot faster due to JIT.

Python doesn't have the luxury of compiling that C# and Java, nor is the VM intended to be high performing.

Re: Rewriting a high performance vector database in Rust

#57

Post by dymk »

kaladin_1 wrote: post #41

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.

Re: Rewriting a high performance vector database in Rust

#58

Post by howinteresting »

rastignack wrote: post #34
howinteresting wrote: post #30

Earlier quoted context omitted.

This is just plain false. C++ in the 1990s had nothing like serde for example.

Where are the production grade and pure rust tls library ? Key-value store ? Ldap client ? SSH client ?

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.

Re: Rewriting a high performance vector database in Rust

#60

Post by ekidd »

kaladin_1 wrote: post #41

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 and maintain once you reach 50k to 80k lines on a group project. Typed Python, however, scales nicely beyond this size.

- Rust is a "medium-sized" language. It requires developers to learn more than Go or Python does, but less than C++. And Rust has far fewer traps for the unwary and the reckless than C++. Rust's tooling is also very good in many areas.

- It's tempting to split a project into a fast "core" language, and high-level "glue" language. There are real advantages to this. (Which is why I've done it on one recent project!) But this also comes with costs: everyone needs to be fairly good at two languages, and switch back and forth. And you pay a tax at the boundary.

If I were building a brand new database (and a team to maintain it), I'd actually be strongly tempted to use Rust exclusively. But this is partly because databases rarely have a "business logic" layer that changes constantly, so there's less need for a high level scripting language.

But with a different team or different constraints, C++ could also be the right choice.

Post reply on HN