Pure Rust Rewrite of Photoshop, 72K Stars in One Month

This week a GitHub project made me do a double take.

storytold/photocraft is Photoshop rewritten from scratch in pure Rust. It was created on September 30, and in less than a month it has 71,991 stars and 12,719 forks.

It is not a wrapper, not an Electron shell. It is a native application, 100% Rust. Layers, masks, adjustment layers, layer styles, text, vectors, and brushes; it can read and write real PSD files.

What catches my attention more is that it is not an isolated case.

One person rewrote five commercial applications

The same author's project matrix, all repositories created within a month: PhotoCraft 72k stars against Photoshop, PdfCraft 17.5k against Acrobat, FilmCraft 15.9k against Premiere, WordCraft 15.8k against Word, LightCraft 14.5k against Lightroom, roughly 136k stars in total.

This combination sends a much clearer message than any single project: the moat around desktop software may not be as deep as people think.

Photoshop, Acrobat, Word and similar products have been around for twenty or thirty years, and their moat has always been understood as "feature complexity." But part of that complexity is historical baggage, and the other part is genuine engineering difficulty. AI-assisted coding has pushed down the cost of the historical-baggage half; the remaining half is the real threshold.

Why Rust

Three reasons, in order of practical importance.

First, zero GC pauses. The thing image editing fears most is the main thread stalling. Java/C# have GC, Go has STW optimizations but still needs a scheduler, C++ has no GC but memory safety depends on people. Rust's ownership model resolves deallocation at compile time, and there is no runtime reclaimer.

Second, predictable memory usage. A single 8000×6000 RGBA8 layer is 192MB; add undo stacks, thumbnails, and caches and it easily reaches several gigabytes. Rust's explicit memory management lets you account for every block.

Third, cross-platform consistency. The same code compiles to macOS, Windows, and Linux with no runtime dependency. For an open-source project, that directly determines how many people can actually run it.

The real difficulty is in the file format

The UI is the easiest part. PSD is the hard part.

PSD is a layered format. A single file contains all of these at once: the layer structure tree, pixel data (possibly RLE-compressed or Zip-compressed), blend modes, adjustment layer parameters, layer styles (drop shadow, stroke, gradient overlay, each with its own parameter set), vector masks, text layers (keeping editable font and typography information), and smart objects.

Being able to "read and write" means bidirectional compatibility. Reading has to tolerate malformed data written by various historical versions; writing has to guarantee Adobe software can open the result. AI acceleration cannot compress this workload much; it has to be done byte by byte against the format specification.

This is the key point in my judgement of how far this project can go. 72k stars prove that "this is something people want"; they do not prove that "this is done."

How image processing is actually written in Rust

Concrete example. The most common layer blending operation is per-pixel traversal, and rayon parallelizes it in one line:

use rayon::prelude::*;

/// Parallel brightness adjustment, RGBA8 buffer
pub fn adjust\_brightness(buf: &mut \[u8\], delta: i16) {
    buf.par\_chunks\_mut(4).for\_each(|px| {
        for c in 0..3 {
            let v = px\[c\] as i16 + delta;
            px\[c\] = v.clamp(0, 255) as u8;
        }
        // alpha channel stays untouched
    });
}

par\_chunks\_mut(4) splits the buffer into 4-byte chunks (one pixel), and for\_each dispatches work to a thread pool. A 192MB layer on an 8-core machine can run in tens of milliseconds. The same logic can be done with C++ and OpenMP, or Python and NumPy, but Rust's benefit is that you do not manage thread safety; the compiler has already checked Send/Sync for you.

Adjustment layers are more complicated to implement because they are non-destructive: original pixels cannot be changed, and the adjustment chain is applied in order at render time. This is more like a small expression evaluation engine. Each node implements an Adjustment trait. The benefit is that the adjustment chain can be dynamically extended, removed, and reordered, and a future GPU backend (wgpu) can be added without changing business logic. The cost is a virtual function call per pixel; for real production use you would switch to enum dispatch or batched SIMD. Open-source projects usually choose correctness first and optimize performance later.

