I nearly did this, but then I swapped to writing native desktop apps and egui - Rust is still worth it.
I've stopped using Tauri and gone with 100% egui. It's cross platform and excellent, and if you give it design constraints it will look beautiful.
Check out my 100% adobe clean room reimplementations:
https://github.com/storytold/filmcraft
https://github.com/storytold/photocraft
https://github.com/storytold/drawcraft (going to rename this vectorcraft)
The #1 thing for the Rust project to do is make Rust faster to compile.
Rust is the agentic AI language. It just needs to lean in and go faster.
Checked out your GitHub profile. This is an insane amount of LLM usage. You created 7 full-blown apps, and each of them is very recent. The earliest commit was only 2 days ago.
I'm normally against fully vibe-coded apps, but at this point, I'm just impressed.
Be impressed when professionals actually test them and find them competitive. Maybe these apps are good, maybe they aren't, absent real data just being vibe-coded doesn't imply quality and a claim like "I one-shotted Photoshop" should cause alarm even if you're all in on GenAI.
At some point we have to move on from amazement at what these models can do to actually caring about the quality of the product.
> The #1 thing for the Rust project to do is make Rust faster to compile.
#0 get rid of the orphan rule
What's the orphan rule?
Rust doesn't let you write an impl a trait that wasn't declared in your crate for a type that wasn't declared in your crate. At least one of the two needs to be locally declared. This makes splitting projects into multiple crates harder than it could be, but on the other hand it makes the crates ecosystem less brittle than it otherwise would be.
Some people propose relaxing this rule for "workspaces" (local projects with multiple crates that are not published individually). I haven't researched whether that would be technically feasible.
It absolutely should be relaxed for workspaces.
Workspaces are a great way to architect larger projects and monorepos, and they'd at least be internally consistent.
If you built two impls, your compiler wouldn't know which to pick. Or to phrase it differently, if you wanted to be able to choose the right one, it wouldn't be 'orphan impls', it would be 'orphan impls plus some selection mechanism'. E.g. Scala implicits. And once you have Scala implicits, non-orphan impls probably start looking like a pretty sweet alternative!
btw. That could actually make it slower to compile. The compiler uses the orphan rule to short circuit some checks IIRC.
Nevertheless, people in the project are trying to figuring out a way to relax the rule while still maintaining coherence, so this might happen some day.
there are good reasons, obviously, but it's my #1 PITA, #2 is comptime type introspection (it looks like @yara-blue is making some progress, so fingers crossed)
BTW: cheers, we should grab a beer some day :)
We should ;)
Looks great. It's early but how well do they work? Comparable to FOSS apps yet?
Also it says egui is immediate mode, does that use a lot of {C,G}PU or have any other issues?
Very cool projects! I agree, desktop apps are one of the areas that Rust beats Go. It's too bad though, since I feel anything with a heavy GUI like this can benefit from a rapid iteration cycle which is painful with Rust.
Are agents able to control these well? I saw vector craft mention MCP and a command api. Whats the command api? No CLI it sounds like.
Working on it! That's the intent for all of these.
Going to do Toon Boom and a few others too and build them as a suite.
Wow those are some nice applications! Thanks for sharing this!
These are great
!!! WOW !!!
Machine code is the ultimate agentic AI language, we will eventually get there, we are in the middle of the transition to 5 GLs.
Humans need to understand the code.
It is right there in the 5 GL language, unless you want to convince us that all your PR come with the corresponding Assembly that the compiler generated, while doing all the compiler passes with PhD level knowledge from everyone that has worked in LLVM since 2003.