Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There are 25 graph databases all going me too in the AI/LLM driven cycle.

Writing it in Rust gets visibility because of the popularity of the language on HN.

Here's why we are not doing it for LadybugDB.

Would love to explore a more gradual/incremental path.

Also focusing on just one query language: strongly typed cypher.

https://github.com/LadybugDB/ladybug/discussions/141



Is LadybugDB not one of these 25 projects?


LadybugDB is backed by this tech (I didn't write it)

https://vldb.org/cidrdb/2023/kuzu-graph-database-management-...

You can judge for yourself what work has been done in the last 5 months. Many short videos here. New open source contributors who I didn't know before ramping up.

https://youtube.com/@ladybugdb


Those 25 are me too; this one is a me as well /s.


Good decision, as proven multiple times, it is the product not the programming language, that makes the customers.


I really wish people would stop using the language as an argument and that commenter would also move on to a more interesting debate.

In your discussion the first comment from an ex kuzu dev made an excellent point that rust for databases in an excellent language to ship faster with confidence while reducing real problems of concurrency and corruption.

At some point it becomes intellectual dishonesty to dismiss a language because of vibes instead of merit.


I didn't dismiss the language. I called it a north star. Rust is still the best option if you desire memory safety.

But rewriting a complex working piece of software in Rust is not trivial. Having an incremental path (where only parts are rewritten in Rust and compatible with C++ code) would be a good path to get there.

Also open to new code and extensions getting written in Rust.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: