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

Deno raises $21M

deno.com

Post reply on HN
Print view View original

381–390 of 397 posts

Re: Deno raises $21M

#381

Post by brundolf »

yencabulator wrote: post #380
brundolf wrote: post #365

Earlier quoted context omitted.

Sure, if you use Python's async feature. But my understanding is that it's relatively uncommon; blocking IO is still the norm, right? I for one have worked in or around a couple of nontrivial Python servers, and I've never once seen an await statement. My understanding (correct me if I'm wrong) is that this comes down to it being newer, and having worse ecosystem support (more "synchronous-colored" APIs, less battle-…

In non-async Python, generally the thing that blocks is a thread -- something Javascript doesn't even have! A different thread will happily run in the meanwhile.

Right, but some other JavaScript on the same thread will run while a different piece of JavaScript is awaiting. That's why JavaScript can get away with not having threads. Also- any number of background threads will be running at any given time to read data off of disk, load and process network requests, load data from a DB, delegate commands to system processes, etc, in true parallel with the JS code. When one finishes, it'll put an event on the event loop and JS will pick it up when it gets the chance.

Re: Deno raises $21M

#382

Post by lmm »

throwawaylala1 wrote: post #310
berkes wrote: post #301

Earlier quoted context omitted.

More practically: for example, I write my web service(s) with event sourced architecture. Now any worker, or any service sending a command, can operate against the storage. Regardless of version. Other architectural patterns offer the same kinds of options. Clean architecture or hexagonal architecture limits the surface (coupling) between your versioned logic and the data so much, that they can version independent. A…

> More practically > event sourced architecture You must be joking. Please tell me you're joking.

It really is a lot more practical. Most webapp devs using SQL databases spend a bunch of time engineering some notional failover into their app that's completely undermined by using a non-HA datastore, a bunch more time mapping data to and from square tables where it doesn't really fit, and end up with a system that's still last-write-wins at the user-facing level. And the ones where it isn't aren't because they used those SQL transactions, but because they wrote their own versioning layer on top.

Re: Deno raises $21M

#383

Post by yencabulator »

mrkurt wrote: post #65
tick_tock_tick wrote: post #37

Earlier quoted context omitted.

Yeah unless I'm missing something isn't this just a stand alone company offering roughly workers?

This is an open source JavaScript runtime with a hosted business model. Deno is great. Deno Deploy is a reasonable way for them to make money.

Meanwhile, Cloudflare says they are open sourcing Cloudflare Workers runtime: https://twitter.com/KentonVarda/status/1523666343412654081

Re: Deno raises $21M

#384

Post by yencabulator »

pier25 wrote: post #296
jhgg wrote: post #23

Deno deploy seems cool and all, but I haven't seen any great rationale for using their service over say Cloudflare Workers.

Workers are not meant as a generalist runtime.

Neither is Deno Deploy, really. The limits on CPU time etc are very similar, with Cloudflare being more flexible on CPU and Deno Deploy being more flexible on bundle size.

https://deno.com/deploy/docs/pricing-and-limits https://developers.cloudflare.com/workers/platform/limits/

Re: Deno raises $21M

#385

Post by yencabulator »

crowlKats wrote: post #166
mkroman wrote: post #161

Earlier quoted context omitted.

> Up to 10ms CPU time per request So less than 17 minutes of CPU time per day - not a lot, but also not nothing.. But at 10ms per request, what would one use it for? Just server-side rendering for something simple?

proper applications as well. example is the https://deno.land website has an average CPU time of 6ms. CPU time means it doesnt include any IO bound operations, so ie doing a fetch request wont really contribute to the CPU time.

Average time 6ms with hard cap at 10ms sounds like a ticking timebomb you don't dare to put in production.

I've had to switch multiple webapps to Cloudflare Workers' "unbound" mode to go beyond CPU time limits.

Re: Deno raises $21M

#386

Post by pier25 »

yencabulator wrote: post #384
pier25 wrote: post #296

Earlier quoted context omitted.

Workers are not meant as a generalist runtime.

Neither is Deno Deploy, really. The limits on CPU time etc are very similar, with Cloudflare being more flexible on CPU and Deno Deploy being more flexible on bundle size. https://deno.com/deploy/docs/pricing-and-limits https://developers.cloudflare.com/workers/platform/limits/

Yes Deno Deploy is for HTTP (just like CF Workers) but my point is that Deno is more of a generalist runtime compared to Workers and has a much broader appeal than just Deno Deploy.

Here's an example. Deno is like any other backend runtime and has regular DB clients. CF Workers do not. If you want to use Workers with PG, the CF docs point you to Supabase which provides REST over PG using PostgREST.

https://developers.cloudflare.com/workers/tutorials/postgres...

Re: Deno raises $21M

#387

Post by yencabulator »

pier25 wrote: post #386
yencabulator wrote: post #384

Earlier quoted context omitted.

Neither is Deno Deploy, really. The limits on CPU time etc are very similar, with Cloudflare being more flexible on CPU and Deno Deploy being more flexible on bundle size. https://deno.com/deploy/docs/pricing-and-limits https://developers.cloudflare.com/workers/platform/limits/

Yes Deno Deploy is for HTTP (just like CF Workers) but my point is that Deno is more of a generalist runtime compared to Workers and has a much broader appeal than just Deno Deploy. Here's an example. Deno is like any other backend runtime and has regular DB clients. CF Workers do not. If you want to use Workers with PG, the CF docs point you to Supabase which provides REST over PG using PostgREST. https://developers…

Yes, Cloudflare Workers originally couldn't make arbitrary outgoing TCP connections. Cloudflare wrote an adapter to transport Postgres over WebSockets (https://blog.cloudflare.com/relational-database-connectors/) and then added support for TCP connections (https://blog.cloudflare.com/introducing-socket-workers/).

Deno Deploy doesn't have much of a moat, and Cloudflare is better funded. Both are promising to be open source & self hostable (https://twitter.com/KentonVarda/status/1523666343412654081). We shall see.

Re: Deno raises $21M

#388

Post by pier25 »

yencabulator wrote: post #387
pier25 wrote: post #386

Earlier quoted context omitted.

Yes Deno Deploy is for HTTP (just like CF Workers) but my point is that Deno is more of a generalist runtime compared to Workers and has a much broader appeal than just Deno Deploy. Here's an example. Deno is like any other backend runtime and has regular DB clients. CF Workers do not. If you want to use Workers with PG, the CF docs point you to Supabase which provides REST over PG using PostgREST. https://developers…

Yes, Cloudflare Workers originally couldn't make arbitrary outgoing TCP connections. Cloudflare wrote an adapter to transport Postgres over WebSockets ( https://blog.cloudflare.com/relational-database-connectors/ ) and then added support for TCP connections ( https://blog.cloudflare.com/introducing-socket-workers/ ). Deno Deploy doesn't have much of a moat, and Cloudflare is better funded. Both are promising to be op…

I'm arguing about Deno (the whole thing) vs Workers, not Deno Deploy vs Workers.

Even when CF open sources Workers, they will be useless for anything non-HTTP related.

Re: Deno raises $21M

#389

Post by yencabulator »

pier25 wrote: post #388
yencabulator wrote: post #387

Earlier quoted context omitted.

Yes, Cloudflare Workers originally couldn't make arbitrary outgoing TCP connections. Cloudflare wrote an adapter to transport Postgres over WebSockets ( https://blog.cloudflare.com/relational-database-connectors/ ) and then added support for TCP connections ( https://blog.cloudflare.com/introducing-socket-workers/ ). Deno Deploy doesn't have much of a moat, and Cloudflare is better funded. Both are promising to be op…

I'm arguing about Deno (the whole thing) vs Workers, not Deno Deploy vs Workers. Even when CF open sources Workers, they will be useless for anything non-HTTP related.

Grandparent said

> Deno deploy seems cool and all, but I haven't seen any great rationale for using their service over say Cloudflare Workers.

Note "their service". You replied with

> Workers are not meant as a generalist runtime.

So, we really were talking about Cloudflare Workers vs Deno Deploy.

Deno is something different, for sure. But it seems Deno Land Inc. is betting on Deno Deploy. Which makes grandparents' question interesting.

Re: Deno raises $21M

#390

Post by pier25 »

yencabulator wrote: post #389
pier25 wrote: post #388

Earlier quoted context omitted.

I'm arguing about Deno (the whole thing) vs Workers, not Deno Deploy vs Workers. Even when CF open sources Workers, they will be useless for anything non-HTTP related.

Grandparent said > Deno deploy seems cool and all, but I haven't seen any great rationale for using their service over say Cloudflare Workers. Note "their service". You replied with > Workers are not meant as a generalist runtime. So, we really were talking about Cloudflare Workers vs Deno Deploy. Deno is something different, for sure. But it seems Deno Land Inc. is betting on Deno Deploy. Which makes grandparents' q…

With all due respect, there's a point I think you're missing here.

What I'm saying is that, even if you're only going to use Deno Deploy, it is an objectively better proposition because Deno (the runtime) has a much broader use case.

Would you rather use something that (for now) can only be used on a single cloud provider for (let's call them) "edge HTTP" workloads and integrations with services of that single cloud provider...

... or use something that can be used on any cloud/hosting provider, for any HTTP workload (plus many other non-HTTP use cases), which also happens to have an "edge HTTP" service custom tailored for it?

And let's not forget, Deno (the company), is much more focused on real developer needs. Workers still have a mediocre DX (although it has improved considerably lately) and still no framework for Workers like Fresh.

https://fresh.deno.dev/

Post reply on HN