Hacker News Reader

Looks like https://deno.com/deploy will be a managed service - the implication seems to be that the default option will be to use their CDN to run code with an option to DIY if you prefer.

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 has a ton of caveats and limitations... but it seems their platform is full of limits as well:

https://deno.com/deploy/docs/pricing-and-limits

AWS sucks hairy balls at providing things that are simple for developers to use, so that could be their competitive advantage, but I'm just guessing here.

And deno will also have a lot of limitations

There are many, many companies competing with AWS on products that strictly speaking AWS also has.

I mean Zoom has no right to exist because you can use Chime?

There is always room for better UX, better support, different approach etc.

I find the idea that AWS will just eat the competition always a little silly as well. I've used AWS managed offerings that were far inferior to the alternatives.

So why were you using the AWS managed offering then instead of the alternative?

Usually because the company already pays an AWS bill. No one will care if you add another Lambda function, but to use an alternative you’ll have to get past some gatekeepers.

So there you go. Lots of friction for competitors.

And yet we've never seen anyone beat Amazon yet. Look at how much the PaaS area has churned over the last 10 years. Giants that stuck around like Docker are completely deflated and near worthless compared to their initial values and expectations. The smart ones like Heroku got out when the getting was good.

> And yet we've never seen anyone beat Amazon yet.

That largely depends on your definitions of "beat" and "win". There are plenty of software infrastructure firms out there that Amazon has yet to smash into the ground.

Nature seems to think (and I agree) simply existing is winning.

Please give examples. I would like to learn more about it (even if subjective)

DigitalOcean is a competitor of comparable size (even if its like a pebble to a boulder): https://finance.yahoo.com/news/blavatnik-backed-digitalocean...

I use Digital Ocean and definitely vouch for them. They are way cheaper compared to AWS too. Nice, slick UI too.

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/

> Firecracker [0], likely to be more, not less, secure than Isolates [1]

This is debatable. It's true that V8 is a much larger attack surface than Firecracker, therefore likely to have more security bugs than Firecracker itself. However, Firecracker runs attacker-provided native code directly on hardware, which means that hardware itself becomes an attack surface, one that is quite wide, not fully documented, and very hard to patch if problems arise. It's much easier to work around hardware bugs when you're working from JS / Wasm and can control the code generation.

Ultimately I don't think you can really say one or the other model is more or less secure.

