Why Desync Only Supports Python

Yeah, you can scrape with Node.js. Puppeteer, Playwright, Cheerio, whatever. The tooling exists. You’ll get your data. But then what? You’ve got this pile of messy HTML, broken JSON, CSV files that lie about their encoding. Now you need to actually do something with it.

Processing is the real work

This is where Python stops being a preference and becomes obvious. You need pandas for the data wrangling. All those libraries that just work because everyone in data has been using them for years.

It’s not about the language being “better” in some abstract way. It’s that the code feels right. Transformations read like what they’re doing. When you’re knee-deep in a parsing nightmare at 2am, you want the language to get out of your way.

Making Desync Python-only was a choice. Honestly, it was a filter. We wanted people who understood that scraping is the easy part. The hard part is everything after: cleaning, joining, pipeline reliability, not breaking when the internet does something weird (always).

Turned out we were completely right about this.

Our customers already had Python pipelines. Whether they picked Python deliberately or just ended up there, they had notebooks and ETL scripts and analysis workflows. All in Python. Desync just slotted in. We didn’t have to convince anyone to rewrite their entire stack.

So when someone asks “why only Python?”, that’s not a bug. That’s the point. If you’re asking that question, you probably haven’t built a serious data pipeline yet. And that’s fine, but we’re building for the people who have.

Language is a tool. Every job has a better tool.

I don’t believe in universal “best” languages. I believe in picking the right tool for what you’re building.

JavaScript? For websites, it’s the obvious choice. React, Next.js, component libraries like shadcn, Tailwind. The ecosystem makes shipping fast. Python’s web story (Django, Flask) feels clunky in comparison. For quick prototypes, Streamlit or Reflex work. For real web products, just use JS.

Rust I learned for fun. Now I’m getting deeper and seeing Tauri, Leptos, WASM compilation. It’s exciting. Would I prototype in Rust? No. But for things where performance matters, or type safety prevents real disasters, or you need correctness under load? Yes.

How the language feels matters

It’s not just about getting the task done. It’s whether the language fights you or helps you think.

Which brings me to R.

R is a masterclass in bad design

When I say I hate R, I mean it. Not in a casual “this is annoying” way. In a “this language actively sabotages you” way.

1. Indexing starts at 1. Every other language I use starts at 0. Constant mental overhead. Off-by-one errors every time you switch contexts.

2. Naming inconsistency. The standard library mixes snake_case, camelCase, and dot.notation randomly. No pattern. Just pick one.

3. Assignment operator chaos. You’ve got <-, =, ->, <<-, ->>. They all behave differently. The double arrow versions reach into parent scopes and create invisible bugs.

But the worst part? Silent errors. Vector recycling repeats short vectors to match longer ones with no warning if lengths divide evenly; your math is wrong and R says nothing. Type coercion silently converts invalid data to NAs (most people just suppress the warning). Factors drop unused levels without telling you. Partial argument matching guesses what you meant, sometimes works, sometimes fails. These aren’t edge cases; they’re core design choices that corrupt your data quietly and let you find out in production.

And RStudio makes it worse. The IDE keeps everything in memory even after deletion until you manually trigger garbage collection. Fresh sessions consume 2GB+ before you write code. Work with moderately sized datasets and watch your system freeze as RStudio eats all available RAM. The workspace restoration feature auto-loads previous objects on startup, silently consuming gigabytes. R’s garbage collector waits to free memory, sometimes indefinitely. You think you’ve cleaned up but your RAM is still maxed.

Why Python Actually Matters Here

So given we use Python to interact with our scraping system, what can be inferred? Let’s say tomorrow a competitor builds exactly what we did, but in R. Say it’s technically successful. That competitor is still at a massive disadvantage because they’re locked out of the entire Python ecosystem. Every data pipeline, ML model, ETL workflow, notebook, and processing library their users already have? Incompatible. Community matters. Network effects are real.

Here’s a more fun example. Hello, vibe coders. Welcome. Prompt your GPT to rebuild what Desync does, but use Rust or WASM or Lisp or whatever esoteric choice makes you feel special. See what happens. You’ll get something that technically works if you are very lucky and is practically unusable long term. No dev with a sane brain would want to begin understanding and explaining that slop.

Some of my favorite Rust projects understand this. LanceDB, Polars, Convex; all blazingly fast, all written in Rust, all provide Python interfaces. Why? Because Rust looks scary. Because users want to write simple functions not wrestle with borrow checkers. Rust is the glue. The performance layer underneath a usable surface.

We optimize for user experience in Python and speed things up in lower-level languages when needed. That layered architecture, that matryoshka doll structure, is how software was built, still is built, and will always be built. There will always be abstraction. I know libraries that map Rust functions or Lisp macros to Python.

End of the day, readability is what matters. If your users can’t understand it, you’ve failed regardless of how fast it runs.

Why Learning Other Languages Actually Matters

Exploring languages is important because it prevents the blub paradox. You can’t see what’s possible if you only know one way to think. Learning new languages brings concepts from one to another. At the end of the day, programming languages tell the computer what to do. The better you get at that skill, the more you can build.

Take Jackson from Desync. He’d never heard of Apps Script before. It took him 24 hours to learn it and ship v1 of our Google Sheets integration. How? He knows JavaScript, so he figured out Apps Script fast. That’s not genius; that’s range. Once you’ve learned enough languages, picking up the next one becomes pattern recognition.

Language choice absolutely matters. The community behind it matters more. The JavaScript community optimizes for making things look nice. Python optimizes for logic and getting answers. Rust optimizes for performance and correctness. Lisp is for people who think in recursion and macros. And R? R is for people too lazy to learn Python. Sorry if that offends you.