The best Hacker News stories from Show from the past day
Latest posts:
Show HN: Hackerbrief – Top posts on Hacker News summarized daily
Show HN: Thermal Receipt Printers – Markdown and Web UI
Show HN: Thermal Receipt Printers – Markdown and Web UI
Show HN: Oxyde – Pydantic-native async ORM with a Rust core
Hi HN! I built Oxyde because I was tired of duplicating my models.<p>If you use FastAPI, you know the drill. You define Pydantic models for your API, then define separate ORM models for your database, then write converters between them. SQLModel tries to fix this but it's still SQLAlchemy underneath. Tortoise gives you a nice Django-style API but its own model system. Django ORM is great but welded to the framework.<p>I wanted something simple: your Pydantic model IS your database model. One class, full validation on input and output, native type hints, zero duplication. The query API is Django-style (.objects.filter(), .exclude(), Q/F expressions) because I think it's one of the best designs out there.<p><i>Explicit over implicit.</i> I tried to remove all the magic. Queries don't touch the database until you call a terminal method like .all(), .get(), or .first(). If you don't explicitly call .join() or .prefetch(), related data won't be loaded. No lazy loading, no surprise N+1 queries behind your back. You see exactly what hits the database by reading the code.<p><i>Type safety</i> was a big motivation. Python's weak spot is runtime surprises, so Oxyde tackles this on three levels: (1) when you run makemigrations, it also generates .pyi stub files with fully typed queries, so your IDE knows that filter(age__gte=...) takes an int, that create() accepts exactly the fields your model has, and that .all() returns list[User] not list[Any]; (2) Pydantic validates data going into the database; (3) Pydantic validates data coming back out via model_validate(). You get autocompletion, red squiggles on typos, and runtime guarantees, all from the same model definition.<p><i>Why Rust?</i> Not for speed as a goal. I don't do "language X is better" debates. Each one is good at what it was made for. Python is hard to beat for expressing business logic. But infrastructure stuff like SQL generation, connection pooling, and row serialization is where a systems language makes sense. So I split it: Python handles your models and business logic, Rust handles the database plumbing. Queries are built as an IR in Python, serialized via MessagePack, sent to Rust which generates dialect-specific SQL, executes it, and streams results back. Speed is a side effect of this split, not the goal. But since you're not paying a performance tax for the convenience, here are the benchmarks if curious: <a href="https://oxyde.fatalyst.dev/latest/advanced/benchmarks/" rel="nofollow">https://oxyde.fatalyst.dev/latest/advanced/benchmarks/</a><p>What's there today: Django-style migrations (makemigrations / migrate), transactions with savepoints, joins and prefetch, PostgreSQL + SQLite + MySQL, FastAPI integration, and an auto-generated admin panel that works with FastAPI, Litestar, Sanic, Quart, and Falcon (<a href="https://github.com/mr-fatalyst/oxyde-admin" rel="nofollow">https://github.com/mr-fatalyst/oxyde-admin</a>).<p>It's v0.5, beta, active development, API might still change. This is my attempt to build the ORM I personally wanted to use. Would love feedback, criticism, ideas.<p>Docs: <a href="https://oxyde.fatalyst.dev/" rel="nofollow">https://oxyde.fatalyst.dev/</a><p>Step-by-step FastAPI tutorial (blog API from scratch): <a href="https://github.com/mr-fatalyst/fastapi-oxyde-example" rel="nofollow">https://github.com/mr-fatalyst/fastapi-oxyde-example</a>
Show HN: Oxyde – Pydantic-native async ORM with a Rust core
Hi HN! I built Oxyde because I was tired of duplicating my models.<p>If you use FastAPI, you know the drill. You define Pydantic models for your API, then define separate ORM models for your database, then write converters between them. SQLModel tries to fix this but it's still SQLAlchemy underneath. Tortoise gives you a nice Django-style API but its own model system. Django ORM is great but welded to the framework.<p>I wanted something simple: your Pydantic model IS your database model. One class, full validation on input and output, native type hints, zero duplication. The query API is Django-style (.objects.filter(), .exclude(), Q/F expressions) because I think it's one of the best designs out there.<p><i>Explicit over implicit.</i> I tried to remove all the magic. Queries don't touch the database until you call a terminal method like .all(), .get(), or .first(). If you don't explicitly call .join() or .prefetch(), related data won't be loaded. No lazy loading, no surprise N+1 queries behind your back. You see exactly what hits the database by reading the code.<p><i>Type safety</i> was a big motivation. Python's weak spot is runtime surprises, so Oxyde tackles this on three levels: (1) when you run makemigrations, it also generates .pyi stub files with fully typed queries, so your IDE knows that filter(age__gte=...) takes an int, that create() accepts exactly the fields your model has, and that .all() returns list[User] not list[Any]; (2) Pydantic validates data going into the database; (3) Pydantic validates data coming back out via model_validate(). You get autocompletion, red squiggles on typos, and runtime guarantees, all from the same model definition.<p><i>Why Rust?</i> Not for speed as a goal. I don't do "language X is better" debates. Each one is good at what it was made for. Python is hard to beat for expressing business logic. But infrastructure stuff like SQL generation, connection pooling, and row serialization is where a systems language makes sense. So I split it: Python handles your models and business logic, Rust handles the database plumbing. Queries are built as an IR in Python, serialized via MessagePack, sent to Rust which generates dialect-specific SQL, executes it, and streams results back. Speed is a side effect of this split, not the goal. But since you're not paying a performance tax for the convenience, here are the benchmarks if curious: <a href="https://oxyde.fatalyst.dev/latest/advanced/benchmarks/" rel="nofollow">https://oxyde.fatalyst.dev/latest/advanced/benchmarks/</a><p>What's there today: Django-style migrations (makemigrations / migrate), transactions with savepoints, joins and prefetch, PostgreSQL + SQLite + MySQL, FastAPI integration, and an auto-generated admin panel that works with FastAPI, Litestar, Sanic, Quart, and Falcon (<a href="https://github.com/mr-fatalyst/oxyde-admin" rel="nofollow">https://github.com/mr-fatalyst/oxyde-admin</a>).<p>It's v0.5, beta, active development, API might still change. This is my attempt to build the ORM I personally wanted to use. Would love feedback, criticism, ideas.<p>Docs: <a href="https://oxyde.fatalyst.dev/" rel="nofollow">https://oxyde.fatalyst.dev/</a><p>Step-by-step FastAPI tutorial (blog API from scratch): <a href="https://github.com/mr-fatalyst/fastapi-oxyde-example" rel="nofollow">https://github.com/mr-fatalyst/fastapi-oxyde-example</a>
Show HN: Claude Code skills that build complete Godot games
I’ve been working on this for about a year through four major rewrites. Godogen is a pipeline that takes a text prompt, designs the architecture, generates 2D/3D assets, writes the GDScript, and tests it visually. The output is a complete, playable Godot 4 project.<p>Getting LLMs to reliably generate functional games required solving three specific engineering bottlenecks:<p>1. The Training Data Scarcity: LLMs barely know GDScript. It has ~850 classes and a Python-like syntax that will happily let a model hallucinate Python idioms that fail to compile. To fix this, I built a custom reference system: a hand-written language spec, full API docs converted from Godot's XML source, and a quirks database for engine behaviors you can't learn from docs alone. Because 850 classes blow up the context window, the agent lazy-loads only the specific APIs it needs at runtime.<p>2. The Build-Time vs. Runtime State: Scenes are generated by headless scripts that build the node graph in memory and serialize it to .tscn files. This avoids the fragility of hand-editing Godot's serialization format. But it means certain engine features (like `@onready` or signal connections) aren't available at build time—they only exist when the game actually runs. Teaching the model which APIs are available at which phase — and that every node needs its owner set correctly or it silently vanishes on save — took careful prompting but paid off.<p>3. The Evaluation Loop: A coding agent is inherently biased toward its own output. To stop it from cheating, a separate Gemini Flash agent acts as visual QA. It sees only the rendered screenshots from the running engine—no code—and compares them against a generated reference image. It catches the visual bugs text analysis misses: z-fighting, floating objects, physics explosions, and grid-like placements that should be organic.<p>Architecturally, it runs as two Claude Code skills: an orchestrator that plans the pipeline, and a task executor that implements each piece in a `context: fork` window so mistakes and state don't accumulate.<p>Everything is open source: <a href="https://github.com/htdt/godogen" rel="nofollow">https://github.com/htdt/godogen</a><p>Demo video (real games, not cherry-picked screenshots): <a href="https://youtu.be/eUz19GROIpY" rel="nofollow">https://youtu.be/eUz19GROIpY</a><p>Blog post with the full story (all the wrong turns) coming soon. Happy to answer questions.
Show HN: Claude Code skills that build complete Godot games
I’ve been working on this for about a year through four major rewrites. Godogen is a pipeline that takes a text prompt, designs the architecture, generates 2D/3D assets, writes the GDScript, and tests it visually. The output is a complete, playable Godot 4 project.<p>Getting LLMs to reliably generate functional games required solving three specific engineering bottlenecks:<p>1. The Training Data Scarcity: LLMs barely know GDScript. It has ~850 classes and a Python-like syntax that will happily let a model hallucinate Python idioms that fail to compile. To fix this, I built a custom reference system: a hand-written language spec, full API docs converted from Godot's XML source, and a quirks database for engine behaviors you can't learn from docs alone. Because 850 classes blow up the context window, the agent lazy-loads only the specific APIs it needs at runtime.<p>2. The Build-Time vs. Runtime State: Scenes are generated by headless scripts that build the node graph in memory and serialize it to .tscn files. This avoids the fragility of hand-editing Godot's serialization format. But it means certain engine features (like `@onready` or signal connections) aren't available at build time—they only exist when the game actually runs. Teaching the model which APIs are available at which phase — and that every node needs its owner set correctly or it silently vanishes on save — took careful prompting but paid off.<p>3. The Evaluation Loop: A coding agent is inherently biased toward its own output. To stop it from cheating, a separate Gemini Flash agent acts as visual QA. It sees only the rendered screenshots from the running engine—no code—and compares them against a generated reference image. It catches the visual bugs text analysis misses: z-fighting, floating objects, physics explosions, and grid-like placements that should be organic.<p>Architecturally, it runs as two Claude Code skills: an orchestrator that plans the pipeline, and a task executor that implements each piece in a `context: fork` window so mistakes and state don't accumulate.<p>Everything is open source: <a href="https://github.com/htdt/godogen" rel="nofollow">https://github.com/htdt/godogen</a><p>Demo video (real games, not cherry-picked screenshots): <a href="https://youtu.be/eUz19GROIpY" rel="nofollow">https://youtu.be/eUz19GROIpY</a><p>Blog post with the full story (all the wrong turns) coming soon. Happy to answer questions.
Show HN: GDSL – 800 line kernel: Lisp subset in 500, C subset in 1300
Show HN: GDSL – 800 line kernel: Lisp subset in 500, C subset in 1300
Show HN: Lux – Drop-in Redis replacement in Rust. 5.6x faster, ~1MB Docker image
Show HN: Learn Arabic with spaced repetition and comprehensible input
Sharing a friends first-ever Rails application, dedicated to Arabic learning, from 0 to 1. Pulls language learning methods from Anki, comprehensible input and more.
Show HN: What if your synthesizer was powered by APL (or a dumb K clone)?
I built k-synth as an experiment to see if a minimalist, K-inspired array language could make sketching waveforms faster and more intuitive than traditional code. I’ve put together a web-based toolkit so you can try the syntax directly in the browser without having to touch a compiler:<p>Live Toolkit: <a href="https://octetta.github.io/k-synth/" rel="nofollow">https://octetta.github.io/k-synth/</a><p>If you visit the page, here is a quick path to an audio payoff:<p>- Click "patches" and choose dm-bell.ks.<p>- Click "run"—the notebook area will update. Click the waveform to hear the result.<p>- Click the "->0" button below the waveform to copy it into slot 0 at the top (slots are also clickable).<p>- Click "pads" in the entry area to show a performance grid.<p>- Click "melodic" to play slot 0's sample at different intervals across the grid.<p>The 'Weird' Stack:<p>- The Language: A simplified, right-associative array language (e.g., s for sine, p for pi).<p>- The Web Toolkit: Built using WASM and Web Audio for live-coding samples.<p>- AI Pair-Programming: I used AI agents to bootstrap the parser and web boilerplate, which let me vet the language design in weeks rather than months.<p>The Goal: This isn't meant to replace a DAW. It’s a compact way to generate samples for larger projects. It’s currently in a "will-it-blend" state. I’m looking for feedback from the array language and DSP communities—specifically on the operator choices and the right-to-left evaluation logic.<p>Source (MIT): <a href="https://github.com/octetta/k-synth" rel="nofollow">https://github.com/octetta/k-synth</a>
Show HN: What if your synthesizer was powered by APL (or a dumb K clone)?
I built k-synth as an experiment to see if a minimalist, K-inspired array language could make sketching waveforms faster and more intuitive than traditional code. I’ve put together a web-based toolkit so you can try the syntax directly in the browser without having to touch a compiler:<p>Live Toolkit: <a href="https://octetta.github.io/k-synth/" rel="nofollow">https://octetta.github.io/k-synth/</a><p>If you visit the page, here is a quick path to an audio payoff:<p>- Click "patches" and choose dm-bell.ks.<p>- Click "run"—the notebook area will update. Click the waveform to hear the result.<p>- Click the "->0" button below the waveform to copy it into slot 0 at the top (slots are also clickable).<p>- Click "pads" in the entry area to show a performance grid.<p>- Click "melodic" to play slot 0's sample at different intervals across the grid.<p>The 'Weird' Stack:<p>- The Language: A simplified, right-associative array language (e.g., s for sine, p for pi).<p>- The Web Toolkit: Built using WASM and Web Audio for live-coding samples.<p>- AI Pair-Programming: I used AI agents to bootstrap the parser and web boilerplate, which let me vet the language design in weeks rather than months.<p>The Goal: This isn't meant to replace a DAW. It’s a compact way to generate samples for larger projects. It’s currently in a "will-it-blend" state. I’m looking for feedback from the array language and DSP communities—specifically on the operator choices and the right-to-left evaluation logic.<p>Source (MIT): <a href="https://github.com/octetta/k-synth" rel="nofollow">https://github.com/octetta/k-synth</a>
Show HN: Signet – Autonomous wildfire tracking from satellite and weather data
I built Signet in Go to see if an autonomous system could handle the wildfire monitoring loop that people currently run by hand - checking satellite feeds, pulling up weather, looking at terrain and fuels, deciding whether a detection is actually a fire worth tracking.<p>All the data already exists: NASA FIRMS thermal detections, GOES-19 imagery, NWS forecasts, LANDFIRE fuel models, USGS elevation, Census population data, OpenStreetMap. The problem is it arrives from different sources on different cadences in different formats.<p>Most of the system is deterministic plumbing - ingestion, spatial indexing, deduplication. I use Gemini to orchestrate 23 tools across weather, terrain, imagery, and incident tracking for the part where clean rules break down: deciding which weak detections are worth investigating, what context to pull next, and how to synthesize noisy evidence into a structured assessment.<p>It also records time-bounded predictions and scores them against later data, so the system is making falsifiable claims instead of narrating after the fact. The current prediction metrics are visible on the site even though the sample is still small.<p>It's already opening incidents from raw satellite detections and matching some to official NIFC reporting. But false positives, detection latency, and incident matching can still be rough.<p>I'd especially welcome criticism on: where should this be more deterministic instead of LLM-driven? And is this kind of autonomous monitoring actually useful, or just noisier than doing it by hand?
Show HN: Signet – Autonomous wildfire tracking from satellite and weather data
I built Signet in Go to see if an autonomous system could handle the wildfire monitoring loop that people currently run by hand - checking satellite feeds, pulling up weather, looking at terrain and fuels, deciding whether a detection is actually a fire worth tracking.<p>All the data already exists: NASA FIRMS thermal detections, GOES-19 imagery, NWS forecasts, LANDFIRE fuel models, USGS elevation, Census population data, OpenStreetMap. The problem is it arrives from different sources on different cadences in different formats.<p>Most of the system is deterministic plumbing - ingestion, spatial indexing, deduplication. I use Gemini to orchestrate 23 tools across weather, terrain, imagery, and incident tracking for the part where clean rules break down: deciding which weak detections are worth investigating, what context to pull next, and how to synthesize noisy evidence into a structured assessment.<p>It also records time-bounded predictions and scores them against later data, so the system is making falsifiable claims instead of narrating after the fact. The current prediction metrics are visible on the site even though the sample is still small.<p>It's already opening incidents from raw satellite detections and matching some to official NIFC reporting. But false positives, detection latency, and incident matching can still be rough.<p>I'd especially welcome criticism on: where should this be more deterministic instead of LLM-driven? And is this kind of autonomous monitoring actually useful, or just noisier than doing it by hand?
Show HN: Context Gateway – Compress agent context before it hits the LLM
We built an open-source proxy that sits between coding agents (Claude Code, OpenClaw, etc.) and the LLM, compressing tool outputs before they enter the context window.<p>Demo: <a href="https://www.youtube.com/watch?v=-vFZ6MPrwjw#t=9s" rel="nofollow">https://www.youtube.com/watch?v=-vFZ6MPrwjw#t=9s</a>.<p>Motivation: Agents are terrible at managing context. A single file read or grep can dump thousands of tokens into the window, most of it noise. This isn't just expensive — it actively degrades quality. Long-context benchmarks consistently show steep accuracy drops as context grows (OpenAI's GPT-5.4 eval goes from 97.2% at 32k to 36.6% at 1M <a href="https://openai.com/index/introducing-gpt-5-4/" rel="nofollow">https://openai.com/index/introducing-gpt-5-4/</a>).<p>Our solution uses small language models (SLMs): we look at model internals and train classifiers to detect which parts of the context carry the most signal. When a tool returns output, we compress it conditioned on the intent of the tool call—so if the agent called grep looking for error handling patterns, the SLM keeps the relevant matches and strips the rest.<p>If the model later needs something we removed, it calls expand() to fetch the original output. We also do background compaction at 85% window capacity and lazy-load tool descriptions so the model only sees tools relevant to the current step.<p>The proxy also gives you spending caps, a dashboard for tracking running and past sessions, and Slack pings when an agent is sitting there waiting on you.<p>Repo is here: <a href="https://github.com/Compresr-ai/Context-Gateway" rel="nofollow">https://github.com/Compresr-ai/Context-Gateway</a>. You can try it with:<p><pre><code> curl -fsSL https://compresr.ai/api/install | sh
</code></pre>
Happy to go deep on any of it: the compression model, how the lazy tool loading works, or anything else about the gateway. Try it out and let us know how you like it!
Show HN: GitAgent – An open standard that turns any Git repo into an AI agent
We built GitAgent because we kept seeing the same problem: every agent framework defines agents differently, and switching frameworks means rewriting everything.<p>GitAgent is a spec that defines an AI agent as files in a git repo.<p>Three core files — agent.yaml (config), SOUL.md (personality/instructions), and SKILL.md (capabilities) — and you get a portable agent definition that exports to Claude Code, OpenAI Agents SDK, CrewAI, Google ADK, LangChain, and others.<p>What you get for free by being git-native:<p>1. Version control for agent behavior (roll back a bad prompt like you'd revert a bad commit)
2. Branching for environment promotion (dev → staging → main)
3. Human-in-the-loop via PRs (agent learns a skill → opens a branch → human reviews before merge)
4. Audit trail via git blame and git diff
5. Agent forking and remixing (fork a public agent, customize it, PR improvements back)
6. CI/CD with GitAgent validate in GitHub Actions<p>The CLI lets you run any agent repo directly:<p>npx @open-gitagent/gitagent run -r <a href="https://github.com/user/agent" rel="nofollow">https://github.com/user/agent</a> -a claude<p>The compliance layer is optional, but there if you need it — risk tiers, regulatory mappings (FINRA, SEC, SR 11-7), and audit reports via GitAgent audit.<p>Spec is at <a href="https://gitagent.sh" rel="nofollow">https://gitagent.sh</a>, code is on GitHub.<p>Would love feedback on the schema design and what adapters people would want next.
Show HN: Ichinichi – One note per day, E2E encrypted, local-first
Look, every journaling app out there wants you to organize things into folders and tags and templates. I just wanted to write something down every day.<p>So I built this. One note per day. That's the whole deal.<p>- Can't edit yesterday. What's done is done. Keeps you from fussing over old entries instead of writing today's.<p>- Year view with dots showing which days you actually wrote. It's a streak chart. Works better than it should.<p>- No signup required. Opens right up, stores everything locally in your browser. Optional cloud sync if you want it<p>- E2E encrypted with AES-GCM, zero-knowledge, the whole nine yards.<p>Tech-wise: React, TypeScript, Vite, Zustand, IndexedDB. Supabase for optional sync. Deployed on Cloudflare. PWA-capable.<p>The name means "one day" in Japanese (いちにち).<p>The read-only past turned out to be the thing that actually made me stick with it. Can't waste time perfecting yesterday if yesterday won't let you in.<p>Live at <a href="https://ichinichi.app" rel="nofollow">https://ichinichi.app</a> | Source: <a href="https://github.com/katspaugh/ichinichi" rel="nofollow">https://github.com/katspaugh/ichinichi</a>
Show HN: Han – A Korean programming language written in Rust
A few weeks ago I saw a post about someone converting an entire C++ codebase to Rust using AI in under two weeks.<p>That inspired me — if AI can rewrite a whole language stack that fast, I wanted to try building a programming language from scratch with AI assistance.<p>I've also been noticing growing global interest in Korean language and culture, and I wondered: what would a programming language look like if every keyword was in Hangul (the Korean writing system)?<p>Han is the result. It's a statically-typed language written in Rust with a full compiler pipeline (lexer → parser → AST → interpreter + LLVM IR codegen).<p>It supports arrays, structs with impl blocks, closures, pattern matching, try/catch, file I/O, module imports, a REPL, and a basic LSP server.<p>This is a side project, not a "you should use this instead of Python" pitch.
Feedback on language design, compiler architecture, or the Korean keyword choices is very welcome.<p><a href="https://github.com/xodn348/han" rel="nofollow">https://github.com/xodn348/han</a>
Show HN: Channel Surfer – Watch YouTube like it’s cable TV
I know, it's a very first-world problem. But in my house, we have a hard time deciding what to watch. Too many options!<p>So I made this to recreate Cable TV for YouTube. I made it so it runs in the browser. Quickly import your subscriptions in the browser via a bookmarklet. No accounts, no sign-ins. Just quickly import your data locally.