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

171–180 of 598 posts

Re: Deno 1.0

#171

Post by jfkebwjsbx »

Roboprog wrote: post #134
spankalee wrote: post #28

Earlier quoted context omitted.

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

I would rather have Clojurescript than Typescript, but absolutely, less is more, and it feels like a bad idea to tie implementation of this runtime to another dependency. My love of the C++, Java, C#, ad nauseum, lineage of Enterprisey OOP languages turned to hate about 15 years ago, though, so take my assessment with a grain of salt. “C with classes” seemed like a good idea, we were told back in the 80s in school, s…

GC is impractical in many domains.

And in the 80s it was even more so due to CPU and RAM performance.

Re: Deno 1.0

#172

Post by bgdam »

ricardobeat wrote: post #162
bgdam wrote: post #153

Earlier quoted context omitted.

Except that now, the download deps in CI step can fail if one of hundreds of websites for my hundreds of dependencies goes down. If the main NPM repository goes down, I can switch to a mirror and all of my dependencies will be available again.

You answered your own question. Nothing stops you from using a mirror with deno too.

Which again brings me back to something I'm still not understanding - How is Deno's package management better than NPM if it is extremely similar to NPM, but slightly less secure?

I'm only asking because lots of people seem to be loving this new dependency management, so I'm pretty sure I'm missing something here.

Re: Deno 1.0

#173

Post by cphoover »

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.

Re: Deno 1.0

#174

Post by mrkurt »

bgdam wrote: post #151
aazaa wrote: post #138

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

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

Sometimes it's ok to think "this project isn't for me" and just leave it be. The cynical-security-concern act is boring.

Re: Deno 1.0

#175

Post by turblety »

jfkebwjsbx wrote: post #170
turblety wrote: post #136

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

Don't ever think of trying a compiled language like C++ or Rust, then :)

I won't :P

But in seriousness, Go compiles like lightening for me. But yeah, I think everyone has their own needs when they choose their tools. I choose Node for its speed at development and runtime.

Re: Deno 1.0

#176

Post by mrkurt »

bgdam wrote: post #172
ricardobeat wrote: post #162

Earlier quoted context omitted.

You answered your own question. Nothing stops you from using a mirror with deno too.

Which again brings me back to something I'm still not understanding - How is Deno's package management better than NPM if it is extremely similar to NPM, but slightly less secure? I'm only asking because lots of people seem to be loving this new dependency management, so I'm pretty sure I'm missing something here.

I like it because it's simpler. I know what happens when I import from a URL. I'd have a hard time whiteboarding exactly what happens when I `npm install`.

Re: Deno 1.0

#177

Post by steveklabnik »

pknopf wrote: post #126

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

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)

Re: Deno 1.0

#178

Post by fctorial »

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.

clojure.jar comes with tools.deps. It needs jvm as well though.

Re: Deno 1.0

#179

Post by batmansmk »

bgdam wrote: post #153
batmansmk wrote: post #147

Earlier quoted context omitted.

To solve your issue, you would do exactly how you do your node deployments: download the deps in a folder in CI, then deploy the whole build.

Except that now, the download deps in CI step can fail if one of hundreds of websites for my hundreds of dependencies goes down. If the main NPM repository goes down, I can switch to a mirror and all of my dependencies will be available again.

To be the rubber duck, if wiping the cache at each build is a risk to your CI, what could you do to keep your CI up?

1 - not wipe the cache folder at each build? It's easy and secure. Oh and your build will be faster.

2 - use a cached mirror of the deps you use? It's like 10min to put in place and is already used in companies that care about security and availability anyway.

3 - you have https://deno.land/x if you want to put all your eggs in the same npm basket

Re: Deno 1.0

#180

Post by bgdam »

mrkurt wrote: post #174
bgdam wrote: post #151

Earlier quoted context omitted.

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

Sometimes it's ok to think "this project isn't for me" and just leave it be. The cynical-security-concern act is boring.

Contrary to the impression I seem to have given you, I'm actually super excited about Deno and am planning to write my next MVP app in it.

That means that I am actually a lot more vested into it, and if I want to put it in production, then I have to be concerned about things like this.

When somebody says they think X is broken, and they present a solution Y which they say is better, I am definitely entitled to ask why they think Y is better when I can't see the difference.

Post reply on HN