Deno is a carbon copy of Golang, a decade too late
Newly released Deno 1.0 does not make any sense to me
10 years ago we saw both Node.js and Golang release for the first time. Node.js was adopted at a rapid rate by scripters fed up with the old PHP/Apache set-up. Golang had a slower start to its adoption, opting for a co-routine design from the very start, probably discouraging unfamiliar users. It has since accelerated its adoption significantly, as co-routines has become increasingly mainstream and accepted.
Node.js on the other hand began with nothing but callbacks, adding promises later on and finally async/await co-routines. While Node.js has aged with this transition from callbacks to co-routines, Golang has had co-routines since day 1 and looks essentially identical to the day it was first released. Its design has aged well over the years.
Furthermore, Golang has had very competitive runtime performance and no need for native plugins since first release. Compiling a Golang program is wickedly fast, mostly in the millisecond realm and often times faster than the start-up time of Node.js. You hit “go run source.go” and it jumps into action within shockingly short wait time.
The similarities between Deno and Golang are undoubtedly obvious, and I would even make the claim Deno is a carbon copy of Golang in every single way, except that it runs TypeScript instead of Golang sources. Deno’s CLI works the same way as Golang’s and their standard libraries are identical in many ways — the Deno docs even says this (verbatim quote):
deno_std is a loose port of Go’s standard library. When in doubt, simply port Go’s source code, documentation, and tests.
Here’s a list of obvious similarities:
- Both Golang and Deno are statically typed with a garbage collector
- Both Golang and Deno fetch sources from URLs and lacks a package manager
- Both Golang and Deno use co-routines for async tasks
- Both Golang and Deno have the same exact standard library design and content — Deno docs even refer to Golang docs
- Both Golang and Deno operate using “go run source.go” and “deno run source.ts” kind of CLI.
- Both Golang and Deno lack “real” threads; they abstract the concept upwards.
With these similarities there must be some big incentive to even consider Deno — if you like the design, then why wouldn’t you just go with Golang? What’s in it to consider Deno other than the newly created hype? What exactly do you get with Deno, in practical terms, that you won’t get with Node.js?
Does it perform really slick? Well, no, not at all. Looking at performance of the different platforms, reports do not make it any more sane to invest in Deno. Even their own release post says that Deno performs about 2/3 of Node.js and my own graphs show similar results, here comparing with Golang:
It doesn’t make any sense to me, why people would want to dive in head first and spend their time and money on a platform that doesn’t scale. Whatever you build in Deno, some consultant or contractor will have to tear down and rebuild in the future when it becomes clear it does the job very poorly.
Productivity means nothing if what you produce is garbage; you’ll just have to tear it down and rebuilt it better anyways
If you have any memory at all about the story of Node.js — you’d remember very clearly that the sole purpose of Node.js was performance. Everyone and their mother was on about how Node.js “performs better than C”. I have extremely strong memories about this flood of nonsense that showered us a decade ago.
So what exactly is sane about going back to worse, a decade later, when we already know Golang to scale much more favorably? Why someone would opt for the shitty clone rather than the original, proven thing, it boggles my mind. It really does. And if you dislike Golang that much, use Rust or whatever.
That’s all, thanks.