a devlog on machines & languages

30 Deno: Expectations and Outcomes

Someone occasionally posts something about Deno on HN1 and I wonder about the original promise and the execution, and how it affected my own projects.

I used to write all my tooling in Java till 2019/20 because that was what I have been using for the past two decades or so. The language is irritatingly verbose, but you never had to worry about lack of infrastructure dependencies like crypto or databases, or worry that your code would stop compiling with the new OpenJDK release. But I eventually got bored of all the ceremony for simple tools when you could do stuff like #!/usr/bin/env python3 on Linux.

I have hated the Python and Node ecosystems (venv/pip/poetry/npm/npx/tsc/tsx/node/wtf) because of poor architectural hygiene. They are basically stuff bolted on top of one another without any planning or foresight. Yes, you can get work done quickly (and to Node's credit, it is fast), but at what cost?

This is why Deno came as a breath of fresh air with its single binary, native TS support and URL based imports. I developed a lot of stuff between 2020-2022 using Deno including a half-completed compiler/vm project called ut and was starting new projects in it even in early 2024.

But the breakage started pretty early and continued unabated even beyond 1.0. It was fine when I was actively developing my tools, but something that was working six months ago would suddenly fail because of rearranged namespaces, or deprecations. And something as critical as databases did not have a good story. Using sqlite3 was a pain even with dyedgreen's WASM-based deno-sqlite. I did not have time to keep track of all this and was looking for a way out, and so I froze the binary I was using, avoided almost all dependencies and stopped developing new stuff with Deno.2

I picked up Python in 2024 when I was briefly thinking of helping out with upgrading the Ambuda codebase. But that never went anywhere. However, I discovered uv in the process and moved to Python as my main tool-writing language. uv made it bearable.

Python is a beautiful language at one level and insane at another. I have ranted about this on a couple of Discord groups as I discovered footgun after footgun and this insanity (and lack of speed) is what triggered my desire to contemplate building Ajagara.3 This is a substantial topic that cannot be covered in a few paragraphs. I will write about it one day, perhaps when Ajagara is ready.

More recently, I have moved to node+TS for any project that needs a frontend and backend because I do not want to maintain two sources of truth as far as business rules and API contracts are concerned. You sometimes have to tolerate some insanity in order to get work done.

Deno was not really a this-is-a-runtime-to-write-tools project by a hobbyist or nonprofit. So, there was always this expectation that a commercial side would emerge just like Modular and Astral and so many other tooling/runtime companies. So it was not a big surprise when they eventually pivoted to adding Node support and compatibility, and looked for revenue of some kind. I also think that the emergence of Bun played a not-so-insignificant role in this.

So, for a brief moment, we had this nice, baggage-free runtime that supported a language like TS and let us write system tools in it.

Update:

Within a couple of days of writing this log, news has arrived that the Deno team is joining Cloudflare. So Deno development has officially ended, and "bug fixes and security updates" will be provided for one more year.

  1. Friendship ended with Deno, now Node is my best friend ↩
  2. This was around 2024. I did some spring cleaning earlier this year and updated the frozen binary to 2.7.12 because the one after that caused deno-sqlite to stop working. ↩
  3. WIP. A language, compiler and runtime to replace Python: the Ajagara system with the Aja programming language and the Gara virtual machine. ↩