AutoHotkey, Python, and Now Rust: How I Decide Which Language to Use

A few weeks back I was sitting there staring at a Rust compiler error for the third time in an hour, and I caught myself thinking: why am I doing this to myself? I have an AutoHotkey script that already does something similar. It works. It took me twenty minutes to write.

And then the Rust version finished processing a batch of audio files at 212 times realtime, and I stopped complaining. 😊

That moment is basically this whole article. After years of building nearly everything in AutoHotkey, I started branching out. Some Python. Now Rust. And the question I kept bumping into was not “can I learn this language?” It was “how do I know WHEN I should reach for something other than AHK?”

Have you ever felt that? You know one tool really well, you suspect you’re using it for jobs it wasn’t built for, but you have no idea where the line actually is.

So I sat down and worked it out. Then I did something I’d recommend to anybody: I took my answer and had four different AI models tear it apart. More on that in a minute, because they caught a mistake that would have cost me real time. Now on with the show…

Choose Your Next Tech Stack For the AI Era

The Question Isn’t “Which Language Is Best”

That question is a trap. It leads to arguments on the internet and nothing useful.

The useful question has four parts, and I ask them in this order:

1. What does it have to touch? Windows itself? A web page? A GPU? Files?
2. How am I delivering it? A single .exe? A script? A URL?
3. How long does it live, and who maintains it? Me forever, or the client next year?
4. Does speed actually matter? Usually no. I check this LAST, not first.

That third one is the one I used to skip, and it turns out it’s the one that matters most. More on that below.

Where AutoHotkey Still Wins (And It’s Not Close)

Let me be really clear, because I don’t want anyone reading this and thinking I’m walking away from AHK. I’m not. It’s still where most of my work happens.

For these jobs, nothing else is even in the same building:

• Global hotkeys. Three lines in AHK. Fifty in C#. Good luck in Go.
• Driving another Windows app. UIA, window control, sending input. This is home turf.
• COM automation. Excel, Outlook, whatever. Terse and readable.
• Quick internal tools. The stuff you build for yourself on a Tuesday afternoon.

For internal automation I’ll still finish 5 to 10 times faster in AutoHotkey than in anything else on this list. That’s not nostalgia, that’s just measuring. Speed of BUILDING is a real kind of speed, and it’s the one that usually matters. ⚡

The Part I Was Missing: When to LEAVE

Here’s where the AI review earned its keep. My first draft of all this listed strengths and weaknesses for every language, and one of the models pointed out that I never actually answered my own question. I described the languages but never said when to leave AutoHotkey.

Ouch. Fair. So here it is. I move up when ANY of these are true:

• The script passes roughly 500 to 1,000 lines and keeps growing
• It needs real concurrency (AHK is effectively single-threaded)
• It needs tests that run automatically
• It has to run unattended for long stretches
• The client will maintain it, not me
• I need a real compiled binary that doesn’t unpack back into source

That last one surprised me when I thought it through. An Ahk2Exe file doesn’t really compile anything, it bundles the interpreter. Anybody who wants your source can get it back out in about a minute. For most of what I do that’s completely fine. For a paid tool going out to a client, it’s worth knowing.

The Short Version of Each Language

The Rule That Fixed Everything: Wrap, Don’t Rewrite

This is the one that took most of the stress out of the decision, and honestly I feel a little dumb for not seeing it sooner.

You don’t have to pick ONE language per project.

I kept framing this as “should this tool be AHK or Rust?” when the real answer is usually both. AutoHotkey stays as the Windows glue, the hotkeys, the window handling, the GUI. And when there’s a slow part, that slow part becomes a small Rust or Go DLL that AHK calls with DllCall. Or a little compiled command-line program that AHK shells out to.

The workflow I’ve settled into:

1. Prototype in AutoHotkey. Fastest way to find out if the idea is any good.
2. Find the slow part (there’s usually exactly one).
3. Move ONLY that part to Rust or Go as a DLL or a small .exe.
4. Keep AHK driving the whole thing.

This is not a compromise or a fallback. It’s how a lot of shipped software actually gets built. And it means “learning Rust” stops being a scary rewrite and becomes “write one small function that does one fast thing.” Way less intimidating. 🚀

How Well Will AI Write It? That’s a Real Criterion Now

Here’s something that would have sounded ridiculous five years ago: how well AI writes a language is now part of how I choose it.

Don’t get me wrong, I’m not letting AI pick my stack. But if I can build something three times faster in a language because the AI is fluent in it, that’s real. Three things predict it:

• How much code exists to learn from. Python and TypeScript, tons. AutoHotkey, not much.
• Can the AI check its own work? This is the big one. Rust and C# have brutal compilers that catch mistakes instantly.
• Version confusion. Python 2 vs 3, and AHK v1 vs v2, both poison the training data.

That middle one flips the ranking in a way I didn’t expect. If you’re just chatting with an AI, Python wins because there’s so much of it out there. But if you’re running an AI agent that writes code, compiles it, reads the errors, and fixes itself in a loop? Then Rust and C# actually pull ahead, because the compiler tells the AI exactly what’s wrong. Python fails at runtime, which is much harder to diagnose.

