It is, I think. I published the article on BCN (the preface is me, the rest is a reader submission) and I find I agree with relatively little of the article, but I think it has observations worth looking at, even so.
In the sense that while there was a positive outcome ("We moved to Rust, which solved our issues with Zig no longer accepting AI-assisted content" - a projection on my part, but one I think makes sense) without an actual contribution that one would expect.
It's in Rust! That means Rust's memory safety applies! ... except as a direct port, it doesn't, it's got Zig's memory semantics in Rust-shaped code. As others have pointed out (including me, FWIW) that's something that can change... but it's not a simple thing to accomplish, and it may ALWAYS be a Zig-shaped skeleton in a bag of Rust.
If I recall correctly - and I might not - the process found places in the test suite that were wrong or lacked clarity, and the suite was modified slightly in a few places to actually fix things that needed fixing. I don't think it was a broad enough change to actually significantly affect the coverage to a real degree, but then again, that WOULD be a good thing to dive into the PR to check - and as I've pointed out, I'm not a Bun user myself, so my main response to that is a vaguely-interested shrug and a nod towards what seems to be the bigger issue: the use of AI to do things performatively.
As far as publishing "the prompt" - there's no "the prompt." The draft was put together and expanded over a set of interactions with an LLM and other people over the space of about six hours. "The prompt" would have been about twelve pages long and unreadable. Funny as heck, but unreadable.
(If you're really interested, you can check the logs in the site and find the actual interaction that started the article out. It was a comment from someone else, and it got me thinking.)
Heh. Funny thing: I've been writing online and professionally for literal decades, since around 2002 or so, and the LLMs tend to change my actual writing voice relatively little and usually in positive ways, since they say I meander too much.
Mostly because I finally figured out what I thought was relevant about the Bun port over the last couple of days, thanks to someone far more embedded in the ecosystem than I complaining about it. That complaint was the seed idea in the post, and shows up only remotely, because I thought the complaint itself was ranty and misplaced, but cast a shadow that actually interested me more.
So I did some casual research, but used generalized numbers and impressions; I wasn't trying to pretend deep research, and some of the numbers (like the 99.8%) were drawn from publications and discussions that seemed not in debate.
I am not an akshual journalist - I'm a systems architect who enjoys writing, who's served in a sort of journalistic role, and I sometimes write about topics that are not in my area of expertise. I don't write JS often myself; I've looked at Bun, particularly when it first came out, but my in-depth experience with it is minimal, so I'm writing everything from afar, and that includes the impression about the git interaction, which people wrote about and from which I inferred my conclusion, particularly because I didn't see the point of manually triggering the rejection.
Humans can make errors; part of why I waited so long to write and post this is because I'm not a great Rust coder (at all) and I don't use Bun, so I felt like I lacked enough relevant insight to say anything, and this is part of that, I think.
Claude (and Codex) designed the site, mostly because I'm not a UI coder; if I'd designed the site nobody'd want to read it but me, simply thanks to the UX.
And I have a full-time job and more; I draft with an LLM's assistance and revise with another LLM (and other humans where possible) because I'm just arrogant enought o think that what I think might be useful to others. If it's not useful to you, I get it. Such is life.
Bun was ported from Zig to Rust by an LLM and passed nearly all its tests - while shipping more than ten thousand unsafe blocks. Memory safety is the main reason you'd pick Rust. So what did the rewrite actually accomplish?
My thought is that this is interesting, but very narrowly scoped. I thought the list would be, um, longer. By a lot. This feels like talking about all of the deaths in pre-Enlightenment Europe and coming up with a list of seven names.
Also fair. I kinda thought the design for the UI was fairly normal - it looks like a lot of standard Wordpress themes would look, with an admin panel, a primary focused "recent post" and a list of other recent posts in descending order of attention. From a UX perspective, I thought it was okay; the animated circuit thing was my idea, but I tried to keep it VERY in the background, I wanted it to be fun and not a focus.
If you have ideas about what a proper UX would look like, I'm all ... eyes? ears? UX is not my thing and I am willing to consider breaking the molds to make something more awesomer if I can.
This is also fair: it's definitely AI-assisted. I'm not a UI person; I have wonky color perception and synaesthesia, and a lot of experience has taught me that what works for ME in UI is what... uh... doesn't work AT ALL for other people.
So it's a problem: I can "hand write it" and have you say "mein Gott, who came up with THIS rubbish? Are they blind? Are they trying to blind US?" or I can have an AI spin something up that looks fairly bland and normalish, but fulfills the specifications I require, and have users go "this looks like a blog that pretty much anyone would write," except the content was always meant to be the differentiator.
And the UI is actually designed to be pluggable, anyway; what I work on is the backend REST services, and the UI goes through those services for all data - it has no access to the underlying datastreams, at all. Everything goes through https://api.bytecode.news, and the intent was that if someone was an awesome UI coder and wanted to show their stuff, they'd write their UI using CoolThing and I'd put it into the system at coolthing.bytecode.news, and if it totally dominated the "normal UI" I'd promote that to the default UI and just leave the other one out there as a reference (the UI you see is also hosted at https://nextjs.bytecode.news, as the "canonical url" for that implementation.)
That way, if someone's going "ooo I could make Struts sing with this" for some reason, well, the API endpoints are published with OpenAPI; go for it. Show the world.
The UI was always secondary to the concepts that drive the information system, and the content was meant to be more important than how the content looked. I'd rather deliver information than flash.
What's your load chain? I've seen some other people (who use Tor through Brave) say that it's slow to load, and I'm curious to fix that - the front end has a cached version that should be rendering pretty aggressively without datafeed updates.
Thanks. I decided long ago that I wasn't the kind of magnetic personality who'd be able to market a mass site - as a "face" I'm a very poor candidate, and I despise cults of personality, which seems to be the "go-to" for a lot of such things. It's the modern version of "smile more!"
I hope you're right. Not for my own sake, but for everyone's. I'm trying to do what I can to put stuff worth reading out there - and whether it's worth reading or not isn't actually mine to judge; if I make it "worth reading" by SEO terms, it's not actually worth reading all that much, being neutered and hedged to the point of milquetoast oblivion.
Also: one of the features of the underlying tech stack is that the UI is actually a completely separate module than the backend API. Different github repo, everything: the site is akshuallyhttps://api.bytecode.news and the UI at the "base url" is just one layer for that API. The goal was always to have multiple interfaces, all tuned for whatever the technology supported best: see https://enigmastation.com/2014/07/09/repost-some-of-what-id-... (from my personal blog).
BCN actually has multiple UIs for it, although I've been concentrating on the content rather than the front-ends - I'm not a front-end guy, so my UIs tend to be impenetrable. The model works. If it's my implementation the other front ends will suck from a UX perspective, because I don't see the UI the same way most people do (there are reasons, they're not important, bottom line is that I avoid UI.)
What would YOU suggest for a UI? I'm very much curious, because I would LOVE for the UI to sing and I would have no idea how to make that happen.
This is the second comment like that. It was honestly not intended - it was actually me trying to respond in my own context to the post, and WHY I was responding; "why" is more important to me than "what," and I have a hard time saying "this" without explaining why I felt "this" - or at least trying to explore it. I'm working on a site; reading the "this kind of thing is how people do things these days" actually made the concept of working on the site (which I hope has value) harder. That's what I was saying, or trying to; the "advertisement" was context, not intent, or else I'd have tried to post my own thing to HN saying "look at how ossum my seite are!"
Hrm. If you're talking about me: I doubt it. I've been a programmer for 30+ years: I've built a LOT of products, some of which got used, some of which ... didn't. If I was going to complain, that'd be new.
And I know how to do SEO and why. And I'm just not interested. "Success" for me... well, I mean, I'd love to retire today based on the brazilians of dollars some mogul hands me for the IP behind the site, but, uh, that's not what it's for. SEO at the service layer? Sure, it has a mode for the bots, it tries to make scanning easy for the machines. But at the content level... nah, I have been watching the world tune information - one aspect of the psyop the OP talked about - for decades, and I can't bring myself to do it.