frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Cowork: Claude Code for the rest of your work

https://claude.com/blog/cowork-research-preview
866•adocomplete•12h ago•398 comments

TimeCapsuleLLM: LLM trained only on data from 1800-1875

https://github.com/haykgrigo3/TimeCapsuleLLM
572•admp•15h ago•230 comments

Text-Based Web Browsers

https://cssence.com/2026/text-based-web-browsers/
20•pabs3•2h ago•8 comments

The Cray-1 Computer System (1977) [pdf]

https://s3data.computerhistory.org/brochures/cray.cray1.1977.102638650.pdf
81•LordGrey•3d ago•44 comments

Postal Arbitrage

https://walzr.com/postal-arbitrage
364•The28thDuck•13h ago•183 comments

Implementing a web server in a single printf() call (2014)

https://tinyhack.com/2014/03/12/implementing-a-web-server-in-a-single-printf-call/
32•nateb2022•4d ago•2 comments

The chess bot on Delta Air Lines will destroy you (2024) [video]

https://www.youtube.com/watch?v=c0mLhHDcY3I
211•cjaackie•11h ago•163 comments

Provenance Is the New Version Control

https://aicoding.leaflet.pub/3mcbiyal7jc2y
33•gpi•4h ago•26 comments

Floppy disks turn out to be the greatest TV remote for kids

https://blog.smartere.dk/2026/01/floppy-disks-the-best-tv-remote-for-kids/
566•mchro•18h ago•328 comments

Some ecologists fear their field is losing touch with nature

https://www.nature.com/articles/d41586-025-04150-w
93•Growtika•4d ago•46 comments

Unauthenticated remote code execution in OpenCode

https://cy.md/opencode-rce/
294•CyberShadow•1d ago•90 comments

Date is out, Temporal is in

https://piccalil.li/blog/date-is-out-and-temporal-is-in/
358•alexanderameye•16h ago•137 comments

Fabrice Bellard's TS Zip (2024)

https://www.bellard.org/ts_zip/
144•everlier•11h ago•57 comments

LLVM: The bad parts

https://www.npopov.com/2026/01/11/LLVM-The-bad-parts.html
324•vitaut•17h ago•60 comments

Apple picks Gemini to power Siri

https://www.cnbc.com/2026/01/12/apple-google-ai-siri-gemini.html
789•stygiansonic•16h ago•469 comments

Show HN: AI in SolidWorks

https://www.trylad.com
148•WillNickols•14h ago•82 comments

Kafka Inc

https://libertiesjournal.com/online-articles/kafkainc/
7•Caiero•5d ago•2 comments

Zirgen: Compiler for a Domain-Specific Language

https://github.com/risc0/zirgen
3•0xkato•4d ago•0 comments

Anthropic made a mistake in cutting off third-party clients

https://archaeologist.dev/artifacts/anthropic
272•codesparkle•20h ago•186 comments

Show HN: Yolobox – Run AI coding agents with full sudo without nuking home dir

https://github.com/finbarr/yolobox
78•Finbarr•12h ago•60 comments

Show HN: Agent-of-empires: OpenCode and Claude Code session manager

https://github.com/njbrake/agent-of-empires
86•river_otter•17h ago•24 comments

Windows 8 Desktop Environment for Linux

https://github.com/er-bharat/Win8DE
177•edent•18h ago•163 comments

F2 (YC S25) Is Hiring

https://www.ycombinator.com/companies/f2/jobs/cJsc7Fe-product-designer
1•arctech•9h ago

The struggle of resizing windows on macOS Tahoe

https://noheger.at/blog/2026/01/11/the-struggle-of-resizing-windows-on-macos-tahoe/
2610•happosai•1d ago•1115 comments

Google removes AI health summaries after investigation finds dangerous flaws

https://arstechnica.com/ai/2026/01/google-removes-some-ai-health-summaries-after-investigation-fi...
155•barishnamazov•8h ago•88 comments

Ozempic is changing the foods Americans buy

https://news.cornell.edu/stories/2025/12/ozempic-changing-foods-americans-buy
377•giuliomagnifico•19h ago•685 comments

Show HN: Fall asleep by watching JavaScript load

https://github.com/sarusso/bedtime
63•sarusso•12h ago•21 comments

Zen-C: Write like a high-level language, run like C

https://github.com/z-libs/Zen-C
182•simonpure•18h ago•108 comments

Message Queues: A Simple Guide with Analogies (2024)

https://www.cloudamqp.com/blog/message-queues-exaplined-with-analogies.html
93•byt3h3ad•14h ago•25 comments

Why BM25 queries with more terms can be faster (and other scaling surprises)

https://turbopuffer.com/blog/bm25-latency-musings
15•_peregrine_•4d ago•0 comments
Open in hackernews

Show HN: Stack Error – ergonomic error handling for Rust

https://github.com/gmcgoldr/stackerror
27•garrinm•7mo 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•7mo 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•7mo 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•7mo ago
I still prefer the Anyhow solution, but I like the approach here.
IshKebab•7mo ago
Isn't this strictly superior to Anyhow? What do you like more about Anyhow?
rhabarba•7mo 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•7mo 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•7mo ago
Might as well be my limited understanding from what I can read behind the link, to be fair.
garrinm•7mo 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•7mo 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•7mo 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•7mo 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•7mo 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•7mo 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