💾 Archived View for perplexing.space › 2021 › re-deno.gmi captured on 2022-04-29 at 11:17:26. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
2021-02-27
adiabatic was kind enough to read and respond to my recent whining about NodeJS:
2021-02-26: People don’t like the Node ecosystem
I had a look at Deno (without trying it, mind you) and have tried to organize my thoughts.
One feature I find interesting is the permissions system. I like the sort of capability management provided by pledge and unveil in OpenBSD and the addition of /something/ is better than nothing. One thing I wasn't able to answer to my satisfaction is permission management in 3rd party code. For example, if I grant my own application network access, do any libraries I use inherit that same permission? I would worry about a kind of permission-creep if that were the case (but like I said, I don't know if that is really the case).
One thing that is a little off-putting to me personally is the pervasive use of the right kind of lingo without much information to back up those claims. I understand the use of shibboleths but if they are going to throw around phrases like "audited" and "reviewed" without telling me what those things mean specifically I am liable to be dubious. This entire project after all comes from the "lgtm" code-review crowd that landed us with the mess we're in, doesn't it?
The inclusion of a set of standard libraries should hopefully alleviate much of the trouble in NodeJS around npm. If a base level of functionality is built-in then fewer projects will require 800 dependencies of various overlapping functionality. Simply moving everyone to a known baseline feels like a logical step forward from NodeJS.
Reading more about the standard library made me laugh though. I won't say I was especially excited about Deno but the following starts to feel absurd:
deno_std is a loose port of Go's standard library. When in doubt, simply port Go's source code, documentation, and tests. There are many times when the nature of JavaScript, TypeScript, or Deno itself justifies diverging from Go, but if possible we want to leverage the energy that went into building Go. We generally welcome direct ports of Go's code.
Which, taken uncharitably, means: Using Deno means writing TypeScript (compiled to JavaScript) run on V8 (written in C++) via bindings and plugins for V8 (written in Rust) leveraging a standard library (ported from Go).
In my experience people tend to underestimate how much they should know about their platforms. If you write Python I think you probably should know how CPython works at least generally. This is doubly true if you are looking for performance in the form of something like NumPy. By layering so many languages and platforms I think Deno is almost guaranteeing that no one is going to be able to know much about their whole platform.
I have used TypeScript professionally and while it does clean up many typing problems with JavaScript it similarly introduces a new (huge) potential amount of complexity in the number of options and avenues available. I think there are enough knobs and gotchas to make V8 itself an area of expertise but I don't think there are many V8 experts.
Deno seems to have pursued the idea that the addition of more software and layers can solve the problems presented by NodeJS. I personally don't see that as a viable solution and am not optimistic that Deno will solve the sorts of fundamental issues I have with the NodeJS ecosystem.
I do want to thank adiabatic for the response though; while I had heard of Deno I never really dug into it. This has been a nice chance to learn something and try to clarify some of my own thoughts on the direction of both languages and runtimes. It turns out many of my thoughts are ill-formed and I'm not yet in a place where I can make the kinds of cogent argument that I personally find persuasive.