Live data from Hacker News

Deno Queues

deno.com

91–100 of 168 posts

Re: Deno Queues

#91

    With grand promises rode the ploy
    Venture capital, ahoy!
    We make a lovable product to capture audience
    Vendor lock them at the earliest convenience
    Hey look at our awesome developer experience
    Add ANSI and emojis and comments saying it’s genius
    Some next level tech, plebs just don’t get it
    Next round of funding, we’ve already spent it
    I took the big dough, got puppets and framed it
    R-O-I is bad though but layoffs gon’ fix it
    Never mind the drama *cough* are ya gon’ install it
    Run it, ship it, kill yourself with working on it
    Entangle your business with it
    Tell the client to deal with it
    Bring it to the big wig
    Get ’em to sign off on it
    Crown your own sh*t
    Dogfood is tasty, ain’t it

Re: Deno Queues

#92
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?

Presumably everything AWS offers is way more battle-hardened and with stricter SLOs just due to the sheer volume of their customers.

But people are way too afraid of simple tech these days. If there aren’t dedicated QA and Ops teams, at least 2k GitHub stars, it’s not web-scale™ and meant to run on a fleet of 726 servers at minimum, it’s not to be trusted!

Re: Deno Queues

#93
post #36

I think what Deno is aiming for here is actually very forward thinking. I'm using Go for the first time this year and some aspects of the language are very C like. Of the list of things that isn't C like (e.g. GC allowing one to return what look like stack allocated pointers from functions) there is the obvious inclusion of things like `map[string]string`. I bring this up because it struck me that inventing a languag…

In this case, they've also documented the remote connection protocol: "KV Connect" https://github.com/denoland/deno/tree/main/ext/kv#kv-connect I kicked the tires on this with a pure TS implementation of the protocol called kv-connect-kit that gives you the KV client api in any Javascript runtime (including Cloudflare workers, which does not have anything Deno namespace related) - github: https://github.com/skymethod…

This library looks really cool, love the idea of unifying the api across various envs is great!

Re: Deno Queues

#94
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…

I don't recall SQS taking anytime to set up queues, at least when using Celery (python task queue). IIRC you just name it in your code and use it.

That's just at the codebase end of it.

But at the infra end of it, it's a different story. AWS is suited towards a very different scale of development effort than Deno currently is. The effort required from scratch to securely and reliably get to a point where a dev can just name a queue is substantial in AWS. You really need account hierarchies, guard rails, roles, permissions, delegated IaC etc etc in place to be able to do that - otherwise it eventually gets out of hand.

AWS is geared towards larger dev teams or groups of dev teams, while (to me at least without using it) Deno seems far more oriented at the smaller scale set and forget PaaS oriented teams - eg Heroku refugees etc. Those teams could very well outgrow Deno and need AWS at some stage though.

Re: Deno Queues

#95
post #14
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…

With all those alternatives you need to spend time installing libraries, then for each environment you need to create the db, and setup environment variables. You’ll also probably want to figure out a local environment.

With deno all that setup/configuration is handled by deno. There’s obvious trade offs but I think what deno is doing is pretty cool.

Re: Deno Queues

#96
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 use Deno because I couldn't be bothered to figure out the Node ecosystem and how to actually wire together the Typescript compiler, package json, builders and bundlers, etc. I just do not care and the mess of tooling is frankly exhausting to wade through. Deno Just Works for me. `deno run file.ts` and you are good to go. Not to say it's been 100% smooth sailing; I have hit a few rough patches with deployment into m…

Even after you figure out typescript with node, then you need to figure out sorucemaps otherwise your stack traces won’t be very useful

Re: Deno Queues

#97
post #38

Earlier quoted context omitted.

I disagree. Tying a language runtime to a specific KV interface which is tied to a specific hosted service is the opposite of forward thinking. In fact the tech industry has made a lot of progress away from vendor locked-in stacks, and this just reminds me of those. What is really the difference between Deno.KV being shipped as part of the runtime vs adding an `import KV` statement at the top of the file (which could…

> Tying a language runtime to a specific KV interface which is tied to a specific hosted service is the opposite of forward thinking. Yeah, I'm hella confused. Isn't Deno the Node.js replacement? But now it's a database as well? It's jumped the shark for sure.

I think people are hung up on a distinction between language and runtime that isn't that valuable and maybe doesn't even reflect normal use.

For example erlang ships a persistent KV store, queue, relational database and much more as part of its standard library. I've never heard anyone complain about this or wish it were otherwise.

Re: Deno Queues

#98
I feel its odd for a compiler/language toolchain to have a cloud offering. I understand the motivations but 20% of the article was about their Deno Deploy product and how to calculate API costs...

I understand its only when using their cloud and there is a local implementation, but I just couldn't imagine using a feature in LLVM, for example, where if you were to upload the binary to a specific cloud it would use a different implmentation that costs behind the scenes.

It just feels odd to me. I guess it's kind of cool. Maybe different clouds can implement the underlying KV and then this becomes cross-cloud with different underlying benefits without changing the code. But I'm not entirely sure how I feel about this.

Re: Deno Queues

#99
post #45
post #38

Earlier quoted context omitted.

I disagree. Tying a language runtime to a specific KV interface which is tied to a specific hosted service is the opposite of forward thinking. In fact the tech industry has made a lot of progress away from vendor locked-in stacks, and this just reminds me of those. What is really the difference between Deno.KV being shipped as part of the runtime vs adding an `import KV` statement at the top of the file (which could…

> What is really the difference between Deno.KV being shipped as a standard library vs adding an `import KVService` statement at the top of the file? The same difference between `#include "myStringMap.h"` and `map[string]string` in C vs.g Go. There is some advantage to everyone in an ecosystem using the same primitives. That kind of language-level standardization goes a long way. For example, it might increase the ec…

> difference between `#include "myStringMap.h"` and `map[string]string` in C vs.g Go.

Except one is a language feature with custom syntax and the other is a library that could be implmented as a library just the same.

Not everyone in the ecosystem is going to use this because its not forced on them through syntax and espically because its inside deno and not node so barely anyone at all will use it.

Re: Deno Queues

#100
post #98

I feel its odd for a compiler/language toolchain to have a cloud offering. I understand the motivations but 20% of the article was about their Deno Deploy product and how to calculate API costs... I understand its only when using their cloud and there is a local implementation, but I just couldn't imagine using a feature in LLVM, for example, where if you were to upload the binary to a specific cloud it would use a d…

These features pay for Deno. If they don't exist, Deno doesn't exist.
Post reply on HN