481–490 of 757 posts
Earlier quoted context omitted.
You’re telling me you would be as likely to contribute to a project hosted in CVS as compared to git (and on GitHub)?
No, but making a codeberg account, seemingly the second most popular forge in the world, is not that huge effort.
Earlier quoted context omitted.
I don't understand what distinction you're trying to draw here. The very specific claim[0] in the Bun blog post that Kelley is calling a fabrication was: > We fuzz Bun's runtime APIs 24/7 using Fuzzilli, the JavaScript engine fuzzer used by V8 & JavaScriptCore It does not look to be a fabrication, and is very explicit just about what they meant by fuzzing. [0] I mean, that sentence doesn't actually match Kelley's par…
For me, using Fuzzilli for testing a Zig code is not fuzzing, it's integration testing. If you're running code externally (e.g. wrapping binary) you cannot guarantee that side effect isn't caused by IO. I consider fuzzing a low level activity with many external variables removed. Depending on where you are and how you communicate semantics matter more or less. It's very similar to compiler/transpiler. E.g. TypeScript…
I've never heard anyone restrict the definition of "fuzzing" in this way. If I repeatedly generate inputs to a program and then run the program with those inputs, that's fuzzing. It doesn't matter if there's IO or not.
> Depending on where you are and how you communicate semantics matter more or less. It's very similar to compiler/transpiler. E.g. TypeScript "Compiler" is called compiler but in fact it's transpiler (it emits other high-level language as a result).
It's still a compiler. It translates code from one language to another. You can argue whether we need the term "transpiler," but a source-to-source compiler is a compiler.
Earlier quoted context omitted.
You’re telling me you would be as likely to contribute to a project hosted in CVS as compared to git (and on GitHub)?
I don't care if it's on GitHub at all, it's not hard to work with any arbitrary git remote. CVS would be a weird choice, but it wouldn't be a dealbreaker on its own. Fossil or some other modern alternative VCS wouldn't be a red flag or weird at all. But I wasn't talking about contributing to the language, which is a weird standard to use here since Zig isn't interested in outside contributors. I was talking about cho…
The original comment you replied to was talking about "the loss of network effect" and you sounded dismissive of it. It might not even matter, but I think it's somewhat fair to say it could have an impact.
Why are we so eager to dismiss the very personal experiences of Andrew - someone who envisioned and developed Zig from the ground up? It is entirely within the realm of possibility that what he describes here did transpire. He had bad experiences with one of the more popular projects within the ecosystem - something that he hoped would become successful but the incentives were clearly misaligned. When in doubt - look…
Having read both articles I'm in the opposite corner. I found Andrew's personal ad-hominem filled emotional post distasteful and Jarred's purely technical and filled with praise of Zig well written and in good taste.
Earlier quoted context omitted.
For me, using Fuzzilli for testing a Zig code is not fuzzing, it's integration testing. If you're running code externally (e.g. wrapping binary) you cannot guarantee that side effect isn't caused by IO. I consider fuzzing a low level activity with many external variables removed. Depending on where you are and how you communicate semantics matter more or less. It's very similar to compiler/transpiler. E.g. TypeScript…
> For me, using Fuzzilli for testing a Zig code is not fuzzing, it's integration testing. If you're running code externally (e.g. wrapping binary) you cannot guarantee that side effect isn't caused by IO. I consider fuzzing a low level activity with many external variables removed. I've never heard anyone restrict the definition of "fuzzing" in this way. If I repeatedly generate inputs to a program and then run the p…
That's true today, but compiling was historically was defined as getting source code (human readable) to bytecode (machine runnable without an interpreter).
Some people didn't like that definition, and consequently the waters have been murkied. Just like with eg crypto. Or real time.
Earlier quoted context omitted.
Also notice how I didn't have to bring up Andrew soiling his Pampers when he was a wee beginner.
It's a good thing there's nothing of the sort in TFA then? Quoting: "He moved fast and tried a lot of different stuff, jumping head first into problems that he was not yet equipped to solve, leading to mediocre outcomes in terms of engineering, but learning a whole heck of a lot in the process. I see it as quite a healthy attitude, particularly for young people and students. This is the best way to level up and learn…
The only connection it has is as a segue into calling Jarred a terrible manager here:
> It was at this point - when he suddenly became a manager - that this "beginner energy" started to hit differently for me.
Note how "beginner energy" is considered good in the first paragraph, but suddenly terrible when applied to a different thing here. Terrible work culture aside, and the fact that it seemingly worked out for those who joined aside, Jarred would obviously have beginner energy in management as well considering he's not done it before. Why is it suddenly bad here?
Honest question, is there any record of Andrew actually saying Jarred had "beginner energy," or was this invented for the post as well?
Earlier quoted context omitted.
If you're going to accuse someone of "an outright fabrication" it's on you to check that you're not wrong before you say that.
I agree that ""an outright fabrication" is a bit too much. But also the claims about the fuzzing in the original blog post are kinda too misleading. Fuzzing harness is basically just coverage-guided random bytes towards Bun's JS APIs and it will not really catch anything in depth from the code. Just the most obvious from the surface. And 24/7 fuzzing is introduced likely around the same time when Rust rewrite seemed…
This is false, it was done many months before (Nov 20 2025). There is some irony in your comment being in reply to a thread about verifying claims before posting them...
Earlier quoted context omitted.
I agree that ""an outright fabrication" is a bit too much. But also the claims about the fuzzing in the original blog post are kinda too misleading. Fuzzing harness is basically just coverage-guided random bytes towards Bun's JS APIs and it will not really catch anything in depth from the code. Just the most obvious from the surface. And 24/7 fuzzing is introduced likely around the same time when Rust rewrite seemed…
> And 24/7 fuzzing is introduced likely around the same time when Rust rewrite seemed to be main focus, This is false, it was done many months before (Nov 20 2025). There is some irony in your comment being in reply to a thread about verifying claims before posting them...
There is no evidence for this. It is integration PR to support fuzzing with one tool. The public repository does not have CI pipeline for it. Fuzzing is done privately somewhere, and the first linked issues are around April.