Rewriting a high performance vector database in Rust • Hacker News Board

Re: Rewriting a high performance vector database in Rust

#81

Post by lijogdfljk » Tue, Oct 18, 2022, 9:50 PM UTC

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.

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

That kinda feels like saying Linux is too crazy because new apps get made for Linux frequently.

You can use the same part of the language tomorrow that you used today. Nothing is changing out from under you. If you're afraid of libraries, don't use them. You'd have the same problem in any ecosystem that is new, no?

Re: Rewriting a high performance vector database in Rust

#82

Post by dkarl » Tue, Oct 18, 2022, 9:52 PM UTC

ekidd wrote: post #60

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 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-level language for writing applications and scripts on top of a Rust codebase, like Boost Python for C++ or Tcl for C.

Re: Rewriting a high performance vector database in Rust

#83

Post by atoav » Tue, Oct 18, 2022, 9:53 PM UTC

krona wrote: post #61

pornel wrote: 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.

All of these tools and we still have exploitable buffer overflows in 2022. So either the tools are not working, people are not using them or they are using them but can simply ignore critical warnings.

Your milage may vary, but I think Rust offers a well considered step into the right direction. Stupid and dangerous code of the kind every developer will produce once in a while just won't compile in Rust. You cannot forget to run a check, you can't hide behind not knowing a tool. You can't ignore the warning of you want a running program.

That is not nothing.

Re: Rewriting a high performance vector database in Rust

#84

Post by pornel » Tue, Oct 18, 2022, 9:55 PM UTC

hutzlibu wrote: post #75

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…

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

You will have Conway's law in your codebase. Coordination between teams is hard, so teams will prefer to implement features entirely in their language, even where that is technically suboptimal.

You will get hot loops in Python, because a Rust programmer wasn't around, and Rust programmers implementing whole complex business logic in Rust behind a single `do_it()` Python call.

Re: Rewriting a high performance vector database in Rust

#85

Post by mamcx » Tue, Oct 18, 2022, 9:56 PM UTC

lupire wrote: post #79

dymk wrote: post #57

Earlier quoted context omitted.

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?

Well...

   UNSAFE {   
      // TODO: Verify all the lines, all the time, are ok
      // Just like you do testing, documentation, security and all that
      // ok?
      #include 
      using namespace std;
      int main() {

         // YOUR CODE
      }   
   }

Re: Rewriting a high performance vector database in Rust

#86

Post by lupire » Tue, Oct 18, 2022, 9:57 PM UTC

I liked the part where they said Python is too slow because it's garbage collected, and didn't show any metrics, and then built a new solution and Rust and didn't show metics to compare to the original system.

Makes me think the eng lead just wanted to do Rust, and made up a rationalization.

Re: Rewriting a high performance vector database in Rust

#87

Post by exceptione » Tue, Oct 18, 2022, 9:57 PM UTC

ekidd wrote: post #60

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

Especially business logic should be taken in the firm grip of static compile time guarantees that the hand of a strong type system delivers. Even more so if it changes constantly! Refactoring without fear.

Only software that does not have to run correctly (prototypes, personal hobby projects) can get away with a non-static type system.

When I have to pick a tool and I see it is written in Python I will have a look for an alternative if possible. Because I know it will have many bugs: some known, lots hidden.

Re: Rewriting a high performance vector database in Rust

#88

Post by doliveira » Tue, Oct 18, 2022, 9:58 PM UTC

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.

With my (admittedly limited) experience with the Hadoop ecosystem, I'd sincerely beg for people to stop writing databases in Java... Apart from the way bigger system requirements, dependency version hell, having to monitor GC pauses is just so, so annoying

Re: Rewriting a high performance vector database in Rust

#89

Post by lupire » Tue, Oct 18, 2022, 9:59 PM UTC

mamcx wrote: post #85

lupire wrote: post #79

Earlier quoted context omitted.

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

Well... UNSAFE { // TODO: Verify all the lines, all the time, are ok // Just like you do testing, documentation, security and all that // ok? #include using namespace std; int main() { // YOUR CODE } }

What are you saying?

Re: Rewriting a high performance vector database in Rust

#90

Post by darksaints » Tue, Oct 18, 2022, 10:00 PM UTC

pjmlp wrote: post #71

darksaints wrote: post #38

Earlier quoted context omitted.

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.

I've used Borland. I'm sure it was marvelous at the time, but it doesn't hold a candle to CLion or Visual Studio in the 2010s or later.