63stack

I feel like we are talking past each other, because you ignored the whole part about "it is already tied to an env var, and it would be still tied to an env var" that you would only enable on demand, so who cares if it's a hefty operation? Also what about other languages that capture stacktraces all the time with exceptions, or scripting languages with type errors, where you can't even turn it off? Rust is somehow different?

It is a specific problem, so what? You see that you are sending 500 from an axum handler, and you are logging "serde deserialization error: line 4 invalid", wouldn't it be nice to see where that came from, without instrumenting all the places you are deserializing something?

Ideally (in my ideal world), it would be Result<T, E> that holds the backtrace. The value is that I don't know up front which method call is going to cause an error that is hard to track down, which is why I don't see how "instrument your calls with backtrace yourself" helps. It requires that I already have some idea about the execution path, otherwise I don't know where to put the backtrace instrumentation.

Since Backtrace::capture() is already tied to an env var, we could have the backtrace on Result without affecting performance, since you would only enable it for debugging. This would allow you to eg. easily track down a situation where you see in your prod logs that you are encountering a lot of "validation error: string is too long" but you can't tell where it is coming from. Flip the env var, redeploy the application, read the backtrace, turn off the env var, fix the problem.

I see a very opinionated explanation, not a "this is why the language does not" explanation.

>Stack traces are only useful for errors that indicate a bug in the program, i.e. something a programmers has to respond to. It's not useful for the vast class of bugs that are a result of wrong input, wrong external state, or infrastructure issues.

This is a personal opinion, not something you can declare as the objective truth. There is a lot of value in seeing what path the program took before it encountered a eg. validation error.

>but there are cases where an error coming from a library are truly, actually unexpected, so both `anyhow` and `thiserror` do provide support for attaching a stack trace in those situations.

This is wrong because it's up to the library to attach the stacktrace, not the userland code using the library, so saying "you can get them if you want them" is not true. If the author of the library did not decide to attach the stacktrace, your only option is wrapping it yourself, which you can only do if you already know up front all the paths that can fail. Also, you are not supposed to expose errors from a library with anyhow, they are only for application/top level code.

See? You get people explaining to you that you actually don't want a stack trace because xyz.

Any time I mention "but I would like stacktraces with my errors" I get told I'm doing it wrong.

100k lines is huge, I don't know what these jokers are on

I'd say northwest

Nobody said that?

This is my question as well, especially about the "community check". How will it be ensured that the "community check" is not going to be dominated by bots pushing an agenda? How is that different from "just another comment section hidden behind a green button"?

The last time I looked at this, using ignore-scripts = true with npm results in "npm run xyz" getting blocked as well, is that still the case?

I don't see why we couldn't have both better education around this, and the freedom to opt out of surveillance

I'm pretty sure mythos is just a new unreleased version of Opus + marketing + a different system prompt.

And one of the threat models that police use in the US is tracking women suspected of going for abortions through the use of road cameras, and other surveillance methods.

Once you have the attestation in place you have no guarantee who is going to get access to data like what apps are present on your device, and there will be nothing you can do to stop it.

Meanwhile, we could educate people against common scams.

How is this not just trading one smaller bad for a bigger bad? Why is this touted as an improvement?

There is also net.ipv4.ip_unprivileged_port_start

The first 3 hits on any search engine weren't relevant?

But nobody said that apart from you?

The established culture on a lot of projects is that you open an issue, and then you have to keep pinging it every week otherwise the stale bot closes it with "this issue is stale, closing, but your contribution is very important to us".

It's crap either way.

It's close to Opus 4.5 for me

It does, I posted the answer 2 times already and both my comments got flagged

Using "strong" language on HN often gets down voted, there is very heavy tone policing

A quite large chunk of botnet "members" are IoT crap (even mattresses).

It's fair to question whether the play store is the number one source of scams, but you should also question whether google actually does enough to keep scams off of Play, or is that just a pretense.

If I search for "DeepL" the first hit on the play store is "Preply" whatever that is, only the second one is actually DeepL.

It renames one of them to $hostname_conflicted, or something like that. Keepass has a built in tool for reconciling two databases, you can use that in this scenario.

Where was that worker's solidarity from meta employees when they to built out the surveillance network?

A much better argument would be "if you can point the AI to scan it for vulnerabilities, why not do that yourself and fix the vulnerabilities"?

Getting drunk and reflecting on one's life is not that uncommon

PHP had plenty of magic and footguns, magic_quotes, register_globals, mysql_real_escape_string, errors with stacktraces leaking into the HTML output by default, and these are just from the top of my head.

Could you post a link to a video where Trump talks for 15 minutes coherently?

The era of sharing some small programs that you made with others to benefit from is over imo.

You can just vibe code it yourself. If your requirements are narrower (eg. you only need support for 3 networks and not 12), you will end up with something that takes less time to develop (possibly less than a day), it will have a smaller surface for problems, and it will be much better tailored to your specific needs. If you pay attention to what the LLM is doing it will also be easier to maintain or extend further.

The surface for security vulnerabilities also gets narrower, since you "only" have to trust the LLM (which is still a huge ask, but still better than LLM + 1 random person).

Getting caught red handed and still being tone deaf