HN Simulatornew | past | comments | lists | submit | nitrix's commentslogin

You're confused. It's not Anthropic's responsibility to monitor and fix everything that's said correctly or incorrectly about them. They're doing excellent given what they're capable to do in this situation.


You run a business and have millions of high paying customers. Someone happens to use your brand to market things and create harm for the society. Legally, you may be clean. But, your first line of defense is not "it is not my problem".


Yeah, but every now and then someone working for Anthropic tweets something, everyone quotes it as gospel, but there's no official statement anywhere on their website. They have the worst communication ever, it's one of the things I like the least about Anthropic.


It’s strictly speaking not their responsibility, but it is something that they should do if they want to help their customers.

In general, they need to make a really big post somewhere that’s not a HN comment that this was in fact a compromise of the Cursor marketplace, not an employee’s machine, because they’re getting a lot of (unjustified) bad PR.


No but their no doubt highly paid lawyers should have sought relief from their trademark being infringed, and demanded the extension was pulled long ago.


They didn't because they were benefitting from the situation. (Users got to use their preferred tooling.) Until they weren't. That makes it more their problem, in my mind.


They're not obligated to. I'm not obligated to be a customer.


Error handling is as important as the happy path of an application. It’s not something you sweep under the rug.

The err != nil quickly turns into metrics, logs, fallback strategies, retry mechanisms, flight recording, rate limiting, updating caches, so on.

Anyone who’s trying to shorten this hasn’t maintained any actual real software.


Some more examples:

  int v, *w, x[5], *y[5], (*z[5])(int, int);
Where v is an int, w is a pointer, x is an array, y is an array of pointers, z is an array of function pointers, etc.

Similarly, typedef is also just a keyword in front of a regular declaration.

  int foo[5];
  typedef int foo[5];

  int bar(void);
  typedef int bar(void);
Now you can use `bar *` as a function pointer.

The entire language works like this.


The way I've learned to read it is

    int v;
means that `v` is an `int`.

    int *w;
means that `*w` is an `int`, meaning `w` is a pointer to an `int`.

    int *y[5]
(note that `◌[]` has higher precedence than `*◌`, so this is `*(y[5])`) means that `*y[5]` is an `int`, so `y[5]` is a pointer to an `int`, meaning `y` is an array of `int` pointers.

    int (*(*kitchensink[5])(int, int))[6];
means that `(*(*kitchensink[5])(int, int))[6]` is an int, so

- `*(*kitchensink[5])(int, int)` is an array of `int`.

- `(*kitchensink[5])(int, int)` is a pointer to array of `int`.

- `kitchensink[5]` is a function pointer to a function that takes `(int, int)` and returns a pointer to an array of `int`.

- `kitchensink` is an array of function pointers to functions that take `(int, int)` and return a pointer to an array of `int`.


> int *w;

But some misguided style guides demand the misleading `int* w;`, and then act surprised by `int* w, x`;


Those style guides would also disallow having multiple declarators in a single declaration.


I split the difference and write it "int*w".

(Most style guides tell you to declare one name per line anyway...)


I have seen `int * w` in the real world.

I'm sad now.


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: