Here's a leaked / rumor image of Apple servers themselves.

https://www.macrumors.com/2026/08/26/leaked-images-of-apple-...

https://asciiflow.com/

I don't think it does. I tried locally:

  mkdir test; cd test; git init
  touch a; git add a; git commit -m 'a'
  touch b; git add b; git commit -m 'b'
  touch c; git add c; git commit -m 'c'
  git checkout -b branched-feature HEAD~
  touch d; git add d; git commit -m 'd'
  git checkout main
  echo 'change' > b; git add b; git commit -m 'fix b'
  git rebase -i --root --update-refs

  * commit (HEAD -> main)
  |
  |     c
  |
  * commit 
  |
  |     b
  |
  | * commit (branched-feature)
  | |
  | |     d
  | |
  | * commit
  |/  
  |       b
  |
  * commit 
  
        a

  * commit (branched-feature)
  |
  |     d
  |
  | * commit (HEAD -> main)
  |/
  |       c
  |
  * commit
  |
  |     b
  |
  * commit 
  
        a

I'm reading that to mean that when I use `git rebase --update-refs` in this situation, where I've currently checked out `D` and update `B` to `B'`:

  A ──► B ──► C ──► D  
        │              
        └───► E        

  A ──► B' ─► C' ─► D'  
  │                   
  └───► B ──► E        

If I use `git history fixup`, it would also update `E` and end up with this?

  A ──► B' ─► C' ─► D'  
        │              
        └───► E'        

https://www.urbandictionary.com/define.php?term=Nebby

Comments URL: https://news.ycombinator.com/item?id=45948311

Points: 176

# Comments: 35

I tend to write most of my async Rust following the actor model and I find it natural. Alice Rhyl, a prominent Tokio contributor, has written about the specific patterns:

https://ryhl.io/blog/actors-with-tokio/

https://blog.rust-lang.org/2025/09/12/crates-io-phishing-cam...

    low_level_result.context(ErrorWithContextSnafu { context })?;
    low_level_result.map_err(|err| CustomError::ErrorWithContext { err, context })?;

- You don't need to move the inner error yourself.

- You don't need to use a closure, which saves a few characters. This is even true in cases where you have a reference and want to store the owned value in the error:

    #[derive(Debug, Snafu)]
    struct DemoError { source: std::io::Error, filename: PathBuf }

    let filename: &Path = todo!();
    result.context(OpenFileSnafu { filename })?; // `context` will change `&Path` to `PathBuf`

----

As an aside:

    #[error("failed to open a: {0}")]

I do too! I've been debating whether I should update SNAFU's philosophy page [1] to mention this explicitly, and I think your comment is the one that put me over the edge for "yes" (along with a few child comments). Right now, it simply says "error types that are scoped to that module", but I no longer think that's strong enough.

[1]: https://docs.rs/snafu/latest/snafu/guide/philosophy/index.ht...

Comments URL: https://news.ycombinator.com/item?id=44120732

Points: 7

# Comments: 3

The Rust playground uses GitHub Gists as the primary storage location for shared data. I'm dreading the day that I need to migrate everything away from there to something self-maintained.

[1]: https://www.w3.org/Provider/Style/URI

[1]: https://docs.rs/snafu/latest/snafu/index.html

I do have https://diataxis.fr/ and related stuff open in another tab and keep meaning to figure out how to best apply it for SNAFU.

Out of curiosity, do you recall if you also read the top-level docs[1]? That’s intended to be the main introduction, I actually don’t expect most people to read the user’s guide, unfortunately.

[1]: https://docs.rs/snafu/latest/snafu/index.html

The people working on Rust are a finite (probably overextended!) set of people and you can't just add more work to their plate. "Just" making the standard library bigger is probably a non-starter.

I think it'd be great if some group of people took up the very hard work to curate a set of crates that everyone would use and provide a nice façade to them, completely outside of the Rust team umbrella. Then people can start using this Katamari crate to prove out the usefulness of it.

However, many people wouldn't use it. I wouldn't because I simply don't care and am happy adding my dependencies one-by-one with minimal feature sets. Others wouldn't because it doesn't have the mystical blessing/seal-of-approval of the Rust team.