Hacker News new | ask | show | jobs
by lampington 1038 days ago
Great article, but I'm saddened by their view that C is too hard to work with, so the 2-year-old extension must be rewritten in Rust.

C certainly has its faults, and while I have no real experience with Rust, I'm willing to believe that it's significantly better as a language.

But pgvector, at least from a quick scan, looks like a well-written, easily comprehensible C codebase with decent tests. There are undoubtedly lots of hard problems that the developers have solved in implementing it. Putting time and effort into reimplementing all of that in another language because of an aversion to C feels like a waste of effort that could be put into enhancing the existing extension.

Maybe there's something I'm missing? Is the C implementation not as solid as it looks at first glance?

1 comments

Rust makes concurrency really easy, at least in comparison to C or C++. It has great cross-platform frameworks available, like Tokio which pgvecto.rs uses, and makes using them safe and straightforward.
C also makes concurrency very easy. So easy the uncareful regularly shoot off both feet. Too easy.
It's hard to get concurrency right in C
I wonder if having that sort of "safe concurrency" causes developers to overuse concurrency and introduce coordination costs.

Do we know that tokio's concurrency strategy is optimal for database access?

Let’s assume that this is true. Then is the solution to go back to C where it is hard to get concurrency running correctly? Seems backwards thinking.
No, the solution is to keep the thing that's running quite well in c unless you can prove that it's better?
Starting with a claimed 20x speedup seems like proving it's better? https://modelz.ai/blog/pgvecto-rs