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

The Deno Company

deno.com

Post reply on HN
Print view View original

411–420 of 446 posts

Re: The Deno Company

#411

Post by threatofrain »

wperron wrote: post #286
threatofrain wrote: post #204

Earlier quoted context omitted.

Is Deno still going for TS runtime? > Deno is a runtime for JavaScript and TypeScript that is based on the V8 JavaScript engine and the Rust programming language.

Insofar as we take `.ts` files seamlessly yes -- though to be clear, one does not simply "run" TypeScript. There are no runtimes for TypeScript directly (there's AssemblyScript that _looks_ like TypeScript, but isn't exactly TypeScript) We've simply incorporated the type-checking and transpiling steps into the deno cli, making it super simple to get going, no config needed.

This is actually quite confusing, because

> A secure runtime for JavaScript and TypeScript.

Shouldn't require caveats, with the caveat being that there is no runtime for TS.

There is reason to believe that the extra information given from TS typings could be carried into runtime wins, and so there is absolutely pent up demand for an actual TS runtime.

Re: The Deno Company

#412

Post by ignoramous »

jppope wrote: post #367
qbasic_forever wrote: post #329

Earlier quoted context omitted.

How does this business model survive Amazon AWS making a blog post, "Here's a template to run your deno code on Lambda!"? They'll never beat AWS on costs in the long term. They can burn VC cash to stay afloat and try I guess.

Lambda uses containers vs. cloudflare workers use v8 isolates. v8 Isolates are much much faster and more secure for serverless functions. Deno seems to be targeting cloudflare as a competitor for their service... But it's probable that AWS will release a cloudflare worker competitor themselves if deno continues with the MIT license.

> Lambda uses containers vs. cloudflare workers use v8 isolates. v8 Isolates are much much faster and more secure for serverless functions.

You're right that v8 Isolates are blazing fast, but Lambda runs functions in a microvm spawn by Firecracker [0], which is likely to be more, not less, secure than Isolates [1].

[0] https://github.com/firecracker-microvm/firecracker/

[1] https://fly.io/blog/sandboxing-and-workload-isolation/

Re: The Deno Company

#413

Post by nilshauk »

From a distance I think Deno has a lot of promising features going for it. Expressing modules as URLs seems like a small difference but I believe it has big ramifications. With clever use of DNS resolving and caching I wonder how fast new instances will be able to spin up. I'm guessing it'll be fast!

My only gripe with the Deno company is that taking investor funding is a double-edged sword. Yes, they'll get to hire very skilled developers. However naturally the investors want a tidy exit, and I wonder if that would be to be bought out by Amazon, Microsoft or Google.

Edit: Just realized that there's a key difference in that Deno does not have something like NPM to be bought and sold because dependencies are URLs and thus decentralized. Also, Deno itself is open-source.

Re: The Deno Company

#414

Post by ignoramous »

summarity wrote: post #337
qbasic_forever wrote: post #329

Earlier quoted context omitted.

How does this business model survive Amazon AWS making a blog post, "Here's a template to run your deno code on Lambda!"? They'll never beat AWS on costs in the long term. They can burn VC cash to stay afloat and try I guess.

They compete much more with Cloudflare Workers, not Lambda. So much so that Deno Deploy is worker API compatible

Workers is now a much capable platform. It supports eventual KV storage, caching large files, longer runtimes (30m+), WebSockets, WASM-executables, and distributed mail-boxes àla Erlang.

Lambda integrates with existing AWS services, whilst Cloudflare invents newer services to go along with the serverless-first paradigm. Different strategies but they do compete with each other.

Re: The Deno Company

#415

Post by Woung1938 »

