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

51–60 of 598 posts

Re: Deno 1.0

#51

Post by rosywoozlechan »

gen220 wrote: post #32

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 , it's a fantastic talk. The last 10 minutes are a pitch for what a "better Node" would look…

> which we should probably think of as bourne-again node.

Or maybe as Perl 6

Re: Deno 1.0

#52

Post by mrkurt »

VWWHFSfQ wrote: post #36

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

It depends what you mean by "superior". JavaScript (well v8) is far safer as a scripting runtime. And there are a ton of existing JS libs for solving problems. AND there's TypeScript, which is pretty great.

Re: Deno 1.0

#53

Post by IggleSniggle »

Gene_Parmesan wrote: post #35
swah wrote: post #31

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

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?).

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

Re: Deno 1.0

#54

Post by mrkurt »

pedalpete wrote: post #44

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.

It's basically the same "exposure" as importing a random npm, but it has the benefit if being explicit when you do it.

It's also exactly what the websites you visit do. ;)

Re: Deno 1.0

#55

Post by gameswithgo »

VWWHFSfQ wrote: post #36

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

i suspect it is more that the whole world is familiar.

Re: Deno 1.0

#56

Post by frank2 »

pedalpete wrote: post #44

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.

Does it also terrify you when code running in a browser does it?

Re: Deno 1.0

#58

Post by gen220 »

lghh wrote: post #45
gen220 wrote: post #39

Earlier quoted context omitted.

such is the curse of having the audacity to develop software :)

Not necessarily. I prefer trying to improve what we have verses making a new thing every time we have a relatively minor disagreement, even if that disagreement is with our past self. EDIT: I'd like to add that clearly he is able to spend his time as he wishes.

I generally agree. Although, some of these are pretty "opinionated" breaking changes (promises all the way down, package manager changes). It would be hard to convince the whole node community that these upgrades are worth the risk forking in a python 2/3-esque way.

Forcing TS is a change node could adopt in the next major version if everybody agreed, but the node community might be too big and diverse at this point, to make such an opinionated switch.

Re: Deno 1.0

#59

Post by cryptica »

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

Re: Deno 1.0

#60

Post by Saaster »

pedalpete wrote: post #44

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.

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.
Post reply on HN