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

Deno.js in production

medium.com

Post reply on HN
Print view View original

71–80 of 100 posts

Re: Deno.js in production

#71

Post by Osiris »

ricardobeat wrote: post #69
dimgl wrote: post #67

I haven't had the same success with Deno that I expected. At first, I was shocked by how good the tooling is, and I was super happy with its dependency management. All of the problems started once I started getting into actual business logic. `redis` and `ioredis` `npm` packages don't work with Deno, even with the Node compat layer (I tried). So you have to use the Deno driver for Redis. But you look up the library f…

On the other hand, not being able to bring all of the node.js package ecosystem along can be considered a feature.

It's not a feature if you can't build the project you are trying to build.

Re: Deno.js in production

#72

Post by SkyPuncher »

ricardobeat wrote: post #69
dimgl wrote: post #67

I haven't had the same success with Deno that I expected. At first, I was shocked by how good the tooling is, and I was super happy with its dependency management. All of the problems started once I started getting into actual business logic. `redis` and `ioredis` `npm` packages don't work with Deno, even with the Node compat layer (I tried). So you have to use the Deno driver for Redis. But you look up the library f…

On the other hand, not being able to bring all of the node.js package ecosystem along can be considered a feature.

I don't really understand this take.

Yes, there are a lot of packages available - but that gives you choice.

Re: Deno.js in production

#74

Post by gernb »

danenania wrote: post #7

The security model is a big one for me. If they could extend the permissions system to work for individual dependencies, they could solve one of the biggest security issues facing developers right now. Especially if policies could also be applied to node packages. Are there any plans to move in this direction? It seems like if you can do it for the full app, you should hypothetically have the capability to make it li…

you will not solve the dependency problem with permissions. You will only solve it by reducing dependencies and reviewing code before you updated dependencies

adding permissions will do nothing except add ridiculous overhead and complexity such that to get anything done devs will just give all permissions

Re: Deno.js in production

#75

Post by benatkin »

Sephr wrote: post #61

The title is very misleading. Deno is not written in JavaScript and is never referred to as Deno.js in any official sources. Deno is written in Rust.

Much of Node.js is written in C, yet it's still called Node.js.

Deno has some JavaScript/TypeScript in it. On GitHub https://github.com/denoland/deno is 22.8% JavaScript and 13.2% TypeScript, and https://github.com/denoland/deno_std is 68.2% JavaScript and 31.6% TypeScript.

So to me the title is misleading about the name (Deno is certainly not named Deno.js), but not about what Deno is written in.

Re: Deno.js in production

#76

Post by zdragnar »

danenania wrote: post #60
zdragnar wrote: post #29

Earlier quoted context omitted.

IIRC there are all sorts of issues around monkey-patching prototypes, shared objects between modules, etc. which would readily allow escaping any sort of module / dependency level permissions system. You'd probably be better off pitching a typescript subset language with its own compiler / interpreter rather than trying to shoehorn it into V8.

These seem like solvable problems. Prototype modifications are rare these days and should probably be restricted in the same way that system/network access is. Shared objects between modules also seem like an edge case apart from callbacks? I posted an idea on how to handle callbacks upthread a bit: https://news.ycombinator.com/item?id=31326123#31332061

System and network access are all done via the runtime library functions, which are easy to control.

Changing prototype access almost certainly involves modifying V8 in unpleasant ways, and I'm not sure how you would get around the overhead of deno needing to the call stack on every function call- statically analyzing when a function is operating in one context or another is certainly not a trivial problem.

Re: Deno.js in production

#77

Post by MuffinFlavored »

dimgl wrote: post #67

I haven't had the same success with Deno that I expected. At first, I was shocked by how good the tooling is, and I was super happy with its dependency management. All of the problems started once I started getting into actual business logic. `redis` and `ioredis` `npm` packages don't work with Deno, even with the Node compat layer (I tried). So you have to use the Deno driver for Redis. But you look up the library f…

> `redis` and `ioredis` `npm` packages don't work with Deno, even with the Node compat layer (I tried).

I'd love to hear specifically what didn't work and how close the Deno team is to maybe fixing those sorts of issues. Not that they owe that to us open-source wise, just curious as like... otherwise you are right. We're starting the ecosystem again over from scratch.

Re: Deno.js in production

#78

Post by danenania »

gernb wrote: post #74
danenania wrote: post #7

The security model is a big one for me. If they could extend the permissions system to work for individual dependencies, they could solve one of the biggest security issues facing developers right now. Especially if policies could also be applied to node packages. Are there any plans to move in this direction? It seems like if you can do it for the full app, you should hypothetically have the capability to make it li…

you will not solve the dependency problem with permissions. You will only solve it by reducing dependencies and reviewing code before you updated dependencies adding permissions will do nothing except add ridiculous overhead and complexity such that to get anything done devs will just give all permissions

Reducing dependencies is generally good (though often at odds with productivity), but I doubt we'll solve it through just reviewing code. Even with a small number of dependencies, the full tree can be absolutely enormous, and there are many ways to obfuscate attacks. It's a severe needle-in-a-haystack problem.

I don't see why permissions have to add "ridiculous overhead and complexity". Most dependencies need very limited (if any) system or network access. Locking those down would be a huge win, and it makes reviewing updates in large dependency trees realistic since you can zero in on permission changes.

Re: Deno.js in production

#79

Post by threatofrain »

mattwad wrote: post #43
RussianCow wrote: post #15

Earlier quoted context omitted.

> The consequence is their hiring pool is also that much smaller. In the current market, unless you're a big company that gets flooded with applications on a daily basis, why would you ever reduce your hiring pool arbitrarily? If you're a 13-person startup with good funding, you want all the candidates you can possibly get. Excluding potentially great engineers because they've never worked with Deno doesn't make any…

Especially if you're a product-focused startup, the last thing you may actually need is an enthusiast for a language. 90% of the time you want people that just want to use the right tool for the job.

We're contending with the reasoning behind an observation, but the observation is already useable to the author of the post — if true. Is the author of the post seeing improvements in candidate quality because Deno is actually a proxy for burning the midnight oil? Who knows. If we generalize to Java vs Go will the observation hold? Who knows.

But as chrisco255 pointed out, neither usage of Deno nor applying a weight to some observation will reduce your hiring pool.

I would also say that a technological perspective of "right tool for the right job" is somewhat independent to the expensiveness of your hiring pipeline. Sometimes Erlang is the right tool for the right job, but that undoubtedly changes the experience of hiring.

Re: Deno.js in production

#80

Post by wy35 »

my69thaccount wrote: post #14
jonny_eh wrote: post #12

Earlier quoted context omitted.

"Too easy to get started" is just gate keeping.

On one hand, JavaScript being easy makes programming accessible. On the other hand, the state of programming is terrible and getting worse. So you can't say if it's bad or not.

It’s not getting worse. Go ahead and make a relatively complex app with jQuery 2.0 and let me know how it compares to spinning up a Next.js app.
Post reply on HN