Two other projects worth watching this week

magpie ⭐20,264

A local gateway written in Go. A small icon in the menu bar controls which model each agent uses: Claude Code connects to Kimi, Codex connects to DeepSeek, Gemini CLI connects to GLM, OpenCode connects to your ChatGPT plan. When quotas run out it automatically switches accounts.

For developers who subscribe to several models at once, the pain point it solves is concrete: no code changes, no editing a pile of dotfiles. Just redirect environment variables to the local gateway:

export ANTHROPIC\_BASE\_URL="http://127.0.0.1:8787"
export OPENAI\_BASE\_URL="http://127.0.0.1:8787/v1"

After that, Claude Code / Codex both go through the local gateway, and you switch backends from the menu bar
====================================

Architecturally it is a conventional reverse proxy plus routing layer. What is interesting is the product positioning: it pulls "model selection" out of code configuration and turns it into a system-level switch.

Strata ⭐31,220

A C++ inference engine with a plain goal: let consumer GPUs run Qwen3.8-Flash-Next. One-click install on Windows/Linux/Mac, starts a local API compatible with OpenAI and Anthropic, and supports image input.

Using it is just the standard OpenAI SDK:

from openai import OpenAI

client = OpenAI(
    base\_url="http://127.0.0.1:8080/v1",
    api\_key="local", # local services usually do not verify
)

resp = client.chat.completions.create(
    model="qwen3.8-flash-next",
    messages=\[{"role": "user", "content": "What is the difference between a PSD layer mask and a clipping mask"}\],
    max\_tokens=512,
)

print(resp.choices\[0\].message.content)

For cost-sensitive teams, this arithmetic is worth doing carefully. A 7×24 always-on agent in the cloud can cost more in one month than a 4090, and it comes with quotas and rate limits. Local inference costs first-token latency and limited concurrency, but neither is fatal if your agent runs batch tasks.

Realistic impact on developers

The capital markets news this week was scary: the Philadelphia Semiconductor Index fell 12% in six trading days, evaporating about $1 trillion; Meta disclosed $825 billion in spending commitments; CDS hit an all-time high. These numbers have no direct relationship to writing code.

But one thing does: when budgets tighten, only projects whose ROI can be calculated survive.

For the past two years, "try AI first" was acceptable. Now it is not. Technology choices will be based more on cost than on parameters. This is good for local inference and open-source tools, and pressure for products that depend purely on APIs.

Two corroborating items landed the same day. Amazon CEO Jassy said that for AI to spread through enterprise software, costs need to drop to one-tenth of current levels. Moonshot AI released Kimi K3.1 Pro, with a 3-trillion-parameter scale and programming and agent benchmark scores that surpass GPT-6. On one side capability keeps stacking up; on the other, buyers demand a tenfold price cut. The gap in between can only be filled by inference efficiency and local deployment.

As a side counterexample: JCET this week raised its 2026 investment plan from 11.01 billion to 18.2 billion, an increase of 65%, with the money going mainly into advanced packaging. The stock can fall 12% in a week, but production lines take 18 to 24 months to build. Corporate decision cycles and market sentiment cycles are completely different things, and technology selection is the same: do not change your architecture based on one quarter's mood.

Finally, two technical questions

First, is your team running AI purely through cloud APIs, or have you started mixing in local inference? If you have, roughly how much did costs drop, and how much did latency rise?

Second, do you think rewriting desktop software in Rust is a repeatable path, or a one-time burst of open-source enthusiasm? I lean toward repeatable: PhotoCraft's real value is not "yet another Photoshop replacement"; it is proof that "pure Rust + a modern rendering pipeline" can compress the development cost of this class of software down to what a small team can bear.

Pick a side:

A. Worth it; next year will see more commercial software rewritten in Rust

B. Not worth it; star counts do not mean maintainability, and two years from now it will be a mess

C. Depends on the category; editing software works, collaboration software does not

Reply in the comments with a letter and your reasoning. Anyone here who has worked on PSD or video editing/decode, I would like to hear the real pitfalls you hit.