Hacker News Reader

Comment by Etheryte | Hacker News Reader

I'm very happy with the direction Deno is taking in its development. At the same time, I'm not sure when I would feel comfortable deploying something to production with it. Is anyone here running Deno in production?

View on HN

We run a medium sized trading system (20 microservices) in Deno for about a year now. There have been a few runtime quirks but they have currently all been ironed out. I love the approach that Deno takes with respect to permissions which allows you to strictly specify which urls your program can access, which files/directories can be read/written, etc.

How are JS's scientific computing and stats libraries?

Python.js ?

There is brain.js and tensorflow.js.

It's not anywhere near python

You are most likely aware but just to point out, Node now also has a version of the permissions features [0] (not sure on parity but it was obviously deno inspired) behind an experimental flag!

[0] https://nodejs.org/api/permissions.html

I have a small Deno powered bot that generates Shopify listings from some inputs. It’s been running for a few months with no crashes or restarts.

I think it really comes down to what APIs or packages you need. I have had trouble with projects such as Prisma and wouldn’t do that in production as the generated output is slightly different for some reason (haven’t had time to inspect).

We have also run it in production for about a year, but it's a tiny metrics collector and doesn't do anything fancy at all. But writing and deploying it end to end was a fantastic and quick experience.

Why wouldn't you be comfortable with running it in production?

Just don't use the parts labeled as "experimental" or "beta" and it's very production-ready and stable.

Because things like adoption and longevity of a project correlate with it not being abandoned, etc. Dealing with abandoned tech in your stack sucks

It's still just V8 under the hood so IMHO it's not nearly as risky as if someone just wrote their own bespoke JS interpretor. And everything around V8 is in rust so there's less chance of catastrophic footguns and crashes (still non-zero, but way more trustworthy than a new C/C++ project).

IMHO the biggest risks would be misunderstanding of capabilities/configuration particularly around its stricter sandboxing, i.e. forgetting it won't let you access file system or network by default and your testing failing to capture some dependency there.

Reply on news.ycombinator.com