Hacker Newsnew | past | comments | ask | show | jobs | submit | milliams's commentslogin

The problem is that everyone dies some day so there's never going to be equality between causes of death and reporting rates. You might expect some correlation between preventable causes and reporting, and in-part that's what's being seen here.

Why does inevitable death mean there’s never going to be reporting equality on the causes? I don’t understand your logic. The image in the article includes a summary of the top causes, so… it is possible?

Many cancer and heart disease deaths are preventable. There's no direct correlation with preventability. The correlation is with fear and spectacle.

Partly about being preventable, yes, but also about being shocking or dramatic (shootings, crashes, natural disasters).

It bothers me that it's not even a "AI web browser", but an "AI browser". I don't want to browse "AI", I want access to the web.


https://peps.python.org/pep-0723/, e.g.:

  # /// script
  # requires-python = ">=3.11"
  # dependencies = [
  #   "requests<3",
  #   "rich",
  # ]
  # ///
  
  import requests
  from rich.pretty import pprint
  
  resp = requests.get("https://peps.python.org/api/peps.json")
  data = resp.json()
  pprint([(k, v["title"]) for k, v in data.items()][:10])


Small aside, AVM have now formally rebranded as "FRITZ!"


  [lints.clippy]
  dbg_macro = "deny"
  unwrap_used = "deny"
  expect_used = "deny"


Exactly. This should be the default for production code at companies like Cloudflare.


https://github.com/search?q=unwrap%28%29+language%3ARust&typ...

This is sobering.

My new fear is some dependency unwrap()ing or expect()ing something where they didn't prove the correctness.

Unwrap() and expect() are an anti-pattern and have no place in idiomatic Rust code. The language should move to deprecate them.


I use unwrap a lot, and my most frequent target is unwrapping the result of Mutex::lock. Most applications have no reasonable way to recover from lock poisoning, so if I were forced to write a match for each such use site to handle the error case, the handler would have no choice but to just call panic anyway. Which is equivalent to unwrap, but much more verbose.

Perhaps it needs a scarier name, like "assume_ok".


I use locks a lot too, and I always return a Result from lock access. Sometimes an anyhow::Result, but still something to pass up to the caller.

This lets me do logging at minimum. Sometimes I can gracefully degrade. I try to be elegant in failure as possible, but not to the point where I wouldn't be able to detect errors or would enter a bad state.

That said, I am totally fine with your use case in your application. You're probably making sane choices for your problem. It should be on each organization to decide what the appropriate level of granularity is for each solution.

My worry is that this runtime panic behavior has unwittingly seeped into library code that is beyond our ability and scope to observe. Or that an organization sets a policy, but that the tools don't allow for rigid enforcement.


> the handler would have no choice but to just call panic anyway

The handler could log the error and then panic. Much better than chasing bad hunches about a DDoS.


Unwrap is in a lot of example code.

If you're using Result<T,E>, there's no automatic language feature for statically typing a nested E that mirrors how it was called.

So out of brevity, they unwrap.

Expect to see this sort of error crop up a lot as people use LLMs to vibe with the borrow checker.


https://www.theverge.com/tech/814928/ikea-matter-thread-diri... has some quotes from IKEA saying that they're using Thread. It's strange they didn't say in this release though.


I guess because to most consumers, it doesn't actually matter. It uses matter and connects to a matter hub, the way it does it is an implementation detail unless you're making your own hub with homeassistant or something.

Even iPhones have been able to talk to thread devices directly for a while now, so it's a fairly transparent process.


Likewise I noticed that Konsole was version 23.08. I've just submitted a PR (https://github.com/jquast/ucs-detect/pull/14) to update it to 25.08.


Why are the table and the description of the RAPTOR algorithm in the article images rather than text?


I'd also argue that VS Code is not open source - at least not the version that 98% of people run. If you download VS Code from almost anywhere (and are not using Codium) then you are subject to the licence terms at https://code.visualstudio.com/license which says you may not:

- reverse engineer, decompile or disassemble the software, or otherwise attempt to derive the source code for the software except and solely to the extent required by third party licensing terms governing use of certain open source components that may be included in the software;

- remove, minimize, block or modify any notices of Microsoft or its suppliers in the software;

- use the software in any way that is against the law;

- share, publish, rent or lease the software, or provide the software as a stand-alone offering for others to use.


KDevelop's semantic highlighting where each variable was given its own colour was always the one I found most useful. It made tracking the meaning of some code much easier than just highlighting by token category.



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

Search: