3 ms·
Spot on! We're starting from specific functions for now, and will expand the scope if/when feasible. The challenges exist across two axes: language coverage and
by olokobayusuf 2y ago
Spot on! We're starting from specific functions for now, and will expand the scope if/when feasible. The challenges exist across two axes: language coverage and library coverage.
For language coverage, Function currently doesn't support classes (on the roadmap) or lambda expressions (much harder). But these are the main limitations.
For library coverage, this is where things get incredibly hairy. If a library isn't pure Python (i.e. most of the important libs), we can't compile them. We instead have to reimplement the library's functionality. For now, we plan on using LLMs to automate this as much as possible.
- DeathArrow 2y ago>If a library isn't pure Python (i.e. most of the important libs), we can't compile them. If the library is written in C, like Numpy, can't you just link against it?
- olokobayusuf 2y agoNot quite. First, Function is designed to be truly cross-platform but libraries like Numpy aren't compiled for say WebAssembly. Second, the native libraries are usually built around CPython interop (i.e. the C API expects to interact with the CPython interpreter). Function does not (and will never) have a CPython interpreter (we generate full AOT compiled code).