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

101–110 of 157 posts

Re: Rewriting a high performance vector database in Rust

#101

Post by timeon »

krona wrote: post #91
pornel wrote: post #72

Earlier quoted context omitted.

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…

The results are a trade-off between sparse or having false positives. Rust just takes the other side of the trade-off, and will reject valid programs. Hence why the unsafe keyword exists, and why tools like Miri ( https://github.com/rust-lang/miri ) exist specifically for rust.

> Rust just takes the other side of the trade-off, and will reject valid programs.

Are we still talking about ease of add novice Rust programmers to a project?

Re: Rewriting a high performance vector database in Rust

#102

Post by heavyset_go »

dkarl wrote: post #82
ekidd wrote: post #60

Earlier quoted context omitted.

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…

> Typed Python, however, scales nicely beyond this size. Could you say more about what tools and practices make this possible, beyond simply adding type annotations in your code? Asking for a friend. > It's tempting to split a project into a fast "core" language, and high-level "glue" language. I did this with C++ and Boost Python back in the day and loved the experience. I wonder if Rust will someday get a high-leve…

> Could you say more about what tools and practices make this possible, beyond simply adding type annotations in your code? Asking for a friend.

Python with type annotations works really well with type checkers like Mypy, along with LSP servers, and both of those integrate with most development environments.

Using a Python-oriented IDE like Pycharm with type annotated Python also allows for better refactoring options. It reduces the uncertainty and guesswork an IDE's static analyzer must engage in for even basic features you'd take for granted with IDE and statically typed languages.

In practice, developers don't have to keep what can be a massively complex application running in their heads to modify code accurately. A nicely typed project makes it easy to see exactly what types of data get passed around and modified. Before gradual typing, you'd have to backtrack to all of a function's call sites to understand exactly what kind of data it takes and returns. With gradual typing, you can just look at types and rely on Mypy to ensure the right data is passed around.

> I did this with C++ and Boost Python back in the day and loved the experience. I wonder if Rust will someday get a high-level language for writing applications and scripts on top of a Rust codebase, like Boost Python for C++ or Tcl for C.

I haven't used Boost Python, but there are some options for Rust and Python that work well and seem to suit this use case like PyO3.

Re: Rewriting a high performance vector database in Rust

#103

Post by gotts »

arriu wrote: post #47
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 agree, rust has a difficult learning curve. I’ve often heard at least a year is required to really feel confident.

6 months is what I heard. I'm currently at ~2 and 6 sounds like a pretty good estimate.

Re: Rewriting a high performance vector database in Rust

#104

Post by pjmlp »

0x457 wrote: post #96
fwip wrote: post #3

> First of all, Python is a garbage collected language, which means it can be extremely slow for writing anything high performance at scale. I don't think garbage collection is in the top 3 causes of why Python is slow.

> First of all, Python is a garbage, which means it can be extremely slow for writing anything high performance at scale. Fixed it.

Thankfully Fintech and military weapon control systems aren't high performance.

Re: Rewriting a high performance vector database in Rust

#105

Post by howinteresting »

notriddle wrote: post #70
nicoburns wrote: post #26

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.

I've led and been on teams that have written multiple production-grade Rust services that have together delivered 100MM+ USD of value. The number of production bugs has been in the single digits, with exactly one outage that lasted more than a few minutes in the last 3 years. How about yourself?

In my experience, Rust delivers by far the fewest number of bugs in production out of any mainstream language. It gets the fundamentals right like nothing before it. &, &mut, Send and Sync take care of many classes of bugs in the inner loop of productivity.

Re: Rewriting a high performance vector database in Rust

#107

Post by pjmlp »

PartiallyTyped wrote: post #56
slt2021 wrote: post #39

Earlier quoted context omitted.

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

PyPy is still slower than the competition and largely ignored by the Python community.

Re: Rewriting a high performance vector database in Rust

#108

Post by dymk »

codegeek wrote: post #48
jalino23 wrote: post #4

rewriting everything in rust is not just a meme?

It's like everyone is trying to do things in "Rust" because it's the new thing to do.

Rust is 12 years old. 1.0 was released in 2015.

We've been past the "it's the shiny new thing" phase for a while.

Re: Rewriting a high performance vector database in Rust

#109

Post by djwatson24 »

pornel wrote: post #72
krona wrote: post #61

Earlier quoted context omitted.

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…

> and that relies on having sufficient test and fuzz coverage

At the faang I worked at, some small portion of servers ran the sanitizers in prod, so you’re not reliant on test coverage nearly so much for catching rare issues.

Re: Rewriting a high performance vector database in Rust

#110

Post by heavyset_go »

arriu wrote: post #47
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 agree, rust has a difficult learning curve. I’ve often heard at least a year is required to really feel confident.

It takes a relatively short time to be proficient enough to make useful contributions, maybe half a year to a year to be confident. You can give an experienced developer the Rust book and have them contributing to a Rust codebase quickly.
Post reply on HN