loadtxt VS okapi

It really depends on what part of Numpy you're using. You can easily leave Numpy's text parsing in the dust. And if you're doing element-wise operations on arrays, you can easily see 2-3x improvement with just numba.

Amdahl's Law will catch up with you really fast as you add threads with this strategy, but it's simple and is amenable to formats where you may have a delimiter in the middle of a record. For situations where you need maximum scaling and don't have the possibility of delimiters scattered into records, you can use the strategy I used to implement a faster numpy.loadtxt: https://github.com/saethlin/loadtxt/blob/master/src/inner.rs#L84 The general idea is that you divide the file among thread boundaries by splitting it on byte boundaries, then seeking from that byte offset to the end of the next record. This gets you non-interleaved sections so there's no duplicate parsing.

It's inspired by others in the space that you might check out: paperclip, okapi, and others.

okapi: supports rocket

okapi looks decent as well. Has codegen for Rocket: https://github.com/GREsau/okapi

I have used it the other way around. I created the Rust code and using that to generate the documentation. https://github.com/GREsau/okapi this worked very good. Here is the generated documentation: https://docs.dfstoryteller.com/rapidoc/ This uses the Rust Doc comments to populate the documentation.

Oh Rocket, you playful muse. I've watched you ascend from my early Rust days; yet each time I reach for you my heart sinks more. This research project of mine led me to okapi, an extension for OpenAPI documentation. And yet, I have to pass once again. While most of the Rust ecosystem blazes toward async, you inch toward it too slowly. Perhaps next time I search for a web framework our paths will align, but until then, I must follow a different orbit.