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

Deno Queues

deno.com

Post reply on HN
Print view View original

21–30 of 168 posts

Re: Deno Queues

#21

Post by Exoristos »

015a wrote: post #10
norman784 wrote: post #6

Earlier quoted context omitted.

Last time I checked deno was a runtime not a programming language

'.deno' files are not drop-in compatible with any other typescript-esque runtime, which I think is a reasonable enough bar to say that its a different programming language. And not just because of the standard library; Deno supports e.g. URL-based import paths, which have very low support in other ECMAScript-ish languages like Node. Generally: the terms "programming language" and "runtime" are synonymous. There are a…

Node is not a language.

Re: Deno Queues

#22

Post by skybrian »

shafyy wrote: post #12
vorticalbox wrote: post #4

Earlier quoted context omitted.

You're getting charged for the replication of deno kv across all regions when you use deno.deploy. KV is free to use locally as I assume this will be too.

Sure, but genuine question: How easy it is to run my own infrastructure for Deno Queue, and, crucially, how can I know that it will still be as easy and transparent in 5 years from now when the VCs want to see some $$$. That the company developing Deno and the services that monetize Deno is the same is a major conflict of interest. And if history is of any guide, in the end economic incentives always win, no matter h…

When imagining future scenarios, maybe don't get too fixated on one? Another possibility is that competitive service providers will implement the same services.

(It didn't really happen with App Engine, but this seems like a cleaner API?)

Re: Deno Queues

#23

Post by locallost »

lopatin wrote: post #17

> Leveraging public cloud infrastructure has traditionally demanded sifting through layers of boilerplate code and intricate configurations, often monopolizing a significant chunk of the developer’s time and energy. I don't buy this line of reasoning. At the end of the day we are building infrastructure that needs to be reliable. Spending 30 minutes to set up an SQS queue (proven technology) doesn't sound as bad as p…

How do you know it's a toy queue?

Re: Deno Queues

#24

Post by lucasyvas »

I actually do quite like the overall idea of having a unified API at the language level that a (configurable) runtime can provide implementations for. Sure, in some cases an API might not be easy to abstract over due to underlying concerns, but in a lot of cases it does work.

It does show a level of understanding by the language creator that they know how the language can and probably should be used - I like how KV defaults to SQLite locally and takes on new meaning in a hosted environment. I haven't seen, but as long as you can actually override the behavior to use your own KV/queue technology (so long as it satisfies the interface) I see absolutely no issue with this.

There is a huge benefit where the code always looks the same for common things we all need to do. I wouldn't mind seeing other languages take an overall stab at this so there is some choice other than JavaScript.

Re: Deno Queues

#25

Post by paxys »

skybrian wrote: post #18
paxys wrote: post #14

Earlier quoted context omitted.

I have tried to be excited about Deno, but just don't see it. What are they doing that hasn't already been done a hundred times in the past? Deno itself is essentially Node.js + automatic TS compilation (which would otherwise have been 1 extra config file). When the project launched they made a big deal about escaping from the messy NPM ecosystem, but then ended up having to turn around and add support for it, taking…

I'm not that familiar with these alternatives. What's a good service provider you recommend for a persistent KV store?

- Redis

- ScyllaDB

- Riak

- Couchbase

- Cloudflare KV

- Many different AWS offerings (DynamoDB, ElastiCache)

- Similar alternatives from Google & Azure if you are in those ecosystems

Of course there's nothing unique about a KV store. You can use literally any SQL or noSQL service out there, or set up your own in any way you want.

They also all have the advantage that you will get bindings for every language, not just Deno.

Re: Deno Queues

#26

Post by 015a »

paxys wrote: post #9
catlover76 wrote: post #2

I don't want my programming language to "implement" task queues and charge me for it. What is this edit: people seem to be getting hung up on the "runtime" v "programming language" distinction. I'm not sure why--it's weird to me that this is "part of the language + runtime" at all. Clearly, reasonable people can disagree about that, but hopefully on points more substantive than pedantic If tomorrow, someone started a…

You don't have to use their hosted service.

They actually have zero documentation I can find for using DenoKV outside of the Deno Deploy environment. It may be possible, or you can always use Deno without using DenoKV, but I think the statement "you have to use their hosted service" isn't inaccurate.

Re: Deno Queues

#27

Post by herpdyderp »

paxys wrote: post #14
nmca wrote: post #7

I find deno to be very exciting. Viable business model, great ergonomics, glorious lack of bullshit configuration busywork.

I have tried to be excited about Deno, but just don't see it. What are they doing that hasn't already been done a hundred times in the past? Deno itself is essentially Node.js + automatic TS compilation (which would otherwise have been 1 extra config file). When the project launched they made a big deal about escaping from the messy NPM ecosystem, but then ended up having to turn around and add support for it, taking…

Deno is compatible with web code to a much deeper level than Node.js is. As the Deno website puts it: "Built with web standard APIs". This might not make a difference to most. Personally though, as someone who strives really hard to share code between frontend and backend, I'm excited for it. This is pretty much the only reason I see Deno eventually winning out over Node.js (in the long run).

I don't have the time to try to port any of my meaningful projects to it right now, but I look forward to the day when I can do so.

Re: Deno Queues

#28

Post by sebringj »

I'm currently using Deno deploy and found it to be fantastically performant and dumb simple for my lone wolf project. I'm experienced in AWS development in larger teams and it is nice to see a move away from complexity for a change where you can easily set something up without having to think about setting it up at all. The DNS stuff was just dead simple as well and automatic ssl certs was super nice. I have 0 complaints for what this is trying to be and am excited for the road map.

Re: Deno Queues

#30

Post by herpdyderp »

Exoristos wrote: post #21
015a wrote: post #10

Earlier quoted context omitted.

'.deno' files are not drop-in compatible with any other typescript-esque runtime, which I think is a reasonable enough bar to say that its a different programming language. And not just because of the standard library; Deno supports e.g. URL-based import paths, which have very low support in other ECMAScript-ish languages like Node. Generally: the terms "programming language" and "runtime" are synonymous. There are a…

Node is not a language.

and browsers, the other main JS runtime, is certainly not a language either.
Post reply on HN