Funny, I thought it was the Go-fication of JavaScript. Look at the 'contributing' section of their stdlib:
"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."
Re:What the Hell Is a Deno?
by randombytes6869 on Sunday June 07, 2020 @07:12AM
(#23446534)
For Deno this seems like a very good choice. Pick the good parts from Go and reuse them. I applaud Deno for going its own way with the module system though... That's been a hot topic in Go for a very long time
Deno -> Java
Runtime security options -> Security Manager.
URL based packages with simple HTTP-> Maven works same way.
Bigger standard library -> Java's is huge.
Types -> Java, yes.
Single executable -> Fatjars.
All the features mentioned in this article have been in Java over a decade. Its relieving to see a JS runtime that finally gives in to enterprise niceties. Us Java devs like to crap on JS for reasons besides being "boomers". The features Deno brings were all real reasons to use Java instead of JS up until this point.
Now if they would only fix threading, I would consider Deno/JS a real contender for backend dev