I agree Scott, that wouldn’t be great. That’s just one potential path of several though. Here’s some other items for consideration:
- The driver is apache licensed. - the scylla folks may even be willing to contribute it. They’ve made efforts to collaborate in the past. - we could take the parts we like and just use those, like the networking bits. Ignoring it entirely seems like an emotional response, not a technical one. It reminds me of how we decided to start sidecar from scratch. Almost a decade later, only a handful of teams are using it. I’ll bow out of this discussion now. I’m not working on the driver, so I’m not impacted. Just wanted to throw an idea out there that might save some folks several years of work. Jon On Thu, Feb 5, 2026 at 11:02 PM <[email protected]> wrote: > I do not see third-party drivers controlled by entities whose core > strategy is to draw users away from Apache Cassandra as a suitable > foundation for official Apache Cassandra clients. > > Some quick thoughts: > > – Advancing the database’s wire protocol is increasingly difficult if it > requires updates to 5+ client libraries. A common core lib can help here. > – I think the native wrapper approach works well for the slightly longer > tail of programming languages we’d like to support. > – If we do adopt a native wrapper approach, we need a sizable number of > committed volunteers to maintain the core library. > – There are downsides to native wrappers such as decreased profileability, > language-native observability, logging integration, and app-level control > of the threading model. > – This raises an important question of driver strategy for the project. > The project's Java, Python, C++, and Go drivers all seem very mature but > have little in common. I wouldn’t be in a rush to replace any of them, > unless core maintainers of these libraries agreed that it would be > desirable to migrate one or more of them toward a native wrapper. > – At the same time, if the maintainers of a driver wanted to pursue > wrapping a memory-safe implementation - I’d also be receptive and eager to > follow. > – It could be interesting to prototype a Python lib implementation backed > by cassandra-rs which exists today as well. > – I think this proposal warrants a fleshed-out CEP. Since there’s a lot to > cover, I think we need more than the body of the CASSPYTHON-8 ticket and a > DISCUSS thread. > > Bret, thanks for starting this discussion - eager to follow. > > – Scott > > On Feb 5, 2026, at 9:38 PM, Jon Haddad <[email protected]> wrote: > > Why reinvent the wheel? > > https://github.com/scylladb/scylla-rust-driver > > On Thu, Feb 5, 2026 at 10:57 AM Bret McGuire <[email protected]> > wrote: > >> I don't disagree at all Josh but I also don't view the two approaches >> as contradictory. I would certainly expect that any Rust work we did for >> the Python driver should transfer very naturally over to a Rust core when >> we get to that point. The Python driver uses a combination of C and cython >> for a fair number of things (including type serde and eval of row data). >> These are things we would need in a common Rust core and I would absolutely >> expect that any impl we come up with for these things would transfer >> easily. Perhaps more importantly I would argue this allows us to work on a >> Rust implementation incrementally; it would be nice to be able to tackle >> chunks of the core (and get them out in the wild where we can validate them >> with real-world use cases) without waiting for the whole core to be >> complete. >> >> This change also has significant benefits for the Python driver as it >> stands now; moving the current cython & C code into a common framework (and >> updating it) will be of considerable utility to the driver going forward. >> But this shouldn't get in the way of any effort to move to a common core. >> >> - Bret - >> >> On Thu, Feb 5, 2026 at 8:52 AM Josh McKenzie <[email protected]> >> wrote: >> >>> From a general philosophical perspective, I think the health of our >>> ecosystem would be better served by having one core natively compiled >>> driver lib and then language ecosystem native wrappers around that core. >>> Similarly to how the Swift driver wraps the C++ driver. Lowering the amount >>> of engineering required to keep multiple language ecosystem drivers in >>> parity is a big win as the ecosystem's currently pretty fragmented. >>> >>> Using rust for the core of that given its memory safety, concurrency >>> correctness, performance, language interconnect ecosystem, and general >>> zeitgeist makes a lot of sense to me. >>> >>> On Tue, Feb 3, 2026, at 2:21 PM, Bret McGuire wrote: >>> >>> Greetings all! >>> >>> Another one that seemed worthwhile to bring to the list. I've just >>> filed CASSPYTHON-8 <https://issues.apache.org/jira/browse/CASSPYTHON-8> to >>> explore the idea of replacing our current C and cython code with equivalent >>> Rust implementations. This technique is becoming more common in the Python >>> world but there are concrete benefits for us on the Python driver team. >>> There's some discussion about these benefits on CASSPYTHON-8. >>> >>> Our upcoming release (likely 3.30.0) will be intended to get an >>> ASF-branded Python driver out into the wild so I'm not planning on tackling >>> any work in this area then. The plan would be to start with this effort >>> for 3.31.0. We'll start with something small, just to try out the >>> mechanism for integrating Rust code into a Python project, and see where >>> that takes us. >>> >>> Thanks! >>> >>> - Bret - >>> >>> >>> >