And AutoHotkey? No compiler. No type checking. No test framework. That means an AI agent has almost no way to verify its own work. That’s a big part of WHY AI writes weaker AHK, and it’s not something more training data alone fixes.

The Boring Stuff That Decides More Than the Language Does

If you ship tools to other people, this section matters more than half the comparison table above. It sure did for me.

• The SmartScreen warning. An unsigned .exe throws a scary Windows warning, and your client will report that as “your tool is broken.” The standard advice is to go buy a code signing certificate. I’ll be honest, I think that advice is mostly oversold. The certificates are EXPENSIVE, the whole reputation system is murky, and a fresh certificate often doesn’t stop the warning anyway until it has built up enough downloads. You can spend real money and still watch the same scary screen pop up. My approach is simpler: tell the client the warning is coming, show them the “More info” then “Run anyway” click, and hand it over through a channel they already trust. Setting the expectation beforehand solves the problem better than a certificate does, and it costs nothing.
• Antivirus false positives. This one is not equal across languages. AutoHotkey and Python .exe files get flagged FAR more than native Rust, Go, or C# builds. If your client has aggressive managed antivirus, test that early.
• Can they read your source? AHK unpacks instantly. Python decompiles. C# decompiles in seconds with free tools. Rust and Go are real machine code and much harder to reverse.
• Who maintains it in two years? Nobody can hire an AutoHotkey developer. That can be leverage if you want the ongoing work, but it should be a choice, not an accident.

Where I’m Headed

So here’s my actual plan going forward:

• AutoHotkey stays the default. Hotkeys, window work, app automation, internal tools, prototypes. That’s not changing.
• Rust for the heavy lifting. Audio processing, batch jobs, anything where speed genuinely matters. Usually as a DLL that AHK calls.
• Python when the library IS the product. AI work, document handling, data.
• TypeScript and Cloudflare Workers for anything phone-shaped. Already doing this and it works great.
• C# is my biggest gap. It’s the honest graduation path for polished client-facing desktop apps. Real GUIs, real threading, real tests, and AI writes it well.
• Tauri is the one I’m most curious about. Rust backend, web front end, 3MB to 10MB .exe file. It sits right where my Rust learning and my existing web work overlap. It might get me a shippable GUI faster than learning C# and XAML would.

One thing I’ve learned from all of this: the goal was never to replace AutoHotkey. It was to stop using AHK for jobs where something else finishes faster, ships cleaner, or holds up better over time. Knowing where that line sits makes me BETTER at AutoHotkey, not less committed to it.

Go Have Your Draft Grilled

Quick side note that might be the most useful thing here. I wrote my version of all this, felt pretty good about it, and then sent it to four different AI models and asked them to find what was wrong with it.

They caught a flat-out factual error (the C# thing), an entire tool I’d never heard of (Tauri), and the fact that I never answered my own central question. All four independently flagged the same problems, which is exactly the signal you want. When four models that disagree about plenty all point at the same paragraph, that paragraph is wrong.

It took about ten minutes and it saved me from confidently telling people something untrue. I highly recommend making that a habit for anything you write, build, or plan. It turns out being wrong quickly and cheaply is a superpower. 🤖

Where to Start With Each One

If any of the above made you curious, here’s where I’d actually send you. These are the official docs and the genuinely good free starting points, not a pile of random tutorials.

• AutoHotkey v2: the official v2 docs and the AutoHotkey forums, which are still one of the friendliest communities out there.
• Python: the official tutorial to learn it, plus uv for package management (it made Python tooling genuinely pleasant) and PyInstaller when you need an .exe.
• Rust: The Rust Book is free and excellent. Rustlings gives you small exercises if you learn by doing. For Windows work specifically, the windows-rs crate from Microsoft covers the whole Win32 API.
• C#: Microsoft’s Tour of C# to start, then WinForms for GUIs. If you want to do UI automation the way AHK does, look at FlaUI and Vanara (comprehensive Win32 bindings). Without those two, C# automation is a lot more painful than it needs to be.
• Tauri: the getting started guide. If you already build web front ends, you’re most of the way there.
• Go: A Tour of Go runs right in your browser, and Wails is Go’s answer to Tauri if you want a GUI.
• PowerShell: the official docs. Already on every Windows machine you’ll ever touch.
• TypeScript: the TypeScript Handbook, and Cloudflare Workers if you want to put something on the web without managing a server.

How About You?

Have you hit the wall where your favorite tool stopped being the right tool? Did you push through in the language you knew, or did you branch out? I’d genuinely like to hear about it, especially if you found a combination that works well together.

And if you’re sitting on the fence about learning something new: try the “wrap, don’t rewrite” approach. Write ONE small fast function in a new language and call it from the AutoHotkey you already know. That’s a Saturday afternoon, not a career change. Life is an experiment. Go run one. ⚡

P.S. The single biggest takeaway from this whole exercise: you don’t have to pick one language.

Keep AutoHotkey doing what it’s great at, and let a small compiled helper handle the one slow part. That one idea removed almost all of the pressure from the decision, and it’s the approach I’d hand to anyone asking the same question.

Want to get sharper with AutoHotkey while you’re at it? Check out the courses and free content over at the-Automator.com.