There are hundreds of programming languages and just as many programming styles. How can an agile organisation serve such myriad needs of library consumers without excluding relevant language paradigms? Should we write and maintain libraries written natively in multiple languages, like Python, C, Go, Java, Node.js and Rust?
While there may be reasons (like performance & changeability) for maintaining multiple implementations, such an approach has a very real engineering cost and mandates perfect cross-team communications and excellent adherence to requirements specifications. This implies maintaining multiple test suites, isolated documentation and cross-language version lock-stepping. This requires more management, resources and developers - ultimately making the cost per abstract line of code simply untenable for all but the largest organisations.
Having a single source of code truth is nothing new. Foreign Function Interfaces (FFI) make it possible for one language to consume code from another language, via so-called bindings. For decades, the go-to language has been C or C++. Unfortunately, the global community has started to come to the realisation that C, while very powerful, makes it challenging to securely manage memory. Large organisations like Microsoft and Google have recognised that the majority of zero-days and critical bugs affecting their products have arisen from improper memory management. They are now actively looking to Rust as a way to prevent overflows and undefined behaviour from happening in the first place.
Nevertheless, library consumers - especially in brownfield projects - often don't have the luxury of simply retooling and retraining. In these very common situations, simply consuming Rust libraries is a challenging proposition, if not downright impossible. This talk will explain the approach and perspective of the IOTA Foundation to tackling this head on. Specifically, the talk will:
- dive into benchmarks between native implementations in different languages (C vs Rust, WASM vs JS)
- learn about the tooling requirements needed to craft Rust-based libraries and then package them with debugging symbols
- investigate the formats of resulting bindings and transpilations
- discuss opportunities for automation and CI
Comments Sign in to post comments
Vote
Submitted by Kais Hossaini on Tue, 2020-06-09 05:59
Really interested to see this presented
Interesting topic
Submitted by Abe Linux on Wed, 2020-06-10 23:01
Very interesting topic, hopefully will get the chance to see this.