(Disclosure: I'm the tech lead for Cloudflare Workers so I am obviously biased here.)

Thanks Kenton.

> Firecracker runs attacker-provided native code directly on hardware, which means that hardware itself becomes an attack surface, one that is quite wide, not fully documented, and very hard to patch if problems arise. It's much easier to work around hardware bugs...

I see your point. I mean, Google wouldn't put as much effort as they are on gVisor if KVMs were the best possible answer.

To be fair, gVisor also runs native code directly on hardware. Any modern VM-based system is still depending on the CPU to enforce boundaries. A big CPU bug could ruin that at any time. (Spectre has been pretty bad, but not quite a showstopper...)

They can always get acquired by Amazon first.

It wouldn't surprise me if that's the eventual end goal. Amazon is looking for good Rust talent too from what I've read.

That’s the goal of almost all startups. Your chances of being acquired by a FAANG company are millions of times greater than going IPO. It is almost always the exit strategy.

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.

I'll be very surprised if "quick and easy hosting" is still a viable business model, considering how crowded the space is by now.

Eh, Vercel pulled it off rather well with Next.js. Given that Guillermo Rauch is an investor in Deno, I wouldn't be surprised if they partnered in some way.

Quick, easy, and cheap hosting will always be a viable model, for varying definitions of cheap.

This is probably a stupid question, but is AGPL/commercial dual-licensing a viable option for something like this? Instead of relying on goodwill donations & maybe assigning 1-2 devs from major corporations, just explicitly charge them money if they refuse to ship source code to end-users.

Many companies would just never touch an AGPL package, and while there are other languages out there with commercial licenses (e.g. Delphi), those are not nearly as mainstream as the open & freely available ones.

Deno is competing against Node.js, which is MIT-licensed. Deno is arguably better, but it would have to be _so much better_ to get people to even give it a second look if it was commercial.

That's why you dual license, which is significantly more approachable. "This is AGPL/GPL unless you pay $200/month per developer seat" is a common licensing scheme for frameworks, people aren't scared by it.

In some places, the people who hold the purse strings are rather far removed from the actual developers, that it's a lot easier to just go with something that's "free".

I think this is one of the reasons why cloud computing monoliths like AWS are so successful. It's way easier to set up a $50/month VM on AWS then to get permission to spend $5/month on a VM elsewhere.

Enterprise sales requires paying salespeople for their network of potential customers and time to reach them. The sales cycle is long and risky for companies that can't absorb the cost of the sales salary and time to get revenue.

Unless you have a ridiculously good relationship with a handful of organizations or a perfect system for fitting into existing infrastructures, it's a big mistake to care about selling something to those organizations.

AWS is popular because it's free for companies with a high potential for getting big (like YC companies) and they can absorb the costs of the sales cycle.

> This is AGPL/GPL unless you pay $200/month per developer seat" is a common licensing scheme for frameworks, people aren't scared by it

Really ? I can think of QT - but that's such a huge body of work with some very specific use cases in which it doesn't really have competition (aside from DOM based shell for UI maybe, but that has it's own problems and is often a hassle to get working).

In this case Node is established, Deno is going to have an up hill battle to gain that mindshare on equal footing, adding a licensing restriction would probably kill it off the ground.

I promise: No trolling with this question.

Can anyone name a few that come to mind?

I only know about one (Qt: GPLv2/3 or LGPLv3), but I don't use a lot of commercial software. Interestingly, Qt looks about 233 USD per month per seat!

Ref: https://www.qt.io/pricing

Unfortunately Deno gave up on their most unique differentiator, the TS [runtime].

We most certainly did not, TypeScript is and continues to be a primary concern for us and we plan on continuing to support it as a first-class citizen of the ecosystem

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.

Exactly. And I guess the package still needs to be compiled to JS before deploying to production? To avoid shipping a full TS compiler on a production server which would be a crazy thing to do.

I don't think that would be that crazy, especially if it's in the stdlib.

It seems like a huge amount of code and potential vulns to bring in production for no good reasons.

Why do you need a full TS compiler - you can just strip type annotations ala babel.

No we didn't?! Where did you get this info from? Deno is made to work with TypeScript out of the box. The Deno Standard Library is written in TypeScript: https://deno.land/std. Most userland modules are TypeScript too.

If it helps, I think this is the main source of misinformation:

https://startfunction.com/deno-will-stop-using-typescript/

It featured on HN some time back:

https://news.ycombinator.com/item?id=23592483

I do find the messaging to be confusing, because what would you think I meant if I talked about the runtime of Elixir or Scala?

This is the marketing line on the front page of the Deno project:

> A secure runtime for JavaScript and TypeScript.

They are using the same term "runtime" to describe JS as well as TS. All replies here by Deno team members use the language "Typescript support" but nobody here is saying TypeScript runtime.

I can understand where the confusion comes from, but I think it's a matter of context. I would never have thought that they would want to build a runtime that runs TS directly. The effort would just be insane.

Hence the implied step that TS needs to first be transpiled to JS before getting executed in the runtime was always in the back of my head and I'm guessing this is the way most people think as well.

And from a black-box perspective, whether TS first gets transpiled to JS or run directly doesn't make a difference. In that sense one could argue that it is a "TS runtime". This is a petty semantics-fight I don't want to get into though and I've probably already said too much :).

If you are interested in something that gets close to a TS runtime though, have a look at AssemblyScript [0]. It compiles to WASM and tries to keep most of the syntax of TS. Very interesting project imo.

Wasn't a TypeScript runtime the original Deno selling point? Didn't the project have to pivot away from that?

No. Nothing has changed about Typescript support since 1.0. It is just as well supported as JS. We never removed support...

So Deno is still committing to TS runtime?

I feel like people are talking past each other here.

To me "TypeScript runtime" means running TypeScript in a mode that runs faster than JavaScript by actually using the type info to generate better machine code. It does not mean translating to JavaScript at runtime and running in V8.

For example at one time there was an experimental version of Chrome that had a Dart Runtime. A quick google finds this HN thread when they decided NOT to have a dart runtime

https://news.ycombinator.com/item?id=9264531

So can we get clear? Does Deno plan to execute TypeScript natively (not via V8 or via a heavily modified V8) or are the plans to continue compiling TypeScript to JavaScript internally and actually just run JavaScript

That's what I understood as well, and now I'm confused at the messaging.

Y E S

Heck yeah

I don't know where I got so misinformed. I thought Deno had stopped going for a TS runtime.

Unfortunately, the words "Deno", "TypeScript", and "removal" made for good headline material, and what was effectively a design document about performance optimization[1] became misinterpreted by many as heralding the removal of TypeScript from Deno, despite the document being updated with a explanatory warning that it was a very deep technical document about a specific part of architecture, and that Deno remains completely committed to supporting TypeScript forever.

1: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...

Was does a TS runtime means anyway? Doesn't checking types at run time rather than at compile time a pure loss?

No, because TS hints should also be able to translate to runtime savings.

I do find the messaging to be confusing, because what would you think I meant if I talked about the runtime of Elixir or Scala?

This is the marketing line on the front page of the Deno project:

> A secure runtime for JavaScript and TypeScript.

They are using the same term "runtime" to describe JS as well as TS. All replies here by Deno team members use the language "Typescript support" but nobody here is saying TypeScript runtime.

They had to remove it from the Deno build process so Deno internals didn't need a compiler. However TypeScript support remains untouched and receives constant updates

I don’t remember “TS runtime” as you’re meaning it ever being pitched. I don’t think Ryan would consider that in scope for Deno unless MS wanted to collaborate on it.

I do find the messaging to be confusing, because what would you think I meant if I talked about the runtime of Elixir or Scala?

This is the marketing line on the front page of the Deno project:

> A secure runtime for JavaScript and TypeScript.

They are using the same term "runtime" to describe JS as well as TS. All replies here by Deno team members use the language "Typescript support" but nobody here is saying TypeScript runtime.

I would say no. I think they should go public domain, as that's the future.

One of the funniest/best business models out there is SQlite (https://sqlite.org/copyright.html). They give it away to the public domain, but some lawyers wrongly claim that that is not enough, so they will "sell" you a warranty asserting it is all public domain.

Those lawyers are correct.

Not all jurisdictions of the world legally recognize the concept of 'public domain'.

There does exist the CC0 license[0] which attempts to alleviate it, but I haven’t heard if it’s been tested in the courts.

[0]: https://creativecommons.org/publicdomain/zero/1.0/

Patent/copyright insurance? Sounds good, and not difficult to get a check written for, considering how much is spent on the service of open-source scanning.

I guess the "commercial applications" should be https://deno.com/deploy

Glad to see I'm not the only one having a hard time figuring out just how they intend to make money. My best guess was that they will offer a tailored Deno to companies that want to embed it (my comment about it is swimming somewhere here).

Other than that, there is the following vague statement at the end of the post:

> The Deno company hopes to enable the millions of web programmers out there to maximally leverage their craft in other domains.

Ah I read that statement in the end like it'll enable front-end devs to also write back-end code, like Node.js but better (APIs follow more the browser than in Node.js), but I didn't think it'd be related to the monetization?

Sounds to me that they will build some sort of hosted service or maybe PaaS based on the Deno runtime (like AppEngine or AWS lambda), but yeah it's pretty vague.

Looks like CDN with Serverless edge functions.

https://deno.com/deploy

Heroku doesn't (yet) officially support Deno. That's the main reason I don't use Deno for my personal site. So I'd say there's a market there.

> Sounds to me that they will build some sort of hosted service or maybe PaaS based on the Deno runtime (like AppEngine or AWS lambda)

or like Joyent

How did Joyent manage to turn Nodejs into money though? I mean weren't they mostly selling unix services?

looks like a crowded space.

vc's will issue course correction very soon.

looks like a repeat of docker.

In other words, capitalise on the decreasing quality of software engineers by offering services to them at a high price because they don't have the ability to make any of these services themselves.

This is a rather naive take I think..

There's a semi-joke that goes "all companies are software companies now" but there is a lot of truth to that..

It comes to down where a company wants to put its effort.

Do you want to own/operate/maintain all your infrastructure and services (and all the challenges that come with retaining scarce talent that is capable of that work), requiring you to substantially invest in an area that is not core to your business?

Or do you want to spend that money (and let's be real, less money too) to pay a trusted third party provider who will do a better job than you would anyways, because that's their area of expertise?

Then you can focus your (likely limited) resources on delivering value to your business instead.

Any of the big 10 tech companies wouldn't mind owning this if it becomes the standard way of developing back end JS. It gives them influence and the ability to lock out competitors.

I know this isn't the SV-approach to things but maybe they intend to offer consulting services for those looking for some expertise with the ecosystem, bill hours, and retire in their 50s as millionaires instead of billionaires.

This might be surprising, but not everyone is looking to be a unicorn.

The article says they "raised 4.9 million dollars of seed capital" so I expect their investors will want a decent return over the next few years.