Fantastic article. It does a great job of describing a point in time in the computer business from the point of view of someone who was deeply inside it. It’s fascinating to see how much Peddle got right and how much he got wrong. This early on, there was little to no installed base, so everything was up for grabs and there were many companies doing the grabbing.
This is going to be a strategic challenge for ARM unless they are going to focus on chips that nobody else wants to make. And given the AI focus, that doesn’t seem to be the case. I would think that the RISC-V folks would be salivating at the prospect of flipping some existing ARM licensees to RISC-V.
I don’t believe that nobody else would build it for them. This chip is not purely custom to Meta, as I understand it. Rather, ARM is going to be selling it to others and entering the market for “AI chips,” which is surely a market that some other ARM licensees want to be in. So therefore, ARM is competing with its other licensees, and in a potentially very lucrative, leading edge market, which is never a great place for an IP-focused company to be. Qualcomm, for instance, is undoubtedly annoyed at this.
Then you’d say that Apple doesn’t make their laptops. Foxconn does.
The kind of work ARM would do to “make” a chip themselves goes beyond just design. It’s synthesis, P&R, test, packaging (generally a different company than the fab), yield management, inventory/logistics, etc.
Have you looked at the code? It was clearly generated in one form or another (see the other comments).
The author created a new GitHub account and this is their first repository. It looks to be generated from another code base as a sorta amalgamation (either through code generation, ai, or another means).
We're supposed to implicitly trust this person (new GitHub account, first repository, no commit history, 10k+ lines of complicated code).
Jia Tan worked way too hard, all they had to do was upload a few files and share on HN :)
I think there are 3 levels at play here. One is code as curation, a model I'm not particularly interested in. Clearly the publisher, despite not being paid, is a supplicant. and as a curator I'm as much or more interested the in process being used and the longetivity of the code base.
The second is code as artifact. Is this code useful, performant, with a reasonable API.
The third is code as concept, or architecture. This is really what interests me here. I use explicit allocators any time I can get away with it, and it's an excellent tool for involved systems projects. I'm not really interested in using this code, but having implemented these things many times, looking at how other people made the various tradeoffs, how it all came together, is really valuable input for when I'm going to do this again. Maybe there are some really brand new ideas here.
While I'm unsympathetic to the first perspective, it's valid. But I don't think its fair to castigate someone who put something on GitHub for not meeting someones adoption criteria.
In the meantime, I don't see much value from your criticism of this particular project. I don't think this is a great example of AI slop even if it is generated, and you haven't clearly articulated harm.
> no commit history, 10k+ lines of complicated code
This kind of pattern is incredibly common when e.g. a sublibrary of a closed source project is extracted from a monorepository. Search for "_LICENSE" in the source code and you'll see leftover signs that this was indeed at one point limited to "single-process-package hardware" for rent extraction purpouses.
Now, for me, my bread and butter monorepos are Perforce based, contain 100GB+ of binaries (gamedev - so high-resolution textures, meshes, animation data, voxely nonsense, etc.) which take an hour+ to check out the latest commit, and frequently have mishandled bulk file moves (copied and deleted, instead of explicitly moved through p4/p4v) which might mean terrabytes of bandwidth would be used over days if trying to create a git equivalent of the full history... all to mostly throw it away and then give yourself the added task of scrubbing said history to ensure it contains no code signing keys, trade secrets, unprofessional easter eggs, or other such nonsense.
There are times when such attention to detail and extra work make sense, but I have no reason to suspect this is one of them. And I've seen monocommits of much worse - typically injested from .zip or similar dumps of "golden master" copies, archived for the purpouses of contract fulfillment, without full VCS history.
Even Linux, the titular git project, has some of these shenannigans going on. You need to resort to git grafts to go earlier than the Linux-2.6.12-rc2 dump, which is significantly girthier.
> It looks to be generated from another code base as a sorta amalgamation (either through code generation, ai, or another means).
I'm only skimming the code, but other posters point out some C macros may have been expanded. The repeated pattern of `(chunk)->...` reminds me of a C-ism where you defensively parenthesize macro args in case they're something complex like `a + b`, so it expands to `(a + b)->...` instead of `a + b->...`.
One explaination for that would be stripping "out of scope" macros that the sublibrary depends on but wishes to avoid including.
> We're supposed to implicitly trust this person
Not necessairly, but cleaner code, git history, and a more previously active account aren't necessairly meant to suggest trust either.
Being limited to just control and alt definitely cuts down on the options. Conversely, having MacOS command key act as “super” in Emacs opens up some possibilities.
reply