Replies: 3 comments 9 replies
-
|
While I don't have the real world systems engineering experience with C++ that some others who comment here may have (and only a basic knowledge of Rust), I've worked with enough people in Kuzu and outside, who deeply understand the tradeoffs involved. From a long-term project maintainability standpoint (with the goal of drawing more OSS contributors who will remain committed to the project), Rust would tend to have the upper hand. During my time at Kuzu, having seen numerous build issues, segfaults and data race bugs (many of which could have potentially been avoided by Rust's thread and memory safety), and most importantly imo, lack of asyncio support for Python users due to interop issues with pybind11, I've always been in support of database/data infrastructure projects being maintained long-term in Rust. PyO3 makes the bridge between Rust and Python an absolute joy, and imo is the reason why so many Python projects built on top of Rust today are so successful. Although LadybugDB is its own binary and is meant to cater to all language clients, there's no doubt that Python users will be its biggest community, so if I had to point to valid reasons for my thinking, my vote for a Rust rewrite is based on the above factors. |
Beta Was this translation helpful? Give feedback.
-
Carbon would take atleast 2 more years to be prod ready
I agree that rewriting a large codebase needs to be considered carefully. In this case, though, the codebase isn’t especially big and, with the help of coding assistants, I think we could move fairly quickly There are also some notable design issues in the current codebase which is making it harder to implement new features. I’m happy to have a go at an initial rewrite to get a clearer view of the risks involved |
Beta Was this translation helpful? Give feedback.
-
|
Here are my observations as a person who is trying to establish familarity with the codebase and the design. The community around ladybugdb is not mature enough to create a healthy feeback/review cycle yet. This is an essential quality required for rewrites. Someone who is rewriting from language A to B should be ideally proficient in both of them to understand why something was written the way it is and how to actually translate it. I see @adsharma being the only active contributor currently, so they must be a good enough judge of their expertise in both. Coming to the topic of coding agents being helpful for a quick rewrite. I highly doubt its efficacy in actual production code. At the end of the day which product would you like to market and have confidence in, a well tested piece of software written with intention in a slightly annoying language or a completely new vibe coded high flyer written in Rust. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
This is a difficult question and frankly a very divisive issue in a lot of other projects. Before it becomes a thing, here's an attempt to describe the current thinking behind sticking to an incremental path.
While there is no question that if we can do it safely and at low cost, we should do it. But...
The last part is the biggest wildcard. We have to wait a bit to figure out where things land when the dust settles. Perhaps different pieces of software get developed at different levels of abstraction and then lowered gradually to things like Rust, MLIR and then machine code.
Beta Was this translation helpful? Give feedback.
All reactions