7 ms·

I could point to the same examples this article refers to: the Bun blog post says "Having a rigid style guide [in Zig] with clear ownership expectations explici

by simjnd 2mo ago

I could point to the same examples this article refers to: the Bun blog post says "Having a rigid style guide [in Zig] with clear ownership expectations explicitly spelled out in the type system was a real option for Bun" and presents no technical reason why they didn't choose (or even TRY) that. They handwave it with "This is and ergonomic than the Zig we expect". Why was it in their own words a real option? And why did they not go for it? This is the technical substance I'm looking for: an engineer explaining what options have been considered and what wanted and unwanted tradeoffs they present. Also only mentioning figures for the platforms that saw an improvement is sketchy. "With ICU and code folding Windows and Linux get 20% smaller", what about macOS? Why did it not see the same gains? The fact that they don't mention it makes me think that they don't KNOW, and isn't confidence inspiring coming from the engineer who SHOULD know.

cognitiveinline 2mo ago
Every blog post has infinite things it does not mention. "Technical substance" simply requires that some technically substantive things are mentioned. Which was indeed the case.
- simjnd 2mo ago
  Not about the things that matter. If you write a blog post about "I switched from X to Y", I expect the WHY: the pros and cons of X, of Y, and of the alternatives that were considered and dismissed before considering Y. This is more a blog post about how to use Fable to switch from X to Y, than it is about X or Y.
lolinder 2mo ago
The very next sentence justifies why they didn't do it: it argues that they would have ended up with what was technically Zig but something that was much less ergonomic than what would be expected from Zig. You can argue that that's a bad justification for not doing it, but that's a debate on the technical merits, not a claim that they didn't provide justification.
- afavour 2mo ago
  As the article mentions, the follow on question from that is: why does that matter if your codebase is written exclusively by AI agents?
  - lolinder 2mo ago
    Because if you have to quadruple the number of tokens in your code base in order to make the Zig provably safe, you have 1/4 of the context window to do useful work.
    - afavour 2mo ago
      So why not say that? Perhaps because it highlights a flaw in AI agent workflows?
      - lolinder 2mo ago
        Because what they did say is true for both agents and humans. Which makes it a more compelling argument than just emphasizing the specific aspect of that limitation agentic workflows. In one comment you are presuming that agents can just ignore ergonomic problems, which would be a kind of magic if it were true, and in the next you are saying that their inability to digest enormous quantities of unnecessary tokens is some kind of flaw that needs to be called out. Enormous quantities of unnecessary tokens are bad ergonomics for anyone, agent or otherwise.
- simjnd 2mo ago
  Yeah since my whole point is about the technical merits of the rewrite article, I don't count that as justification. Why is just a wrapper type "less ergonomic"? Everybody does that all the time in every language. And then if you can convince me it is less "ergonomic": why does it matter if it solves the problem? And that is considering humans write the code manually. Why does it matter if agents write the code? This makes no sense.
  - 2mo ago

by simjnd 2mo ago

cognitiveinline 2mo ago

Every blog post has infinite things it does not mention. "Technical substance" simply requires that some technically substantive things are mentioned. Which was indeed the case.

simjnd 2mo ago
Not about the things that matter. If you write a blog post about "I switched from X to Y", I expect the WHY: the pros and cons of X, of Y, and of the alternatives that were considered and dismissed before considering Y. This is more a blog post about how to use Fable to switch from X to Y, than it is about X or Y.

lolinder 2mo ago

The very next sentence justifies why they didn't do it: it argues that they would have ended up with what was technically Zig but something that was much less ergonomic than what would be expected from Zig. You can argue that that's a bad justification for not doing it, but that's a debate on the technical merits, not a claim that they didn't provide justification.

afavour 2mo ago
As the article mentions, the follow on question from that is: why does that matter if your codebase is written exclusively by AI agents?
- lolinder 2mo ago
  Because if you have to quadruple the number of tokens in your code base in order to make the Zig provably safe, you have 1/4 of the context window to do useful work.
  - afavour 2mo ago
    So why not say that? Perhaps because it highlights a flaw in AI agent workflows?
    - lolinder 2mo ago
      Because what they did say is true for both agents and humans. Which makes it a more compelling argument than just emphasizing the specific aspect of that limitation agentic workflows. In one comment you are presuming that agents can just ignore ergonomic problems, which would be a kind of magic if it were true, and in the next you are saying that their inability to digest enormous quantities of unnecessary tokens is some kind of flaw that needs to be called out. Enormous quantities of unnecessary tokens are bad ergonomics for anyone, agent or otherwise.
simjnd 2mo ago
Yeah since my whole point is about the technical merits of the rewrite article, I don't count that as justification. Why is just a wrapper type "less ergonomic"? Everybody does that all the time in every language. And then if you can convince me it is less "ergonomic": why does it matter if it solves the problem? And that is considering humans write the code manually. Why does it matter if agents write the code? This makes no sense.
- 2mo ago