frontpage.
newsnewestaskshowjobs

Open Source @Github

fp.

Residential proxies detected on White House network

https://layer3intel.com/blog/residential-proxies-white-house-network
465•Rasbora•2h ago•133 comments

Insects don't swarm at LED lights

https://www.birdsoutsidemywindow.org/2026/11/03/insects-dont-swarm-at-led-lights/
135•speckx•3h ago•73 comments

Ripple-65B Preview: U.S. Open-Weight SOTA on Agentic Coding

https://www.ricursive.com/ripple
186•Philpax•4h ago•64 comments

AI is forcing us to pay off 40 years of technical debt

https://spectrum.ieee.org/ai-in-cybersecurity-php2shell-vulnerability
1006•pseudolus•11h ago•607 comments

Hacking the Xbox 360 Hypervisor Part 3: Bad Update Improvements

https://icode4.coffee/?p=1746
28•muricula•1h ago•2 comments

A new Go API for JSON

https://go.dev/blog/jsonv2
189•olexsmir•5h ago•80 comments

Qualcomm Cloud AI 100 Ultra – 150W AI Accelerator Card with 128GB at 548GB/s

https://www.qualcomm.com/data-center/products/cloud-ai-100-ultra
75•peter_d_sherman•3h ago•36 comments

Progress on provable inference for large language models

https://www.anthropic.com/research/provable-inference
161•ltononro•6h ago•79 comments

Less Popular Than Coal

https://www.argmin.net/p/less-popular-than-coal
12•_delirium•1h ago•1 comments

Show HN: After a decade of reversing, I got co-op working in DOS Wing Commander

https://fireflyk64.github.io/wcmulti/
86•daniel_rh•4h ago•9 comments

Nvidia RTX Spark encrypted firmware slows inference speed to 35% on Linux

https://www.mindstudio.ai/blog/linux-nvidia-rtx-spark-laptop
576•novaRom•14h ago•266 comments

Is Curiosity Good for Us?

https://www.lrb.co.uk/the-paper/v48/n20/adam-phillips/is-curiosity-good-for-us
7•NaOH•1d ago•1 comments

Conductor is joining Meta

https://www.conductor.build/announcement
73•kenrose•5h ago•127 comments

Ask HN: What Cryptography book do you recommend for reading with 10 year olds?

32•mike_richards•1d ago•37 comments

OpenAI to acquire Pierre Computer Company

https://openai.com/index/openai-to-acquire-pierre/
151•itunpredictable•8h ago•52 comments

Launch HN: Kino AI (YC S23) – AI media manager and video editor

62•lukeigel•5h ago•26 comments

Successful People (2013)

https://blog.samaltman.com/successful-people
5•epestr•26m ago•4 comments

Ask HN: What your experience with the monthly "who wants to be hired" thread?

36•newswangerd•1h ago•25 comments

Tencent Hy4

https://hy.tencent.ai/research/hy4
162•Philpax•9h ago•51 comments

AMD expects to outsell Intel in Q4 for the first time in history

https://www.tomshardware.com/pc-components/cpus/amd-expects-to-outsell-intel-in-q4-for-the-first-...
431•rbanffy•7h ago•149 comments

Show HN: The DNA of DOOM – How code structure survives across 44 ports

https://squid-protocol.github.io/gitgalaxy/museum-of-code/doom-dna/
9•joe-esquibel•2d ago•10 comments

Show HN: Gauge – Open-Source CLI to recursively improve your docs

https://github.com/gauge-sh/gauge-cli
4•0x63_Problems•2h ago•1 comments

Death Comes for XSLT

https://dbushell.com/2026/11/03/xslt-rip/
13•colejohnson66•2h ago•0 comments

Verification Is Not Knowledge: Science needs more than answers

https://blog.cosmos-institute.org/p/verification-is-not-knowledge
219•ersinesen•14h ago•128 comments

Incident with Pull Requests, Git Operations and Issues

https://www.githubstatus.com/incidents/smtdswd1h2w4
251•kevcampb•13h ago•126 comments

North Korean fake job interview led to $6.3B Binance heist

https://www.theregister.com/security/2026/11/03/north-korean-fake-job-interview-led-to-63b-binanc...
554•smalltech•9h ago•340 comments

From wild to mild: Friendly foxes show changes in brain region

https://news.cornell.edu/stories/2026/11/wild-mild-friendly-foxes-show-changes-brain-region
35•gmays•5h ago•6 comments

Tell HN: Gemini trains on chat history, even for subscribers (personal accounts)

614•jameslk•13h ago•155 comments

Kimi K3.1 Pro model weights are out

https://huggingface.co/moonshotai/Kimi-K3.1-Pro
313•abrarthought•7h ago•85 comments

Guerrilla bike lanes: San Francisco makes illicit infrastructure permanent (2016)

