Good discussion all! I'd like to take a step back for just a second. I feel like there are at least three different conversations going on here and it seems worthwhile to me to separate those out (since I suspect they have very different outcomes).
The ongoing threads as I see them are: 1. The replacement of some (or all) of the C and cython code in the Python driver code base with Rust 2. The idea of implementing a common core containing driver functions + language-specific bindings for our drivers 3. Implementing a new Rust driver The scope of CASSPYTHON-8 is (1) and nothing else. It was also the original motivation for starting this thread. The Python driver already contains some cython code (and a small amount of C) to speed up certain ops so I'm not proposing _adding_ new functionality here... just replacing this functionality with Rust for the reasons outlined in CASSPYTHON-8. We should be able to talk about this idea without involving (2) or (3) at all. I'm in agreement with Scott that (2) probably deserves a CEP; it's certainly much too big to discuss in a dev@ thread. I'm happy to create this CEP and move that discussion there. I also agree that the case for (3) is less clear to me, although this is certainly something we can talk about. My inclination is to create the CEP for (2) and see if there's any interest in (3) as part of that conversation but for now I'd categorize (3) as a "stretch goal" or "maybe someday kinda thing". So for purposes of _this_ discussion my primary goal was to see if anybody had thoughts/objections to (1) above. I'll also start working on putting the CEP together. Thanks everybody! - Bret - On Fri, Feb 6, 2026 at 1:02 AM <[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 - >>> >>> >>> >
