About rust lib

[nxdong]

About rust lib:
I had seen Contact mario4tier on github if interested.
i wonder the progression about it.

tks a lot

[mario4tier]

Sorry no good news.

Unless someone shows up to lead this, it is unlikely to happen within 2024.

Personally, I should have enough experience with Rust by ~2025 (I am actively gaining experience with Rust app with another project while 2024).

[halohsu]

@mario4tier Hello, I have extensive experience in Rust development. My idea is to wrap the TALIB library through Rust FFI. How can I contribute Rust code to talib?

[mario4tier]

Sure. You are welcome to contribute with a PR.

For FFI, ideally your change would be isolated into its own directory, therefore making it easier for others to review and merge "without worrying".

As an alternative to FFI, consider that TA-Lib are fairly simple array processing functions. It would be great to tweak tool/gencode to make the source code compatible to native Rust (in same way that the existing code builds in Java, C, C++ and managed C++ after running through a C preprocessor). It is more work, but a more solid contribution that should reward you for the next 25 years 😄 If you can pull this off... you would likely become an admin for TA-Lib (can more freely merge and maintain it).

One way or another, you are OK to proceed with your FFI solution (nobody else working on this approach right now).

[mario4tier]

@halohsu,

Chad (@chadfurman) is evaluating to generate native Rust. That would be ideal since it would eliminate all "C" tool dependencies for the Rust users... bringing us one step closer to generate a ta-lib-rs crate.

Feel free to join the Native Rust effort or keep going with FFI as an alternative.

[halohsu]

Good news, hopefully we can all use secure rust code, I wrapped secure talib through ffi, which is time-consuming.

[halohsu]

Looking forward to talib computing performance built with native rust code. I'm optimistic about the future. I use any infrastructure in the trading broker data center for free, including servers and switches. talib continues to generate revenue for me as strategy core code on low-latency trading systems and low-latency hardware (exanic and x2522). I wrapped talib with ffi just because I was worried about my ability to optimize my C project. Tongda software also has a library similar to talib, using C language development, although the performance is better than talib, but the use of a large number of macros, which leads to later optimization difficulties, I dare not adopt. For now, talib is the only choice and the right one, offering high enough performance and good code optimization. Expect execution latency and performance from talib built with native rust code.
Anyway, I wish all the best.

[mario4tier]

@halohsu, Thanks for the feedback.

Will be interesting to learn how Native Rust performance will compare to Rust/FFI/C. I do not dare to predict, may eventually need you to measure 😉

** if you can share a few examples of your Rust API, it may inspire us to do the same.

[mrjbq7]

It's going to be fun to see whether "rewrite it in Rust" or "rewrite it in Zig" wins this race. :-)

[mario4tier]

@mrjbq7, glad to see you 😄

I recently fix gen_code and ta_regtest (now works with Linux/autoconf), and doing some refactoring to reduce the "ugliness".

@chadfurman is evaluating what needs to be done for Rust be generated in same way as done for Java.... so there is "hope" to have all the functions working at once. I estimate sometimes within 2025.

The other priority is continuous integration and scripted release (did gain some github actions experience the last ~2 years)... that should help keep all TA-Lib variants "fresher".

[chadfurman]

I like Mario's realistic, grounded approach and timeline estimates. First target is _something_ in rust. Already doing some initial experiments and expecting to dive deeper closer to EOY. I've been looking into pyo3 vs cython a bit also. Looks like performance should be comparable. Biggest costs are around rust's memory safety, but optimizations exist. Excited to see all the excitement here.

…

