291–300 of 330 posts
Earlier quoted context omitted.
> I’m the author of this PR. > And yes, the PR description is entirely Claude. If you didn't write it, you're not the author. That's how it works, man. I would also love to read that blog post about the Rust rewrite, when you get it published.
[flagged]
(If we're going by excerpts from HN profiles that is)
I wonder if I'm the only one for whom the bun project vanished completely. In software code is only part of the package. Stability and trust are big part of it, too. And for me 1800 files change PRs created by Anthropic overseen by one person is not necessarily adding to the package. Even it that'd be the best code and design in the world, I won't use it. I don't trust it.
Personally not interested in performative/marketing-driven decision so I am done with the project and the author. Quite disappointed
Earlier quoted context omitted.
It makes no sense. If a feature takes 10k loc to implement, it'd be a huge disservice for the reviewer and yourself to split it up into multiple PRs. Your comment is equivalent to saying that no feature ever takes 10 loc to implement. It'd be quite ridiculous to say that aloud.
Ideally, you could find pieces of that 10k that would also work as a standalone improvement to the app. I understand that team cultures can vary, but doing small features or refactors in service of a larger goal is nice, because while the reviewer knows you must be up to something, they can still approve your preparatory PRs as face value beneficial.
It does not one any favours if your 10k LoC gets split in 5 changes that aren’t supposed to regress anything (but need to be validated not to) then 1 tiny on that brings things together.
Some features will be confusing for end users if you drip feed them. We had a whole host of changes recently overhauling our moderation system to be able to track and audit compliance with DSA and the key factor is ensuring the system makes sense to our users and that they can enable, have documentation and on-boarding materials for the changes in functionality and that it’s all QA tested.
In this case we did still review smaller chunks of code, we accumulated them into 1 large merge request at the end and merged it after QA.
Earlier quoted context omitted.
Everyone's excited about using AI to make their quick end products. But no-one wants to actually build on or rely on vibe-coded frameworks, languages, or tools.
I am constantly confused at work that people see AI as binary: it’s either a person writing the code and taking ownership of it, or it’s AI and the poor person has no control. It’s rather bespoke or entirely vibe coded. Why? When I use AI it’s still me writing the code, I just get better autocomplete and a tool that can verify my changes using fuzzy sentence as the linting rules. Why did so many people just immediate…
People live to benefit from AI for their own work, but are understandably uneasy about depending on code written by AI, even if it's (mostly) human reviewed. 2-3% more bugs may not seem like a big deal, but when you start building stacks of things these bugs bubble up and increase exponentially.
Earlier quoted context omitted.
Hmm, it sounds like the main example of “slop” there is 1000 global variables. I’m curious if that matters if humans are never going to even read this code?
>I’m curious if that matters if humans are never going to even read this code? If by never even read you don't include attaching a debugger to solve an issue. 1,000 global mutable variables would make debugging anything an absolute nightmare.
I’m the author of this PR. This PR is an implementation of the design from https://webkit.org/blog/7846/concurrent-javascript-it-can-wo... . I think it would be really cool if JavaScript had true shared object multi-threading without compromises (SharedArrayBuffer, postMessage are not that). If we had both threads and structs, it’s likely the TypeScript compiler would never have needed to be rewritten in Go. The titl…
> I’m the author of this PR. > And yes, the PR description is entirely Claude. If you didn't write it, you're not the author. That's how it works, man. I would also love to read that blog post about the Rust rewrite, when you get it published.
He also didn't even say the code was generated by Claude, just the description, although a decent amount of the code probably was.
> Scalability, measured (the honest section) Barf
Earlier quoted context omitted.
>I’m curious if that matters if humans are never going to even read this code? If by never even read you don't include attaching a debugger to solve an issue. 1,000 global mutable variables would make debugging anything an absolute nightmare.
For us, but for an LLM with the right tooling? Idk…
I wonder if I'm the only one for whom the bun project vanished completely. In software code is only part of the package. Stability and trust are big part of it, too. And for me 1800 files change PRs created by Anthropic overseen by one person is not necessarily adding to the package. Even it that'd be the best code and design in the world, I won't use it. I don't trust it.
For me it’s still up in the air. I won’t bet against them just yet. Also, did they say only one person reviewed it? I really doubt that. Don’t assume that what you can see on GitHub is the sum of all actions taken.
Earlier quoted context omitted.
Exactly. Nothing stops your writing a high-performance parallel database in TypeScript today. Given that runtimes and tooling are actually pretty good, I think TypeScript is actually a fine choice of language for the task. The only thing you can't do with JS today is share a heap across threads. You have SharedArrayBuffer. You have atomics. You don't need a shared address space. There's a high performance database ca…
SharedArrayBuffer gives you a byte array, and asks you to re-implement the entire JavaScript universe on top of that. String -> use TextEncoder to copy in / out of a byte buffer. Object/class? Sure, devise your own protocol to serialize + copy instances in/out of a byte array. Even basic arithmetic operations on a TypedArray over a SharedArrayBuffer is slow AF in v8 compared to a "native" JS Array for small-medium in…
Yeah, that sucks, but at least it's just an implementation problem. Java's analogous ByteBuffer methods have been fast compiler intrinsics for a long time, so there's an existence proof of this stuff done right.