The best Hacker News stories from Show from the past day

from

All Show

from the past*

day week month

with these search terms:

Create follow Go back

Latest posts:

Show HN: Loreline, narrative language transpiled via Haxe: C++/C#/JS/Java/Py/Lua

Show HN: I turned a sketch into a 3D-print pegboard for my kid with an AI agent

We have pegboards and plywood all over our apartment, and I had an idea to make a tiny pegboard for my kid, Oli. So I naturally cut the wood, drilled in the holes, sat down at the computer to open Fusion 360 and spend an hour or two drawing the pieces by hand.<p>Then I looked at the rough sketch Oli and I had made together, took a photo of it, pasted it into Codex, and gave it just two dimensions: the holes are 40mm apart and the pegs are 8mm wide.<p>To my surprise, 5 minutes later my 3D printer was heating up and printing the first set.<p>I ran it a few times to tune the dimensions for ideal fit, but I am posting the final result as a repository in case anyone else wants to print one, tweak it, or have fun with it too. I am already printing another one to hang on our front door instead of a wreath, so people visiting us have something fun and intriguing to play with while they knock.<p>This is also going onto my list of weird uses of AI from the last few months.

Show HN: 1-Bit Bonsai, the First Commercially Viable 1-Bit LLMs

Show HN: Postgres extension for BM25 relevance-ranked full-text search

