Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno 1.0

deno.land

Post reply on HN
Print view View original

21–30 of 598 posts

Re: Deno 1.0

#21

Post by williamdclt »

seleniumBubbles wrote: post #13
threatofrain wrote: post #9

> 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 exist…

What is the ongoing performance cost of using the official TypeScript compiler for long-running applications? Or is this primarily a concern of startup time for scripts and short-lived programs like CLIs?

AFAIK, tsc is just a compiler, not a runtime. Once you compiled, you're just executing javascript so it only impacts startup time.

ts-node is a runtime able to run TypeScript. It is definitely much much slower at execution, not just at startup time. It's useful for hacking around, I use it as a REPL but even for a dev environment it's faster to use tsc's incremental compilation with a file watcher, and execute the resulting JS

Re: Deno 1.0

#22

Post by hayd »

seleniumBubbles wrote: post #13
threatofrain wrote: post #9

> 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 exist…

What is the ongoing performance cost of using the official TypeScript compiler for long-running applications? Or is this primarily a concern of startup time for scripts and short-lived programs like CLIs?

It's purely in the compilation step, V8 executes javascript.

Re: Deno 1.0

#24

Post by javajosh »

networkimprov wrote: post #19
firloop wrote: post #10

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

Who somehow still hasn't realized that backends written in Javascript don't scale very well. Automatic asynchronicity only buys you so much. I'm writing as a former Node.js user.

"Automatic asynchronicity[sic]"?! Node and all async io is cooperative multi-tasking, the opposite of automatic. The node event loop is a thin wrapper around the epoll() system-call (or one of its equivalents), and leaves the details of multi-tasking to the app developer. It's no wonder you weren't able to scale under node if you thought something was happening automatically for you!

Re: Deno 1.0

#25

Post by piscisaureus »

cocktailpeanuts wrote: post #18

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?

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

Re: Deno 1.0

#26

Post by root_axis »

networkimprov wrote: post #19
firloop wrote: post #10

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

Who somehow still hasn't realized that backends written in Javascript don't scale very well. Automatic asynchronicity only buys you so much. I'm writing as a former Node.js user.

Why do you say this?

Re: Deno 1.0

#27

Post by klodolph »

ahupp wrote: post #17
rvz wrote: post #12

Earlier quoted context omitted.

A note on Deno and the safety of its V8 bindings: > All of the V8 source code is distributed in the crate itself. Finally rusty_v8 attempts to be a safe interface. It's not yet 100% safe, but we're getting close. Being able to interact with a VM as complex as V8 in a safe way is quite amazing and has allowed us to discover many difficult bugs in Deno itself. We'll also have to wait on who will be the first to have a…

For this sort of problem Rust's safety guarantees don't buy you all that much. If you're generating machine code and implementing a GC that's not the sort of thing that Rust's typesystem can prove correct. That said, a rust JS runtime would be amazing just because it's easier to integrate into rust projects.

Well, sure, but a big chunk of the bugs in JRE were in the library, not the code generation or GC.

Re: Deno 1.0

#28

Post by spankalee »

threatofrain wrote: post #9

> 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 exist…

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.

Re: Deno 1.0

#29

Post by snek »

ravenstine wrote: post #7

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.

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))`)

Re: Deno 1.0

#30

Post by omniscient_oce »

m00dy wrote: post #23

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

Is there much point asking for signups when the only info there is is one sentence and a screenshot?
Post reply on HN