On Wed, Nov 13, 2024, 17:28 Mario Fortier ***@***.***> wrote: @mrjbq7 <https://github.com/mrjbq7>, glad to see you 😄 I recently fix gen_code and ta_regtest (now works with Linux/autoconf), and doing some refactoring to reduce the "ugliness". @chadfurman <https://github.com/chadfurman> is evaluating what needs to be done for Rust be generated in same way as done for Java.... so there is "hope" to have all the functions working at once. I estimate sometimes within 2025. The other priority is continuous integration and scripted release (did gain some github actions experience the last ~2 years)... that should help keep all TA-Lib variants "fresher". — Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE3CITAGGJF3X4EMST2FHT2APHCFAVCNFSM6AAAAABP4PWVRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZUHE2TCOJXG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mrjbq7]

Is the goal of Rust to use PyO3? What would that add that the current Python bindings aren’t providing?

[chadfurman]

The goal is to get to rust with all current indicators and no loss of functionality. I was mostly just curious about pyo3 and polars native rust extensions are also interesting and I'm curious about that comparison as well.

…

On Wed, Nov 13, 2024, 18:43 John Benediktsson ***@***.***> wrote: Is the goal of Rust to use PyO3? What would that add that the current Python bindings aren’t providing? — Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE3CIWB2LYBHV6TIYFMCGD2APPYTAVCNFSM6AAAAABP4PWVRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZVGA2DONJYGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mrjbq7]

It would be interesting if polars and rust bindings would provide any efficiency gain versus cython taking polars objects and passing backing memory to the C functions.

[mario4tier]

@mrjbq7 Just to also confirm, the primary goal is a Rust native "Core" library.

