Hacker News
Latest
Kagi Translate now supports LinkedIn Speak as an output language
2026-03-17 @ 04:39:42Points: 442Comments: 107
Monkey Island for Commodore 64 Ground Up
2026-03-17 @ 04:00:28Points: 119Comments: 35
Jepsen: MariaDB Galera Cluster 12.1.2
2026-03-17 @ 03:46:22Points: 69Comments: 5
Every layer of review makes you 10x slower
2026-03-17 @ 03:20:36Points: 210Comments: 103
US SEC preparing to scrap quarterly reporting requirement
2026-03-17 @ 00:02:35Points: 568Comments: 307
AnswerThis (YC F25) Is Hiring
2026-03-16 @ 21:00:06Points: 1
Beyond has dropped “meat” from its name and expanded its high-protein drink line
2026-03-16 @ 20:59:49Points: 123Comments: 234
Leanstral: Open-source agent for trustworthy coding and formal proof engineering
2026-03-16 @ 20:59:40Points: 510Comments: 102
Meta’s renewed commitment to jemalloc
2026-03-16 @ 18:12:32Points: 430Comments: 185
Language model teams as distributed systems
2026-03-16 @ 17:19:13Points: 91Comments: 39
The “small web” is bigger than you might think
2026-03-16 @ 17:17:57Points: 416Comments: 175
The American Healthcare Conundrum
2026-03-16 @ 17:13:27Points: 335Comments: 291
Speed at the cost of quality: Study of use of Cursor AI in open source projects (2025)
2026-03-16 @ 17:07:37Points: 110Comments: 61
Show HN: Claude Code skills that build complete Godot games
2026-03-16 @ 16:07:29Points: 247Comments: 153
Getting LLMs to reliably generate functional games required solving three specific engineering bottlenecks:
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.
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.
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.
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.
Everything is open source: https://github.com/htdt/godogen
Demo video (real games, not cherry-picked screenshots): https://youtu.be/eUz19GROIpY
Blog post with the full story (all the wrong turns) coming soon. Happy to answer questions.
AirPods Max 2
2026-03-16 @ 13:22:03Points: 277Comments: 455
My Journey to a reliable and enjoyable locally hosted voice assistant (2025)
2026-03-16 @ 13:09:58Points: 370Comments: 104
Lazycut: A simple terminal video trimmer using FFmpeg
2026-03-16 @ 12:05:08Points: 197Comments: 58
Polymarket gamblers threaten to kill me over Iran missile story
2026-03-16 @ 12:00:06Points: 1478Comments: 935
Why I love FreeBSD
2026-03-16 @ 11:23:14Points: 427Comments: 206
Starlink Mini as a failover
2026-03-16 @ 08:07:29Points: 255Comments: 185
The bureaucracy blocking the chance at a cure
2026-03-15 @ 18:32:27Points: 130Comments: 151
Pyodide: a Python distribution based on WebAssembly
2026-03-13 @ 17:34:45Points: 69Comments: 23
Show HN: Thermal Receipt Printers – Markdown and Web UI
2026-03-13 @ 16:49:01Points: 80Comments: 30
The unlikely story of Teardown Multiplayer
2026-03-13 @ 16:20:00Points: 53Comments: 7
Claude Tips for 3D Work
2026-03-13 @ 14:53:10Points: 73Comments: 16
Show HN: Oxyde – Pydantic-native async ORM with a Rust core
2026-03-13 @ 13:35:12Points: 104Comments: 55
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.
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.
Explicit over implicit. 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.
Type safety 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.
Why Rust? 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: https://oxyde.fatalyst.dev/latest/advanced/benchmarks/
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 (https://github.com/mr-fatalyst/oxyde-admin).
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.
Docs: https://oxyde.fatalyst.dev/
Step-by-step FastAPI tutorial (blog API from scratch): https://github.com/mr-fatalyst/fastapi-oxyde-example