Deno 1.0 - <AUTHOR> https://deno.land/v1 <comment><USER3> > ... Deno is (and always will be) a single executable file. Like a web > browser, it knows how to fetch external code. In Deno, a single file can > define arbitrarily complex behavior without any other tooling.

> ...

> Also like browsers, code is executed in a secure sandbox by default. Scripts > cannot access the hard drive, open network connections, or make any other > potentially malicious actions without permission. The browser provides APIs > for accessing cameras and microphones, but users must first give permission. > Deno provides analogous behaviour in the terminal. The above example will > fail unless the --allow-net command-line flag is provided.

The Deno feature that seems to draw the most fire is dependency management. Some skeptics may be latching onto the first point without deeply considering the second.

Deno is just doing the same thing a browser does. Like a browser, there's nothing that JavaScript running on sandboxed Deno can do that a browser can't - in principle. So the security concerns seem a little over the top.

The one caveat is that once you open the sandbox on Deno, it appears you open it for all modules. But then again, that's what NPM users do all the time - <USER2> default.

As far as criticisms around module orchestration, ES modules take care of that as well. The dependency graph forms from local information without any extra file calling the shots.

This seems like an experiment worth trying at least.

<comment><USER4> See the thing about the sandbox is that it's only going to be effective for very simple programs.

If you're building a real world application, especially a server application like in the example, you're probably going to want to listen on the network, do some db access and write logs.

For that you'd have to open up network and file access pretty much right off the bat. That combined with the 'download random code from any url and run it immediately', means it's going to be much less secure than the already not- that-secure NPM ecosystem.

<comment><USER5> Maybe this will develop into a standard of multi-process servers (real _micro_ services you could say), where the permissions are only given to a slice of the application.

<comment><USER6> Reinventing QNX will always be cutting edge.

<comment><USER7> QNX is hands down amazing! No car manufacturer could ever come close to having their in-house infotainment system being as snappy as QNX...which is why they gave up and switched to QNX! Fine print: Tesla not included.

