[randombytes6869]

Deno is the Java-fication of JS. I'm sure there will be Node-like tide of "JS is better than Java now that we have X" even though Deno brings JS closer than ever to Java. Despite being cynical, I don't think its a bad thing. Java does a lot of things right.

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

[SPBS]

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."

[randombytes6869]

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