Soremwar

That new bench reporter is really something to look at

Tracking where open resources like timers were invoked is something that is quite literally a game changer

People sleep on how good the Deno test runner is, but I can't for the life of me stress enough how many times the resource leak feature has saved my ass (developer of x/postgres)

"Immutable" in the sense that packages can't be taken down or modified by authors

If you wanna take it a step further, you can always opt in to that lock file with various degrees of strictness as you yourself mentioned

Hence why developers always recommend to use immutable sources when importing modules

They don't though. They transpile it behind the scenes

They are different, currently no Deno registries have dynamic version resolution (no greater than operator). Once you have locked in on a version you are in it for good unless you change it manually

However if the argument is: updating libraries break stuff, that is gonna happen every time in every language. There is no guarantee the next version will just work as the last one did

Reimplement in the way that they change certain rules to accommodate a more "modern JS" feel

And they absolutely use TS for the std library, just not in the runtime itself

Not that simple of a comparison since "data centers" mean a different thing in both cases

You don't need to test a feature that they don't have

Wrong, 1.0 released exactly one year ago, before there was mostly destabilization of the runtime and not really development features

We may have WebGPU powered desktop applications in the near future though. Let's see how things play out, as you daid

There have been multiple test runners built on top of Deno's vanilla testing (through the JSON output feature), those may fit your use case better

The current multi threaded and module isolated model however I think it's good for the great majority of projects, so I'm glad it's built in

IMO this is a terrible idea.

If I have learned anything from working long time with NPM is you can't trust a single command with updating your dependencies and you can't trust developers to respect semver on the long run.

I can't stress how many times I had to review and undo automated dependency bumps because my app suddenly stopped working, and the times I was forced to I had to bump said dependencies in the lock file myself

In a compiled language, where code is compiled once and valid there 'til the end of times this is not even a problem. In an interpreted language where all code is evaluated every time you run your program, this makes automated dependency management an impossible task

Only if you update dependencies, a fresh install would not have such integrity checks, so it's just as vulnerable as Deno hosts to such attacks

No they can't, Deno is JavaScript compliant

For frontend TypeScript I assume you mean TypeScript that doesn't use JS modules but extensionless modules, the TypeScript folks sadly have decided to not bring compatibility here ATM.

You do something like this

  export * as Oak from "https://deno.land/x/oak/mod.ts";
  export * as Postgres from "https://deno.land/x/postgres/mod.ts";

Then you do this:

  import { Oak, Postgres } from "./deps.ts";

Yeah, libraries can't use import maps because import maps are not extensible

You don't ever lose productivity or knowledge on a tool when a new one comes out though. A new thing that people like becomes popular and people start using it, old one becomes less used but it doesn't dissapear.

You only really "switch" to a new tool if that's what you like the most, not because that's what people like now.

They had to remove it from the Deno build process so Deno internals didn't need a compiler. However TypeScript support remains untouched and receives constant updates

This. I cannot stress how important is this for modern app development. Just like Deno doesn't trust any script that is passed to it, no user should trust an app just cause it's installed directly in the system (and I can't believe I lived with that mindset as well). The developers should grow cautious of any tool and library they install, and the user should inspect more often what kind of access is it giving to anything they browse on the web, cause at least there they can block it.

What link?

The thing is that without read/write or net permissions, a malitious script that turns your computer into a mining rig will throw because it can't connect to any server or use your filesystem. We already expose CPU to third party code, doing the same for GPU is trivial in that sense if you remove the possibility to do anything with it without your consent

Already fixed

No matter if you are interested in Deno or not, seeing this amount of features in a year alone gives you an idea of what's to come for Deno in the future

The catch is that it works in a case by case basis. The most used libraries are there and work wonders, but things like the Vue compiler won't work with NPM transformations and are better off with a native port, like VNO

Actually that is being worked on (std/node is a shim for Node libraries that aims to make Node ecosystem 100% usable from Deno) but the idea is to build software with Deno's mindset and features on top of it. Just look at this Vue compiler, it is really lightweight in comparison to what the actual Vue compiler actually takes up in Node.

Fundamentally, Deno works way more like the language JavaScript is meant to be according to the vision of the ECMA committee (the ones who add features to the language).

Problem is that a lot of software was built upon areas where Node deviates from this standard (things like module system, language features, async management, etc) so there can't be a 1:1 translation in some cases

What's even the point of using Go? If it's for static typing Rust has that

So what's the benefit?

Same can be said about any language really, it's personal preference

Whot? How is that even comparable? It's third party code after all, the same happens when you use a library in any other language