4 ms·
I wish the PoC of these were written in Go or Rust so they could be built without weird hacks or dependencies.
by api 6y ago
I wish the PoC of these were written in Go or Rust so they could be built without weird hacks or dependencies.
- capableweb 6y agoHaving both Python (https://github.com/tprest/falcon.py https://github.com/tprest/falcon.py) and C (https://falcon-sign.info/impl/README.txt.html https://falcon-sign.info/impl/README.txt.html) seems good enough for a PoC. Usually you only get one implementation :)
- theamk 6y agoC is great because almost every language, Go and Rust included, has well supported FFI interface for it, and because it has no runtime requirements. This particular library doesn't even use memory allocation, which is great for things like embedded, OS-less hardware. This would be impossible in Go, and will require non-ideomatic Rust.
- steveklabnik 6y agoZero-allocation Rust is quite idiomatic. I write some every day :)
- theamk 6y agoMaybe "not ideomatic" is not quite the right word... They are explicitly making their API more complex in order to support unusual usages. They avoid heap allocation by making user pre-allocate output buffers. And they even avoid stack allocation by having user provide "void* tmp" argument (see [0]). One can definitely implement such interface in Rust, but I don't think it would be pleasant to use. Having to worry about temp buffer allocation at most calls is not something one wants to do. I am pretty sure that this library is designed to be wrapped by a second layer -- be it in Rust, C++ or even GLib-style C. [0] https://falcon-sign.info/impl/falcon.h.html https://falcon-sign.info/impl/falcon.h.html
- steveklabnik 6y agoTaking a mutable slice is extremely common for exactly this reason. Even in the standard library, which can allocate. We added some convenient functions later, but it's a pretty standard practice.
- deleted 6y ago[deleted]