Not convinced. I was looking for an answer like "it doesn't actually have parity with CPython." If it does, that's a decent indication that it can be sustained.
Humans have time-cost too, much higher than machines. Considering SOTA right now, for a project like this it would make more sense for the community to contribute and verify tests, sponsor updates with $.
It's possible, but we're at the moment when most of us can ask Fable to implement a custom compiler to a custom target for our favorite language, and even use it as a part of custom solution. Why do I need someone else's implementation? Where's the magic in this project? What's the secret sauce?
>Where's the magic in this project? What's the secret sauce?
Someone else paying for the tokens.
Also someone seeing it through (should that come). Obviously we're not "at the moment when most of us can ask Fable to implement a custom compiler to a custom target for our favorite language, and even use it as a part of custom solution", without thousands to spare and lots of time to shape the solution.
Even if it does cost thousands (does it? I genuinely have no idea how to scope such a thing) that might be a good price if a custom compiler to your custom target is something you really want. People have paid far more for far less.
If you're a hobbyist trying to compile python to your weird little arduino based thing, then that's a lot of money and you would want to use somebody else's solution, no doubt.
But if you're an aerospace company trying to compile for a flight control computer (and I guess you really want to use python for some reason), spending thousands of dollars on tokens to make and maintain a custom compiler could represent serious savings.
The big picture impact of AI that I see/anticipate the most is SAAS dying out because AI coding makes this kind of enablement and support software easier to make in-house, and this feels like an example of that, but maybe I'm seeing what I expect to see.
>Even if it does cost thousands (does it? I genuinely have no idea how to scope such a thing) that might be a good price if a custom compiler to your custom target is something you really want. People have paid far more for far less.
I wouldn't spend $100K in tokens to get a custom bare metal Python. Or even $10K.
And I'd guess that most devs wouldn't either, unless they spend $10K like it's nothing.
People that have "paid far more for far less" are people who have the money to buy $10K watches, or fancy multi $1000 clothes.
This isn't about the shell of a calculator though, but the functionality. Like if the only operations are addition and subtraction, theoretically you could derive the effects of other operations but it's extremely limiting.
So yeah, half of Python might still be Turing-complete, but it wouldn’t really be Python for any practical purpose.
Just like how a device that can’t multiply or divide is not a 4-function calculator; it’s more like an adding machine. Many of which did multiply by serial addition.
Mojo folks created a new language, officially called it "superset", and trying to sell to enterprise. And it's not a superset by definition, because it can't run it's "subset" (the original Python) without CPython (which was used as libcpython under the hood, iirc). It's a travesty.
The “status” section of the project’s readme explicitly says that it is not passing the full test suite, and that the AOT compiler passes fewer tests than the JIT one.
It also explicitly says that they’re still working on building out the standard library.
I’m maybe not as pessimistic as leobuskin, but they are absolutely right that this is not the first time someone has tried to build an alternative Python implementation, and that all previous ones have failed because they weren’t able to get close enough to 100% parity to be acceptable to most users. Python is an unusually quirky language. I kind of wonder if “written in Rust” adds an extra headwind here because there’s nothing even remotely memory-safe about Python’s extension mechanism. I don’t know enough to know, but I have read about the death of a few of these projects in the past and a common theme of the post-mortem seems to be, “It went so smoothly at the start that we were caught off guard how much of a brick wall the last 5% was going to be.”
Your reply would have been much better without the first line [0]
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that"
> What is explicitly not done yet — this is the active roadmap, in order:
> CPython test suite (cpython-full): the standing grind; failures are clustered and burned down per wave.
I am a fan of AI assistance, but “ratchet” is pretty much a Claude giveaway. The kids, now in their twenties because the reference is dated, might make a joke here.
If AI can find new proofs for well posed math problems, i see no reason why it shouldn't be able to implement a more performant fully featured version of an existing interpreter (eg with JIT and AOT) that emulates python api well and passes all python tests and tests of other projects. It is true that a lot of human effort and thought has been put into squeezing performance out of the existing implementation. It is true that many people have found that getting that last 1% of python test suite to pass turned out to be insurmountably hard. Same is true for math, and yet AI sometimes finds simple solutions that we somehow missed. Maybe there's a simple optimization that was used in an obscure interpreter of a domain specific language that we never heard of. Worth a shot in my mind. If that turns out to be successful, we should ideally find the code that served "as an inspiration" if any.
It might make more practical sense to start from CPython and try to optimize that further though. It even has a "not fully fleshed out" JIT already.
If humans can find (and have been finding for millennia) new proofs for well posted math problems, I see no reason why they shouldn’t be able to implement a more performant fully featured version of an existing interpreter.
Awesome. Not for this repo specifically; more about the trend. More people are realizing that we have such powerful tools at our disposal and will want to do something awesome, worth while with them. Of course, many will fall off after a week, then more after a month, but some will survive. Knowledge will be spread and some will be winners through adoption. Grit can lead to knowledge, and can lead to awesome stuff.
I hate to be that guy, but... one week old project, clear signs of vibing. I will be shocked if the remaining work listed (cpython test suite) proceeds in any reasonable timeline.
This is a pretty hard problem to just solve in a week.
EDIT: and man, these kind of comments LLM created comments are really starting to grind my gears as my job slowly turns into reviewing LLM PRs:
> Known gaps at the language level are burned down through the ratcheted floors above — the committed floor files, not this README, are the authoritative compatibility baseline.
"Very experienced" might mean different things to you. The oldest repo on their GH is from 2017. As for highly skilled: Could you point closer to which parts of their portfolio we are supposed to be awestruck by?
>when it's vibed it works, until it doesn't and then it's really hard to make it work again
Is it?
People have solved AI bugs with AI. If some vibe project eventually hits some bug and stops working, what exactly stops using AI to fix it? Is the idea that bugs will go beyond the limits of AI capability?
If you meant to say that when an AI vibe coded project beyond some complexity it's difficult for a human coder to manually go through all the code they didn't write, understand it, and find the issue, sure.
The problem is the _way_ AI will solve an AI bug. I've seen the loop countless times. There's a creeping complexity and brittleness that creeps in over time as more and more complexity is left purely to the LLM agent. It will become unsustainable without a human understanding and making course corrections at some point.
Doesn't matter what AI companies do, since AI companies just "move fast and break things" not caring for bug fixing but for iterating quickly on their agents. That's a business decision, not an AI limitation.
If you use AI yourself, with a focus on bug fixing and stability, you'll find that AI can fix bugs just fine.
Given the stdlib modules listed as "explicitly not done yet", I'm going to say: it doesn't yet, in any meaningful sense. The question then becomes: how confident do we feel that it will work in the near future?
I was trying to say "not confident at all" but hedged a bit too much.
I see this as a case of the "quick to get to a POC that falls apart after sustained development for the same reasons it didn't work pre-Fable" problem.
Dynamic typing means you don't know the sizes/offsets of things beforehand. The "compiled to metal" thing still resembles a runtime more than your typical compiled code. Like naively, object would be a struct with a hashmap of property names->values since technically you can alter the keys at runtime, and many values will be pointers to other objects. Idiomatic C or Rust code will have flatter structs.
Is it faster than the original interpreter? Maybe if you optimize out the primitives and certain well-known object types, unless you do some more advanced static analysis.
pickle files are usually the limiter here. I would be surprised if it can handle pickle files since it relies so much on runtime LUTs of the objects and arbitrary object definitions. This usually doesn't work in other use cases such as swig or cython either IIRC.
For NumPy/Pytorch, the C API is much bigger issue than pickle. I have not looked at the architecture of this, but given it uses its own IR + replaces ref counting w/ a GC, I am assuming it does not have C API compatibility.
Can those AI slop projects have a reserved tag on HackerNews? So many in the past few weeks I wouldn't have clicked and wasted my time on if I knew it was just some vibe-coded garbage.
I see the same thing, and believe that ironically AI is going to bring about the return of good search engines as we’re currently drowning in slop and need a real way to filter it.
you'd need a tacit agreement that real humans who care tag and filter things for the search engine. like a webring or stumbleupon. I imagine it's easier to bolt this on to an existing product by adding "tags" and a "AI likelihood score" or something.
or we can bring back gopher and just not index slop sites?
A few problems with this Fable's project:
1. It's not Python by any means, it's a subset with its own runtime, its own quirks and nuances;
2. It will be impossible to maintain parity with CPython without AI assistance;
3. It will die the same way as dozens of similar (even non-AI projects) died before, and reasons will be the same: (1) and (2).
"Without ai assistance" - ok, but what about with ai assistance?
For a project like this, relying on AI assistance also makes it effectively dead in the water.
Not convinced. I was looking for an answer like "it doesn't actually have parity with CPython." If it does, that's a decent indication that it can be sustained.
Why?
Time-cost for machines instead of willing knowledgeable humans. The former requires money, the latter requires passion.
Arguably, passion for a project is without price.
Humans have time-cost too, much higher than machines. Considering SOTA right now, for a project like this it would make more sense for the community to contribute and verify tests, sponsor updates with $.
Someone pays for the AI? That's the new human maintainer.
Who will pay if someone, somewhere is not passionate about it?
Hypothetically, maybe. In practice, probably not.
If it's valuable enough to someone, and it isn't keeping up, someone will pay. If it's not valuable enough for someone to pay, then who cares?
Trust
A memory of theirs. Trying to use some heavily quantized gpt-3 era toddler to assist the development of a project. Maybe. A blind posit. Yea
I don’t want to be mean, but try to run a large project and you’ll realize there’s more to it than “can I find some bodies to crank out code”
Good luck implementing and then maintaining a project of this size and complexity at ~100 lines of verified code per human developer per day.
It's possible, but we're at the moment when most of us can ask Fable to implement a custom compiler to a custom target for our favorite language, and even use it as a part of custom solution. Why do I need someone else's implementation? Where's the magic in this project? What's the secret sauce?
>Where's the magic in this project? What's the secret sauce?
Someone else paying for the tokens.
Also someone seeing it through (should that come). Obviously we're not "at the moment when most of us can ask Fable to implement a custom compiler to a custom target for our favorite language, and even use it as a part of custom solution", without thousands to spare and lots of time to shape the solution.
Even if it does cost thousands (does it? I genuinely have no idea how to scope such a thing) that might be a good price if a custom compiler to your custom target is something you really want. People have paid far more for far less.
If you're a hobbyist trying to compile python to your weird little arduino based thing, then that's a lot of money and you would want to use somebody else's solution, no doubt.
But if you're an aerospace company trying to compile for a flight control computer (and I guess you really want to use python for some reason), spending thousands of dollars on tokens to make and maintain a custom compiler could represent serious savings.
The big picture impact of AI that I see/anticipate the most is SAAS dying out because AI coding makes this kind of enablement and support software easier to make in-house, and this feels like an example of that, but maybe I'm seeing what I expect to see.
>Even if it does cost thousands (does it? I genuinely have no idea how to scope such a thing) that might be a good price if a custom compiler to your custom target is something you really want. People have paid far more for far less.
I wouldn't spend $100K in tokens to get a custom bare metal Python. Or even $10K.
And I'd guess that most devs wouldn't either, unless they spend $10K like it's nothing.
People that have "paid far more for far less" are people who have the money to buy $10K watches, or fancy multi $1000 clothes.
your first mistake is thinking this would cost that much. with DS4 this might cost far less than 1k imo
It's like we invented a worse github.
Gimphub.
To be fair, most of the training data likely came from GitHub.
it will be impossible to maintain parity with wetware
Then the question is why? Because that is an another way of saying donating tokens.
>1. It's not Python by any means, it's a subset with its own runtime, its own quirks and nuances;
A subset of python is python. Half a tomato is still tomato
>2. It will be impossible to maintain parity with CPython without AI assistance
What does that even mean? If you would have said that it's impossible to update to python 3.15 of further, I'd get it.
> A subset of python is python. Half a tomato is still tomato
The funny thing about this is not that the first sentence is wrong, which it is. It’s the failed reductio ad absurdum.
> A subset of python is python. Half a tomato is still tomato
A subset of a calculator is still a calculator, but that subset definitely can't do everything the full version can.
Most subsets of a physical calculator are properly called “a broken calculator”.
This isn't about the shell of a calculator though, but the functionality. Like if the only operations are addition and subtraction, theoretically you could derive the effects of other operations but it's extremely limiting.
So yeah, half of Python might still be Turing-complete, but it wouldn’t really be Python for any practical purpose.
Just like how a device that can’t multiply or divide is not a 4-function calculator; it’s more like an adding machine. Many of which did multiply by serial addition.
> A subset of python is python.
Mojo folks (rightly) disagree.
Mojo folks created a new language, officially called it "superset", and trying to sell to enterprise. And it's not a superset by definition, because it can't run it's "subset" (the original Python) without CPython (which was used as libcpython under the hood, iirc). It's a travesty.
Reading is hard.
It runs and passes the full cpython testsuite, just 5x faster.
With AI it's 100x easier to maintain than by hand.
It reminds my on pperl. same approach using crane lift. Looks good
The “status” section of the project’s readme explicitly says that it is not passing the full test suite, and that the AOT compiler passes fewer tests than the JIT one.
It also explicitly says that they’re still working on building out the standard library.
I’m maybe not as pessimistic as leobuskin, but they are absolutely right that this is not the first time someone has tried to build an alternative Python implementation, and that all previous ones have failed because they weren’t able to get close enough to 100% parity to be acceptable to most users. Python is an unusually quirky language. I kind of wonder if “written in Rust” adds an extra headwind here because there’s nothing even remotely memory-safe about Python’s extension mechanism. I don’t know enough to know, but I have read about the death of a few of these projects in the past and a common theme of the post-mortem seems to be, “It went so smoothly at the start that we were caught off guard how much of a brick wall the last 5% was going to be.”
It passes only curated corpus (snippets), not the full CPython test suite. So, yes, reading is hard. Nothing against AI, btw.
Your reply would have been much better without the first line [0]
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that"
[0] https://news.ycombinator.com/newsguidelines.html
> Reading is hard.
The irony…
How am I misreading this part of the readme?
> What is explicitly not done yet — this is the active roadmap, in order: > CPython test suite (cpython-full): the standing grind; failures are clustered and burned down per wave.
>> The project is under heavy active development
Is a pretty oof sentence for a project with one contributor and no users. Just reeks of llm barf with no oversight.
I am a fan of AI assistance, but “ratchet” is pretty much a Claude giveaway. The kids, now in their twenties because the reference is dated, might make a joke here.
It says ratchet so much. Yeah that's pretty ratchet. Idk what it even means for some of those usages.
Oh what the fuck I can t unsee
If AI can find new proofs for well posed math problems, i see no reason why it shouldn't be able to implement a more performant fully featured version of an existing interpreter (eg with JIT and AOT) that emulates python api well and passes all python tests and tests of other projects. It is true that a lot of human effort and thought has been put into squeezing performance out of the existing implementation. It is true that many people have found that getting that last 1% of python test suite to pass turned out to be insurmountably hard. Same is true for math, and yet AI sometimes finds simple solutions that we somehow missed. Maybe there's a simple optimization that was used in an obscure interpreter of a domain specific language that we never heard of. Worth a shot in my mind. If that turns out to be successful, we should ideally find the code that served "as an inspiration" if any.
It might make more practical sense to start from CPython and try to optimize that further though. It even has a "not fully fleshed out" JIT already.
If humans can find (and have been finding for millennia) new proofs for well posted math problems, I see no reason why they shouldn’t be able to implement a more performant fully featured version of an existing interpreter.
Awesome. Not for this repo specifically; more about the trend. More people are realizing that we have such powerful tools at our disposal and will want to do something awesome, worth while with them. Of course, many will fall off after a week, then more after a month, but some will survive. Knowledge will be spread and some will be winners through adoption. Grit can lead to knowledge, and can lead to awesome stuff.
I hate to be that guy, but... one week old project, clear signs of vibing. I will be shocked if the remaining work listed (cpython test suite) proceeds in any reasonable timeline.
This is a pretty hard problem to just solve in a week.
EDIT: and man, these kind of comments LLM created comments are really starting to grind my gears as my job slowly turns into reviewing LLM PRs:
> Known gaps at the language level are burned down through the ratcheted floors above — the committed floor files, not this README, are the authoritative compatibility baseline.
This is written by fable with the guidance of a very experienced, highly skilled person. See their previous work.
"Very experienced" might mean different things to you. The oldest repo on their GH is from 2017. As for highly skilled: Could you point closer to which parts of their portfolio we are supposed to be awestruck by?
https://github.com/vtil-project/VTIL-Core
https://github.com/can1357/selene
Experience doesn't change the fundamental problem. I don't see this project going anywhere for general use beyond their needs.
This guy is behind the awesome Oh My Pi agent, so I’d give him a chance.
These tics are fairly easy to remove via hooks and prompts, but once the codebase is infected, it is 10x as much work to get the agents to stop.
of course it is vibed.
it doesn't matter as long as it works.
That's the neat part, when it's vibed it works, until it doesn't and then it's really hard to make it work again.
>when it's vibed it works, until it doesn't and then it's really hard to make it work again
Is it?
People have solved AI bugs with AI. If some vibe project eventually hits some bug and stops working, what exactly stops using AI to fix it? Is the idea that bugs will go beyond the limits of AI capability?
If you meant to say that when an AI vibe coded project beyond some complexity it's difficult for a human coder to manually go through all the code they didn't write, understand it, and find the issue, sure.
The problem is the _way_ AI will solve an AI bug. I've seen the loop countless times. There's a creeping complexity and brittleness that creeps in over time as more and more complexity is left purely to the LLM agent. It will become unsustainable without a human understanding and making course corrections at some point.
In my experience, it just needs some high level guidance.
And it's quite easy to ask an AI to refactor a certain way too.
AI will simply code you into an architectural corner where you can’t get out of without a refactor.
AI companies are unable to fix the bugs in their own text editors for years… no AI cannot fix bugs, clearly.
Doesn't matter what AI companies do, since AI companies just "move fast and break things" not caring for bug fixing but for iterating quickly on their agents. That's a business decision, not an AI limitation.
If you use AI yourself, with a focus on bug fixing and stability, you'll find that AI can fix bugs just fine.
> it doesn't matter as long as it works.
I think the clankers would call this a "load bearing statement".
In 12 months… vibe code mess. Or discontinued. Or both.
How much time have you spent with Fable? We're in new territory here. It does not create messes.
> We're in new territory here.
> It does not create messes.
?
Anecdote, yes, but I am _right now in the middle of helping Fable clean up a mess_. Complex code is hard and Fable still makes mistakes.
>this time it’s different!
Same thing people claim every time a new model is released, yet never seems to be true.
Something working is pointless if there are no users and no need is being addressed.
Given the stdlib modules listed as "explicitly not done yet", I'm going to say: it doesn't yet, in any meaningful sense. The question then becomes: how confident do we feel that it will work in the near future?
I was trying to say "not confident at all" but hedged a bit too much.
I see this as a case of the "quick to get to a POC that falls apart after sustained development for the same reasons it didn't work pre-Fable" problem.
A couple of other interesting Python compiler projects recently..
https://github.com/Nonannet/copapy uses copy and patch, discussed here https://news.ycombinator.com/item?id=46972392
Single-pass SSA bytecode compiler and threaded-code stack VM for a sandboxed Python subset https://github.com/dylan-sutton-chavez/edge-python
Dynamic typing means you don't know the sizes/offsets of things beforehand. The "compiled to metal" thing still resembles a runtime more than your typical compiled code. Like naively, object would be a struct with a hashmap of property names->values since technically you can alter the keys at runtime, and many values will be pointers to other objects. Idiomatic C or Rust code will have flatter structs.
Is it faster than the original interpreter? Maybe if you optimize out the primitives and certain well-known object types, unless you do some more advanced static analysis.
Don't we have Nuitka for this?
It's not the same, that one works.
that compiles to C presumably, not to machine code
Can it run Numpy and Torch?
pickle files are usually the limiter here. I would be surprised if it can handle pickle files since it relies so much on runtime LUTs of the objects and arbitrary object definitions. This usually doesn't work in other use cases such as swig or cython either IIRC.
For NumPy/Pytorch, the C API is much bigger issue than pickle. I have not looked at the architecture of this, but given it uses its own IR + replaces ref counting w/ a GC, I am assuming it does not have C API compatibility.
Looks like it still uses python object model. You need auto unboxing for good performance.
What happens if you call exec/eval? Are they just not available?
Also getattr/setattr, the magic methods, etc. I imagine this dead on arrival.
this as well as pickle files will likely be unavailable
It uses JIT
How does performance compare to RustPython compiled in a similar way?
Mojo not good enough?
Seems to be slow as molasses compared to cpython.
it's been tried 10 million times. so yeah
Surely this will succeed where $4B Modular failed!
Can those AI slop projects have a reserved tag on HackerNews? So many in the past few weeks I wouldn't have clicked and wasted my time on if I knew it was just some vibe-coded garbage.
I see the same thing, and believe that ironically AI is going to bring about the return of good search engines as we’re currently drowning in slop and need a real way to filter it.
How would a search engine filter that out?
you'd need a tacit agreement that real humans who care tag and filter things for the search engine. like a webring or stumbleupon. I imagine it's easier to bolt this on to an existing product by adding "tags" and a "AI likelihood score" or something.
or we can bring back gopher and just not index slop sites?