undefined | Better HN

0 pointsModernMech1y ago0 comments

Makes sense, that's definitely a downside with Mojo. But my understanding is they made this tradeoff because compiling the python code directly would not work out. So is this something that is for the function-level (hence the name) and you don't plan to do this for full programs?

0 comments

3 comments · 1 top-level

olokobayusuf1y ago· 2 in thread

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.

DeathArrow1y 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?

olokobayusuf1y ago

Not 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).

j / k navigate · click thread line to collapse