Rendered at 14:28:39 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
leobuskin 18 hours ago [-]
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).
subarctic 18 hours ago [-]
"Without ai assistance" - ok, but what about with ai assistance?
zahlman 18 hours ago [-]
For a project like this, relying on AI assistance also makes it effectively dead in the water.
minimaxir 18 hours ago [-]
Why?
all2 17 hours ago [-]
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.
jack_pp 15 hours ago [-]
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 $.
zero1009 16 hours ago [-]
Someone pays for the AI? That's the new human maintainer.
nozzlegear 16 hours ago [-]
Who will pay if someone, somewhere is not passionate about it?
throw1234567891 9 hours ago [-]
You can spin up a model locally and pay yourself. Who will maintain the project if the passionate sole maintainer burns out?
inigyou 4 hours ago [-]
Which model works well?
bloppe 16 hours ago [-]
Hypothetically, maybe. In practice, probably not.
CookieCrisp 15 hours ago [-]
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?
jpfromlondon 6 hours ago [-]
Plenty of important things have been born of passion without necessity.
wild_pointer 15 hours ago [-]
Trust
bt1a 17 hours ago [-]
[flagged]
chomp 17 hours ago [-]
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”
frollogaston 15 hours ago [-]
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.
simonw 15 hours ago [-]
Good luck implementing and then maintaining a project of this size and complexity at ~100 lines of verified code per human developer per day.
leobuskin 18 hours ago [-]
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?
coldtea 17 hours ago [-]
>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.
hannasanarion 16 hours ago [-]
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.
coldtea 15 hours ago [-]
>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.
jack_pp 15 hours ago [-]
your first mistake is thinking this would cost that much. with DS4 this might cost far less than 1k imo
int_19h 8 hours ago [-]
With DS4 it would have a lot more bugs, too.
imtringued 7 hours ago [-]
Just eight years ago basically nobody wanted to pay for compilers and developer tooling, and now you're suggesting people will spend a thousand dollars for a compiler they'll have to maintain themselves just because they're willing to pay for AI generated tokens but not for finished tools?
>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.
If you're an aerospace company you're willing to pay thousands of dollars for a compiler, because you need a DO-178C certified toolchain so that you can DO-178C certify the whole airframe. Suggesting AI here tells me you have no clue about the realities of aerospace, because you've just thrown out the entire value proposition of the commercial toolchains.
cyanydeez 17 hours ago [-]
It's like we invented a worse github.
dotancohen 17 hours ago [-]
To be fair, most of the training data likely came from GitHub.
15 hours ago [-]
coldtea 17 hours ago [-]
Gimphub.
bt1a 17 hours ago [-]
it will be impossible to maintain parity with wetware
up2isomorphism 17 hours ago [-]
Then the question is why? Because that is an another way of saying donating tokens.
TZubiri 16 hours ago [-]
>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.
geraneum 16 hours ago [-]
> 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.
skeledrew 16 hours ago [-]
> 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.
cwillu 14 hours ago [-]
Most subsets of a physical calculator are properly called “a broken calculator”.
skeledrew 14 hours ago [-]
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.
bunderbunder 14 hours ago [-]
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.
Archit3ch 15 hours ago [-]
> A subset of python is python.
Mojo folks (rightly) disagree.
leobuskin 14 hours ago [-]
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.
rurban 17 hours ago [-]
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
bunderbunder 16 hours ago [-]
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.”
leobuskin 17 hours ago [-]
It passes only curated corpus (snippets), not the full CPython test suite. So, yes, reading is hard. Nothing against AI, btw.
anitil 15 hours ago [-]
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"
No, it wouldn't, because he didn't actually read the readme which clearly states that they are still working on passing the CPython test suite and that 5x performance is an aspirational goal, not something they accomplished yet.
>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.
>Stdlib build-out: _io/os, math/struct/random, collections/itertools/json, datetime, importlib parity — each lands as a native module plus a differential corpus module.
>AoT parity growth toward the full corpus, plus single-binary product polish.
>No-GIL/free-threaded runtime hardening: thread/GC/signal stress is now on the default runtime path, with remaining gaps tracked by the ratcheted suites.
Overall the substantial parts of his comment are completely wrong and the subjective parts are not much better
>With AI it's 100x easier to maintain than by hand.
This is an unsubstantiated opinion. In practice AI has a limit well below 100x.
>It reminds my on pperl. same approach using crane lift. Looks good
>This program turns ordinary perl scripts into long running daemons, making subsequent executions extremely fast. It forks several processes for each script, allowing many proceses to call the script at once.
Which sounds nothing like pon, which is heavily inspired by bun. Meanwhile if it's this: https://perl.petamem.com/ which took quite a while to find, then I'm wondering why that would have precedence over bun?
Once you add the first sentence, it basically turns into a negative value comment that shouldn't have been posted.
anitil 1 hours ago [-]
I noticed that it wasn't the best comment, I was only concerned with the tone, and I feel like dang has enough going on that we also need to help elevate the conversation. I admit there's some delicious irony in the accuser committing the same crime, but it doesn't improve the discussion to revel in that.
cwillu 14 hours ago [-]
> Reading is hard.
The irony…
ubercore 17 hours ago [-]
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.
getpokedagain 17 hours ago [-]
>> 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.
tclancy 17 hours ago [-]
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.
frollogaston 15 hours ago [-]
It says ratchet so much. Yeah that's pretty ratchet. Idk what it even means for some of those usages.
3form 7 hours ago [-]
Ahh, AI. All ratchet and clank.
getpokedagain 14 hours ago [-]
Oh what the fuck I can t unsee
dr_kretyn 16 hours ago [-]
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.
ubercore 18 hours ago [-]
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.
himata4113 18 hours ago [-]
This is written by fable with the guidance of a very experienced, highly skilled person. See their previous work.
Dilettante_ 18 hours ago [-]
"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?
Experience doesn't change the fundamental problem. I don't see this project going anywhere for general use beyond their needs.
roger_ 17 hours ago [-]
This guy is behind the awesome Oh My Pi agent, so I’d give him a chance.
thx67 15 hours ago [-]
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.
baq 18 hours ago [-]
of course it is vibed.
it doesn't matter as long as it works.
ActionHank 18 hours ago [-]
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.
coldtea 17 hours ago [-]
>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.
ubercore 17 hours ago [-]
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.
coldtea 15 hours ago [-]
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.
ubercore 5 hours ago [-]
Been there done that. My point is that even with Fable being a big improvement, it still needs constant feedback.
The loops themselves are a lot better, but it still needs judgement calls, and Fable will often take an odd direction, and if you don't catch it, that odd choice will compound as it continues to layer on top.
coldtea 5 hours ago [-]
>Been there done that. My point is that even with Fable being a big improvement, it still needs constant feedback.
Even so, if it does 80% of the work itself, that's still a 5x improvement.
Plus it keeps the human coder in control and in the loop (and in a job).
int_19h 8 hours ago [-]
If you just keep throwing feature requests at an LLM, then yes, this happens. However it can self-correct if you specifically give it engineering debt / code cleanup as a task. And Fable in particular is very good at this exact thing.
8 hours ago [-]
timacles 12 hours ago [-]
AI will simply code you into an architectural corner where you can’t get out of without a refactor.
coldtea 6 hours ago [-]
Not if you give it guidance for the architecture and don't just blindly let it one-shot after one-shot of huge chunks of the program.
Besides, AI can also be told to do the refactor.
nielsbot 9 hours ago [-]
to be fair that happens with code i write too…
LtWorf 15 hours ago [-]
AI companies are unable to fix the bugs in their own text editors for years… no AI cannot fix bugs, clearly.
coldtea 15 hours ago [-]
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.
LtWorf 8 hours ago [-]
It matters, it shows the limits of the technology, and they have all the interest to showcase how good it is (and are failing to show it can fix bugs)
coldtea 6 hours ago [-]
They have little interest to "showcase how good it is with doing that" since (a) people already see it's good and are hooked, (b) they don't want to stop the pace of changes and fall behind on features by focusing on stability and bug fixing.
LtWorf 5 hours ago [-]
They literally could use unlimited tokens and focus on both… it's telling that they cannot.
And they are TRYING to fix the bugs, they just keep failing over and over, so your reply is entirely incorrect.
Nice try though.
coldtea 5 hours ago [-]
>They literally could use unlimited tokens and focus on both… it's telling that they cannot.
If you ship updates fast, you can't just 'focus on both'. You focus on one or another, doesn't matter if you use "unlimited tokens", same way 9 pregnant women can't make a baby in a month.
>And they are TRYING to fix the bugs, they just keep failing over and over, so your reply is entirely incorrect.
That they "keep failing over and over" is a huge overstatement, it just has some bugs like other software has, so your point can be simply dismissed.
LtWorf 4 hours ago [-]
> you can't just 'focus on both'
Can you explain why not? Just spin up another agent. 9 pregnant women can do 9 babies in 9 months.
This is a real question. I assure you that teams of more than 1 developer do exist, so I don't see why agents could not work on the same code.
> That they "keep failing over and over" is a huge overstatement
You call it an overstatement because of your religious beliefs. Unfortunately religious beliefs don't really change the fact that they keep failing in fixing their things.
I think the clankers would call this a "load bearing statement".
nielsbot 9 hours ago [-]
it reads like marketing copy…
kameit00 18 hours ago [-]
In 12 months… vibe code mess. Or discontinued. Or both.
ttul 16 hours ago [-]
How much time have you spent with Fable? We're in new territory here. It does not create messes.
nozzlegear 16 hours ago [-]
> We're in new territory here.
> It does not create messes.
?
ubercore 16 hours ago [-]
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.
what 16 hours ago [-]
>this time it’s different!
Same thing people claim every time a new model is released, yet never seems to be true.
int_19h 8 hours ago [-]
It was true every time though. The capacity of frontier models to tackle complicated issues has improved immensely. I still remember the first time I saw a model do a non-trivial issue end to end, and that was less than two years ago. Now they can genuinely do whole projects with human only as a supervisor / quality checker.
Do they still make mistakes? Sure. So do humans, though, so it would be unrealistic to expect perfection. The question is: does Fable make fewer mistakes than the median human coder? And at this point I'm genuinely not sure anymore.
mcphage 18 hours ago [-]
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?
ubercore 18 hours ago [-]
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.
getpokedagain 14 hours ago [-]
Something working is pointless if there are no users and no need is being addressed.
rcarmo 8 hours ago [-]
Funny to see it took the same IR approach as I did with https://github.com/rcarmo/go-joker - although I did it somewhat based on the .NET IR and this seems a bit more AI-ish.
thx67 15 hours ago [-]
A couple of other interesting Python compiler projects recently..
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.
bbminner 15 hours ago [-]
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.
henry2023 14 hours ago [-]
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.
eru 10 hours ago [-]
They can, and they have been doing so. But humans are expensive. Especially smart humans.
int_19h 8 hours ago [-]
Fable is also very expensive, unfortunately.
It will be interesting to see how cheap they can make it long term.
eru 7 hours ago [-]
Well, so far any gives level of capability has started with (expensive) frontier models, but everyone else, including the cheaper models, usually quickly catches up and the frontier keeps moving forward.
Fable-level capability will most likely be available for pennies soon enough.
cuzezzzbbfofai 18 hours ago [-]
Can it run Numpy and Torch?
smithza 18 hours ago [-]
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.
cdavid 17 hours ago [-]
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.
RantyDave 17 hours ago [-]
Don't we have Nuitka for this?
LtWorf 17 hours ago [-]
It's not the same, that one works.
TZubiri 16 hours ago [-]
that compiles to C presumably, not to machine code
15 hours ago [-]
drivebyhooting 17 hours ago [-]
Looks like it still uses python object model. You need auto unboxing for good performance.
echoangle 18 hours ago [-]
What happens if you call exec/eval? Are they just not available?
skeledrew 16 hours ago [-]
Also getattr/setattr, the magic methods, etc. I imagine this dead on arrival.
smithza 18 hours ago [-]
this as well as pickle files will likely be unavailable
moronicles 17 hours ago [-]
[dead]
leobuskin 17 hours ago [-]
It uses JIT
piloto_ciego 10 hours ago [-]
Lol, all the people squawking about how this means nothing and this is a worthless project amuses me. A lot of people just don't see it yet. This is coming for literally everything and it is so exciting. The next decade is going to be awesome.
worldsavior 8 hours ago [-]
You can see it cause...you're a prophet right?
LtWorf 3 hours ago [-]
The man's called "blind pilot".
imtringued 7 hours ago [-]
Most of the value proposition of Python is that it calls into fast native modules. Compiling Python itself helps a little, but it isn't that big of a deal. The most prominent Python JITs have been a failure because of the tight coupling between CPython and native modules.
Basically the entire Python ecosystem has deep integration into implementation details of CPython, if there was a runtime independent api like HPy, then the effort would be better spent migrating to it rather than building yet another half baked JIT.
weregiraffe 9 hours ago [-]
What's so exciting about your software being made of code nobody can or wants to understand?
piloto_ciego 9 hours ago [-]
Can you not see how amazing this is?
weregiraffe 8 hours ago [-]
A nuclear explosion is amazing, but I won't be excited about the nuke falling on my head.
7 hours ago [-]
westurner 18 hours ago [-]
How does performance compare to RustPython compiled in a similar way?
elzbardico 16 hours ago [-]
Seems to be slow as molasses compared to cpython.
zoom6628 14 hours ago [-]
Mojo not good enough?
xiaodai 15 hours ago [-]
it's been tried 10 million times. so yeah
Archit3ch 15 hours ago [-]
Surely this will succeed where $4B Modular failed!
iLoveOncall 18 hours ago [-]
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.
andy99 18 hours ago [-]
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.
ranger_danger 15 hours ago [-]
How would a search engine filter that out?
genewitch 14 hours ago [-]
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?
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).
Arguably, passion for a project is without price.
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.
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.
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.
>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.
If you're an aerospace company you're willing to pay thousands of dollars for a compiler, because you need a DO-178C certified toolchain so that you can DO-178C certify the whole airframe. Suggesting AI here tells me you have no clue about the realities of aerospace, because you've just thrown out the entire value proposition of the commercial toolchains.
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.
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 a calculator is still a calculator, but that subset definitely can't do everything the full version can.
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 (rightly) disagree.
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
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.”
> 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
>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.
>Stdlib build-out: _io/os, math/struct/random, collections/itertools/json, datetime, importlib parity — each lands as a native module plus a differential corpus module.
>Performance ratchets: tagged small-int flip, TLAB allocation, dict fast paths, float unboxing, call/attribute specialization, generator tiering — toward the ≥5× CPython geomean target (numerics ≥20×).
>AoT parity growth toward the full corpus, plus single-binary product polish.
>No-GIL/free-threaded runtime hardening: thread/GC/signal stress is now on the default runtime path, with remaining gaps tracked by the ratcheted suites.
Overall the substantial parts of his comment are completely wrong and the subjective parts are not much better
>With AI it's 100x easier to maintain than by hand.
This is an unsubstantiated opinion. In practice AI has a limit well below 100x.
>It reminds my on pperl. same approach using crane lift. Looks good
The only thing I can find on the internet that mentions "pperl" is this https://metacpan.org/pod/PPerl
>This program turns ordinary perl scripts into long running daemons, making subsequent executions extremely fast. It forks several processes for each script, allowing many proceses to call the script at once.
Which sounds nothing like pon, which is heavily inspired by bun. Meanwhile if it's this: https://perl.petamem.com/ which took quite a while to find, then I'm wondering why that would have precedence over bun?
Once you add the first sentence, it basically turns into a negative value comment that shouldn't have been posted.
The irony…
> 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.
Is a pretty oof sentence for a project with one contributor and no users. Just reeks of llm barf with no oversight.
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.
https://github.com/can1357/selene
it doesn't matter as long as it works.
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.
And it's quite easy to ask an AI to refactor a certain way too.
The loops themselves are a lot better, but it still needs judgement calls, and Fable will often take an odd direction, and if you don't catch it, that odd choice will compound as it continues to layer on top.
Even so, if it does 80% of the work itself, that's still a 5x improvement.
Plus it keeps the human coder in control and in the loop (and in a job).
Besides, AI can also be told to do the refactor.
If you use AI yourself, with a focus on bug fixing and stability, you'll find that AI can fix bugs just fine.
And they are TRYING to fix the bugs, they just keep failing over and over, so your reply is entirely incorrect.
Nice try though.
If you ship updates fast, you can't just 'focus on both'. You focus on one or another, doesn't matter if you use "unlimited tokens", same way 9 pregnant women can't make a baby in a month.
>And they are TRYING to fix the bugs, they just keep failing over and over, so your reply is entirely incorrect.
That they "keep failing over and over" is a huge overstatement, it just has some bugs like other software has, so your point can be simply dismissed.
Can you explain why not? Just spin up another agent. 9 pregnant women can do 9 babies in 9 months.
This is a real question. I assure you that teams of more than 1 developer do exist, so I don't see why agents could not work on the same code.
> That they "keep failing over and over" is a huge overstatement
You call it an overstatement because of your religious beliefs. Unfortunately religious beliefs don't really change the fact that they keep failing in fixing their things.
https://www.youtube.com/watch?v=zfYsSFY4l18
I think the clankers would call this a "load bearing statement".
> It does not create messes.
?
Same thing people claim every time a new model is released, yet never seems to be true.
Do they still make mistakes? Sure. So do humans, though, so it would be unrealistic to expect perfection. The question is: does Fable make fewer mistakes than the median human coder? And at this point I'm genuinely not sure anymore.
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.
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
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.
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.
It will be interesting to see how cheap they can make it long term.
Fable-level capability will most likely be available for pennies soon enough.
Basically the entire Python ecosystem has deep integration into implementation details of CPython, if there was a runtime independent api like HPy, then the effort would be better spent migrating to it rather than building yet another half baked JIT.
or we can bring back gopher and just not index slop sites?