I don't see "Anthropic hacked!" anywhere in that post. This extension was uploaded to the Cursor marketplace.

nobody is saying anthropic was hacked?

That’s what the title said before it was changed.

Two out of the three links in the post still say exactly that.

That’s also what the majority of the comments here are saying, likely because they read the first two.

Is that your “nobody”?

Just finished a rewatch of The Wire, which I think captures this transitional period well.

> The idea that web components slot and template give you close to the same flexibility in functionality that a component library in a programming language does is absurd.

The web component API is programmatic, in JS just like all the rest of the platform.

This is directly addressed in the article.

hey thanks for mentioning that skill, I hadn't heard of it before but I just ran it on a non trivial codebase I've been planning to refactor and it did a great job.

I don't use a lot of "skills" so if there are others you've started using frequently I'd be curious to learn about them.

> From the perspective of high level application development, I can't see a technical use case for a language other than Rust.

Bit of a red flag if you really can't.

I know, haha. It's a bit of an absolute statement but as far as all of the features I look for in the context of creating scalable and maintainable software (especially in the age of agent-assisted coding) - Rust has been the most productive, least frustrating language I have worked with.

It's basically TypeScript but runtime exceptions are impossible. If it compiles, it works - so the _only_ thing you worry about is how you organised your code (abstractions, domains, etc) and if the logic is correct.

It saves a lot of time in PR reviews because you only really complain about logic or code organization.

By contrast, C#, Go, Java all have runtime exceptions for things like null pointers and race conditions. That means, when reviewing code, you have to be on the lookout for those things in addition to the logic and structure.

On the single threaded side, TypeScript is great, but JavaScript runtime performance and resource utilization is obscene. With Rust basically being TypeScript but without those limitations (and also natively supporting more frontend frameworks without transpilers), what is the use case for TypeScript (other than legacy software already being written in JavaScript or TypeScript)?

You can write Rust with your eyes closed and it'll probably work.

This is giving real "if all you have is a hammer" vibes.

I also have years of experience with Rust, but I moved off Rust a few years back simply because I'm sick of the anemic stdlib and lack of mature ecosystem around anything even one inch off the beaten path. Cargo is a shitshow and Rust forces you into an npm-like experience for a whole bunch of functionality that ought to be included in the box. You're juggling libraries with versions like 0.1.2 of which there's seven, none of which are feature complete and five of which are semi abandoned. Then you run into the orphan rule trying to fix or extend any of them.

I kind of think some other language will come along, take the borrow checker, take all the type conveniences that Rust stole from OCaml that make Rust so nice, glue it all to a Python/Go/dotnet style fat stdlib, complete with an optional GC for all the things that don't actually need bare metal performance (just stick an arena in stdlib), and Rust will feel like a clunker by comparison.

> I kind of think some other language will come along, take the borrow checker, take all the type conveniences that Rust stole from OCaml that make Rust so nice, glue it all to a Python/Go/dotnet style fat stdlib, complete with an optional GC for all the things that don't actually need bare metal performance (just stick an arena in stdlib), and Rust will feel like a clunker by comparison.

That'd be a dream to me.

To turn bad short writing into good long writing you must necessarily change the content of the writing, not just the shape.

But this is the same with coding. The reason that AI can write code from a description that is shorter than the output is in large part because it makes decisions about the behavior that were unspecified in your prompt. We accept this for coding apparently, I guess because those decisions are often unimportant. We might accept it for writing too. I hope not.

Not necessarily. Poorly worded, ambiguous, confusingly ordered writing can be massively improved without changing the core content. Better setups and explanations can be longer without changing the message or meaning.

Look at it the other way, could you take a good longer message you’ve written and make it shorter and less readable for your audience while still making sense to you and containing the key points?

wasn't it thoreau who said "Not that the story need be long, but it will take a long while to make it short"

personally, I think there's a time and place for short versus long, just like there's a time and place for a 45mins TV episode versus a 2 hour marathon movie.

I'm looking in the same space: have you found anything else you're considering beyond OpenViking?

There are many more labs than that, and humans aren't designing unique scraping processes per domain.