Last summer we faced a conundrum at my company, Tiger Data, a Postgres cloud vendor whose main business is in timeseries data. We were trying to grow our business towards emerging AI-centric workloads and wanted to provide a state-of-the-art hybrid search stack in Postgres. We'd already built pgvectorscale in house with the goal of scaling semantic search beyond pgvector's main memory limitations. We just needed a scalable ranked keyword search solution too.<p>The problem: core Postgres doesn't provide this; the leading Postgres BM25 extension, ParadeDB, is guarded behind AGPL; developing our own extension appeared daunting. We'd need a small team of sharp engineers and 6-12 months, I figured. And we'd probably still fall short of the performance of a mature system like Parade/Tantivy.<p>Or would we? I'd be experimenting long enough with AI-boosted development at that point to realize that with the latest tools (Claude Code + Opus) and an experienced hand (I've been working in database systems internals for 25 years now), the old time estimates pretty much go out the window.<p>I told our CTO I thought I could solo the project in one quarter. This raised some eyebrows.<p>It did take a little more time than that (two quarters), and we got some real help from the community (amazing!) after open-sourcing the pre-release. But I'm thrilled/exhausted today to share that pg_textsearch v1.0 is freely available via open source (Postgres license), on Tiger Data cloud, and hopefully soon, a hyperscalar near you:<p><a href="https://github.com/timescale/pg_textsearch" rel="nofollow">https://github.com/timescale/pg_textsearch</a><p>In the blog post accompanying the release, I overview the architecture and present benchmark results using MS-MARCO. To my surprise, we were not only able to meet Parade/Tantivy's query performance, but exceed it substantially, measuring a 4.7x advantage on query throughput at scale:<p><a href="https://www.tigerdata.com/blog/pg-textsearch-bm25-full-text-search-postgres" rel="nofollow">https://www.tigerdata.com/blog/pg-textsearch-bm25-full-text-...</a><p>It's exciting (and, to be honest, a little unnerving) to see a field I've spent so much time toiling in change so quickly in ways that enable us to be more ambitious in our technical objectives. Technical moats are moats no longer.<p>The benchmark scripts and methodology are available in the github repo. Happy to answer any questions in the thread.<p>Thanks,<p>TJ (tj@tigerdata.com)

Show HN: Forkrun – NUMA-aware shell parallelizer (50×–400× faster than parallel)

forkrun is the culmination of a 10-year-long journey focused on "how to make shell parallelization fast". What started as a standard "fork jobs in a loop" has turned into a lock-free, CAS-retry-loop-free, SIMD-accelerated, self-tuning, NUMA aware shell-based stream parallelization engine that is (mostly) a drop-in replacement for xargs -P and GNU parallel.<p>On my 14-core/28-thread i9-7940x, forkrun achieves:<p>* 200,000+ batch dispatches/sec (vs ~500 for GNU Parallel)<p>* ~95–99% CPU utilization across all 28 logical cores, even when the workload is non-existant (bash no-ops / `:`) (vs ~6% for GNU Parallel). These benchmarks are intentionally worst-case (near-zero work per task) because they measure the capability of the parallelization framework itself, not how much work an external tool can do.<p>* Typically 50×–400× faster on real high-frequency low-latency workloads (vs GNU Parallel)<p>A few of the techniques that make this possible:<p>* Born-local NUMA: stdin is splice()'d into a shared memfd, then pages are placed on the target NUMA node via set_mempolicy(MPOL_BIND) before any worker touches them, making the memfd NUMA-spliced. Each numa node only claims work that is <i>already</i> born-local on its node. Stealing from other nodes is permitted under some conditions when no local work exists.<p>* SIMD scanning: per-node indexers/scanners use AVX2/NEON to find line boundaries (delimiters) at speeds approaching memory bandwidth, and publish byte-offsets and line-counts into per-node lock-free rings.<p>* Lock-free claiming: workers claim batches with a single atomic_fetch_add — no locks, no CAS retry loops; contention is reduced to a single atomic on one cache line.<p>* Memory management: a background thread uses fallocate(PUNCH_HOLE) to reclaim space without breaking the logical offset system.<p>…and that’s just the surface. The implementation uses many additional systems-level techniques (phase-aware tail handling, adaptive batching, early-flush detection, etc.) to eliminate overhead, increase throughput and reduce latency at every stage.<p>In its fastest (-b) mode (fixed-size batches, minimal processing), it can exceed 1B lines/sec.<p>forkrun ships as a single bash file with an embedded, self-extracting C extension — no Perl, no Python, no install, full native support for parallelizing arbitrary shell functions. The binary is built in public GitHub Actions so you can trace it back to CI (see the GitHub "Blame" on the line containing the base64 embeddings). Trying it is literally two commands:<p><pre><code> . frun.bash frun shell_func_or_cmd < inputs </code></pre> For benchmarking scripts and results, see the BENCHMARKS dir in the GitHub repo<p>For an architecture deep-dive, see the DOCS dir in the GitHub repo<p>Happy to answer questions.

Show HN: The Alphabetical Clock

Show HN: Public transit systems as data – lines, stations, railcars, and history

Show HN: Coasts – Containerized Hosts for Agents

Hi HN - We've been working on Coasts (“containerized hosts”) to make it so you can run multiple localhost instances, and multiple docker-compose runtimes, across git worktrees on the same computer. Here’s a demo: <a href="https://www.youtube.com/watch?v=yRiySdGQZZA" rel="nofollow">https://www.youtube.com/watch?v=yRiySdGQZZA</a>. There are also videos in our docs that give a good conceptual overview: <a href="https://coasts.dev/docs/learn-coasts-videos">https://coasts.dev/docs/learn-coasts-videos</a>.<p>Agents can make code changes in different worktrees in isolation, but it's hard for them to test their changes without multiple localhost runtimes that are isolated and scoped to those worktrees as well. You can do it up to a point with port hacking tricks, but it becomes impractical when you have a complex docker-compose with many services and multiple volumes.<p>We started playing with Codex and Conductor in the beginning of this year and had to come up with a bunch of hacky workarounds to give the agents access to isolated runtimes. After bastardizing our own docker-compose setup, we came up with Coasts as a way for agents to have their own runtimes without having to change your original docker-compose.<p>A containerized host (from now on we’ll just say “coast” for short) is a representation of your project's runtime, like a devcontainer but without the IDE stuff—it’s just focused on the runtime. You create a Coastfile at your project root and usually point to your project's docker-compose from there. When you run `coast build` next to the Coastfile you will get a build (essentially a docker image) that can be used to spin up multiple Docker-in-Docker runtimes of your project.<p>Once you have a coast running, you can then do things like assign it to a worktree, with `coast assign dev-1 -w worktree-1`. The coast will then point at the worktree-1 root.<p>Under the hood the host project root and any external worktree directories are Docker-bind-mounted into the container at creation time but the /workspace dir, where we run the services of the coast from, is a separate Linux bind mount that we create inside the running container. When switching worktrees we basically just do umount -l /workspace, mount --bind <path_to_worktree_root>, mount --make-rshared /workspace inside of the running coast. The rshared flag sets up mount propagation so that when we remount /workspace, the change flows down to the inner Docker daemon's containers.<p>The main idea is that the agents can continue to work host-side but then run exec commands against a specific coast instance if they need to test runtime changes or access runtime logs. This makes it so that we are harness agnostic and create interoperability around any agent or agent harness that runs host-side.<p>Each coast comes with its own set of dynamic ports: you define the ports you wish to expose back to the host machine in the Coastfile. You're also able to "checkout" a coast. When you do that, socat binds the canonical ports of your coast (e.g. web 3000, db 5432) to the host machine. This is useful if you have hard coded ports in your project or need to do something like test webhooks.<p>In your Coastfile you point to all the locations on your host-machine where you store your worktrees for your project (e.g. ~/.codex/worktrees). When an agent runs `coast lookup` from a host-side worktree directory, it is able to find the name of the coast instance it is running on, so it can do things like call `coast exec dev-1 make tests`. If your agent needs to do things like test with Playwright it can so that host-side by using the dynamic port of your frontend.<p>You can also configure volume topologies, omit services and volumes that your agent doesn't need, as well as share certain services host-side so you don't add overhead to each coast instance. You can also do things like define strategies for how each service should behave after a worktree assignment change (e.g. none, hot, restart, rebuild). This helps you optimize switching worktrees so you don't have to do a whole docker-compose down and up cycle every time.<p>We'd love to answer any questions and get your feedback!

Show HN: I made a "programming language" looking for feedback

Show HN: Crazierl – An Erlang Operating System

Crazierl is an experimental/hobby operating system based around BEAM.<p>I've linked the browser based demo; I don’t recommend using a phone; it does work, slowly, on the phones I tested, but it’s very awkward to use. You can share a link with a hashtag with your friends and click the consent checkbox, and it (should) link up into dist and I’ve also included a chat application you can start with chat:start(). (quit chat with /quit, or use the shell menu with ctrl-g to switch between shells etc).<p>The browser demo relies on the v86 javascript x86 virtual machine. You can also run Crazierl on a real x86 system, but I’ve had mixed luck on modern systems, it uses some esoteric legacy VGA features and support for that isn’t getting better.<p>Crazierl is fairly limited: 32-bit x86, BIOS boot, only two NIC drivers virtio-net and realtek 8168. But it's got enough to become part of an Erlang dist cluster. It also supports SMP, but it’s crashy with high core counts in qemu; there’s almost certainly several concurrency bugs in the kernel. There's also a lot of excess tcp debug spew (sorry).<p>Source code is available (Apache) <a href="https://github.com/russor/crazierl/" rel="nofollow">https://github.com/russor/crazierl/</a>

Show HN: Crazierl – An Erlang Operating System

Crazierl is an experimental/hobby operating system based around BEAM.<p>I've linked the browser based demo; I don’t recommend using a phone; it does work, slowly, on the phones I tested, but it’s very awkward to use. You can share a link with a hashtag with your friends and click the consent checkbox, and it (should) link up into dist and I’ve also included a chat application you can start with chat:start(). (quit chat with /quit, or use the shell menu with ctrl-g to switch between shells etc).<p>The browser demo relies on the v86 javascript x86 virtual machine. You can also run Crazierl on a real x86 system, but I’ve had mixed luck on modern systems, it uses some esoteric legacy VGA features and support for that isn’t getting better.<p>Crazierl is fairly limited: 32-bit x86, BIOS boot, only two NIC drivers virtio-net and realtek 8168. But it's got enough to become part of an Erlang dist cluster. It also supports SMP, but it’s crashy with high core counts in qemu; there’s almost certainly several concurrency bugs in the kernel. There's also a lot of excess tcp debug spew (sorry).<p>Source code is available (Apache) <a href="https://github.com/russor/crazierl/" rel="nofollow">https://github.com/russor/crazierl/</a>

Show HN: 30u30.fyi – Is your startup founder on Forbes' most fraudulent list?

Show HN: 30u30.fyi – Is your startup founder on Forbes' most fraudulent list?

Show HN: I built an OS that is pure AI

I've been building Pneuma, a desktop computing environment where software doesn't need to exist before you need it. There are no pre-installed applications. You boot to a blank screen with a prompt. You describe what you want: a CPU monitor, a game, a notes app, a data visualizer and a working program materializes in seconds. Once generated, agents persist. You can reuse them, they can communicate with each other through IPC, and you can share them through a community agent store. The idea isn't that everything is disposable. It's that creation is instant and the barrier to having exactly the tool you need is just describing it.<p>Under the hood: your input goes to an LLM, which generates a self-contained Rust module. That gets compiled to WebAssembly in under a second, then JIT-compiled and executed in a sandboxed Wasmtime instance. Everything is GPU-rendered via wgpu (Vulkan/Metal/DX12). If compilation fails, the error is automatically fed back for correction. ~90% first-attempt success rate.<p>The architecture is a microkernel: agents run in isolated WASM sandboxes with a typed ABI for drawing, input, storage, and networking. An agent crash can't bring down the system. Agents can run side by side, persist to a local store, and be shared or downloaded from the community store.<p>Currently it runs as a desktop app on Linux, macOS, and Windows. The longer-term goal is to run on bare metal and support existing ARM64 binaries alongside generated agents. A full computing environment where AI-generated software and traditional applications coexist.<p>Built entirely in Rust.<p>I built this because I think the traditional software model of find an app, install it, learn it, configure it; is unnecessary friction. If a computer can generate exactly the tool you need in the moment you need it, and then keep it around when it's useful, why maintain a library of pre-built software at all?<p>Free tier available (no credit card). There's a video on the landing page showing it in action.<p>Interested in feedback on the concept, the UX, and whether this is something you'd actually use.

Show HN: PeriodicTableOfElements.org

Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes

QuickBEAM is a JavaScript runtime embedded inside the Erlang/OTP VM.<p>If you’re building a full-stack app, JavaScript tends to leak in anyway — frontend, SSR, or third-party code.<p>QuickBEAM runs that JavaScript inside OTP supervision trees.<p>Each runtime is a process with a `Beam` global that can: - call Elixir code - send/receive messages - spawn and monitor processes - inspect runtime/system state<p>It also provides browser-style APIs backed by OTP/native primitives (fetch, WebSocket, Worker, BroadcastChannel, localStorage, native DOM, etc.).<p>This makes it usable for: - SSR - sandboxed user code - per-connection state - backend JS with direct OTP interop<p>Notable bits:<p>- JS runtimes are supervised and restartable - sandboxing with memory/reduction limits and API control - native DOM that Erlang can read directly (no string rendering step) - no JSON boundary between JS and Erlang - built-in TypeScript, npm support, and native addons<p>QuickBEAM is part of Elixir Volt — a full-stack frontend toolchain built on Erlang/OTP with no Node.js.<p>Still early, feedback welcome.

Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes

QuickBEAM is a JavaScript runtime embedded inside the Erlang/OTP VM.<p>If you’re building a full-stack app, JavaScript tends to leak in anyway — frontend, SSR, or third-party code.<p>QuickBEAM runs that JavaScript inside OTP supervision trees.<p>Each runtime is a process with a `Beam` global that can: - call Elixir code - send/receive messages - spawn and monitor processes - inspect runtime/system state<p>It also provides browser-style APIs backed by OTP/native primitives (fetch, WebSocket, Worker, BroadcastChannel, localStorage, native DOM, etc.).<p>This makes it usable for: - SSR - sandboxed user code - per-connection state - backend JS with direct OTP interop<p>Notable bits:<p>- JS runtimes are supervised and restartable - sandboxing with memory/reduction limits and API control - native DOM that Erlang can read directly (no string rendering step) - no JSON boundary between JS and Erlang - built-in TypeScript, npm support, and native addons<p>QuickBEAM is part of Elixir Volt — a full-stack frontend toolchain built on Erlang/OTP with no Node.js.<p>Still early, feedback welcome.

Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes

QuickBEAM is a JavaScript runtime embedded inside the Erlang/OTP VM.<p>If you’re building a full-stack app, JavaScript tends to leak in anyway — frontend, SSR, or third-party code.<p>QuickBEAM runs that JavaScript inside OTP supervision trees.<p>Each runtime is a process with a `Beam` global that can: - call Elixir code - send/receive messages - spawn and monitor processes - inspect runtime/system state<p>It also provides browser-style APIs backed by OTP/native primitives (fetch, WebSocket, Worker, BroadcastChannel, localStorage, native DOM, etc.).<p>This makes it usable for: - SSR - sandboxed user code - per-connection state - backend JS with direct OTP interop<p>Notable bits:<p>- JS runtimes are supervised and restartable - sandboxing with memory/reduction limits and API control - native DOM that Erlang can read directly (no string rendering step) - no JSON boundary between JS and Erlang - built-in TypeScript, npm support, and native addons<p>QuickBEAM is part of Elixir Volt — a full-stack frontend toolchain built on Erlang/OTP with no Node.js.<p>Still early, feedback welcome.

Show HN: Create a full language server in Go with 3.17 spec support

Show HN: Create a full language server in Go with 3.17 spec support