Hacker News

The JIT + tensor model ends up being a really nice way to express light transport all in simple python, so I reimplemented some new research papers from SIGGRAPH like REstir PG and SZ and it just works. instead of complicated cpp its just a 200 LOC of python.

https://huggingface.co/sweepai/sweep-next-edit-1.5b) or try it in our JetBrains plugin (https://plugins.jetbrains.com/plugin/26860-sweep-ai-autocomp...).

Next-edit autocomplete differs from standard autocomplete by using your recent edits as context when predicting completions. The model is small enough to run locally while outperforming models 4x its size on both speed and accuracy.

We tested against Mercury (Inception), Zeta (Zed), and Instinct (Continue) across five benchmarks: next-edit above/below cursor, tab-to-jump for distant changes, standard FIM, and noisiness. We found exact-match accuracy correlates best with real usability because code is fairly precise and the solution space is small.

Prompt format turned out to matter more than we expected. We ran a genetic algorithm over 30+ diff formats and found simple `original`/`updated` blocks beat unified diffs. The verbose format is just easier for smaller models to understand.

Training was SFT on ~100k examples from permissively-licensed repos (4hrs on 8xH100), then RL for 2000 steps with tree-sitter parse checking and size regularization. The RL step fixes edge cases SFT can’t like, generating code that doesn’t parse or overly verbose outputs.

We're open-sourcing the weights so the community can build fast, privacy-preserving autocomplete for any editor. If you're building for VSCode, Neovim, or something else, we'd love to see what you make with it!

https://www.anthropic.com/constitution

The core insight: Canvas2D is fundamentally CPU-bound. Even WebGL chart libraries still do most computation on the CPU. So I moved everything to the GPU via WebGPU:

- LTTB downsampling runs as a compute shader - Hit-testing for tooltips/hover is GPU-accelerated - Rendering uses instanced draws (one draw call per series)

The result: 1M points at 60fps with smooth zoom/pan.

Live demo: https://chartgpu.github.io/ChartGPU/examples/million-points/

Currently supports line, area, bar, scatter, pie, and candlestick charts. MIT licensed, available on npm: `npm install chartgpu`

Happy to answer questions about WebGPU internals or architecture decisions.

I started Muky in April 2024. Classic side project that got out of hand. We have two kids - the younger one is happy with the Toniebox, but our older one outgrew it. She started asking for specific songs, audiobooks that aren't available as figurines, and "the music from that movie."

We had an old iPad Mini lying around and already pay for Apple Music. Felt dumb to keep buying €17/$20 figurines for 30-45 minutes of content when we have 100 million songs.

Now at version 4.0 after ~20 updates. Some lessons:

On the hardware vs app tradeoff: Toniebox and Yoto are brilliant for little ones – tactile, simple, no screen needed. But they hit a wall once kids want more. And handing a 5-year-old Apple Music means infinite scrolling and "Dad, what's this song about?" Muky sits in between – full library access, but parents control what's visible.

On sharing: Remember lending CDs or cassettes to friends? Or kids swapping Tonie figurines at a playdate? I wanted that for a digital app. So I built QR code sharing. Scan, import, done. And unlike a physical thing – both keep a copy.

On onboarding: First versions: empty app, figure it out yourself. Retention was awful. Now: 4-step onboarding that actually guides you. Should've done this from the start.

On content discovery: 100 million songs sounds great until you have to find something. Parents don't want to search – they want suggestions. Spent a lot of time building a Browse tab with curated albums and audiobooks for kids. Finally feels like the app helps you instead of just waiting for input.

On going native: Went with Swift/SwiftUI instead of Flutter or React Native. No regrets - SwiftUI is a joy to work with and performance is great. Android users ask for a port regularly. No capacity for that now, but Swift for Android is progressing (https://www.swift.org/documentation/articles/swift-sdk-for-a...). Maybe one day. CarPlay is another one parents keep asking for – going native should make that easier to add, if Apple grants me the entitlement.

On subscriptions vs one-time: Started with one-time purchase. Revenue spikes at launch, then nothing. Switched to subscription – existing one-time buyers kept full access. Harder to sell, but sustainable.

Ask me anything about indie iOS dev or building for kids. App is at https://muky.app if you're curious.