-
Notifications
You must be signed in to change notification settings - Fork 4
On Wrapping CBash #27
Description
I'd like to bring forth a proposal - this is obviously a long-term goal but from short discussions with @Infernio I believe it's something achievable (since part of it already has been) and can be considered. Wrapping CBash in Rust, RBash.
TL;DR - Memory-safe with no loss of performance wrapper. Python 3 64bit only. Long term goal. Example. Built wheel.
CBash is written in C++ and afaik I believe none of the current devs have the skill in it needed to tackle working on CBash. The biggest draw of C/C++ is the perfomance, mainly via the low-level access, which let's you bypass some slower, safer abstractions to achieve it. It also benefits from being an old language, pretty much everything has been done with C++ and you can leverage that. And if there is something you need that hasn't, you can just use C, which was created around the time the primordial dust was gathering into what would one day become Earth.
Rust, on the other hand, is the hipster newcomer. Version 1 in 2015(?), with a new edition in 2018. A memory-safe systems programming language with influence from functional programming. No more segmentation faults or memory leaks. It seems to be more and more talked about as a credible alternative to C/C++ but it could just be confirmation bias on my end. Pretty easy to learn, too. Biggest drawback is its age - the existing material for it is in no way comparable to the others above. BUT, much like C++, we can just use C behind the scenes and hope it doesn't segfault or memory leak there :P In terms of performance I've seen benchmarks that placed it above C++ and below C, and I know that benches are not real life situations but the point is that performance shouldn't be an issue.
Rust also allows us to create a python extension module from code completely in rust. In the example repo I'm using pyo3, although there is another crate who can also create python extensions. This can be discussed later if this proposal is accepted.
As far as specific goals for the wrapper, I'd like to divide them into 3 stages. These are all long term goals that will be done slowly, over time.
-
Stage 1 - Create a simple wrapper around CBash public API and expose it to python. Essentially a replacement for ctypes in
cint. This should already be accomplished in this repo, but I'm sure I forgot something or there's some mistake, can't really test right now. -
Stage 2 - Consume
cint. Slowly take overcint, start moving the python code there into rust. The templates/macros in rust should also help with reducing the monstruosity that is that module right now and provide a better API. At the end of this stage the public RBash API should be stabilized. -
Stage 3 - Consume CBash. This is a very long term goal, but if done slowly over time we could do it. Not much to say here, CBash is ridiculously huge, who knows what secrets it hides.
Over these stages, we'll never lose access to CBash and indeed we'll be using as RBash's own backend, so there's never any "big" breaking step. Keep in mind this is just a proposal and nothing is really set in stone.
EDIT: A handy flowchart to help with deciding :P
Hope this gets greenlit!