</comment></comment></comment></comment></comment><comment><USER8> If you're getting into Deno and want to keep up with new stuff from the ecosystem on a regular basis, we're now publishing [https://denoweekly.com/](https://denoweekly.com/) .. issue 2 just went out minutes after the 1.0 release. I've been doing JavaScript Weekly for 487 issues now, so this is not a flash in the pan or anything :-D

Of course, Deno has an official Twitter account as well at [https://twitter.com/deno_land](https://twitter.com/deno_land) :-)

<comment><USER9> Root certificate not trusted for [https://denoweekly.com/](https://denoweekly.com/) on both chrome and firefox.

<comment><USER10> Maybe they fixed this in the last 2 hours, but it works for me (firefox, linux).

<comment><USER9> Weird, it still says that "Cisco Umbrella Root CA" is not trusted. Maybe its only from certain countries.

<comment><USER10> I'm Canadian and in Canada for what it's worth. Clicking on the lock tells me that it was verified by lets encrypt. The root is "Digital Signature Trust Co." Common Name "DST Root CA X3".

Cisco sounds like a router might by running a MITM on you?

Edit: This looks to be confirmation that that root (or one by a very similar name) is used by a MITM tool:

[https://docs.umbrella.com/deployment- umbrella/docs/rebrand-c...](https://docs.umbrella.com/deployment- umbrella/docs/rebrand-cisco-certificate-import-information)

<comment><USER9> Thanks for the diagnosis. Accessed from a different network and with no issues. And got the right certificate this time.

</comment></comment></comment></comment></comment></comment><comment><USER11> > TSC must be ported to Rust. If you're interested in collaborating on this > problem, please get in touch.

This is a massive undertaking. TSC is a moving target. I occasionally contribute to it. It's a fairly complex project. Even the checker + binder (which is the core of TS) is pretty complex.

One idea that comes to mind is to work with Typescript team that they are only using a subset of JS such that tsc can be compiled down web assembly and have llvm spit out a highly optimized binary. This not only benefits demo, but the rest of the internet.

TSC has done some great architectural changes in the past like doing mostly functional code, rather than lots of classes.

The target we should be aiming for is a powerful typed language like typescript that complies very quickly to webasshmbly that can run in guaranteed sandbox environments.

<comment><USER12> v8 has the ability to snapshot a program just after it loads, but before it executes. If you snapshot after doing some kind of warmup, to trigger the right optimisations, you get something that should fire up ready to go, which is probably the main problem - the compiler being repeatedly invoked and parsed from javascript and compiled on the fly.

<comment><USER13> One problem with taking the v8 snapshot and using it as a binary executable is that it will probably be much slower then running v8 live. Although the startup time will be 10x faster. The runtime will be 10x slower.

</comment></comment></comment><comment><USER4> The dependency management is highly questionable for me. Apart from the security concerns raised by others, I have huge concerns about availability.

In it's current form, I'd never run Deno on production, because dependencies have to be loaded remotely. I understand they are fetched once and cached, but that will not help me if I'm spinning up additional servers on demand. What if the website of one of the packages I depend on goes down, just as I have a huge spike in traffic?

Say what you want about Node's dependency management, but atleast I'm guaranteed reproducible builds, and the only SPOF is the NPM repositories, which I can easily get around by using one of the proxies.

<comment><USER14> Why can't you download all the packages you use actually _with_ your source code? That's how software has been built for decades...

I'm a desktop developer so I understand I'm the dinosaur in the room but I've never understood why you would not cache all the component packages next to your own source code.

Since this is straighforward to do I presume there is some tradeoff I've not thought about. Is it security? Do you want to get the latest packages automatically? But isn't that a security _risk_ as well, as not all changes are improvements?

<comment><USER15> For Node, the main tradeoff is number and size of files. Usually the distribution of a node module (that which is downloaded into node_modules) contains the source, documentation, distribution, tests, etc. In my current project, it adds up to 500MB already.

They would do well to have an option to optimize dependencies for vendoring.

</comment></comment></comment><comment><USER16> I like what Deno is selling. URL like import path is great, I don't know why people are dismissing it. It is easy to get up-and-running quickly.

Looks like my personal law/rule is in effect again: The harsher HN critics are, the more successful the product will be. I have no doubt Deno will be successful.

<comment><USER17> My concern is what happens when popular-library.io goes down or gets hacked?

Or how about attack vectors like DNS poisoning? or government-based firewalls?

I know there's this[1], but somehow I still feel uneasy because the web is so fragile and ephemeral...

At the very least I would like to have the standard library offline...

[1] [https://github.com/denoland/deno/blob/master/docs/linking_to...](https://github.com/denoland/deno/blob/master/docs/linking_to_external_code.md)

<comment><USER18> > what happens when popular-library.io goes down or gets hacked?

What is anyone going to do about it? Anything has a chance of getting hacked or goes down just when you need it, be it GitHub, npmjs.org...

Blaming the tool for not having a protection against DNS poisoning is a bit far fetched.

<comment><USER19> ultimately i guess it is about how/if deno caches its imports. with node.js/npm you have the exact same problems, just the source & sink occur at different places (package installation)

<comment><USER13> With Node.js you install the packages in a dev environment, and test extensively, then push all the code, including node_packages folder to production. Running npm on the prod server is forbidden. At least in theory =)

</comment></comment></comment></comment></comment><comment><USER20> Forget the (reasonable) security and reliability concerns people have already brought up with regard to importing bare URLs. How about just the basic features of dealing with other people's code: how am I supposed to update packages? Do we write some separate tool (but not a package management tool!) that parses out import URLs, increments the semver, and... cURLs to see if a new version exists? Like if I am currently importing "[https://firstname.lastname@example.com"](https://email@example.com"), do I just poll to see if "1.0.2" exists? Maybe check for "2.0.0" too just in case? Is the expectation that I should be checking the blogs of all these packages myself for minor updates? Then, if you get past that, you have a huge N-line change where N is every file that references that package, and thus inlines the versioning information, instead of a simple and readable one-line diff that shows "\- blah: 1.0.1, + blah: 1.0.2".

<comment><USER21> Another thing is that with package.json every dependency can say which versions of its dependencies it works with. This lets you update a dependency that is used by other dependencies and only have a single version (most up to date) of it. Some package managers also let you completely override a version that one of your dependencies uses, allowing you to force the use of a newer version.

With Deno, both of these use cases seem way harder to satisfy. None of your dependencies can say "hey, I work with versions 1.1 to 1.3 of this dependency", instead they link to a hardcoded URL. The best chance of overriding or updating anything is if Deno supports a way to shim dependencies, but even then you might need to manually analyze your dependency tree and shim a whole bunch of URLs of the same library. On top of that, as soon as you update anything, your shims might be out of date and you need to go through the whole process again. To make the whole process easier, Deno could compare checksums of the dependencies it downloads and through that it could show you a list of URLs that all return the same library, but this would be like the reverse of package.json: instead of centrally managing your dependencies, you look at your dependencies after they have been imported and then try to make sense of it.

<comment><USER22> > None of your dependencies can say "hey, I work with versions 1.1 to 1.3 of > this dependency"

That's a real problem that needs to be solved.

Also, what happens when two lib A and lib B depend on different versions of lib C? Each have their own scoped instance of C?

</comment></comment></comment><comment><USER23> Congratulations on the 1.0 release! I've been using Deno as my primary "hacking" runtime for several months now, I appreciate how quickly I can throw together a simple script and get something working. (It's even easier than ts- node, which I primarily used previously.)

I would love to see more focus in the future on the REPL in Deno. I still find myself trying things in the Node.js REPL for the autocomplete support. I'm excited to see how Deno can take advantage of native TypeScript support to make a REPL more productive: subtle type hinting, integrated tsdocs, and type- aware autocomplete (especially for a future pipeline operator).

<comment><USER24> Seconded, a Deno TS REPL would be amazing, but they probably have a few bigger fish to fry yet :)

<comment><USER25> > bigger fish to fry

> fish

I see what you did there, and I approve.

</comment></comment></comment><comment><USER26> Does anyone else see the import directly from URL as a larger security/reliability issue than the currently imperfect modules?

I'm sure I'm missing something obvious in that example, but that capability terrifies me.

<comment><USER27> Does Deno have some built in way to vendor / download the imports pre- execution? I don't want my production service to fail to launch because some random repo is offline.

<comment><USER28> Deno caches local copies and offer control on when to reload them. in term of vendoring you can simply download everything yourself and use local paths for imports.

<comment><USER29> How would this work with transitive dependencies? Sure I can control which parts I import myself, but how do I keep a vendored file from pulling in another URL a level deeper?

<comment><USER30> Unlike node, recommended deno practice is to check-in your dependencies to the VCS.

> Production software should always bundle its dependencies. In Deno this is > done by checking the $DENO_DIR into your source control system, and > specifying that path as the $DENO_DIR environmental variable at runtime.

[https://deno.land/manual/linking_to_external_code](https://deno.land/manual/linking_to_external_code)

<comment><USER31>
        du -hs node_modules

        1.7G node_modules

</comment></comment></comment></comment></comment></comment><comment><USER32> For the uninitiated, worth noting that one of the names on this post, Ryan Dahl, was the original node.js developer.

<comment><USER33> Also for the uninitiated, fly.io is migrating to deno for their Serverless functions: [https://news.ycombinator.com/item?id=22621926](https://news.ycombinator.com/item?id=22621926)

<comment><USER34> Precisely the use case that Deno should be used for. Serverless functions are a great use case for Deno right now.

</comment></comment></comment><comment><USER35> It would be great if this line were at the top:

>> Deno is a new runtime for executing JavaScript and TypeScript outside of the web browser.

<comment><USER36> Thanks. Came looking for this post. Way too many web developers just assume that everyone follows every nook and cranny of their ecosystem.

</comment></comment><comment><USER37> > In Deno, sockets are still asynchronous, but receiving new data requires > users to explicitly read()

Interesting. If I understand correctly, they're essentially using pull streams[0]/reactive streams[1]. I compiled a few resources on this topic when I was digging into it a while back[2]. I've found the mental model to be very elegant to work with when needing backpressure in asynchronous systems.

As for the dependencies-as-URLs, I don't mind it, and may prefer it. I've been experimenting with minimizing my dependencies lately, and vendoring them in git submodules. It's worked fairly well.

[0]: [https://github.com/pull-stream/pull-stream](https://github.com/pull- stream/pull-stream)

[1]: [https://github.com/reactive-streams/reactive-streams- jvm](https://github.com/reactive-streams/reactive-streams-jvm)

[2]: [https://github.com/omnistreams/omnistreams- spec](https://github.com/omnistreams/omnistreams-spec)

<comment><USER38> When describing the input stream back-pressure problem:

> To mitigate this problem, a pause() method was added. This could solve the > problem, but it required extra code; and since the flooding issue only > presents itself when the process is very busy, many Node programs can be > flooded with data. The result is a system with bad tail latency.

Are they saying that even with correct use of pause() there are still issues?

<comment><USER39> They're saying since the issue doesn't present itself until it's too late most code does not use pause().

</comment></comment></comment><comment><USER40> Of all the problems with NPM, it being centralized is the last of them imo. Having experienced the mess that is go's decentralized dependency management, I'm not sure why anyone would want to replicate it.

Putting aside security, availability and mutability is a massive problem, anyone can stop hosting their module, or worse, change an existing published module at any time.

Why not take some inspiration from maven central, and run a central repo that actually provides some validation on the quality of and consistency of published artifacts.

<comment><USER41> > Why not take some inspiration from maven central, and run a central repo > that actually provides some validation on the quality of and consistency of > published artifacts.

Because then it would be hard to have a new hot framework every day.

</comment></comment><comment><USER42> So it's an alternative to Node? Sounds incredibly cool, honestly. This:

> Supports TypeScript out of the box.

Seems like a small thing, but it has me interested all on its own. It's a huge pain to set up a whole build process just for TypeScript (which is generally the only preprocessing you need outside of the browser).

<comment><USER43> You'll like [https://www.npmjs.com/package/ts- node](https://www.npmjs.com/package/ts-node) \- it allows zero processing use of typescript

<comment><USER4> Word of warning though - ts-node can be excruciatingly slow. We recently switched a project from using ts-node in our dev environment to compiling with tsc and running with node, and shaved around 5 minutes from our startup time.

<comment><USER44> You had 5 minutes _startup_ time?!

<comment><USER13> More then one second and people will test their code less often. Five minutes and people start relying on the type-checker. Like with the chicken and egg problem, what came first, the type-checker or the need to have a type checker?

</comment></comment></comment></comment></comment><comment><USER45> One question.

> The browser provides APIs for accessing cameras and microphones, but users > must first give permission. Deno provides analogous behaviour in the > terminal.

I read this and I started looking around for the camera API or maybe for the Audio API. And the thing is that I can't seem to find anything about it. I can't see anything about it in "The Manual" or in the API reference.

Then I thought that there may not be documentation because it just mimics the browser's API. Ok, but... there must be some command-line flag to give permission to it, right? Can't find it either. Maybe "it was just an example; there's no media API just yet"?

But then I set out to find available command-line flags in general. And I can't find those either. There's this [0] but is that _all_? There's just --allow-net, --allow-read and --allow-write? Or is there some other place where the available permission flags are listed?

[0] [https://deno.land/manual/getting_started/permissions](https://deno.land/manual/getting_started/permissions)

<comment><USER46> I don't see it listed in the docs, but try running `deno run -h` to see the command line help. It should produce output like:

        -A, --allow-all                    Allow all permissions
            --allow-env                    Allow environment access
            --allow-hrtime                 Allow high resolution time measurement
            --allow-net=<allow-net>        Allow network access
            --allow-plugin                 Allow loading plugins
            --allow-read=<allow-read>      Allow file system read access
            --allow-run                    Allow running subprocesses
            --allow-write=<allow-write>    Allow file system write access

etc

<comment><USER45> Thanks.

</comment></comment></comment><comment><USER47> > Internally Deno uses Microsoft's TypeScript compiler to check types and > produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it > is very slow.

> Early on in the project we had hoped that "V8 Snapshots" would provide > significant improvements here. Snapshots have certainly helped but it's > still unsatisfyingly slow. We certainly think there are improvements that > can be done here on top of the existing TypeScript compiler, but it's clear > to us that ultimately the type checking needs to be implemented in Rust.

> This will be a massive undertaking and will not happen any time soon; but it > would provide order of magnitude performance improvements in a critical path > experienced by developers. TSC must be ported to Rust. If you're interested > in collaborating on this problem, please get in touch.

<comment><USER48> Deno really shouldn't run TypeScript files directly. Not only is TypeScript too slow for this, it receives far too many breaking changes.

How will Deno decide when to upgrade its TypeScript compiler version? Will Deno have to have breaking changes every three months or so?

Also, Deno appears to allow import TypeScript files with .ts extensions while tsc doesn't. This alone means the same code won't run in Deno and compile with tsc.

JavaScript at Stage 3 and above is a stable compile target, and Deno should just run that.

<comment><USER49> I'm a huge TS fan and I agree. Deno is just running tsc for me it seems. So far I don't see much advantage. It also potentially ties Deno to current trends. TS is pretty dang popular, but what if something else comes along and scoops it?

<comment><USER50> Note that Deno started out as _Typescript_ runtime, it was it's tagline, they added the JavaScript later there.

> TS is pretty dang popular, but what if something else comes along and scoops > it?

Earth is rather small, type inferencing dynamic language is _really_ hard. There is simply no other language or team that has achived anything like TS. It's very unlikely that anyone else will do it for JS again. You can just look at amount of work in TS already.

Only thing that can "scoop it" is another language entirely taking off and leaving JS developers in the history. In that case the point becomes useless, it can happen to any runtime for any given language.

</comment></comment></comment></comment><comment><USER51> >> Internally Deno uses Microsoft's TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow.

>> We certainly think there are improvements that can be done here on top of the existing TypeScript compiler, but it's clear to us that ultimately the type checking needs to be implemented in Rust.

Funny, I was just talking about something like this in an earlier TypeScript discussion today. I was saying that I don't understand why Microsoft doesn't have their own native TypeScript runtime engine by now.

I have nothing against TypeScript as a language but I hate the TypeScript transpiler; it should be packaged as an engine, not as a transpiler. I just hate having to debug mangled transpiled code and dealing with sourcemaps. I want to be able to run and debug my own code, not some alternative mangled version of it.

I think Deno is a promising project in the sense that they seem to understand the drawbacks of transpilation and are actually trying to provide TypeScript support which feels native. Everyone else seems to be ignoring this problem including the creators of TypeScript.

<comment><USER52> > I don't understand why Microsoft doesn't have their own native TypeScript > runtime engine by now

what would they do with it? ship it in Edge? great, now some small fraction of users can run TS natively. but most can't, so everyone would still transpile to JS anyway...

it could work if Google did it, but i don't think MS has enough market share to have an influence here

<comment><USER53> It would work for server-side tools (like Deno). For example, cloud functions on various cloud platforms often support TS.

<comment><USER52> yeah but i don't think MS uses TS-on-the-server enough or has enough Azure TS users to justify putting in the effort

</comment></comment></comment></comment><comment><USER54> Number of things come to mind:

\- How do you update dependencies? They are urls spread along many files which can be everywhere... Do I have to find and replace every import statement?

\- In some enterprise environments, we use mirroring of package distributors (Nexus, jfrog etc.). This give us the ability to audit what packages are being imported, create a cache of packages so that a single delete or unpublish (like good old leftpad) won't break all applications, etc. Since package locations are hard-coded in the package files, it becomes challenging to do this.

The argument that deno is mimicking a browser is thin. Browsers are client side, they don't access databases or lives inside your firewall. Server applications are much more sensitive to security issues than browsers.

<comment><USER55> A lot of comments here can be answered by reading the documentation.

[https://deno.land/manual/linking_to_external_code#faq](https://deno.land/manual/linking_to_external_code#faq)

</comment></comment><comment><USER56> I briefly looked over this project when this link first popped up and didnt think much of it, but then i was surprised to see this huge surge in votes. I dont do much in the javascript and related world - can someone explain what in particular about this project has generated such interest? Even after reading the top comments, I feel like im missing the bigger pitcure.

<comment><USER57> >> _I dont do much in the javascript and related world - can someone explain what in particular about this project has generated such interest?_

The majority of the interest lies in the fact that Ryan Dahl[1] was the original creator of Node.JS[2], which is currently a very popular Javascript runtime and web backend.

Dahl released the initial version of Node.JS in 2009[3]. After a decade of experience working on Node.JS and growing the community, Dahl decided to create an alternative Javascript (and Typescript) runtime in mid/late 2018 called Deno which is now v1.0.

[1] [https://en.wikipedia.org/wiki/Ryan_Dahl](https://en.wikipedia.org/wiki/Ryan_Dahl)

[2] [https://nodejs.org/en/](https://nodejs.org/en/)

[3] [https://en.wikipedia.org/wiki/Node.js](https://en.wikipedia.org/wiki/Node.js)

<comment><USER58> > After a decade of experience working on Node.JS and growing the community, > Dahl decided to create an alternative Javascript (and Typescript) runtime in > mid/late 2018 called Deno which is now v1.0.

Just to nit-pick: Ryan Dahl had stepped away from node and the surrounding ecosystem in 2012. So for the vast majority of node's lifetime, he hasn't really been involved. Node in 2012 was a very different project.

(That doesn't take away from his observations or from the things that deno does differently. Just trying to reduce confusion.)

</comment></comment></comment><comment><USER59> Congrats to the Deno team and community on reaching 1.0!

We've launched Deno support on repl.it here (in beta): [https://repl.it/languages/deno](https://repl.it/languages/deno) for folks to try out.

</comment><comment><USER60> This is super effing awesome.

You know what would be extra amazing? Incorporating (at some point in the future) all of the very smart stuff that the unison people have been doing. That would be _tremendous_ for code re-use and guarantees about remote packages. What I wouldn't give for a JS vm that could do all that. . . .

* [https://www.unisonweb.org/docs/tour](https://www.unisonweb.org/docs/tour)

<comment><USER61> I like that Deno prefers URLs as module specifiers. Need immutable/content- addressed dependency graphs? Publish and consume modules via IPFS.

<comment><USER60> Maybe I'm missing something but the reason why the concept behind unison is so neat is that identifying libraries by AST allows for the kind of code re use that Joe Armstrong was talking about. It's not about urls as identifiers, that's superficial.

What's the relevance of IPFS?

</comment></comment></comment><comment><USER62> This is exciting news indeed. Deno hitting 1.0 still makes the ecosystem surrounding it quite young, but it's an important milestone and I'm excited to see what comes of it in the future.

</comment><comment><USER63> For context:

Deno's lead is Ryan Dahl, the creator of Node.

In the past, Dahl's expressed regrets over choices he made early on in Node's development, and on the direction Node has gone since he left the project many years ago.

He bravely presented on this topic at jsconf eu, 2018: [https://www.youtube.com/watch?v=M3BM9TB-8yA](https://www.youtube.com/watch?v=M3BM9TB-8yA), it's a fantastic talk.

The last 10 minutes are a pitch for what a "better Node" would look like, if he were to start from scratch in 2018. The end result of that train of thought this project, which we should probably think of as bourne-again node.

Deno's development is (presumably) strongly influenced by his experience and furstrations with Node's shortcomings in both performance and developer ux.

<comment><USER64> And now, he'll make a whole different set of good and bad choices to potentially regret later.

<comment><USER63> such is the curse of having the audacity to develop software :)

<comment><USER65> Sure, but there's a tendency to start over when the development gets hard to maintain or support instead of just fixing the mistakes.

This really feels like the fundamental response in the js world and why we see much churn.

<comment><USER66> But isn't this an inherent problem in software development that is really super hard to not do?

Let's say you are deciding how to make node when it was first conceived and how it would work. You've made decisions about how the thing fundamentally works. Then after using it and developing for it many years and after having millions of critical software projects dependant on it, you slowly start to see the shortcomings of the software that you could only see at this stage. The problem is that these shortcomings come from a false assumption or solution to the fundamental problems you had to solve when making node. Now, the only way to fix node is to change how it fundamentally works. But if you do that, millions of users' code will break. So, do you require everyone now to fix their broken code and potentially piss everyone off? Or do you give people a choice? Stick with node if you aren't noticing any of those fundamental problems you found, or switch to the new thing on your own time? It's a question of how to affect the least number of people in the least negative way.

<comment><USER65> I think the answer is a break in backwards compatibility on a major version release.

People in JS/frontend world are willing to drop the world for the latest new thing, I see this as less jarring than, say, Python 2 -> Python 3.

<comment><USER67> I find it amusing that you use the example of Python 2 -> Python 3, a breaking change in a widely used language, that has famously been very difficult and long for organisations to deal with.

Compare that with javascript which has never had a breaking change. On top of that Typescript is a backwards compatible superset of javascript.

More to the point, Ryan has a humble explanation of what regrets he has about Node.js[1], why they exist and in some cases why there isn't an easy fix.

The point that I assume you're making, that sometimes it is better to spend significant energy to fix something, rather than throwing the baby out with the bath water, is a good one. However I'd suggest this is not one of those cases.

[1] [https://www.youtube.com/watch?v=M3BM9TB-8yA](https://www.youtube.com/watch?v=M3BM9TB-8yA)

<comment><USER65> > I find it amusing that you use the example of Python 2 -> Python 3, a > breaking change in a widely used language, that has famously been very > difficult and long for organisations to deal with.

Why is that amusing? I specifically chose that example for that exact reason. I was highlighting the difference in the audience and use case.

> However I'd suggest this is not one of those cases.

I don't see the argument that supports that, either in the post or your reply.

The thing is, I can see Beepboo 1.0 being announced in 2025 to address the things that went wrong with deno. Because there _will_ be design mistakes. And at what point do you say 'oh too many people rely on this software to fix this, I have to start over'?

Couple this with a very real trend-chasing and resume pushing in frontend dev and I'm starting to understand why people are so cynical about this stuff.

Typescript is something more palatable to me because it _wasn 't_ throwing the baby out with the bathwater.

<comment><USER67> > Why is that amusing? I specifically...

My apologies I misread.

> ... there's a tendency to start over when the development gets hard to > maintain or support instead of just fixing the mistakes.

The thought that Node.js should have been 'fixed' instead of creating Deno is where I disagree. At a glance I can see a few reasons:

\- Node.js maintainers + community may not even think there is something to be fixed (see various discussions in this thread about module resolutions)

\- Politics, death by committee, inertia

\- Effectively a dependency with npm registry (although not technically)

\- Lack of backwards compatibility with changes (e.g. module resolution)

> The thing is, I can see Beepboo 1.0 being announced in 2025

Node.js was initially released in 2009 so it's probably fairer to suggest Beepboo 1.0 will be released in 2030. And yes, if it improved on Deno and solved inherent problems that couldn't be solved internally, I would wholeheartedly cheer it along.

I think it's also worth mentioning that Node.js is at a level of stability and maturity that people who plan to and have already built on it, aren't left abandoned.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER68> This project looks really cool to me.

I'm glad the link to the video is there, because my intuition about pronouncing the name was incorrect.

It looks like it could be "deeno" OR "denno", and I was pushed to the former by the presence of the dinosaur graphic. Isn't that old fashioned dinosaur on the Flinstones pronounced deeno? Anywho... good name overall: short, no collisions (i think?), and no strong baseline associations.

And only right this instant am I realizing that this is an anagram of node... oh my god i'm slow. Now it's a _great_ name.

<comment><USER69> What video? Mind linking directly?

<comment><USER70> I think he meant Ryan Dahl's talk: Design Mistakes in Node [https://www.youtube.com/watch?v=M3BM9TB-8yA](https://www.youtube.com/watch?v=M3BM9TB-8yA)

</comment></comment></comment><comment><USER22> \- "Rust has its own promise-like abstraction, called Futures. Through the "op" abstraction, Deno makes it easy to bind Rust future-based APIs into JavaScript promises."

That's exciting! I wonder if that binding is public for end users to use, or if it's an internal design

<comment><USER71> This exists for wasm too; it's super easy with wasm-bindgen. I wrote a program with multiple layers, worked flawlessly. (Promise in a future in a promise created by Rust and passed back to JS)

</comment></comment><comment><USER72> Given that all API calls in JS have to go through the interpreter, couldn't unsafe API calls have an implicit parameter added that requires a per-package token, with the API accessed through an interface requested by the package that pins that interface to that token? Additionally, you could allow package authors to set their token as a cryptographic public key from a package manifest, so they could grant access to the API to sub-packages within their own ecosystem. If you passed the API interfacing object to a package outside of your control, the calling code's token wouldn't match the API interfacing object's expected token and would kick a security access exception. This would be completely transparent to the package author. With such a system, access to unsafe APIs could be granted to only a shortlist of packages.

Something like this is already done with only allowing access to certain APIs if they are called from certain types of event handlers, until the callstack of the event handler is left.

</comment><comment><USER73> The fundamental problem of dependency management, as anyone who ever kept bookmarks knows, is that the external sources might go away at any time. It's not a problem unique to Deno or Go. Take Java for example, its standard dependency management tool is Maven, which relies on external repositories of artefacts to function. From time to time, a repository might go down, or it might be moved to another address, or a library might be migrated to another repository. Whenever this happens, your build might break. The solution is to proxy all requests at the organizational level through your own server which keeps a mirror of any package that has been referenced once. That way, if it become unavailable externally, then you can still use it internally. You can also override packages with patched versions if they misbehave.

I think that Deno should define a standard dependency fetching protocol, and allow proxying transparently at a native level. If it does, that kind of dependency management will be fine.

</comment><comment><USER42> > A hello-world Deno HTTP server does about 25k requests per second with a max > latency of 1.3 milliseconds. A comparable Node program does 34k requests per > second with a rather erratic max latency between 2 and 300 milliseconds.

Under-mentioned feature. I may migrate my personal site to Deno just for that latency drop.

<comment><USER74> Yeah it seems like the p99 latency of node, which isn't great, doesn't get mentioned much.

</comment></comment><comment><USER75> if you require modules by URL, how does it make sure that the URL always contains the same library?

I've read the docs and it says it caches on the initial execution and doesn't update unless it's forced to update, but what happens when you for example publish a deno module to github, and someone else downloads it and runs it, and turns out the URL contains completely different library at his execution point?

<comment><USER76> This is something that we'll further work out in future versions. For now you can use a lockfile: [https://deno.land/manual/linking_to_external_code/integrity_...](https://deno.land/manual/linking_to_external_code/integrity_checking)

<comment><USER77> > Deno can store and check module subresource integrity for modules using a > small JSON file. Use the --lock=lock.json to enable and specify lock file > checking. To update or create a lock use --lock=lock.json --lock-write.

HALLELUJAH that there is a clear, simple separation of when (a) you expect a lock file to be checked to guarantee integrity and (b) when you want it to be generated. The complete insanity that was npm shrinkwrap and lockfiles for years, summed up in this stackoverflow post [https://stackoverflow.com/questions/45022048/why-does-npm- in...](https://stackoverflow.com/questions/45022048/why-does-npm-install- rewrite-package-lock-json) , always baffled me in that it seemed like it could have just been so easily avoided about being explicit when you're writing a lockfile vs. when you're using it.

That said, why not be even MORE explicit about it, i.e. "\--use- lock=lock.json" vs. "\--write-lock=lock.json"?

</comment></comment></comment><comment><USER78> The import from url feature is drawing a lot of initial skepticism - but I think once you look closer at it there are even more things to be wary of.

The initial thing is the fear "whoa, that is hella insecure!" which, I agree NPM is basically the same problem... although, with NPM - Git system, you can 1. fork a version and use that version (which you can do with this, just host different url) or two you can freeze version you are using and theoretically only update after checking stuff out (I guess you would have to do the same with host different url, seems more difficult process)

Also NPM basically makes a local cache of the files you will be importing, I guess the first time you run your program it must get the files and then caching keeps them from updating until the resource updates? Maybe I'm missing something and it isn't like that but if it is like that I find that weird because you are arbitrarily adding extra performance overhead to parts of your system as code loads and sees it needs to get a resource that has updated? I guess what would end up happening is versioning would be in the url and an expires header set a long time in the future, like you might do with static assets now, but Deno doesn't require that, it will be an outgrowth of this import from url system. Will there be situations where someone has done the caching poorly, or set the header badly or whatever and you are loading a resource too often? I would expect so, anyway I guess there will have to be testing of Deno's caching [https://www.mnot.net/blog/2017/03/16/browser- caching](https://www.mnot.net/blog/2017/03/16/browser-caching)

Finally, in NPM's system if a module I'm importing is a little bit weird I can always just go into the folder quickly and start debugging and maybe fixing the code, and then when I've got things working the way I think they should with changes do an actual fork pull-request, or just fork and use my fork of the code, or if it turns out as it often does that I've misunderstood something revert my changes to their code and go fix my code instead. I can of course still achieve the same effect with Deno but the workflow would have to be different and I think would end up being more convoluted, at least in the beginning.

These are the initial worries that I get when seeing import from some url. I suppose someone has already thought these things through and I'm unnecessarily worried so if that someone is you (the reader of this long post) you can maybe assuage my worries.

<comment><USER79> Well is has a huge security hole that ry wont fix [https://github.com/denoland/deno/issues/1063](https://github.com/denoland/deno/issues/1063)

<comment><USER78> I would like to write a long damn with an exclamation point at the end but the margins of my screen are insufficient to hold it.

</comment></comment></comment><comment><USER80> What is the reason for making a JavaScript runtime based on browser APIs that cannot also be a browser?

Or in other words, wouldn't it have been easier and better to make an optionally headless version of the Servo browser with additional native APIs and some enhancements like being able to run JavaScript directly in addition to HTML?

The choice made means that Deno can't be used, at least directly, to make desktop applications, and also doesn't have all the features that browsers have for free, like multiprocess and multiple sandboxes, network traffic inspector, local storage, GPU compute, etc.

<comment><USER81> The Javascript engine is a lot smaller code surface area than an entire browser rendering engine.

</comment></comment><comment><USER82> I feel explicit location imports are a step backwards. Node ecosystem is moving toward workspaces and Yarn Plug'N'Play style manifest lookups for deps. The de-coupled import from where physically the dependency is being satisfied from seems desirable and it is a common next-level pattern in project and dependency management across language ecosystems.

Sure, I guess you could shim it somehow like is happening in the node ecosystem but then.. I'm not sure what the stock situation brings to the table TBH.

</comment><comment><USER83> As a functional developer who doesn't care for TypeScript in any way, it's frustrating to see Deno has it "built-in".

As a node developer writing pure none-compiled JavaScript, my run time is extremely fast from changing code to seeing its results. It takes milliseconds for me to run brand new code in my terminal.

If I make an index.ts file simply adding two numbers together (with no TypeScript), there is a 1 to 2 second delay while it "compiles" my "TypeScript". (Again I don't write TypeScript so I don't need this feature). I should note, subsequent runs will be faster, but as I'm developing I don't want delays between my runs.

Since it's not even native TypeScript, it's just embedded the tsc which builds and caches the compiled code, why not let TypeScript developers add their bundling pipeline in the same way as they've always done.

Anyway, I'm very interested in the fact it's built in Rust and seems to be faster than node after compilation in many aspects. Congratulations to the Deno guys and thanks for all the effort.

[edit] Correcting myself. I was wrong. As @jon889 informed me, you can actually run a `.js` file and it will skip compilation. Again I remain that the TypeScript compiler should not have been included, but the fact I don't have to use it completely mitigates my main concern.

<comment><USER84> > As a node developer writing pure none-compiled JavaScript, my run time is > extremely fast from changing code to seeing its results. It takes > milliseconds for me to run brand new code in my terminal.

Deno runs JavaScript faster than node:

       echo "console.log(1 + 2)" > not-ts.js
       time deno run not-ts.js
       3
       0.01s user 0.01s system 89% cpu 0.025 total
       time node not-ts.js
       3
       0.03s user 0.08s system 53% cpu 0.203 total

> Since it's not even native TypeScript, it's just embedded the tsc which > builds and caches the compiled code, why not let TypeScript developers add > their bundling pipeline in the same way as they've always done.

You can!

<comment><USER83> > Deno runs JavaScript faster than node

Yup, and that's really cool and exciting. My issue isn't with runtime timing. That's not what costs me money. Developer time is what costs money, and every change having to "recompile" my already raw JavaScript costs way more than saving 0.02s at runtime.

<comment><USER85> Can't you just pass it a .js file and it will skip the TypeScript compiling completely?

<comment><USER86> That's not gonna help if you're using any part of the standard library though (or presumably most 3rd-party modules), since it's written in TS, right?

<comment><USER87> I'd assume you can just use regular node modules in that case?

</comment></comment></comment></comment></comment></comment><comment><USER88> Just a random though but if they want speed they could consider making a typescript JIT instead of typescript -> javascript. Typed languages _can_ run much faster than untyped. Maybe that's impossible with current typescript given anything can be changed, eg (30 minutes into running something does Math.floor = ... etc, but maybe some kind of escape analysis could help or maybe push for some new keyword to mark code as safe to optimize.

<comment><USER89> Building a new JIT for a dynamic language, if it is supposed to be competitive with JS compilers, is a project several orders of magnitude bigger than building a runtime like this.

TypeScript's design is very much that of a typing layer over a dynamic language. It's unsoundness and various loopholes to escape typing mean it's not much of a help for typed compilation.

<comment> torb-xyz Microsoft _do_ have the research project Static TypeScript that does try to do this with a subset: [https://www.microsoft.com/en- us/research/publication/static-...](https://www.microsoft.com/en- us/research/publication/static-typescript/)

But your point stands I think this subset will be incompatible with how many (including myself) writes TypeScript.

</comment></comment></comment><comment><USER90> Won't Meteor.js make this project extinct?

<comment><USER34> Clever ;)

</comment></comment><comment><USER91> I predict cdnjs/jsdelivr types will explode in use for Deno packages since they can make bandwidth and security guarantees behind what's actually returned from the URL as well will be able to accomodate versioning in the path. That seems to be what this dep system is built for, unless I'm missing something.

</comment><comment><USER92> If you need a server framework for Deno, please take a moment to check out Pogo. It's got a powerful and friendly API. It also has the best documention and plenty of tests.

[https://github.com/sholladay/pogo](https://github.com/sholladay/pogo)

</comment><comment><USER93> What exactly does Deno do? I still can't figure it out: is it a secure version of Node, if so, how?

<comment><USER94> It's an alternative to node. If Node is Photoshop than Deno is Pixelmator. They both take in similar kinds of output and make similar things, but have a very different approach on how the tooling is built and used.

<comment><USER93> Good explanation, thanks!

</comment></comment></comment><comment><USER95> Some of the bigger previous threads:

[https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=Deno%20&sort=byPopularity&type=story)

</comment><comment><USER79> Well, there is a known MITM vuln in Deno by design and the team refuses to fix it soooooo

REF: [https://github.com/denoland/deno/issues/1063](https://github.com/denoland/deno/issues/1063)

<comment><USER96> Lockfiles should be used for production code, as per [https://deno.land/manual/linking_to_external_code/integrity_...](https://deno.land/manual/linking_to_external_code/integrity_checking)

<comment><USER97> Can checksums/hashes be specified directly in the source file?

EDIT: I mean hashes of dependencies.

That is important for single-file scripts, if this is meant to be useful as a bash replacement for scripting.

Having to download two separate files for a script and execute it with special arguments already adds too much friction to that scenario.

<comment><USER79> >Can checksums/hashes be specified directly in the source file?

That would defeat their point actually :D malicious attacker could inject any script by hacking on the network and replace modules that are downloaded through http

<comment><USER97> How? Say I have `script.ts`. That file exists locally on my computer and the code inside it is trusted (say it was downloaded from a trusted github project via https). It contains

        import { dependency } from 'http://email@example.com'
            with hash '6f09aa686a6263f9e992'

or something like that. If an attacker replaces stuff during transfer of the dependency, then the hash won't match (assuming a collision resistant hash function). This can be transitive if the dependency also has hashes of its dependencies directly inside it (and a "only allow that" mode could enforce it).

The additional benefit is that you also don't need to trust the server to not replace code for a URL under your nose from one you have previously verified. So like a lockfile, but without needing to download a separate file (because you also want verification on the first run) and a command-line argument on launch - which makes it a much more viable replacement for bash scripts (in fact, that's why I care about the ability, I wouldn't mind https-only). Am I missing something here?

<comment><USER79> Oh, I did not get what you meant ^^ well, there are still other issues than integrity with not using https.

<comment><USER97> Yeah, I'll edit the original comment to clarify that I mean hashes of dependencies.

</comment></comment></comment></comment></comment></comment></comment><comment><USER98> I am a long-time Node.js user. My question about Deno is "is there any indication that this project will have a different trajectory from the node.js project (also started by some of the same people as Deno), or should I expect Deno to also follow a 10 year arc?"

I think evolution & starting over can both be appropriate steps forward, I don't question the Deno project, but to have the _exact same_ people who created Node.js say "OK here's the _new_ new JS hotness," I think "how can we expect this time to be different" is a reasonable question. Or perhaps these ecosystems are not meant to last/be supported more than 10ish years?

</comment><comment><USER99> Are imports async by default in Deno? That seems to be how it works given that you can import from a URL. This is interesting since async imports are currently a part of JavaScript(or at least a proposal?) by using the `import()` function.

<comment><USER100> there are no "async" or "sync" imports in js. there are static and dynamic imports. An implementation is free to spend as much time as it likes between parsing a file to get the static imports and actually running the file doing whatever it likes, including fetching urls, reading the file system, etc. dynamic imports return a promise but the implementation is free to resolve that promise immediately (e.g. `return Promise.resolve(loadSync(module))`)

<comment><USER99> I suppose that makes sense since loading a module from a file on a disk isn't all that different from loading a file over a TCP connection.

</comment></comment></comment><comment><USER10> Is there some deterministic way of measuring JS execution time?

Explanation for why I want that:

I've started making an game RTS game - think starcraft but you can program your units.

Currently I'm trying to decide what language to expose to players. The two main requirements are that it's secure (I'll be running player A's code on player B's computer) and that it has a deterministic method of counting execution time (so that player A and player B's computer can both make the same decision on whether or not a script took too much time).

I'd appreciate any hints towards other languages I should look at as well.

<comment><USER101> I guess it would depend on the JS engine. If the player is the one writing JS, and you want a scaled down environment (since it's not an app in the browser), probably making your own JS parser/engine could be the way to go? You'd want the JS engine to be inside the game engine somehow.

<comment><USER10> > and you want a scaled down environment

This is definitely a requirement, a very scaled down one since I don't want any interaction with the outside world apart from the game engine (for determinism purposes).

> probably making your own JS parser/engine could be the way to go

That sounds like a _lot_ of work to do well. If I had infinite time I suppose re-implementing a common language would be the best way forwards, but I don't, especially for a hobby project.

<comment><USER101> Yeah I can't comment much on how long a JS engine would take. You could start using V8 I guess, but I would think using an existing JS engine inside a game engine might by tricky because they seem complex. JS the language is easy to create a _parser_ for, and that might be what you really want to be custom in order to do other things in between the JS code. Maybe try looking for stripped down JS engines that have source code to see how hard it is. I'm also assuming you will code this game with C++ for performance, but maybe a JS/HTML game could leverage V8 from the browser, if that was your initial thinking.

<comment><USER10> I'd be _delighted_ to use V8... if I could figure out a way to get a deterministic estimate of the runtime of scripts (e.g. in languages that compile to a bytecode I could add a "bytecodes executed counter" easily enough).

I'm coding the game in Rust, but I really don't care what the language is coded in, linking in a language runtime isn't a problem.

</comment></comment></comment></comment></comment><comment><USER102> Some compatibility with Npm modules would have been better choice for adoption.

</comment><comment><USER103> Even if this new thing has slightly nicer syntax or usage of promises or whatever, does this alone justify it's existence? Learning all this new tooling and ecosystem all over again? Dividing the web development ecosystem even more? I really don't see how the problem it's solving is big enough for us to care really. I mean - enough already. In 8 years I'm sure Ryan Dahl can come up with an even better runtime written in Grust, will we then all be migrating our codebases from Node -> Deno -> Dynamite?

<comment><USER104> Also you can get most of the benefits of async/await without all the downsides of promises: [https://www.npmjs.com/package/casync](https://www.npmjs.com/package/casync)

</comment></comment><comment><USER105> Question:

        deno run https://deno.land/std/examples/welcome.ts

This works - it downloads the code from that URL, then compiles and runs it.

But if you visit [https://deno.land/std/examples/welcome.ts](https://deno.land/std/examples/welcome.ts) in your browser you get back HTML, not raw code.

Anyone know how this works? Is deno.land a special case or is there some Accept header cleverness or something going on?

<comment><USER106> Was waiting for the first person to point out that what you get when you visit a url is not guaranteed to be the exact same on a subsequent visit.

Not seeing how url-based package management is safer when a package host can use a server that sends a special payload to certain requester ips, headers, cookies or referrer.

Until there are firm guarantees around what you get from a url, a trust-able third party is needed, even if just as an option.

</comment></comment><comment><USER107> Some people for the last decade: wouldn't it be great if node had a comprehensive, idiomatically coherent, thoroughly typed standard library ? Look, typescript is right here !

No-one, at all, for the love of jeebus: Do another node-like thing, but make it in rust _on top_ of C++ (or is the other way around ?), somewhat similar but generally incompatible, have a whole different set of APIs, a bunch of new tools and yet another package/module system.

</comment><comment><USER108> I don't understand how Promises help with backpressure.

</comment><comment><USER109> So I can import using the URL "[https://somekind.com/ofpackage.ts"](https://somekind.com/ofpackage.ts"), that's great but what if that random endpoint changes?

The benefit of NPM is that every package version is immutable...

Also first class Typescript support is great, but they are just using tsc internally... isn't that directly tying a typescript version to the DENO version?

</comment><comment><USER110> I'm probably just one more person among the hundreds who are missing something here but: if the big thing about deno is that you can directly fetch dependencies from source with, for example, a GitHub repo URL, instead of going to a package registry like npm, where the package is decoupled from the source, why don't you simply do this already by changing the package.json and swapping the npm identifier with a URL to the repo?

You can already do decentralisation with npm by simply not using`npm i some- package --save` and instead, modify the package.json yourself.

Now the problem with deno is that if I import 5 packages (locked to a specific version) across 50 files and I want to update them to a new version, am I really gonna need to go into every single file and change the URLs??

That's just insane, I get the whole idea of decentralisation but why can't we concentrate all packages into a single file??

Sire this is all good for distribution because you won't have to run `npm i` every time you want to run your program, but more often than not, I'm the one that's going to use my program and I don't mind running `npm i` beforehand and feel safe that I have all my packages downloaded and ready to go, instead of worrying that my program will fail at run-time because the URL for one of my packages is down..

</comment><comment><USER111> > We believe JavaScript is the natural choice for dynamic language tooling; > whether in a browser environment or as standalone processes.

I disagree with this assessment. Lua is still far superior as an embed-able scripting language/runtime. I suspect the preference for JavaScript is mostly due to the Deno developers' familiarity and preference.

<comment><USER112> > Lua is far superior

I disagree with this assessment.

<comment><USER111> LuaJIT is nearly 3x faster than V8 JavaScript the last time I checked. Just anecodal DDG search [0]. Maybe V8 has gotten faster since the last time I checked.

[0] [https://duckduckgo.com/?t=ffab&q=is+luajit+faster+than+v8+ja...](https://duckduckgo.com/?t=ffab&q=is+luajit+faster+than+v8+javascript%3F)

<comment><USER113> Lua also has a smaller footprint I think.

<comment><USER114> It has a worse standard library than Javascript. And its static typing solutions don't compare to Typescript.

<comment><USER115> Funnily enough the state of art in typed lua _is_ typescript: [https://github.com/TypeScriptToLua/TypeScriptToLua](https://github.com/TypeScriptToLua/TypeScriptToLua)

</comment></comment></comment></comment></comment></comment><comment><USER116> > TSC must be ported to Rust. If you're interested in collaborating on this > problem, please get in touch.

Have you talked with the TS people to see if maybe there are some bottlenecks that could be rewritten in Rust rather than rewriting everything? Even though I would love to have TSC in Rust, it seems like it would be a huge amount of work.

</comment><comment><USER117> > We seek a fun and productive scripting environment that can be used for a > wide range of tasks.

So Lua, but Javascript? Could be neat

</comment><comment><USER118> I think Deno is fine, and I think the project is interesting, but I also think those who want to use Typescript should do so, and stop pretending they're doing anything with Javascript. If I wanted deal with repetitive code like "function add(x: number, y: number): number {...}" I'd just use Java. There's reasons I love JavaScript, and not dealing with types is one of them. When is Typescript going to have its own version of the V8 engine and just leave JavaScript out of it? Honestly, it harkens back to the classic Microsoft Embrace, Extend, Extinguish strategy that I though we left behind in the early 2000s...

I like that Deno is resetting some of the underlying assumptions that Dahl made in Node. But I think he's throwing the baby out with the bath water. I actually _like_ and prefer an explicit node_modules directory. Grabbing everything I need, and then being able to zip it up as needed to save or share is convenient and easy. Not sure why so much effort was made to avoid this module pattern. I really think using URLs is going to be a maintenance nightmare. Instead of changing one entry in package.json (great for testing new code or tweaking something locally), I have find/replace all the imports? Seems very odd unless I'm missing something big. Also, not a fan of the hidden .deno cache directory, but whatever.

Having to send along a shell script in order to even _start_ an app is another problem. "Here's a JavaScript file which will do some task. In order to run it, you need to make sure you include these 10 command-line flags for security purposes. To make sure you don't forget them, I've included various shell scripts you can run depending on your platform." That's not improving anything.

<comment><USER119> > Instead of changing one entry in package.json (great for testing new code or > tweaking something locally), I have find/replace all the imports?

This is my biggest beef. When building large scale applications there are many more files with imports than a typical large scale golang project that uses the url import scheme. It's just going to be a really annoying thing to deal with. ATM I see deno being great as a replacement for nodejs scripts and smaller scale projects. But for massive projects I don't see the gain.

</comment></comment><comment><USER120> I have two questions: 1) How to port a node package to deno? 2) How to keep both a node and deno packages in the same repo?

Clearly without packages we are not going to use deno. Also I don't want to switch from well-proven packages like express/koa to an new unknown http server just because it supports deno.

<comment><USER121> There are some manual things you can do to ensure portability from Node to Deno:

* separate out the Node APIs from the rest of your application logic as much as possible as those will be different unrelated API conventions.

* convert your application from using _require_ to using ES6 modules. This won't work if you have more that few highly trivial dependencies as Node requires picking one way of importing files and that one way extends to your dependencies as well.

* Node uses callbacks for asynchronous logic where Deno uses promises, so ensure all callback functions are passed by reference so that the difference is an API difference instead of a logic difference.

</comment></comment><comment><USER122> > for await (const req of serve({ port: 8000 })) { > req.respond({ body: > "Hello World\n" }); > }

It's not the first time I see js iterators used and abused this way, and every time I feel that js and it's users are ready for full-blown monads and do notation instead.

</comment><comment> torb-xyz First-class TypeScript support is the thing that excites me the most about this. It's so annoying when you want to navigate TypeScript code from a dependency in Node and it kicks you to a TypeScript-definition file instead of the actual TypeScript source.

</comment><comment><USER123> I would really like a testing framework like AVA on deno, same amazing API of seperating parallel and serial tests and running them on multiple threads. Also I will need npm compatibility soon, once these are in, why would I ever write code in node.js?

</comment><comment> kalium-xyz Finally we can use it on production, great work everyone involved in making this happen!

</comment><comment><USER124> For anyone that's interested, here's a list of projects I'm interested in or use with new major versions in 2020: [http://maker.sh/2020](http://maker.sh/2020)

</comment><comment><USER125> I tried it briefly on a side project a couple of months ago. I like some of the ideas in it, but my editor tooling (which is TypeScript-ready but not Deno-ready) wasn't ready for it. I might revisit in a year or two.

</comment><comment><USER126> I don't want to be overly critical of a very well-intentioned and worthy effort, but it is looking less and less to me like Ryan and the rest of the Deno team understand what problems node.js developers care about. Specifically:

1\. The sandboxing via --allow-net, --allow-fs, etc is very odd to me. I don't recall hearing about a lot of security issues that could have been prevented by this. I mean, I suppose this won't hurt anyone, but it's certainly never something that I've wanted. I expect most people will simply white-list most access by default in all new projects.

2\. deno bundle: Initially, when I heard about this, I was excited. The need to bundle code via webpack and similar systems is one of the worst things about front end browser development. It introduces tons of complexity and makes debugging much harder. So I thought, wow, maybe deno is going to just give us a first-class solution to this problem that will just work. Nope. They are only concerned with bundling code such that it can be run elsewhere by deno. A friend put it thus: "we don't want bundlers anymore, so we're making deno bundle, the one true bundler!" "does it do any of the stuff that webpack does?" "mostly no, because it's not meant for that" Read the comments on [https://github.com/denoland/deno/issues/2475](https://github.com/denoland/deno/issues/2475) to get a sense of what I'm complaining about.

3\. URL Imports. Packages in node.js are stupendously easy to use. Making me import from a URL instead of typing `yarn add foo` and `import * as foo from 'foo'` does not make my life any easier. It certainly makes the implementation easier, and I'm glad to see the last of node_modules and path-climbing module resolution. But the URL-based system offers no equivalent that I can see to lock files and automatic upgrades (e.g. `yarn upgrade`), which are two crucial features. This is something that node developers need and want, and if Deno doesn't provide it, 3rd parties will. My worry is that we'll end up with competing third-party solutions and a fractured ecosystem, due to Deno's failure of leadership here.

4\. Stack traces: The single worst thing about using node is the frequency with which you get utterly useless stack traces that tell you nothing about the true source of the error. It was easier to debug C++ programs 20 years ago that it is to debug node.js apps today. But as far as I can tell, deno isn't making any efforts to improve this. That's ok, they don't have to fix every problem. But it does make me worry that they don't know what node.js developers actually care about, if this wasn't on their "must fix" list.

5\. Typescript by default. I really like typescript. I mostly want to use it instead of javascript these days. But tsc is slow. Slooooooow. Really really slow. I am worried that most deno programs are going to be very slow to start up in practice. (Before you say "caching", 99% of the time that you want to start a program, it's because you just changed the source code. caching can only do so much in this case). And I am extremely skeptical of the plan to build a new typescript compiler in rust.

I'll conclude with praising a few things that I am very glad to see: No more node_modules, Web APIs, and a promise-based stdlib.

</comment><comment><USER127> "It's important to understand that Deno is not a fork of Node - it's a completely new implementation. "

New implementation of WHAT? Is this a JS Engine, or a wrapper around V8? Which version?

Guys - whatever it is - I love it (!!!), but this is a very long and wordy article that does not well summarize the most relevant things, and uses words, long explanations for issues that I think are just a little specific.

"First Class Typescript" \- does this mean just 'transpilation at runtime'? Or does it mean something more hardcore? What does it mean at all?

This could be 1/2 as long a 2x more explanatory and precise.

Finally - it all looks super cool - but why specifically am I interested in this over things like Node? Speed, security?

Not to take away from the great work.

</comment><comment><USER128> This is interesting. Can you ship the Deno runtime with your runtime code? That's the thing that kills me about Javascript; having to assume the consumer has a runtime setup.

<comment><USER129> Compiling to a single binary is on the roadmap, but was dropped from 1.0

<comment><USER128> Great, thx, I'll definitely be keeping an eye on this project!

</comment></comment></comment><comment><USER13> Could take that one step further and run apps from URL's like the browser does. eg. deno [https://my.app](https://my.app)

</comment><comment><USER130> Is anyone else excited about a standard library out of the box?

</comment><comment><USER131> I do a lot of django. Does anyone know if it can handle backpressure as described in the deno announcement? Or is that typically seen only in a microservices context?

</comment><comment><USER132> Is the name Deno a play on shifting noDe over two spaces?

<comment><USER133> Yes. Maybe the next framework will be called "Done".

</comment></comment><comment><USER112> I want that hoodie but $100 is a little steep for me...

</comment><comment><USER134> This sentence, five paragraphs below, says what this is about:

> _Deno is a new runtime for executing JavaScript and TypeScript outside of > the web browser._

</comment><comment><USER135> Pet peeve: programming sites behind Cloudflare protection with email address protection enabled, because we regularly have things with at signs in them that aren't email addresses, which it mangles, ruining my standard no-JS experience:

      import { serve } from "https://deno.land/[email protected]/http/server.ts";

I mean, firstname.lastname@example.com _is_ a syntactically valid email address, but… protecting email addresses on _IP addresses_? Why, Cloudflare, why?

</comment><comment><USER136> As someone not from a js background, when would I use this? is it a drop in replacement for node with TS support? or something else

<comment><USER137> Deno will likely be well suited for network oriented server-side programs. Deno is not a drop-in replacement for node. It is an alternative JS runtime.

</comment></comment><comment><USER138> No. Without some kind of signature check (SHA256 or SHA512 or something more modern - just say No). it's tempting though :)

</comment><comment> Avi-D-coder This is fantastic. I would love to see vscode, coc, kde, gnome and other applications that use node extensions, to adopt Deno.

</comment><comment><USER139> Basically better node by creator of node?

<comment><USER140> Yes

</comment></comment><comment><USER141> The key is, can it re-use all those npm modules? otherwise the ecosystem is too large to take on these days.

</comment><comment><USER142> Does anyone know if there's an RSS feed somewhere for posts like these from the Deno project?

</comment><comment><USER143> What do you think which major projects will use deno in future and which not?

React/React Native/Expo?

</comment><comment><USER144> Soooooo yea. I'm excited.

(I've been using deno for ~6 months but I'm happy we hit 1.0!!!)

</comment><comment><USER145> Waiting for Denodify so I don't have to do anything to switch from node.js

</comment><comment><USER146> >JavaScript is the most widely used dynamic language

Wouldn't that actually be python?

<comment><USER84> There are way more browsers in use than Python runtimes. ;)

</comment></comment><comment><USER147> Seems like a good fit for bundling and/or containerization of js-apps.

</comment><comment><USER148> Main thing that would prevent me investing in this stack is that the runtime has been designed with typescript in mind. In a few years if the typescript thing blows over, you're left with a runtime and conventions skewed toward statically-typed programming patterns.

<comment><USER142> As someone who works with TypeScript extensively, TypeScript patterns are basically Javascript patterns - although perhaps with slightly fewer runtime type checks.

</comment></comment><comment><USER149> Would like to see a comparison between node and deno using http2 and TLS.

</comment><comment><USER150> This is fantastic news!

</comment><comment><USER151> I'm drawn to the simple beauty of the deno.land website.

</comment><comment><USER141> Installed and run the REPL deno, hit TAB twice there is nothing, node REPL give you auto-complete but there seems no for deno, not beginner friendly unfortunately.

</comment><comment><USER152> This is pretty fantastic. excited to try it.

</comment><comment><USER153> Nice. seems Deno is an anagram of Node.

<comment><USER154> In my mind, it came across as Deno(de) :)

</comment></comment><comment><USER155> I remember node stayed 0.11 or some sub 0.* numbers for the longest time. barely progressing version numbers, anything changed? Just wondering.

<comment><USER137> IMHO those were the golden years of developing with node.

</comment></comment><comment><USER156> > it's clear to us that ultimately the type checking needs to be implemented > in Rust

I hope this results in a faster typescript compiler.

</comment><comment><USER157> ELI5: why is this so much upvoted?

</comment><comment><USER158> NODE -> * swap * -> DENO

</comment><comment><USER159> Deno = no de, sorted ascending

</comment><comment><USER160> Its improved security model

</comment><comment><USER161> Added to the resume already

</comment><comment><USER162> 404 not found

<comment><USER163> [http://deno.land](http://deno.land) itself (without the trailing `/v1`) seems to work. It's "a secure runtime for JavaScript and TypeScript".

</comment></comment><comment><USER164> Hi, I've been thinking for a while that I want something like Deno that has something like WireGuard built in to it.

1) I make a public / private key pair.

2) I log on to a DNS-like system, and create an account for myself, upload my public key.

3) I start up a Deno server, giving it my private key, and I give it the address of the DNS. Deno uses my private key to inform the DNS that it exists and is serving traffic. (Much like any Dynamic DNS server.)

4) My friend does the same - makes a public / private key pair, finds a DNS he likes, uploads his public key, makes a Deno server and registers it with the DNS.

5) My friend and I trade DNS+public keys. It's a URL to the DNS that has the public key in it.

6) I go to some administrator page on my Deno, it looks a lot like this [1]. I create a new Connection, and plug in the DNS+public key of my friend. He does the same on his server.

7) On my admin page, I pick an app that I want to use to communicate with my friend. I can see a list of my Connections, and I just check off a box that the app has permission to communicate with that friend.

8) This app that I've picked, it only sees the world through an incredibly narrow API. It's like WireGuard. Deno handles all of the communication and permissions, much like Sandstorm.io. The first thing I want is just queued-up JSON messaging. The app can send and receive JSON messages. I envision that I want it to be in messaging mode (rather than "streaming online"), so it has something like ZeroMQ under the hood to pub/sub, client/server, all that. But roughly it has a bi-directional pipe for sending and receiving JSON and can queue up messages when the other server is offline.

9) I now have a sandboxed app that can't talk to the rest of the world, has its own private VPN-like connection to another process. All traffic is encrypted like WireGuard. The DNS aspect lets my friend move his server if the IP changes.

I feel like if some project kind of like Sandstorm, kind of like Dynamic DNS, kind of like WireGuard, and kind of like Deno all got together, they would make a beautiful thing.

When I think about how I wish Diaspora worked, as a way to replace Facebook, this is it. I wish it was built on top of something like this. This is the atomic unit of distributed, yet safe, that I wish internet apps were made out of. I imagine that I would be setting up hosting of the Deno server nodes for my friends and family, since I'm their tech support guy. But they'd be in charge of their own connections and apps in their nodes.

So, HN, time for you to tell me that it's 1) a terrible idea, 2) already exists, 3) why don't I just make it myself. Right? =)

[1] [https://alpha.sandstorm.io/demo](https://alpha.sandstorm.io/demo)

<comment><USER13> You can run wireguard in a Linux network namespace, then start the app in that namespace. You can also use Systemd or Docker.

</comment></comment><comment><USER165> Awesome!

</comment><comment><USER166> Nice, I deno about this.

</comment><comment><USER167> FWIW I tried to install it in a) Windows 10 via PowerShell, success, it took 1 min. b) Linux (WSL1) with curl, 2 min, failed. 3) Linux(WSL1) via cargo.10 min failed with this jewel:

> error[E0433]: failed to resolve: use of undeclared type or module > `proc_macro` \--> > /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/swc_ecma_visit_macros-0.1.0/src/lib.rs:25:20 > | 25 | pub fn define(tts: proc_macro::TokenStream) -> > proc_macro::TokenStream { | ^^^^^^^^^^ use of undeclared type or module > `proc_macro`

error[E0433]: failed to resolve: use of undeclared type or module `proc_macro` \--> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/swc_ecma_visit_macros-0.1.0/src/lib.rs:25:48 | 25 | pub fn define(tts: proc_macro::TokenStream) -> proc_macro::TokenStream { | ^^^^^^^^^^ use of undeclared type or module `proc_macro`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0433`. error: could not compile `swc_ecma_visit_macros`. warning: build failed, waiting for other jobs to finish... error: failed to compile `deno v1.0.0`, intermediate artifacts can be found at `/tmp/cargo-installFIkSV2`

Caused by: build failed

</comment><comment><USER168> _" Internally Deno uses Microsoft's TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow"_

TypeScript is way too slow for what it does and that's _ridiculous_ for a language that rejects useful features because it doesn't want to "stray too far" from ECMAScript.

In my view, typechecking doesn't belong in the "compiler" part of TypeScript. It should stay in the IDE. The compiler should just strip type annotations and do other trivial transformations.

</comment><comment><USER169> Here we go again guys [https://xkcd.com/927/](https://xkcd.com/927/)

</comment><comment><USER170> Why are we still treating dynamic languages as "scripting languages" as if you can't do the same thing one does in Go?

<comment><USER171> So at this fine grain of semantic detail, making strong statements about differing labels feels a little silly, but I have always thought that the difference is dynamic refers to typing, whereas scripting is usually a reference to the language being interpreted rather than compiled. Dynamically typed languages can certainly be compiled (I think Clojure qualifies here?).

<comment><USER25> And in that case, what do we make of QuickJS, which compiles JavaScript to bytecode?

</comment></comment></comment><comment><USER172> And the very first line of sample code is adding a dependency on someone else's code.

Reminds me of [https://npm.anvaka.com/#/view/2d/react- native](https://npm.anvaka.com/#/view/2d/react-native)

Good luck, though. Everyone lives in a different (mental) tribe I suppose...

<comment><USER173> The very first line of sample code is linking to Deno standard modules, basically the standard library for Deno, aiming to be feature complete enough to bring down the side of dependencies

</comment></comment><comment><USER174> The claim "TypeScript is an extension of the JavaScript language that allows users to optionally provide type information" is misleading. Typescript is not an extension of Javascript (not all javascript code is valid TS code). Typescript is a subset of Javascript plus mild type checking. For more details a nice article [https://medium.jonasbandi.net/here-is-why-you-might-not- want...](https://medium.jonasbandi.net/here-is-why-you-might-not-want-to-use- typescript-50ab0d225bdd)

<comment><USER114> This is such a weird point to me, maybe pedantry at best. Typescript is, to 99% of people, just Javascript with types. With few exceptions, TS compiles 1:1 to JS.

That blog article just looks like an intro for beginners who don't quite know what static typing entails. Yes, static typing is different from runtime checks, that's why it's static.

<comment><USER174> The devil is in the detail

</comment></comment></comment><comment><USER111> I guess I'm wondering why Deno is targeting V8 instead of Servo? Maybe I'm mistaken, but Servo [0] and Stylo [1] are both production-ready browser scripting and styling engines implemented in Rust.

[0] [https://servo.org/](https://servo.org/)

[1] [https://wiki.mozilla.org/Quantum/Stylo](https://wiki.mozilla.org/Quantum/Stylo)

<comment><USER71> You've made a category error; Servo is not a JavaScript engine.

<comment><USER111> > Servo is a modern, high-performance browser engine designed for both > application and embedded use.

What does that mean? "browser engine"

Does it execute JavaScript code?

Edit:

I bought your Rust book on Amazon, supposed to be delivered this Friday. I can't wait!

<comment><USER71> Servo puts all the parts of a browser together. SpiderMonkey is what Servo uses to execute JavaScript. That's shared with Firefox.

Ah cool! I hope you like it! :)

</comment></comment></comment></comment><comment><USER175> I won't be using Deno. For starters, I like javascript, not typescript, and I think Ryan was considering the idea of making Deno TypeScript only at one time. That is enough for me to never consider it alone.

I think it falls into the same category as Koa (TJs successor to Express) and the upcoming "Rome" project. Someone creates a successful open-source project and then at some point in the future decides to make a better one with questionable tangible benefit and various downsides of its own.

The downsides I can see of Deno so far are that it is slower than node, it is not compatible with any server-side node code because it has rewritten the standard library, and it is inspired and based on the Go standard library, seemingly using Go idioms and so on.

Its benefits are questionable, vague, and not really proven.

</comment><comment><USER176> Hi,

I'm the co-founder of [https://deno.services](https://deno.services) . We would like to make Deno first language in history comes with its own infrastructure.

<comment><USER177> Is there much point asking for signups when the only info there is is one sentence and a screenshot?

<comment><USER178> Don't you know? [https://unbounce.com/landing-pages/test-new-products-and- ide...](https://unbounce.com/landing-pages/test-new-products-and-ideas/) :)

</comment></comment></comment><comment><USER179> I think Deno is a mistake at this point... Yes we thank Ryan Dahl for his huge contributions to integrating libuv and v8 outside of a browser to create node.js but a lot of work has been created by a huge ecosystem of developers after this. I think this de-facto fork of node.js will only serve to create fragmentation, and confuse product owners about which platform to use.

<comment><USER180> If We were all follow your rationale, We will be all programing in COBOL still. Accept the pain of experiment and growing up.

<comment><USER179> Sometimes splitting a community is worth it, but it shouldn't be a decision made lightly. And Ryan Dahl should consider his words bear weight as the original creator of the platform. I think it's a fair issue for critique.</comment></comment></comment>


Ask HN: Remote Jobs. How to get started? - <AUTHOR>

Dear HN,
I'm a (web) front-end/UX-developer from Germany. I'm finishing my master degree right now and will have to get a job the next months, so I'm considering remote jobs, since I don't want to be bound to my workplace.
Most companies in Germany are rather conservative and want their people to be in-house most days a week. In other Europe countries this seems to be only a "bit" better.
Can I just apply for jobs all over the world and still stay where I want to work from there? Like USA or Canada?
Where do I need to pay taxes then?
Do I need a work visa for the countries I live in or the countries I have the job in?
If I don't want to do contract/freelancing work, how is my employment status if I got a job in another country, like the USA? <comment><USER2> In other countries you will need a work visa. For the USA and Canada that can be a long process (if you want to work there several months). The 90 day tourist visa doesn't allow you to work in the US though I know people who regularly work from there one month per year. As a German you can work from any other European country.

You need to pay income taxes where you live. For example if you lived in Germany for 8 months, then Italy 2 months and Spain 2 months you would need to file three income tax statements and each country is interested in the total you earned that year. Double-taxation agreements exist between most countries so even if you pay twice there is a legal way to get money back from one country.

On hackernews you read about digital normads who go to Thailand or Marocco to work from there. Most are ignoring the local tax laws, use a tourist visa and write their invoices with a business address from their home country (e.g. Germany).

With sales tax (VAT, MwST) you need to pay that for any client in Germany. For clients in the rest of Europe the client needs to pay the sales tax in their country (so called reverse charge, applies to cross-border software development). For clients outside of Europe you don't need to pay sales tax.

<comment><USER3> Just a couple quick notes:

a) USA has also 90 days business visas that are very easy to get.

b) I can't vouch for all countries in the EU, but in many, you only need to fill a report if you lived for more than 6 months there (168 days I think). So in your example, you would need to file tax in Germany, but for all income of the year (including the 2 months in Spain or Italy). It is different if you work for a company in Italy and Spain for those months, but if you are a 'nomad' for yourself, usually you only need to file in one country.

<comment><USER2> Excellent points. You're right: self-employment makes both options easier.

</comment></comment></comment><comment><USER4> I just started a remote job in November -- I am in the US working for a US company, but this advice still applies.

When I was looking for a job, the best source of remote jobs was StackOverflow careers. If you need an invite, write me. There was a large variety and many would hire from Europe (some were in Europe). The place I work, Trello, hires from Europe.

There are other remote job sites (weworkremotely.com) to check out. They weren't good for me -- but, they may be good for front-end/UX.

You should ask the place you apply, but anywhere with an established remote- friendly environment will set things up so your taxes are as close to possible to what it would be if you just worked for a local place. This is something to work out with their accountants and yours, but it would be a good sign if they already had German employees.

The biggest impediment to you being hired remotely is that you don't have a track-record (I assume) of working remotely for others. It would be good to prepare an answer to why you would be disciplined enough to do this for your interviews -- it will come up -- in any case, you should bring it up, because they will be thinking it.

<comment><USER5> SO Careers requires an invite?

and one more question, is this your first job? Or first job as remote?

<comment><AUTHOR> Yes it does. I can send you one, if you like.

<comment><USER3> Does careers require an invite or the "My Profile" part requires one? I have a careers account where I found my last job (but don't remember if I was invited or just signed up) but still need an invitation to create a "My Profile"

<comment><AUTHOR> I don't know. They just told me one day, that I should use careers and gave me 5 invites.

<comment><USER3> if you have then, can you send one my way? ;)

<comment><AUTHOR> Consider it done.

<comment><USER3> It does seem the invitations are for the profile section but you can still register normally.

In any case, thanks!! Seems like an interesting way to create a profile. Wonder how 'valuable' this is compared to LinkedIn or a simple webpage.

<comment><AUTHOR> I don't know. Never got a job with this :\

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> I have a question. Is it okay to go for remote in early career? There was a discussion in Reddit, and people had suggested that during initial years lots of nurturing happens and it cannot be done via remote. And also it's effective to work under a mentor, physically, for a beginner. So basically they were against going for remote for an absolute beginner.

How true is that with employers?

(In my case, I have working experience of 10 months. Later I had to resign my job for some personal reasons. Soon I will be looking out for jobs. Should I consider remote or not?)

<comment><USER6> I think this is very true. Go work, spend as much time as you can learning in person. After a few years, you can work out an arrangement to work remotely.

</comment></comment><comment><USER7> Hi :)

I am trying to put together a little team and right now I am looking also for front end developer.

It will be more a free lance position than a standard position, but if you are interested feel free to write me, you should see my email in my info contact...

</comment><comment><USER8> You need to approach the company and provide them what you can offer to them, it shouldn't be the other way around "what can your company offer me?"</comment>


Ask HN: Why doesn't SSH implement a 'Perfect hash function' for known hosts - <AUTHOR> I know that this is a bit paranoid, but once/if you get access to someone's computer, you're pretty much left with a catalog of other systems that you might have access to in ~/.ssh/known_hosts
My question is: why aren't those entries hashed in a way that there are no collisions? if someone wants to verify if the fingerprint is ok, there should be a command that given the domain would print the existing fingerprint (by calculating the hash meanwhile)<p>Ofcourse, the Hash would have to be salted (and/or peppered) by system.<p>*Perfect 'hash' function: https://en.wikipedia.org/wiki/Perfect_hash_function <comment><USER2> Huh? known_hosts files _are_ hashed by default.

If yours aren't, it's probably because you have `HashKnownHosts no` in your config somewhere.

<comment><AUTHOR> gosh, nevermind you're right, I just checked and on a 'recent' Linux VPS that I had spinned out and indeed they are. But they weren't on my Mac and I had never noticed that detail on new machines. All of the other ones where I looked into ~/.ssh/known_hosts had plain hosts there.

on a side note: it's great to know that it's supported :)</comment></comment>


Q&A with Mike Kimelman: How prison changes you - <AUTHOR> http://www.cnbc.com/id/102623598 <comment><USER2> [the interviewer asks why didn't he take the plea deal]

> [Because] I didn't think I broke the law, and if I wasn't willing to stand > up and say that, how could I look my children in the eye and tell them with > a straight face they should stand up for the right thing, or the underdog, > as I try to teach them to do.

This is why I don't moralize at other people ever, and why I think the law is a poor substitute for morality. I believe him when he says 1) that he didn't think he did anything wrong, and 2) that the choices in front of him looked different that how they looked to third-party observers.

It's stupidly easy to tell someone, "You should have [taken the plea deal|not done that in the first place|...]." But I think people say those things to 1) distance themselves from their interlocutor and 2) say something that feels good to say, but is useless (not actionable at this point!), obvious dreck to hear.

Of course I'm not faulting the interviewer for asking the questions in this case; the answers were enlightening.

Marshall McLuhan had a great quote against moralizing: "Don't ask whether it is right or wrong. Instead try to figure out what is going on!"

</comment><comment><USER3> I'm happy Kimelman got the best out of it. It's nice to read experiences that don't involve any kind of intimate assault.

The system is designed not to _re_ habilitate, but to _de_ humanize the inmates, while guards often support the lowest forms of behavior.</comment>


Venture Capital Funnel Shows Odds of Becoming a Unicorn Are About 1% - sahin-boydas https://www.cbinsights.com/research/venture-capital-funnel-2/ <comment><AUTHOR> So only about 400 startups of the 1100 that they tracked that took VC funding ended up with a status of "not dead yet". About 25 were wildly successful exits.

So, the raw odds of being the co-founder of a VC raising startup (using USA population) are about 1 in 150,000. That's actually pretty decent odds.

The chance of being the co-founder of a relatively successful VC funded startup are 1 in 412,500.

The chance for being a unicorn cofounder? 1 in 7,500,000.

Of course, these statistics should be weighted for ethnic, race, education, family backgrounds etc. There are more white/asian male CEOs than black female CEOs for example, which is a tragic and depressing reality.

For context, the chance of turning $10,000 into $3,500,000 through a private arrangement with a casino is about 1 in 36.</comment>