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.