It seems there are many toothing problems with Deno. I just tried stuff from their blog (https://deno.com/blog/v1.8):

    $ deno run --unstable --allow-write=output.png https://raw.githubusercontent.com/crowlKats/webgpu-examples/f3b979f57fd471b11a28c5b0c91d0447221ba77b/hello-triangle/mod.ts
    Download https://crux.land/2arQ9t
    Download https://crux.land/api/get/2arQ9t
    error: Import 'https://crux.land/api/get/2arQ9t' failed: 404 Not Found
        at https://raw.githubusercontent.com/crowlKats/webgpu-examples/f3b979f57fd471b11a28c5b0c91d0447221ba77b/deps.ts:4:0
(A dependency got removed?)

Another one:

    $ deno run https://deno.land/v1.8/permission_api.ts
    error: An unsupported media type was attempted to be imported as a module.
      Specifier: https://deno.land/v1.8/permission_api.ts
      MediaType: Unknown
(The site is a 404 returning status code 200... just... why?)

Re: The Deno Company

#416

Post by mrjoelkemp »

elisee wrote: post #315
cozuya wrote: post #296

Earlier quoted context omitted.

Are you running multiple cores/threads of deno? If so how are you holding/communicating state server side?

There's a central Deno server program called the switchboard, which serves static content, runs a small REST API for account management / login, and starts a WebSocket server for game servers to register themselves. Each game server (a stand-alone Deno program that might or might not run on its own machine) connects to the switchboard over websocket and authenticates itself with an API key (since people will be able…

For completeness, you should check out Elixir and Phoenix (channels and presence) for the server. Easy websockets, isolated player processes, non-blocking VM, plus deep introspection for debugging issues. https://youtu.be/JvBT4XBdoUE. We see more and more indie games being built with Phoenix LiveView.

Re: The Deno Company

#417

Post by afiori »

jhgb wrote: post #273
pknopf wrote: post #247

Earlier quoted context omitted.

There will likely be some kind of npm at some point.

If the goal is to get rid of NPM, why would you add another one in the future?

The goal is not to eliminate npm, but to decouple it from the runtime itself

Re: The Deno Company

#418

Post by afiori »

j-pb wrote: post #320
ericlewis wrote: post #299

Earlier quoted context omitted.

- TS also lets anyone do whatever they want so not a great thing to support, I have always said TS would be better if people couldn't configure it without a PR to TS itself - we have the chance to define a new and better API, we should do it - you are already adopting something different - I agree, but its not a selling point, these things are probably in containers already and my OS should be doing most of the work…

You go out and fix all the library code that uses window then. The web has been paving the cow paths for good reason. There are hills worth dying on, what the common namespace is called isn't one of them.

relatively speaking the windows vs. global should be a non issue. I believe that every js runtime except for IE supports globalThis such that `globalThis.window === window` in the browser and `globalThis.global === global` in node.

Deno's difference from node is the choice to implement web API instead of nodejs stdlib API

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: The Deno Company

#419

Post by wperron »

Woung1938 wrote: post #415

It seems there are many toothing problems with Deno. I just tried stuff from their blog ( https://deno.com/blog/v1.8 ): $ deno run --unstable --allow-write=output.png https://raw.githubusercontent.com/crowlKats/webgpu-examples/f3b979f57fd471b11a28c5b0c91d0447221ba77b/hello-triangle/mod.ts Download https://crux.land/2arQ9t Download https://crux.land/api/get/2arQ9t error: Import 'https://crux.land/api/get/2arQ9t' faile…

Thanks for reporting, we recently moved our blog to deno.com/blog and haven't updated the post -- we'll fix that as soon as possible

Re: The Deno Company

#420

Post by youngtaff »

lucacasonato wrote: post #241
unityByFreedom wrote: post #222

Earlier quoted context omitted.

Their comparison to Cloudflare workers doesn't seem right. The benefit of cloudflare workers is that they run on the edges of a CDN. Putting Deno on one server wouldn't achieve that.

Then you put Deno on the edge : https://deno.com/deploy

Where is the edge in Deno terms though?

It's the same issue with Netlify, Vercel etc. where their edge is very different to say Akamai, Cloudflare or Fastly's edge.

Post reply on HN