Once we get that delivered, we can evaluate if/how it could be used as an "easier" dependency than the stumbling "C library" ( https://github.com/PyO3/maturin ? )

I do not desire stretching us into having multiple competing "high performance" python project. Instead, I feel an alternative installation procedure using only Pypi packages (with wheels) would be welcome by many... and this would ideally be done as part of the project/community you have built over the years.

[mrjbq7]

I agree. And regarding wheels, I should probably just do it. I’ve resisted for awhile to separate the Python wrapper from the underlying C library. But it seems like the community needs it. Mostly for windows users that don’t seem as easily supported by their package managers. It just felt like a giant matrix of binaries to build and test and support, but I know GitHub actions can help us with the most common ones. Also, a related issue is some of the Python users apply the “small numbers” patch to their TA-Lib C library to allow doing technical analysis on crypto which sometimes has small prices. And I didn’t want to orphan them by building with the upstream C library that didn’t have that patch applied.

[mario4tier]

Also, a related issue is some of the Python users apply the “small numbers” patch to their TA-Lib C library to allow doing technical analysis on crypto which sometimes has small prices.

OK, will prioritize including this as a "0.6.0" release by EOY, with updated autoconf (+github to build windows 64-bits binaries). This release will be more about learning what still works or not on various platform.

[mario4tier]

@mrjbq7 Double checking that we are on the same page. The code in the TA-Lib repos already has that small numbers fix. What is missing is a new ".tar.gz" release. Correct?

===

On another subject, made a lot of progress on the Linux support. There is now a ta-lib-0.6.0-src.tar.gz "release candidate" in the directory "dist". Feel free to try, but do not change your installation instructions yet... (it will eventually be release as a Github binary asset).

[mrjbq7]

Yes, I don’t personally use the small number patch but that’s my understanding also. See for example this thread: TA-Lib/ta-lib-python#157 If you need any help testing or docs or other things for new releases let me know!

[gitctrlx]

Hi everyone,

I’ve been following this discussion about Rust bindings for TA-Lib with great interest, and I wanted to chime in with something I’ve been working on that might align with what’s being explored here. I’ve created a Rust-native implementation of technical analysis functions called kand, which you can find at https://github.com/rust-ta/kand. My aim with kand was to build a lightweight, performant, and pure-Rust alternative inspired by TA-Lib, without relying on C bindings.

So far, kand includes implementations of some popular indicators like moving averages, RSI, and MACD, with a focus on simplicity and integration with Rust’s ecosystem (e.g., it works nicely with libraries like ndarray). It’s still a work in progress, but I’d love for it to be a useful resource—or even a starting point—for anyone interested in technical analysis in Rust.

I’d really appreciate hearing your thoughts! Does something like kand fit into the vision being discussed here? Are there specific features or indicators you think would be valuable to prioritize? I’m excited to collaborate and learn from this community, so feel free to drop by the repo or share your feedback here.

Thanks for the great discussion so far—it’s inspiring to see so much interest in bringing TA-Lib concepts to Rust!

[mario4tier]

Hi @gitctrlx ,

I am divided in the sense that it would have been great for you to be a major contributor within the TA-Lib organization 😄, at the same time, I want to applaud your initiative.

kand looks great and will inspire us back. Also, if you are interested into the on-going effort there is still place for major contribution to be done (and you will be very welcome).

@chadfurman organize zoom meetings once or twice a month to coordinate the native Rust effort. Also, feel free to direct message me on Discord.

Differences
One long-term design decision for TA-Lib is to maintain a single "neutral source" to produce native C#, C/C++, Java and Rust (using a pre-processor to handle the syntax differences). That makes contributing new functions to TA-Lib a lot harder (versus kand source that has to handle a single language). We will keep going with this approach, because we believe there is some value into "write once" and have many native library automatically produced with the same algo (for consistency and more eyes to find bugs).

Would be great if at some point you integrate ta-lib native rust in kand deployment automation for, say, benchmarking and/or testing? At the current pace, we expect to have TA-Lib rust completed (for all functions) early next year.

Simplification
I encourage you to keep going as kand takes a simpler approach with its API and some (may be even many?) users might prefer this.

As an example, TA-Lib does not process (or output) NaN. It expects the caller to do "data alignment" (with startIdx, endIdx and the outBegIx and outNbElement params). This gives more flexibility for integration and speed optimization, but requires more "development work" which might turn off some users.

Food for thought, consider to contribute and integrate the TA-Lib Rust Native Core and still build kand on top of it? (for incremental feature, simplified API and better interfacing with ndarray and such). This approach is essentially what ta-lib-python did and they are very successful.

Thanks for sharing.

[mario4tier]

@gitctrlx ... and I like your creativity for merging Rust/TA-Lib into the kand logo 😄

Source: https://github.com/rust-ta/kand

[gitctrlx]

Hi @mario4tier ,

First off, apologies for replying so late—I just made it through a long, dark night over here and am finally catching up! Thanks so much for your thoughtful response and warm words. I really appreciate the encouragement and the insight into what the TA-Lib team is building—it’s amazing to see the dedication behind a unified, multi-language approach. The “write once” philosophy makes a lot of sense for consistency and reach, and I’m genuinely excited to hear the Rust effort is on track for early next year.

I’m happy you see some value in kand! My aim with it was to create something lightweight and Rust-native, with a simple API that plays nicely with tools like ndarray. I totally get that TA-Lib’s design offers powerful flexibility for advanced users, and I think kand can complement that by being a quick, approachable option for folks who want to dive in with less setup. It’s great to hear you think both can coexist and even inspire each other—I love that idea.

Your suggestion about integrating TA-Lib’s Rust native core for benchmarking or testing really caught my eye, and I’d be keen to explore that down the line. That said, I should be upfront that my time’s a bit stretched right now, so I wouldn’t be able to dive deeply into contributing to TA-Lib directly. I’d still love to stay connected, though—maybe joining a Zoom call with @chadfurman when I can, or chatting on Discord to bounce ideas around. I’ll reach out there soon!

For now, I’m focusing on polishing kand—adding a proper README and examples this week—so it’s easier for people to try out. I’d be thrilled if you or anyone here wanted to give it a spin and share thoughts! If there are specific indicators or features you think would be useful, I’d love to hear them and prioritize what resonates with the community.

Thanks again for the feedback and the logo nod (glad it made you smile 😄). I’m excited to keep in touch and see how we can support each other moving forward!