https://99percentinvisible.org/article/guerrilla-bike-lanes-san-francisco-makes-illicit-infrastru...
238•zenincognito•8h ago•171 comments
Open in hackernews

Show HN: Stack Error – ergonomic error handling for Rust

https://github.com/gmcgoldr/stackerror
27•garrinm•1y ago
Stack Error reduces the up-front cost of designing an error handling solution for your project, so that you focus on writing great libraries and applications.

Stack Error has three goals:

1. Provide ergonomics similar to anyhow.

2. Create informative error messages that facilitate debugging.

3. Provide typed data that facilitates runtime error handling.

Comments

tevon•1y ago
This is awesome! Will give it a try in my next project.

How does it keep track of filename and line number in a compiled binary? I'm fairly new to rust libraries and this doesn't quite make sense to me. I know in JS you need a source-map for minification, how does this work for a compiled language?

fpoling•1y ago
Rust provides file!, line! and column! macros that expands into a compile-time constants that the compiler embeds then into the executable. This way no source map at runtime is necessary as the relevant errors are constructed from those constants.

Presumably StackError just uses those macros.

But for debugging a source map is still necessary and is a part of various debug formats.

rhabarba•1y ago
I still prefer the Anyhow solution, but I like the approach here.
IshKebab•1y ago
Isn't this strictly superior to Anyhow? What do you like more about Anyhow?
rhabarba•1y ago
I prefer Anyhow's non-intrusiveness: "Result" is still "Result" and all I need is a "?". I agree with Stack Error's documentation that Anyhow can't help with debugging that well, but it's "good enough" in my opinion.
IshKebab•1y ago
Result in `anyhow::Result` though. It's still a different type. Or do you literally mean you like that it is still spelt the same?

And I think you can still use `?` with this if you don't want to add any context... Not 100% sure on that though.

rhabarba•1y ago
Might as well be my limited understanding from what I can read behind the link, to be fair.
garrinm•1y ago
Anyhow still makes things easier for application development. The main drawback is that the resulting error type doesn't implement std::error::Error, so it's not suitable for library development (as pointed out in the anyhow documentation). Stack Error is a bit less ergonomic, but suitable for library development.
shepmaster•1y ago
I hope to read through your crate and examples later, but if you have a chance, I’d be curious to hear your take on how Stack Error differs from my library, SNAFU [1]!

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

garrinm•1y ago
I played around a bit with SNAFU a couple of years ago, but I'm haven't worked deeply with the library so there might well be some features I'm not aware of.

I think SNAFU is more like a combination of anyhow and thiserror into a single crate, rather than Stack Error which leans more heavily into the "turnkey" error struct. Using the Whatever struct, you get some overlap with Stack Error features:

- Error message are co-located.

- Error type implement std::error::Error (suitable for library development).

- External errors can be wrapped and context can easily be added.

Where Stack Error differs:

- Error codes (and URIs) offer ability for runtime error handling without having to compare strings.

- Provides pseudo-stack by stacking messages.

Underlying this is an opinion I baked into Stack Error: error messages are for debugging, not for runtime error handling. Otherwise all your error strings effectively become part of your public interface since a downstream library can rely on them for error handling.

lilyball•1y ago
If the macros only exist to get file and line information, you could do the same thing by using `#[track_caller]` functions combined with `std::panic::Location` to get that same info. For example, `stack_err!` could be replaced with

  impl StackError {
      #[track_caller]
      fn new_location(msg: impl Display) -> Self {
          let loc = std::panic::Location::caller();
          Self::new(format!("{}:{} {msg}", loc.file(), loc.line()))
      }
  }
such that you call `.map_err(StackError::new_location("data is not a list of strings"))`. A macro is nice if you need to process format strings with arguments (though someone can call `StackError::new_location(format_args!(…))` if they want), but all of your examples show static strings so it's nice to avoid the error in that case.

The use of `std::panic::Location` also means instead of baking that into a format string you could also just have that be an extra field on the error, which would let you expose accessors for it, and you can then print them in your Debug/Display impls.

Speaking of, the Display impl really should not include its source. Standard handling for errors expects that an error prints just itself with Display because it's very common to recurse through sources and print those, so if Display prints the source too then you're duplicating output. Go ahead and print it on Debug though, that's nice for errors returned from `main()`.

garrinm•1y ago
Thanks for the insight, I wasn't aware of `track_caller`. I'll definitely be looking into this. I was scratching my head trying to figure out how to make file and line number usage consistent and customizable, this looks like the answer!

You're also right that this will pretty much eliminate the need for macros.

That's also a very key insight about Display vs. Debug printing. I'll be looking into that as well.

Thank you for the thoughtful reply.

DavidWilkinson•1y ago
Dei here, from the team behind Error Stack [1] (a similarly named existing, context-aware error-handling library for Rust that supports arbitrary attachments). How does Stack Error, here, compare?

[1]: https://crates.io/crates/error-stack