[_jplc]

Think of it as Node.js + Typescript, but you don't have to think about configuring the typescript compiler, linter and formatter as everything is bundled in the `deno` binary.

Don't think about syncing that formatting/linting/import aliases configuration with VSCode, all you need is the Deno plugin and you'll get all the benefits of working with TS on VSCode.

Packages are obtained (and heavily cached) from any URL instead of relying on a centralized repository. Obtain your dependencies as you want, whether it's Deno's proxy, directly from raw.githubusercontent.com, your own http server, or any other thing accessible thru an URL.

At the end, the permission system is the least interesting part of the project imho. It's useful, because if you're doing a CLI that just receives stdin, processes it, and prints to stdout, you can block any disk and network access, but apart from that it's really limited because the nature of JS itself. (Maybe for the next trendy language we could think about the Object-capability model before it's too late. https://en.wikipedia.org/wiki/Object-capability_model)

The thing I value the most is consistency and having a fully working development environment out of the box to be productive.

[Zababa]

> Maybe for the next trendy language we could think about the Object-capability model before it's too late. https://en.wikipedia.org/wiki/Object-capability_model

There is an object-capability model in the upcoming OCaml 5.0, however it's only in the Eio library, that deals with IO https://github.com/ocaml-multicore/eio#design-note-object-ca.... There's also Emily, a subset of OCaml based on POLA (Principle of Least Authority) https://www.hpl.hp.com/techreports/2006/HPL-2006-116.pdf. I'm unaware of any plain to extend OCaml in that direction though.

[synergy20]

nice to have ts+linter+formatter together, it took me one or two hours to set up with my own vim(using vite/volar), so it saves me some time.

what I really like a new Node.js(e.g. deno) is actually its module system, I don't like the `npm i` in node.js pulls hundreds of modules, a standard library that contains most commonly needed modules is the key. If deno does not do that, I probably will never try that(as I can have the bundle of tooling done myself in one-or-two hours, vite/volar now makes this even simpler).

In short, I will prefer gold-quality set of modules or APIs(e.g. glibc) to the 100% flexibility "you pull whatever you want freely now even over http URL", for security and stability reasons.

[dmitriid]

> I don't like the `npm i` in node.js pulls hundreds of modules

Because modules/packages routinely have dependencies. And their dependencies have dependencies. And...

Deno changes nothing in that regard with one single exception:

> a standard library that contains most commonly needed modules is the key

^ This is the bane of Javascript, yes. But this doesn't mean that having a standard library somehow prevents modules having multiple dependencies and subdependencies.

> "you pull whatever you want freely now even over http URL", for security and stability reasons.

- If you pull your deps from a random URL and that URL goes away, how do you solve that?

- If your deps pull other subdeps from a random URL and that URL goes away, how do you solve that?

- For security, how do you vet what your dependencies keep on pulling from random URLs?

For node, the answer is: run your own registry, and don't load anything from outside. That's how many companies operate. How can this be solved with Deno?

[_jplc]

In Deno's case, there are two things:

Deno API, which comes bundled with Deno and is present globally, always, without importing: https://doc.deno.land/deno/stable. Includes basic stuff like stdin, stdout, stderr, file management... etc and standard Web APIs like Fetch API, web assembly interoperability, localStorage, FormData, TextEncoder/TextDecoder, etc.

Deno std lib, an official library that presents what you could expect from a standard library, based on Deno API: https://deno.land/std@0.120.0, but you need to import it, because it's no different than any other module in the wild. Mime types, more encoding options, extended file system management, etc.

[ihnorton]

I just noticed that Deno merged their native FFI support: https://deno.land/manual@main/runtime/ffi_api

I had been watching some issues around this, but lost track, so I'm very excited to see it is available now! This makes Deno _very appealing_ for a wide range of tasks where FFI is a small but non-negotiable necessity (places where I would use Python's ctypes, for example tooling around C libraries; such tooling becomes much more complicated if another toolchain and compilation step is required before lib can be called from a script).

[synergy20]

So what's Deno's stdlib principle:

    1. you got pretty much 80% of what you will need from the std libraries for a mid-size 'normal' application(similar to glibc, libstdcpp, go stdlib, python's stdlib)
    2. you got a small stdlib than usual(rust's stdlib), the rest you use cargo and good luck with that
    3. you grab whatever you need(node.js, you have no idea about the 500 modules npm just installed)

I prefer No.1 here.

[CodesInChaos]

Isn't the scope of the standard library of C and C++ close to the scope of the Rust standard library (an thus much smaller than python's)?

[synergy20]

nope, I was told rust prefers to a light stdlib approach.

[CodesInChaos]

C and C++ also have light stdlibs from my point of view, just like Rust.

Rust has collections, strings and algorithms manipulating these. It supports synchronous IO (files and network) and can work with threads/processes. It lacks async IO, higher level network protocols (e.g. HTTP and TLS), regex, advanced unicode support, serialization, UUIDs, GUI, linear algebra/vectors, logging, encoding, time, randomness, command line parsing, cryptography, compression.

C++ has reasonable randomness and time support, but apart from that Rust isn't far behind.

[_jplc]

It's definitely No.1.

[andrew_]

That built in linter leaves a lot to be desired. If you're a big big fan of being told how your code should be formatted, then it's a good fit. however, if you're the slightest bit opinionated, you still have to implement ESLint and jump through those hoops.

[_jplc]

Right. Personally, I don't think any opinion is more correct than any other in regards to code formatting, so, consistently and collectively choosing one and going forward with it is the way.