I forsook RN years ago. I am not a huge fan of the JavaScript ecosystem in the first place, and the UX of RN apps is not the best. Instead, I adopted Kotlin Multiplatform (shortly after their memory management overhaul). I haven't been disappointed. As coding agents have come along, they are really good at writing both Swift and Kotlin, and I get to write all the business logic once. UI can either be shared with CMP, which is quite good, or platform-specific.
I did this as well. I found that it was really inefficient because if I was doing anything with a significant amount of text, it has to shuttle all of that through the model to the MCP invocation. It was way better to work with temporary files and pipe them around CLI tools once you’re happy with the contents. E.g. developing a user story and creating the Jira issue.
700k LoC of human written code is probably like 2M LoC of LLM "slop". That's probably around 8M tokens. Assuming a single fable agent that one shots the new source code at 30 tok/s, that's 74 hours. Of course it needs wayyy more tokens because it wouldn't one shot it, plus the reasoning tokens. Generation speed would be faster because you'd have many simultaneous agents though.
Bun rewrite took 6 days of coding and was a similar number of LoC, so I think a couple of weeks is definitely reasonable, although you probably need more than 5 Claude subs.
It's way more than 8M tokens. That might be around the amount of the raw output, but there's going to be tons of tool calls, back and forth... it's probably more like 100M+ tokens.
> Bun rewrite took 6 days of coding and was a similar number of LoC, so I think a couple of weeks is definitely reasonable, although you probably need more than 5 Claude subs.
Bun had numerous standardized and extensive javascript test suites to validate the slop code against. I doubt paint.net has test coverage anywhere near that complete, and without it using LLMs to rewrite something is a much larger risk.
Besides which, Bun claims the rewrite took 6 days but they took months after that to finish hammering out the bugs and actually ship, so I don't really buy the original price tag or timeline on their rewrite.
> It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems.
Assuming you mean "they don't actually want to use Arch" as a criticism (rather than a truism), I think that's fair for a distro described as "Arch linux but configured X way". I don't think it's a good criticism for something like SteamOS which is configurable but is aiming hard for "it just works".
If you are asking concerning security, the answer is that it’s an insecure default that should have protected an unwitting user.
If you are asking concerning consistency with real world situations, then there is no difference and it feels like the fit is over a somewhat controversial figure (DHH) and how he created the distro’s recent release without reading any of the code himself. The counter is that no one installing a distro actually understands how their distro is configured, and trusts someone else’s judgement. Here that judgment was farmed out to AI, and while that is controversial, the uncomfortable truth is that this is how an awful lot of real people are told to configure their Docker installations.
IMO Docker running as a root daemon is a bad idea in the first place and I’d much rather use Podman’s rootless containers.
reply