News for hackers. Stuff that matters.
Re:Show HN: Python at the Speed of Rust by ModernMech on Wednesday April 09, 2025 @11:10AM (#43633030)
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?
Re:Show HN: Python at the Speed of Rust by olokobayusuf on Wednesday April 09, 2025 @11:16AM (#43633097)
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.

Re:Show HN: Python at the Speed of Rust by DeathArrow on Saturday April 12, 2025 @09:48AM (#43664334)
>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?

Re:Show HN: Python at the Speed of Rust by olokobayusuf on Sunday April 13, 2025 @12:41PM (#43674034)
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).