Can someone explain like I'm five what Deno is and what it's for? Is it for the desktop or web applications? What practical things can you / should you do with it? I just can't get my head around what it does.
Now, some years later, deno is more like: ok, we know what happened. But now browser js have some new apis we could (should) re-use (modules, fetching resources) - and this typescript thing looks good. So what if we put typescript inside a rust event loop, and surfaced some of the sandboxing ideas that browsers use (eg: no file system access by default)?
https://web.archive.org/web/20120205214227/http://blog.redfi...
(was a surprisingly large number of dead links on hn regarding this one).
I believe this is a copy of the video: https://www.youtube.com/watch?v=ztspvPYybIY
So in short, deno is a javascript interpreter suitable for local scripting, server/services, etc. Just like node.
You can probably use it for desktop applications, but it more closely targets server code, again like node.
So how does deno differ from node? It has a different module system and stdlib (better, more modern). It has first-class typescript support. It has much better security controls so that it's possible to use it to interpret untrusted code (this is not security advice).
The 'untrusted code' bit means deno's also gunning a little for the niche lua and other embedded scripting languages occupy, but I don't think it has much of a foothold there yet.
I want an embedded statically-typed language that compiles directly to something that is memory layout compatible with C++.
We have 1001 languages now, but it looks like I'd still have to write my own to get what I want...
> I want an embedded statically-typed language that compiles directly to something that is memory layout compatible with C++.
Isn't this asking for ABI compatibility with C++? I thought C++'s ABI is unstable so nothing can be compatible with it.
Deno is mostly written in rust.
What that means is... How is JS code executed?
You need some other program to interpret (and possibly JIT compile) the JavaScript and actually execute it.
Normally that "other program" is a web browser like Chrome, FireFox, Safari, Opera, etc.
But those programs run JavaScript in a restricted way. That is, they only execute JavaScript attached to a web page that they loaded and within the context of that page, and they limit what the JavaScript can do to the operating system. Like can it delete files on your disk? Can it listen to an open port? Etc.
Also, those programs don't let you run JavaScript conveniently outside the context of a webpage. You can't just do at the command line: `chrome myscript.js`
Thus if you wanted to use JavaScript to write command line applications or desktop applications, using a web browser wouldn't work.
So we need another program that lets you run JavaScript from the command line, or as an executable, and we need that program to provide more facilities to the JavaScript code which allows it to do more things to the OS, such as deleting files from the disk, listening to a port, connecting to arbitrary remote servers, etc.
The first such program to appear was NodeJS. And some people don't like it. They don't like the way it runs JavaScript and the way it has exposed to JavaScript those additional OS facilities. Thus they decided to create another one called Deno.
Most languages have one defacto run-time, for example for Python it's CPython, for Ruby it is MRI, for Java it is OpenJDK, etc.
And if they have alternative ones, like Ruby also has JRuby for example. They normally copy the same language APIs, so that code for one works on the other.
In the case of Deno this is not the case. Deno decided that the NodeJS exposed JavaScript APIs arn't great, so it has a different set of language APIs. That means JavaScript code written for NodeJS will not work for Deno and vice versa.
It's really rare to see such a split in mainstream established languages, because the cost of breaking compatibility with established "in-production" code is normally too high. For example, Microsoft has build .NET core, as a new run-time for C#, but it tried really hard to provide all of the old .NET framework APIs, yet not all of them, so it did break se backwards compatibility. I believe Deno will break much more.
I've only seen this happen in the past for less popular languages, like Smalltalk has a bunch of slightly incompatible runtimes: Squeak, VisualWorks, Pharo, Cuis, etc.
And when that happens, sometimes people even consider it a whole new language, like a dialect. So in some ways, you could almost consider NodeJS and Deno to be dialects of JavaScript, since their code isn't compatible and their APIs and some of their features will differ. Similarly, their code will not always run in a browser either without rewrite, because again, the capabilities and APIs differ.
Hope this helps, I know it's kind of complicated, but at the same time it's simple. You need a runtime to run JavaScript. Each runtime can expose different APIs to the JavaScript to use, and each runtime can choose to support custom extensions of JavaScript or choose to not support certain features of JavaScript, etc. Deno and NodeJS are two such runtimes for JavaScript that are both making different choices.
What I still don't fully understand is why people want to write non-webpage software in JavaScript, a language designed to run in web pages. Why not Python or Go or Rust or literally anything else? But perhaps that ship has sailed, and the answer now is just inertia, people use JavaScript because people are already using JavaScript :P
1. performance: v8 is incredibly fast.
2. convenience: many ppl are already pretty familiar with javascript and node/deno gave them the ability to use it generically outside the browser
- a vast ecosystem all based on async IO, sidestepping the colored function problem, as opposed to the clusterfuck that is Python’s asyncio ecosystem
- a powerful and expressive structural typing system that allows you to make illegal states unrepresentable in many cases, similar to Rust, as opposed to the language of interface{} and if err != nil
- I feel silly comparing it to Rust because the Venn diagram of what problems these 2 languages are appropriate for looks like 2 disjoint circles to me. Yes, technically you could write your backends in Rust, and your competitor using Node will launch their MVP 2 years before you do.
I would say familiarity is a big one. Lots of people now learn JavaScript first, and once you know it well, having to re-learn a whole other language might seem like a big hurdle that if you can avoid seems like a good proposition.
Another one is this new concept of "full stack". While most JS code in browser and in server won't work as is, there's still a lot of overlap. So you can have subsets of code that you can copy/paste from your front-end into your backend and vice versa.
This also means that as a dev, if you want to do backend and frontend work, you only need to learn one language, that's 50% less effort on your part than having to learn two languages :p
Something else that kind of happened as a lucky accident is that JavaScript was designed for event driven programming mostly, due to it being used as a language to handle user events on webpages for interactivity. Now it turns out that the problem of managing interactive user interfaces is highly concurrent in nature. At the same time, it happened that most backend code needed to scale horizontally, which meant that it too needed to become highly concurrent. This was the innovation brought by NodeJS to the backend. It was one of the first run-time for backend that was designed exclusively in an event driven model, which actually allowed it to scale quite well for non CPU intensive workloads. In that sense NodeJS was a pioneer on the back end side as well, and other runtimes are just catching up.
Finally, writing an optimized runtime for any language is a huge endeavour. It requires lots of dev work and effort, which is quite expensive. Since web browsers make a ton of money and are backed by the richest companies around, and they care a lot about the performance of JavaScript in their browsers, there's actually an immense amount of investment made to the JS interpreter and virtual machines to have it be as efficient and optimized as can be. In practice it means that there exists JS VMs that outperform all of Ruby, Python, PHP, Perl, and almost all other dynamic programming language interpreter/VM out there. There's not many things that can rival that, you've got Go, JDK, .Net, GCC, and the Rust compiler maybe. The former because they've also had ton of money poured into them, and the latter because its entire language design and everything targets performance. Also you've got OCaml, Haskell, CommonLisp and Scheme runtimes of yore that might rival it due to how long they've had dedicated researchers and volunteers contribute. In any case, it means JS VMs are quite competitive performance wise.
Except for the various Lisp flavors that have really high speed implementations.
Many good sibling answers already - but another thing to note - is that if you want a modern (js) front-end and optional server side rendering (for faster initial load/display and/or to present something nice to search engine crawlers) - you'll probably end up having to execute js on the server side too.
Also, there's the hope of being able to re-use code for business logic, like validating data - you can (should) validate client side for better ux (quick feedback on misding/wrong data) - but since you cannot trust the client you have to validate server side.
Obviously it seems attractive to write that validation code in one place, always having it in sync between client and server.
There are multiple reasons, but it mainly comes down to
1) JavaScript is simple and widely used. And as many people are using it, those many people often also have the wish to use it outside the web for other things.
2) Webpage-Software has evolved to Application-Software in the last decade, and nowadays you can create proper interfaces with javascript&css&html which can compete with native desktop-software in terms of ability and somewhat performance.
3) You have one sourcecode for all devices. You only need to write it once, and use it everywhere with a little bit of tweaking. Which is cheaper and faster than writing separate software for every platform and device.
The only thing I would object to here is the context. The guy who created Deno isn't just "some people", but in fact is the same person who created NodeJS.
Deno might turn out to be a failed experiment, but it's coming from someone who knows the warts of NodeJS intimately.