vrtcn

I am a bit suspicious about the choice of startup time as the metric to evaluate performance in Claude Code. With a rewrite from a language like Zig to Rust, my biggest performance concern would be allocation. Where a Zig app might use a fast linear or buddy allocator, a Rust app is more likely to use malloc. During startup, both versions are likely to make tons of allocations. In fact, the Zig version is likely to make larger allocations during startup to reserve memory for its custom allocators. So I would expect both versions to be roughly on par, or Zig slightly worse there. However, during normal execution, I would expect the Zig version to be potentially faster, because it has paid the cost of malloc at startup and now an allocation might be as fast as incrementing an integer. This is speculation, but I would like to see performance numbers for the rest of the app lifecycle.

I refuse to believe that these takes are not clickbait at this point

IMO, this is a product for five years ago, when sites like figma were beyond the capabilities of most machines. Looking five years ahead, most of their potential users (higher income or working at companies able to afford the subscription fee) will have moved on to M-series machines from Apple. Intel and AMD will probably also have catched up far enough to be able to efficiently handle most use cases, for companies that cant or dont want to switch to macOS.

Honestly, as much as I admire the energy of their founder, I think this product should have never gone far past the idea phase with Apple experts like Rene Ritchie having predicted the integration and performance benefits of Apple Silicon since the first rumors came up many years ago.

Highly dubious... asking for access to control the computer, asking for email, communicating with their servers. I don't care how much time this would save me, it absolutely isn't worth the risk.

As far as I know, the new concurrency features can be adopted gradually which would make it very simple for developers to transition from the current completionHandler-based model to the new async/await-based model. Every Obj-C UIKit method with such a completionHandler parameter would from now on be available in two ways from Swift: 1. as usual, with completionHandler 2. new, without completionHandler, marked as ‚async‘ and returning the input types of the completionHandler