Agreed in general. To me, what's interesting about this is how fast it is. This isn't a transliteration. It's a reimplementation. I'm not looking at the source code at all other than in the initial spec generation - I'm taking it from spec and redoing it entirely.
At the very least, it implies to me that there's a lot of performance that glibc leaves on the table.
Disclaimer: The Liella project is entirely LLM generated, and is a collaboration between me and Claude Code.
Hi! (I read all the tips, so I'm typing this in by hand, no LLMs here):
A few weeks ago, I had an idea: what would happen if I took a massive codebase and reimplemented it from first principles? So I sat down with Claude Code, told it to generate specs and never consult glibc source ever again, and see what it generated. 400,000 LOC or so later, and I have something that's nearing ready for release. It currently implements nearly all of glibc, and currently significant effort is being put into making it performant. Most code (especially on the hot paths) is at parity with or significantly faster than glibc (16% or so on average, and some regex or local based code is twice as fast). Some code (particularly on the cold path) is still slower but I'm working on improving that. I'm driving towards a release soon - maybe in a couple of months. I still have to build the dynamic loader. Coreutils currently compiles and runs against it, and that's part of the core test suite.
I did build most of this project in rust, mostly because in this case I thought it was the right tool for the job. Some code on the hot path is implemented in C/assembly, and there's a C ABI that has entry points into the rust code. The goal is to be drop-in compatible with glibc in the vast majority of cases.
I'm looking for people who are interested in taking this further - maybe testing on other platforms, helping to work on performance, starting work on the dynamic loader phase, or just code and documentation cleanup (Claude is not perfect).
This is a 100% LLM generated project, so if that's not your cup of tea, I understand. No hard feelings. But if this sounds like it's something you're interested in helping with, I'd love to hear from you!
Code in URL. This is not a fly by night project - I've invested significant resources into this, and will continue to do so.
You can contact me at liella@koiren.ai if you're interested, or comment here.
AI transliterations aren't very interesting. AI can convert any project from any language to any other language.
Agreed in general. To me, what's interesting about this is how fast it is. This isn't a transliteration. It's a reimplementation. I'm not looking at the source code at all other than in the initial spec generation - I'm taking it from spec and redoing it entirely.
At the very least, it implies to me that there's a lot of performance that glibc leaves on the table.
Disclaimer: The Liella project is entirely LLM generated, and is a collaboration between me and Claude Code.
Hi! (I read all the tips, so I'm typing this in by hand, no LLMs here):
A few weeks ago, I had an idea: what would happen if I took a massive codebase and reimplemented it from first principles? So I sat down with Claude Code, told it to generate specs and never consult glibc source ever again, and see what it generated. 400,000 LOC or so later, and I have something that's nearing ready for release. It currently implements nearly all of glibc, and currently significant effort is being put into making it performant. Most code (especially on the hot paths) is at parity with or significantly faster than glibc (16% or so on average, and some regex or local based code is twice as fast). Some code (particularly on the cold path) is still slower but I'm working on improving that. I'm driving towards a release soon - maybe in a couple of months. I still have to build the dynamic loader. Coreutils currently compiles and runs against it, and that's part of the core test suite.
I did build most of this project in rust, mostly because in this case I thought it was the right tool for the job. Some code on the hot path is implemented in C/assembly, and there's a C ABI that has entry points into the rust code. The goal is to be drop-in compatible with glibc in the vast majority of cases.
I'm looking for people who are interested in taking this further - maybe testing on other platforms, helping to work on performance, starting work on the dynamic loader phase, or just code and documentation cleanup (Claude is not perfect).
This is a 100% LLM generated project, so if that's not your cup of tea, I understand. No hard feelings. But if this sounds like it's something you're interested in helping with, I'd love to hear from you!
Code in URL. This is not a fly by night project - I've invested significant resources into this, and will continue to do so.
You can contact me at liella@koiren.ai if you're interested, or comment here.
Thanks!