[HN Gopher] Deno raises $21M
___________________________________________________________________
Deno raises $21M
Author : 0xedb
Score : 389 points
Date : 2022-06-21 18:33 UTC (4 hours ago)
(HTM) web link (deno.com)
(TXT) w3m dump (deno.com)
| [deleted]
| Zababa wrote:
| > Cold start (time to first response, ms) O(100) O(1000) O(10000)
|
| I think ~100 ~1000 ~10000 would be clearer than using the big O
| notation, since this has nothing to do with fuinctions.
| vaishnavsm wrote:
| Agreed! I'm pretty sure they're just using O(x) to mean on the
| order of x, since big O of any constant is the same (unless
| that's their point??? :O)
| laputan_machine wrote:
| I genuinely don't even understand it. I was either taught
| wrong, learned wrong or this doesn't make sense. O(100) is
| constant time, so it's no different to saying O(1) or whatever,
| I've only ever used O to talk about how we care about the time
| complexity of a function, e.g. comparing linear time to
| quadratic time. 1 is the same as 100, irrelevant.
| LudwigNagasena wrote:
| If it's big O notation, it makes no sense because
| O(10000)=O(1000)=O(100)=O(1).
| koshergweilo wrote:
| I think they're trying to communicate that those are worst
| case latency numbers. You're correct in that formal use of
| Big O notation doesn't distinguish constants.
| csmpltn wrote:
| It's _that_ easy to raise money these days, at the 10%
| inflation mark. Spin up a webpage full of nonsense promises and
| they 'll come chasing after you to take their cash.
| pdpi wrote:
| I would read ~100 to mean "approximately 100", while O(100) to
| me reads like "measured in the hundreds". So 200-600ms cold
| starts are O(100) and 3-7s cold starts are O(1000).
| koshergweilo wrote:
| I'm not sure, I'm pretty sure they're trying to communicate
| that these are worst case estimates. ~100 seems like it's
| communicating average case estimates (big theta notation),
| which isn't really the same thing
| chrismsimpson wrote:
| Interesting raise. I leave the front marketing page of Deno
| Deploy open in my browser for a few moments and I get the
| ubiquitous "This webpage is using significant energy. Closing it
| may improve the responsiveness of your Mac."
|
| Says it all about the state of the JavaScript ecosystem really.
| caust1c wrote:
| The color changing on this page gives me a migraine:
|
| https://deno.com/deploy
|
| I like Deno in principle, but I'd love to see how Slack, Github
| and Netlify are using it.
| lucacasonato wrote:
| If you have "prefers-reduced-motion" set to true in your
| browser / OS, the animation will stop :)
| madeofpalk wrote:
| Unfortunately browser's don't really give you an easy way to
| control this. Changing system-wide settings just because one
| website is bad is quite the ask ask.
| lagrange77 wrote:
| > I like Deno in principle, but I'd love to see how Slack,
| Github and Netlify are using it.
|
| https://docs.netlify.com/netlify-labs/experimental-features/...
|
| _All this dynamic processing happens in a secure runtime based
| on Deno directly from the worldwide network edge location
| closest to each user._
| cloudyglider wrote:
| Weird... it's having the same affect on me, something about
| slowly fading to white background is making me flinch. Is this
| a known phenomenon?
| yccs27 wrote:
| I suspect that it basically confuses your brain because it
| tries to adjust the "white balance" so that the background
| becomes normal white. But the background is just saturated
| enough and changing so quickly that it just can't follow.
| airstrike wrote:
| As a second data point, I added the same effect to my blog
| back in, I don't know, 2002 and all my friends complained
| about getting a headache as well, so I turned it off
|
| For some reason it never had that same negative effect on me
| kevsim wrote:
| Funny thing is after looking at it for a bit, I'd _swear_ HN is
| changing colors now.
| synu wrote:
| Same, and a bit of a persistent queasy feeling. I think it's
| something to do with how it's slightly off white but pulsing,
| so your brain tries to cancel it out.
|
| It reminds me of the feeling after surfing when you lie in
| bed with your eyes closed and still feel the waves going up
| and down.
| asdfasdfdsfa wrote:
| Leave it to hacker news for such a dramatic comment about a
| trivial design choice
| caust1c wrote:
| Yeah I love making prospective customers feel pain too.
|
| /s
| bowsamic wrote:
| The world doesn't exist to cater to your weird specific
| thing that gives you a headache
| danuker wrote:
| The rank of the root comment says others are displeased
| as well.
| asadlionpk wrote:
| Not as dramatic as you but it does feel a bit weird looking at
| it.
| qweqwerwerwerwr wrote:
| are there real-world, commercial products actually running on
| """serverless""" architecture?
|
| no matter how much I think about that whole concept, I see no
| application for it that couldn't be done better, faster and
| easier with regular tools
| golergka wrote:
| There's plenty of real-world, commercial products which do not
| get extremely high loads but earn much more money on each
| request. They're mostly in B2B without sexy names and media
| coverage, though.
| [deleted]
| nikanj wrote:
| Hot take: investors really are stupid enough to think
| "servers/datacenters are a massive cost for large companies. A
| serverless solution should save them lots of money"
| wperron wrote:
| It's not a hot take, it's just a bad take, and a complete
| failure to understand the value proposition of these types of
| offerings (and why we're seeing so many of them pop up these
| days)
| lghh wrote:
| > are there real-world, commercial products actually running on
| """serverless""" architecture?
|
| Yeah, thousands I would imagine. The last two companies I have
| worked at have been 100% serverless or nearly 100%.
|
| > no matter how much I think about that whole concept, I see no
| application for it that couldn't be done better, faster and
| easier with regular tools
|
| Considering you have to ask if there are _any_ products running
| in a serverless environment, I would imagine you need more
| exposure to the concept before you make such a large judgement
| on it.
| capableweb wrote:
| > Yeah, thousands I would imagine. The last two companies I
| have worked at have been 100% serverless or nearly 100%.
|
| If you can answer (for legal or other reasons you might not
| be able to): What kind of monthly bills did your setup have
| and how many req/s did you serve (in lack of a better
| metric)? It'd also be useful to know average min/max response
| time if that's something you remember.
|
| I wish that was a good way of evaluating "performance /
| price" but that's really hard... If someone know a better way
| to frame the question regarding price, it would be very
| helpful.
| lghh wrote:
| I can't list that, but both companies migrated to
| serverless and both companies are glad they did.
|
| There is more than "raw dollar amount on monthly bill" to
| account for in cost, as well. For one, there's stability
| and the toll that takes on both your team and your
| customers. Not saying non-serverless apps are not stable by
| nature, but I've now been part of two teams that have seen
| the same types of benefits and those benefits line up with
| the "sales pitch" benefits.
| qweqwerwerwerwr wrote:
| what was the product and the scale then?
| lghh wrote:
| I'd rather not list my last two companies or their scale,
| but I can assure you they are real companies that exist,
| have users, and make money. I'm not sure why I even would
| be asked to.
| ArrayBoundCheck wrote:
| I'm not particularly interested in serverless but my
| understanding is a developer doesn't need to know the server
| configuration and drops some code in. The service figures out
| how to route the domain to code and handle the storage,
| caching, etc
|
| I rather know my configuration and use one big server with the
| static files on a CDN
| jppope wrote:
| Yes, there are many real-world completely serverless products
| and architectures. I've been working exclusively on serverless
| architectures for many years now, I have no plans on going back
| to provisioning servers or working with containers.
| dangoor wrote:
| It depends on what you categorize as "serverless". I wrote
| about how Khan Academy is built on essentially serverless
| architecture and has millions of monthly users:
|
| https://blog.khanacademy.org/the-original-serverless-archite...
| msoad wrote:
| Running little processes on the server without the VM/K8s
| expensive abstraction has a lot of potential. I'm sure Deno will
| do great! At least this way of deploying web apps has a lot of
| potential.
| whatever1 wrote:
| Isn't this what an operating system is doing by default?
| msoad wrote:
| I should say "untrusted code" to be more specific.
| pseudosavant wrote:
| As a Deno fan I was surprised to learn that the free tier for
| Deno Deploy includes 100k requests per day and 100GB of bandwidth
| monthly. I know I'll be trying it out now.
| benatkin wrote:
| I think Deno Deploy and using Deno on fly.io could be a
| powerful combo. Deno has some advantages that definitely lend
| themselves to having control of your entire MicroVMs. An app
| could easily be split between serverless-friendly and non-
| serverless-friendly parts of the stack by using both together.
| mkroman wrote:
| > 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?
| crowlKats wrote:
| 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.
| [deleted]
| lxe wrote:
| The business end here is Deno Deploy - a heroku-like. That's what
| the "startup" behind the funding is. The tech is in service of
| that.
| TazeTSchnitzel wrote:
| > Early in cloud computing, virtual machines were the compute
| abstraction [...]
|
| This is funny to me because serverless sounds to me like the
| return of PHP (etc) shared hosting. What's old is new again?
| scarface74 wrote:
| Virtual machines are still the abstraction. Each Lambda/Fargate
| (serverless Docker) runs in its own VM.
| thegeomaster wrote:
| I changed my view on this--I hated how things were going full
| circle. But in reality, human civilization loves overdoing a
| particular direction and then reverts to the mean. You see this
| with the economy, moral fashions, everything.
|
| I am an optimist in that I (have started to) believe that this
| slowly allows us to converge on better solutions for
| everything.
|
| PHP was easy to set up, easy to host, easy to understand and
| easy to build stuff with, but it resulted in an unmaintainable
| mess over the long run.
|
| Then Node was all of that, but JS was a better language than
| PHP. Then Node grew warts in the form of the clutter that is
| npm, then it grew complex build systems and unstable libraries.
|
| Now there's Deno. It uses TypeScript by default, which is a
| surprisingly useful and productive language, it rethinks some
| things, it's much more secure by default, and now we're back at
| the PHP-level easiness to host using Deno Deploy.
|
| We've ended up with an overall better solution and it only took
| us 20 years :)
| speed_spread wrote:
| We didn't go back far enough, CGI is still where it's at.
| Spivak wrote:
| I mean CGI still lives on just moved up the stack a bit
| with WSGI and Rack.
| bbatchelder wrote:
| We're there again with WASM and WAGI.
|
| https://www.fermyon.com/blog/wasm-wasi-wagi
| 0des wrote:
| perl did nothing wrong
| keyle wrote:
| whilst technically correct, perl hackers on the other
| hand...
| brtkdotse wrote:
| It's amusing to see a whole generation of senior developers
| ("senior" as in 5+ years of experience) that haven't
| experienced web development without React[0] and who proceed to
| reinvent PHP/ASP.NET/RoR.
|
| [0] Used here as shorthand for "modern js driven development"
| jacobr wrote:
| Another developer here who's been around for the tech you
| mention.
|
| The evolution has been 2 steps forward but 1 step back. It's
| how many complex systems evolve and it's fine. Just because
| you see that some problems/solutions resemble what you saw 10
| years ago doesn't mean nothing was improved along the way.
| dgb23 wrote:
| Personally I've been using both PHP and Node/React
| extensively and let me tell you there are very good reasons
| for the React/Node/JS ecosystem to exist and they are
| decidedly not borne out of ignorance of the PHP ecosystem.
| Ryan Dahl (inventor of Node and Deno) said that he created
| (paraphrasing) "the PHP of this generation" and React was
| invented within the probably the largest PHP shop to date.
|
| PHP is an unsafe, slow by default (execution model - the
| language itself fast), hard to use well, clunky, limiting and
| bloated language that is kept together by duct tape and the
| incredible effort and ingenuity of it's open source community
| by educating developers and improving/cleaning up the
| language at full blast, unfortunately often by breaking
| backwards compatibility.
|
| Whether JS (including Deno) is a good alternative or the
| right answer is up for debate. But people who try to mimic
| some of the benefits of PHP in the JS ecosystem are not doing
| so accidentally or because of lack of experience.
| efdee wrote:
| We could really do without this kind of snark here. Not only
| is it condescending, but it's also just plain wrong, either
| on purpose or due to the writer not being familiar with the
| subject at hand.
| dntrkv wrote:
| Such a tiring take...
|
| Nobody is reinventing PHP or RoR development. What is
| happening is the community taking all our favorite parts of
| these stacks and combining and implementing them in ways that
| facilitate a dev experience that we could only have dreamed
| of back in the PHP/RoR days.
|
| - Senior dev that started off in the PHP and then RoR days
| manigandham wrote:
| Back in RoR days? It's still here with new releases
| offering modern features. ASP.NET is even more cutting
| edge.
| edgyquant wrote:
| Yep totally agree with this.
|
| - Engineering Lead who got his start in PHP/ASP(pre .net)
| and loves the modern ecosystem despite its flaws
| nonethewiser wrote:
| You seem to be suggesting the Deno team has <= 5 years
| experience. Else, who is recreating PHP/ASP.NET/RoR?
| christophilus wrote:
| Been writing web stuff since before the dot-com bust. Preact
| + TypeScript is probably my favorite front-end programming
| combo yet. I liked VB6 and C# WinForms, though, so maybe I'm
| an invalid sample.
| sealthedeal wrote:
| Just like GoLang, I only wanna use this because that dinosaur is
| SO CUTE!! hahaha
| spicyusername wrote:
| Is the intent of this product to compete with something like
| Netlify?
| crowlKats wrote:
| No, Netlify actually uses Deno to some degree:
| https://www.netlify.com/blog/announcing-serverless-compute-w...
| spicyusername wrote:
| Right, but the $21M of funding seems to be for Deno Deploy,
| the product, not Deno, the CLI.
| crowlKats wrote:
| The wording in that blogpost might be a bit off, here it is
| more in-depth: https://deno.com/blog/netlify-edge-
| functions-on-deno-deploy
|
| Netlify is using Deploy
| haolez wrote:
| I think it's a good opportunity for Meteor, which is a very
| interesting framework but with some technical debt, to jump ship
| on Deno and start fresh again. Maybe they could try replacing
| their in-house synchronization mechanisms by managed services
| such as AppSync. Randomly wondering :)
| ChrisArchitect wrote:
| I'm not deep in Node world but I use it and see it being used,
| who is using Deno out there? Have there been some notable/major
| ship jumps? Or is it not that kind of situation (perception from
| when it came on the scene is that's exactly what it is,
| constantly trying to woo Node devs over). And also there's alot
| of recognizable brand competition out there from things like
| Cloudflare, Netlify (but they're an investor in this?), Vercel on
| fire the last year or two, and not to mention the big FAANG
| types. Again, who's using this?
| marcofatica wrote:
| Slack is the biggest I know of https://deno.com/blog/slack
| wperron wrote:
| Netlify, Supabase and Slack whitelabelling Deno Deploy for
| starters, I'm sure there are others out there self-hosting as
| well
| ChrisArchitect wrote:
| See now that's interesting - All of those have very out-there
| brand reach and recognition but who knew they were using
| Deno, nobody heh. Okay, then, so it's a bit under the radar
| but ticking away down there, hence the raise. Fairplay.
| wperron wrote:
| If you're not following those companies' offerings then it
| stands to reason you haven't heard about it but all three
| of them did broadcast pretty widely that they were using
| Deno, I would assume quite a few people were aware of this.
| jacobr wrote:
| From my horizon the most significant adoption has been Netlify
| edge functions. So not exactly ship jumping, but adjacent and
| growing spaces.
| IshKebab wrote:
| I think it's still pretty early days but it's clearly far
| superior to Node so I think we'll see more and more people use
| it.
|
| The biggest barrier is the library ecosystem. JS's insane
| packaging history means a lot of NPM libraries don't work
| seamlessly with Deno even if they don't use Node APIs.
| markandrewj wrote:
| I imagine you are already aware, but the creator of Node, Ryan
| Dahl, is also the creator for Deno. He is trying to create a
| new language which integrates what he learned from building
| Node.
| Johannesbourg wrote:
| Somebody doesn't understand O notation.
| m00dy wrote:
| I also didn't get it.
|
| so I think in their notaion O(10) has greater magnitude than
| (>) O(1)
| naniwaduni wrote:
| You're expected to read it out loud (in English), where one
| of the conventional readings of O(f) is "order of f".
| Conveniently "order of 100" is usually taken to mean _not_
| asymptotic behavior bounded by a constant multiple of 100,
| but a range within an order of magnitude or so of 100.
|
| Which is to say, they're saying Deno has a cold start time of
| ~100 ms, package size ~10M, a physical machine can support
| ~1k instances.
| pdpi wrote:
| They're abusing the notation, but doing so in a way that's
| perfectly clear.
| LudwigNagasena wrote:
| What does O(100) mean in the comparison table?
| selljamhere wrote:
| It's used as a comparison to the alternative, O(1000), an
| order-of-magnitude improvement.
| dragonwriter wrote:
| I think they are using O(x) as a shorthand for
| antilog10(log10(x)+-0.5).
|
| Or, in simpler terms, O(x) = "approximately x, to one
| significant figure"
| sfink wrote:
| "on the order of 100ms"
|
| It's misusing big-O notation for "order of magnitude", but
| after I initially tripped over it, it seemed clear enough.
| [deleted]
| sergiotapia wrote:
| Where's the angle for the investors - what will Deno do to
| produce the returns necessary for such a high amount? I thought
| Deno would be the eradication of Node and bring stability to
| Javascript. From the outside it seems to be firmly on it's way to
| being just another Zeit/Vercel. :(
| jhgg wrote:
| Deno deploy seems cool and all, but I haven't seen any great
| rationale for using their service over say Cloudflare Workers.
| kjksf wrote:
| As someone who dabbled with both workers and Deno Deploy: Deno
| Deploy actually works.
|
| I was very excited about the idea of workers but their tooling
| is (or at least was when I tried it last) abysmal, buggy and
| hard to understand. To this day I don't know how to setup a
| basic dev vs. production in workers.toml. Local debugging was
| buggy for naked domains (even found a GitHub issue for it that
| languished for months with no bugfix or clear explanation /
| workaround) and very slow.
|
| Great idea killed by poor dev tooling.
|
| Deno deploy is the opposite of that: deploys are instant and
| it's obvious how to deploy. You can develop and test locally.
|
| Cloudflare released wrangler v2 (which dropped rust for node)
| and maybe it's better now but the one experience I had with
| wrangler v2 was trying to deploy a small static website (pages)
| and it failed due to their backend throwing 50x errors.
| tick_tock_tick wrote:
| Yeah unless I'm missing something isn't this just a stand alone
| company offering roughly workers?
| mrkurt wrote:
| 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.
| threatofrain wrote:
| CloudFlare workers is on my radar because of an ecology of
| other "edge" products that are in the works or already
| released. That's what Deno would need to catchup on to be
| on the table for discussion for me. Otherwise it remains a
| toy I use in my spare time (which I do enjoy at the
| moment).
| mattlondon wrote:
| You could say the same about AWS Azure, and GCP.
|
| Competition is good.
| jhgg wrote:
| Competition is great - sure, but I want to know what Deno
| gives me over its competitors.
| jbaczuk wrote:
| Deno Deploy, how is this different than lambda functions, or
| elastic beanstalk?
| danielovichdk wrote:
| I read half and thought "how did this get any funding".
|
| Who validated this idea and with what measures?
| LAC-Tech wrote:
| Does this mean we can finally get a REPL where a file can be
| loaded, modified, then reloaded, without having to restart the
| whole thing?
|
| Seriously my biggest pet peeve with both deno and node.js. In
| every other REPL I've used this is basic functionality. When I
| talk about this to JS people they look at me like I'm from mars.
| alexwebb2 wrote:
| JS modules can produce side effects on load. Does that present
| an obstacle to that kind of REPL pattern?
| LAC-Tech wrote:
| I don't think so.
|
| Most repls use a special in repl keyword to accomplish this.
|
| For some reason the JS community can't move past "but modules
| are special". Ocaml has modules too and the repl can reload
| stuff from a file no problem.
| stephen wrote:
| Naive question, but is that dictated in the spec? Probably?
|
| Just wondering that, since Deno is rewriting all of npm
| anyway, it would have been a great time to revisit some of
| these historical script-y design decisions, to make
| JavaScript/TypeScript-at-scale suck less.
|
| Granted, probably too late now, but as-is neither of Deno's
| url-based imports or sandboxed-by-default changes has seemed
| worth the migration cost.
|
| But, if they also made something like "everything hot reloads
| for free" level ergonomic/platform changes, then yeah, I'd be
| hopping over.
| kirankp89 wrote:
| I've never been interested in JS as I mostly work in C++ but the
| ease of install/use of Deno over Node made me actually want to
| try it. It's nice to have access to a bunch of web tech with a
| single binary. Very excited to see where this project goes!
| mmastrac wrote:
| I played with an early version of Deno a few years back and it
| was already way more comfortable to use than node. It's a real
| counterexample to second-system syndrome.
|
| The only reason I didn't continue was a lack of ARM support.
| zackangelo wrote:
| Surprised this is the case because I use their Rust v8 bindings
| on an ARM laptop almost every day. Have you tried building it
| from source?
| mmastrac wrote:
| It was a few years back and I was mainly playing with a few
| early projects. I was very productive, but wanted to target
| my Raspberry Pi and it just wasn't there. I ended up going
| 100% rust instead.
| mattlondon wrote:
| There are still no RPi builds as far as I am aware, which
| is a shame as there are now Mac silicon builds so not sure
| what the hold up is. I do wonder if there are.more
| Raspberry Pi's out there than M1/M2 Macs :)
|
| Someone is doing the builds here - been using them and seem
| ok: https://github.com/LukeChannings/deno-arm64
| crowlKats wrote:
| The M1 builds are made manually by us, as github doesnt
| provide any runners. the same problem does apply for
| linux arm, however we don't have any arm linux systems
| any one of the members use; and building on a pi is a no-
| go, as that can take 70+ minutes, so that would make our
| release cycle a lot more complicated. Either way, we are
| investigating potential possibilities besides waiting for
| github to have runners available
| pcl wrote:
| Have you tried building in a rpi virtual machine on a
| Mac? I have no idea what the performance would look like,
| but it'd be easy enough to try, especially since you are
| already managing your own max builders.
|
| I want to say I followed these instructions for doing so
| recently:
|
| https://gist.github.com/plembo/c4920016312f058209f5765cb9
| a3a...
| beaker52 wrote:
| What made it "way more comfortable" for you?
| DangitBobby wrote:
| I had a very different experience. I very much wanted to make
| it work, but trying to use it with existing npm packages and
| import maps was incredibly painful, and I ultimately switched
| over to node for that project.
| keb_ wrote:
| Haven't tried import maps, but so long as the npm package
| uses ES Modules and doesn't rely on Node specific APIs, you
| should be good to go.
| vlunkr wrote:
| This question is going to make me sound like a jerk, but why do
| you want to write your back-end in JS? Deno looks like a great
| improvement over node.js, but I don't feel compelled to use it.
| It seems like people jumped to node based on some performance
| promises that didn't really pay off (IMO). And since then, we
| have newer options like Rust, Go, and Elixir as performant back-
| end options, and even older choices like Ruby and Python have
| continued to improve.
|
| Seems like the standard arguments would be that developers
| already know JS, and that you can share code with the browser. I
| don't find these highly compelling.
|
| EDIT: I haven't learned typescript yet, based on the replies, it
| seems like that could be a good reason to choose it. Seems like a
| nice middle-ground between typical scripting and compiled
| languages.
| Escapado wrote:
| I think developers knowing JS/TS is a highly compelling
| argument given the fact that most companies are struggling to
| find any devs at all. I would argue finding Rust/Go/Elixir
| developers is going to be _a lot_ harder for a lot of companies
| than finding JS developers.
|
| Also then sufficiently proficient frontend Devs have an easy in
| into backend development which has turned out to be a very good
| thing at 5 different companies I have worked for in the last 4
| years.
|
| In addition to that not every backend or service needs much
| performance. I have written quite a few services that get hit
| maybe 3 or 4 times a minute at best and Node was great for
| that. Actually I have yet to work anywhere where performance
| was limited by the language choice and not by architectural
| decisions or inconsidered use of databases and data structures.
| I am not saying this does not exist but it does not mirror my
| experience with the majority of companies at all.
|
| I'd also say that despite npm and dependency hell being a real
| problem there is a vast ecosystem of packages out there. I know
| python has that going for it too. But Elixir is much less
| developed in that regard - simply by being less popular.
| quickthrower2 wrote:
| Hard to out my finger on a single reason for it but I prefer it
| for hobby projects.
|
| Part of the reason is I am already using node for tooling for
| the front end.
|
| It is less powerful than say C# for example in multitasking -
| but for hobby projects that rarely matters.
|
| Typescript makes a big difference.
|
| There is a lot of community support: stackoverflow, npm
| packages etc. Every SDK has a JS version.
|
| It is fast enough for my needs.
|
| NextJS is another good reason.
| presentation wrote:
| Sharing code with the browser can be really sweet. At a past
| job we used TypeScript, and I had whipped up some shared types
| that our API was forced to conform to, and that automatically
| generated a strongly typed API client for the frontend to use.
| Sure, you can do that with some other protocol or server like
| GraphQL/Hasura/writing up a JSON schema, but it was pretty
| sweet that A) any of our engineers could figure out how to make
| the endpoints they needed to implement a new feature, B) these
| types could generally be inferred from the actual API
| implementation without having to explicitly write types out
| which completely eliminated bugs around API misuse with minimal
| extra code, and C) all of the code we wrote followed the same
| linters, formatters, idioms, and utilities (fetching, logging,
| error handling, and so on). There are projects out now that
| wrap up a lot of what I had done like tRPC [1], as a testament
| to the value of the shared abstractions.
|
| [1] https://trpc.io/
| rr888 wrote:
| To me its very powerful to have the same developers do both
| front end and back end. With modern frameworks its probably
| easier for front end devs to do back end work than
| Rust/Go/Elixir devs to dirty themselves with JS. So even though
| ts is suboptimal it allows one language, one set of tools and
| developers.
| flohofwoe wrote:
| I may be the odd one out, but for me node.js (and hopefully in
| the future Deno) isn't about the backend, but instead it's a
| pretty nice scripting environment for tooling and automation.
| I've been using mainly Python for this in the past, but got
| burned out quite a bit by the python2=>3 transition.
|
| (but still: don't underestimate the raw performance of V8, for
| many things it's definitely good enough)
| mmcnl wrote:
| I completely understand what you're saying, but Python is a
| lot better now. You don't have to worry about Python 2
| anymore and the tooling is a lot better as well (Black,
| Flake8, Poetry are all really nice).
| mrkurt wrote:
| I like TypeScript and would like to write backends in
| TypeScript.
|
| I'm coming around on Elixir.
|
| I never want to write Go that interacts with a database again.
|
| Rust seems complicated. I don't think I'm smart or committed
| enough to get anywhere with rust.
| norman784 wrote:
| > Rust seems complicated. I don't think I'm smart or
| committed enough to get anywhere with rust.
|
| Rust is a bit rough yet to do the front and backend
| development, but IMHO it will catch in a year or two. Also
| for backend rust now with (actix and axum) looks pretty
| similar to expressjs, so you will feel like home there, but
| for the frontend there's still no killer framework nor a
| settled architecture that fits better rust model.
| kbd wrote:
| > I never want to write Go that interacts with a database
| again.
|
| Why? I've been using sqlx and it seems fine.
| cdelsolar wrote:
| yeah, i'm using pgx and it rocks
| christophilus wrote:
| Sqlx is the way.
| timmg wrote:
| You're kinda stuck writing JS on the frontend. The (only)
| advantage of also using it on the backend is that you can share
| code. In some cases, I could see that being compelling.
|
| FWIW, I think Typescript would make an even stronger case. And
| I think(?) that's one thing Deno is trying to do.
| Hamcha wrote:
| I use Deno from time to time, and in my opinion more than a
| back-end language it's a really powerful scripting language.
| Being able to reference libraries by URL and the Go-like
| standard library mixed with Typescript async makes it a breeze
| to develop simple one-use CLI tools!
| mattlondon wrote:
| It uses typescript predominantly, and only compiles down to
| JavaScript. (I think you can code in plain JavaScript directly
| but I don't think anyone would want to do that)
|
| The benefits are in my mind not that you can share code
| directly but more that the std lib is the same (mostly) between
| backend and frontend. This means no mental context switching
| for developers.
|
| The other bonus is that typescript is just such a lovely thing
| to code in. Expressive, universal and ubiquitous, performant -
| modern JS is a joy to use (...if you don't need to use NPM...
| If you need to use NPM at all then it is a shit show)
| digitxpc wrote:
| I've written up an at-scale production backend in Node.js and
| can very much stand by the decision to use Node over Elixir or
| Go (which I was considering at the time). I think
| fundamentally, the power of a JS-based backend is its
| pragmatism--it's not the best at most things, but it comes very
| close to it in so many categories that it's a safe option for a
| lot of use cases.
|
| > It seems like people jumped to node based on some performance
| promises that didn't really pay off (IMO). And since then, we
| have newer options like Rust, Go, and Elixir as performant
| back-end options, and even older choices like Ruby and Python
| have continued to improve.
|
| I'd agree that Node.js performance is generally not the best
| reason to be writing a backend in it since a static language
| will often yield better performance, but for the amount of
| dynamic power you get, it's extremely performant by default[1].
| The next most performant dynamic language for I/O is, like you
| said, probably Erlang/Elixir, but V8 is generally understood to
| have better CPU-bound performance than BEAM.
|
| [1]: https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
|
| > Seems like the standard arguments would be that developers
| already know JS, and that you can share code with the browser.
| I don't find these highly compelling.
|
| I've found that developers already knowing JS is a very
| practical reason, if not ideological. I'm in a team with a lot
| of generalists who like to work full-stack, and being able to
| use the same mental models and syntax is a lot of cognitive
| load lifted off our shoulders. It also doubles the hiring pool
| of people who can hit the ground running on the backend,
| because now anyone who has experience with JS on the frontend
| can jump over to the backend with relatively little training.
|
| The other key reason for a backend in JS is that the community
| is extremely large, which means that a lot of the
| troubleshooting I'd have to do in languages with smaller
| communities is done for me by someone who was kind enough to
| post a workaround online. This saves me a lot of time and
| energy, as does the plethora of packages.
| brundolf wrote:
| And the performance argument isn't even just about CPU time,
| right? The fact that JS is heavily event-friendly, and all of
| its IO APIs are non-blocking by default, gives it an
| automatic advantage over busy-waiting languages like Python,
| and also languages where concurrency means writing threads
| manually. If your web server spends most of its time on IO
| (network, DB, file system), as many do, JS acts as a
| lightweight task-delegator to a highly parallel and
| performant native runtime.
|
| I haven't worked on a large-scale JS back-end myself, but
| this is the case I've heard others make
| golergka wrote:
| I've written backends using C#, PHP back in the day, a little
| bit of Go, Java and naked SQL, and I prefer Typescript language
| and npm ecosystem, hands down. May be not for writing highload
| distributed systems that are critical at RAM & CPU, but IO-
| heavy business logic where managing requirements and their
| changes is the hardest challenge, it's a godsend.
| pictur wrote:
| deno seems like a great project that solves problems that don't
| actually exist
| femiagbabiaka wrote:
| Are there any sources for the claims made in the chart on the
| second half of the page or are they theoretical? Seems really
| cool in theory!
| potamic wrote:
| Interesting how this will play out. It's an ambitious goal to
| consolidate client side and server side javascript ecosystems
| which is quite fragmented today. On the other hand, this may only
| increase fragmentation further by introducing another target to
| develop for (wait for transpilers that can automagically convert
| between deno and node code). I will always look at javascript as
| this problem kid that cannot get its shit together in life,
| perpetually chasing the romance of utopia.
| jitl wrote:
| There is already a system for building a NPM node package from
| a Deno package, called dnt (deno to node). It's maintained by
| some Deno team members. Here's a blog post they wrote about
| porting "Oak" (a deno HTTP server framework) to Node:
| https://deno.com/blog/dnt-oak
|
| The nice thing about Deno conceptually, is that it's much more
| similar to the browser platform than node is. It uses ES6 only,
| has things like `fetch` built-in by default, and generally
| follows browser standards around interfaces like Request,
| Response, etc. Instead of needing a complicated build process
| to make Node code work on the browser, now we have a
| complicated build process to make Deno/Browser code work on
| Node. -\\_(tsu)_/-
| melony wrote:
| Can the same build pipelines be reused for CF/Fastly workers?
| The DX for workers is horrible with multiple buggy Wrangler
| implementations and zero observability into deployed workers.
| capableweb wrote:
| Not to take away from the rest of your message, I thought you
| wanted to get up to speed on that `fetch` is now available in
| nodejs core since version 17 or something like that (think it
| got included early this year).
| jitl wrote:
| I think this requires the `--experimental-fetch` command-
| line argument (per
| https://nodejs.org/tr/blog/release/v17.5.0/), so I don't
| think it qualifies as "by default".
| wging wrote:
| That's an old blog post; the current release is 18.4.0,
| which supports `fetch` without a command-line argument.
| You do get this warning the first time it's invoked,
| though: (node:340760)
| ExperimentalWarning: The Fetch API is an experimental
| feature. This feature could change at any time
| (Use `node --trace-warnings ...` to show where the
| warning was created)
|
| (some later blog posts that mention fetch being enabled-
| by-default and in the global scope are
| https://nodejs.org/en/blog/announcements/v18-release-
| announc... and
| https://nodejs.org/en/blog/release/v18.0.0/)
| wdb wrote:
| Yeah, but you could use `undici`-package for older Node
| version as it is being used to provide this experimental
| Fetch in Node 17+
| the_gipsy wrote:
| What about using an npm package in deno?
| wperron wrote:
| Has been possible (and surprinsingly easy) for a while
| through CDNs like skypack or esm.sh
| danielvaughn wrote:
| It's what I kind of love about it though - the JS ecosystem is
| Neverland.
| tambourine_man wrote:
| https://xkcd.com/927/
| ricardonunez wrote:
| I knew that xkcd before I even clicked. They should update it
| and increase the number dramatically.
| tambourine_man wrote:
| It could store a cookie and increment the number every time
| you see the comic
| keyle wrote:
| I think we're in the 100s by now, within the javascript
| ecosystem alone! :)
| thdxr wrote:
| there is a group formed including Deno that will work together
| to try to maintain standards + compatibility
|
| https://blog.cloudflare.com/introducing-the-wintercg/
| asien wrote:
| Funny because I don't see how they can make any money from
| this....
|
| Plus outside of << Running Typescript >> or shitting on npm /
| Isaac Ryan has so far solved none of the problems that exist in
| the node ecosystem...
|
| Deno is node.js all over again , with its team lacking any sort
| of vision of maturity dependencies all over the place , but this
| time.... decentralized !
|
| The language still doesn't include the fundamentals library or
| providing an homogenous api design for I/O ... it's just
| baffling...
|
| I find that fascinating since the whole motto for Deno was
| Consistency, Ecosystem and Performance....
|
| I'm a node.js guy but if I need performance or design a large
| project I go with something fast and professional like
| Rust/Go/Kotlin.
|
| When I look at the ecosystem of JavaScript it's frightening to
| see how little coders care compared to Go or Kotlin and how
| outdated in terms of design the code often is... Even the source
| of node it's just a bunch of function from pre-ES4...
|
| At least I'm happy for him he could finally cash out on sequoia
| money and become a SV millionaire like everyone else !
| latchkey wrote:
| Attack the technology all you want as those are some valid
| criticisms, but the sarcastic personal attack at the end seems
| unnecessary. Imagine how he'd feel reading that. Would you want
| to have that same feeling yourself?
| l30n4da5 wrote:
| > Even the source of node it's just a bunch of function from
| pre-ES4
|
| Old code does not mean bad code. Seems like a silly thing to
| look at, honestly.
|
| A bunch of java was written pre-java8, does that make it all
| bad? No, no it doesnt.
| spoils19 wrote:
| In most scenarios, new ways of writing the same code is a
| waste of time. I actively discourage use of things like type
| inference in newer Java versions as it goes against the
| purity of the original vision of the language. It's a
| detriment to mental agility, and it also makes scores of
| incredibly useful, deep books and learning resources outdated
| and useless.
| jonny_eh wrote:
| New language features are for new code.
| rlt wrote:
| > At least I'm happy for him he could finally cash out on
| sequoia money and become a SV millionaire like everyone else !
|
| Tell me you don't know how venture capital works without
| telling me you don't know.
| jxf wrote:
| > Funny because I don't see how they can make any money from
| this....
|
| Deno Deploy makes money; it's $10/mo/app:
| https://deno.com/deploy/pricing
| gumby wrote:
| > At least I'm happy for him he could finally cash out on
| sequoia money and become a SV millionaire like everyone else !
|
| It doesn't actually work that way. This is an A round, so a
| priced round, so in theory the founders' equity could have some
| noticeable valuation but in reality the common will have no
| meaningful cash value and the founders aren't worth anything as
| a result of this funding. Yet, at least.
| nxmnxm99 wrote:
| They raised 21 million how are they millionaires lol
| gumby wrote:
| > When I look at the ecosystem of JavaScript it's frightening
| to see how little coders care compared to Go or Kotlin ...
|
| I don't know about _care_ but there is a clear difference
| between people with a computer science or formal programming
| background and most developers. You can bemoan that, but isn 't
| it desirable that there be a democratization of development? In
| fact the number of simplifying tools and packages built by
| programmers to speed _everyone_ up inevitably decreases
| barriers to doing development, and in many cases improves the
| quality by managing the harder stuff properly.
|
| We had the same phenomenon a generation or more ago with
| Visicalc and Excel, where people who would never think of
| themselves as programmers wrote complex macros to get their
| jobs done.
|
| And a decade before that we famously had secretaries writing
| EMACS macros who certainly never thought of themselves as
| programmers.
|
| I think this is all a good thing, even if I am dubious about my
| bank's phone app.
| threatofrain wrote:
| Personally I got the sense that the Go community doesn't really
| care for web apps or anything too close to React, but maybe I'm
| just not experienced enough yet with Go. Is there something
| like CreateRustApp but with Go?
|
| https://github.com/Wulf/create-rust-app
| geodel wrote:
| I think you are right. Go devs seem content with their mark
| position/ranking. Use Rust if it is providing more resources
| that are helpful to you.
| mmgutz wrote:
| I don't think it's needed. The new front-end build tools
| optimize for production use and have a great developer
| experience. Use Next.js or any of the many toolkits out
| there. There will be a lot more support for them too.
|
| I use Go with Next.js and svelte-kit.
| brundolf wrote:
| My experience with Deno has been:
|
| - I don't need to mess with third-party tooling, half a dozen
| project configs, etc because everything is built-in and Just
| Works
|
| - The standard APIs are mostly wonderful- modern, promise-
| based, practical, etc. Documentation leaves something to be
| desired and many core APIs are still unstable (in that they get
| breaking changes (though you can easily pin to a specific
| version)), though for most of the ones with direct analogs in
| Node you can honestly just follow the Node docs
|
| - Standardized importing is awesome; we may finally leave
| behind the nightmare of multiple coexisting module systems
|
| - Standardized testing is awesome
|
| - The lack of an install step is awesome
|
| "Isaac Ryan has so far solved none of the problems that exist
| in the node ecosystem" is simply wrong, and feels like a cheap
| and uninformed dig rooted in some personal beef you must have.
| password4321 wrote:
| + People get paid, hopefully a few even get big $.
|
| - Investors want unicorn returns.
|
| Good luck!
| [deleted]
| brundolf wrote:
| What is their actual business model? I know there's Deno
| Deploy, and presumably they offer some kind of enterprise-
| support type deal. But the first is easily copied by
| competitors (in an already-crowded market), and the other isn't
| super lucrative. Is there anything else?
|
| I love Deno and want it to succeed, but it doesn't feel like a
| unicorn, and I'm worried about it being expected to become one
| [deleted]
| Vinnl wrote:
| Considering that one of those competitors is Netlify, then
| either the incumbent (i.e. Netlify) is in a great position to
| benefit from a succeeding Deno, or Deno Deploy does succeed
| and Netlify can profit from that. A bunch of other
| participants (GitHub/Nat Friedman, Automattic) seem like they
| could benefit from a thriving ecosystem around Deno as well,
| even if Deno Deploy isn't particularly successful.
| danenania wrote:
| Open source ecosystems that become big enough often end up
| either producing unicorns, or failing that, producing
| unicorn-level returns for existing companies.
|
| There's no guarantee that the creator of the ecosystem will
| be one of the unicorns, but they're as good a bet as any
| other company to pull it off. VCs aren't looking for 100%
| certainty, just a plausible path.
| kjksf wrote:
| https://deno.com/deploy/pricing is their business model.
|
| They charge you for CPU and bandwidth more than they pay for
| it.
| brundolf wrote:
| Right, my point is that any number of cloud providers could
| swoop in and offer the same product for probably cheaper
| amsnl wrote:
| This is generally true about every company though.
| Someone can always swoop in, and huge incumbents can
| always do it cheaper, at least in theory.
| IshKebab wrote:
| I feel like they have a better business plan than NPM did at
| least. They'll probably get acquired by one of the big cloud
| players.
| brundolf wrote:
| I guess that makes some sense. Still feels like it would be
| a weird thing to aim for, but maybe that's the state of the
| industry
| TAForObvReasons wrote:
| Pecunia non olet. If the goal is to make money, an exit
| via acquisition is one potential way to make money
| bowsamic wrote:
| I think they should get a reasonable return. Deno has a lot of
| hype and Node has a lot of cultural weight, as does Ryan
| himself. Not sure about unicorns though! It does not seem like
| a unicorn product, but I'm not a VC
| nikanj wrote:
| You don't get $21M from investors for nothing. They will
| force the square peg through the unicorn-shaped hole - or
| kill the company trying
| bowsamic wrote:
| > You don't get $21M from investors for nothing.
|
| Do you think that investors see every company that isn't a
| unicorn as "nothing"? I think you're living in a fairytale
| nikanj wrote:
| The VC model is not built on 10x exits. Later rounds,
| sure, but series A is definitely looking for larger
| multiplier.
| crsv wrote:
| If you're a venture capitalist, this is in fact the
| model.
| bowsamic wrote:
| If they're expecting a unicorn why are they funding Deno?
| lmeyerov wrote:
| VCs see a tiny chance that it can be a 100X return. So
| raising $20M at say a $50-100M valuation now, that means
| betting on a $5B+ exit. In return for getting money to
| take a shot at that level of artificially-fueled revenue
| growth, the founders are willing to cede control of the
| community to professional financiers. As others wrote,
| that's the VC model: make a ton of these bets, and as
| long as 2-4 turn out, the lottery winners pay for the
| bankruptcies.
|
| Given every big company uses JS, and thus many SaaS VCs
| have JS in their annual set of thesis bets, it's
| reasonable that Deno got picked by a top group given
| their team & growth. Same story with npm, netlify, etc.
|
| I wish the team luck in hitting significant revenue in
| the next 9-12mo, as that will determine a lot of what
| happens to the community. A lot of pressure & culture
| change to work through!
| bowsamic wrote:
| Maybe they see a chance of it but they cannot seriously
| expect it
|
| EDIT: the comment I responded to was completely rewritten
| and replaced with a different one. Please don't do this
| lmeyerov wrote:
| The main _base_ expectations are that out of all of
| Sequoias bets, some will become $5B+ co 's, and for the
| next 18mo, deno can grow headcount with salaries
| unrelated to sustainability
|
| Some people involved might expect more, and I'm sure hope
| for more, but I'm a language designer & CEO, not a mind
| reader :)
| mrkurt wrote:
| They do, but that's not a bad thing. Sequoia invests in
| companies they think could be worth multiple billions.
|
| If Deno reaches 30% of the impact of Node, their company
| could be worth billions.
|
| In the meantime, we get a better open source runtime
| because they have money to build it out.
| ushakov wrote:
| a startup could be worth billions only based on the fact
| that investors continue throwing money at it
|
| there are lots of companies, which are technically
| "unicorns", but haven't even got any revenue yet (Rivian
| and Nikola come to mind)
| loftsy wrote:
| An "isolate cloud" is exactly how Google App Engine worked 10
| years ago. It was a good idea then and is still a good idea now.
| jaredcwhite wrote:
| The rise of JavaScript-only clouds intended as "defacto"
| solutions for web development scares the hell out of me.
| Monocultures are dangerous. At least in the early Node era, it
| sat alongside all the other flavors of server infra out there
| with a near-infinite variety of languages, platforms, OSes. Now
| we're being told that the future of web development is...Deno?
| That's it? One tool? One language? One platform?
|
| Not the web I intend to build and participate in, I can tell you
| that right now.
| madeofpalk wrote:
| Granted, I don't pay a lot of attention to it, but I thought
| Docker(files) ended up being the defacto standard, not
| Javascript?
|
| I'm sure _Deno_ will tell you the future is _Deno_. You don 't
| have to believe them.
| pharmakom wrote:
| Deno sounds like a powerful runtime, but what is there to sell?
|
| I won't build on anything that isn't permissively licensed. They
| can't charge for anything without license protection.
| erk__ wrote:
| They are selling a global Deno hosting service
| https://deno.com/deploy
| pharmakom wrote:
| And what happens when AWS, Azure, Google Cloud, Digital
| Ocean, OpenShift, IBM, ... roll this out?
| gtirloni wrote:
| Is it Docker Inc all over again?
| 0des wrote:
| joyent
| pcj-github wrote:
| Comments are a bit negative. I for one think they are onto
| something here. Surprised it's only 21M. I would have expected in
| these market conditions to beef up more for the next 2-3 years.
| vincentmarle wrote:
| > Surprised it's only 21M.
|
| Indeed, especially when you compare with a company such as
| Supabase (which is working on way less interesting technology
| imho) who just raised $80M:
| https://news.ycombinator.com/item?id=31328783
| mrkurt wrote:
| Deno probably would have raised $80M if they'd raised the
| same time Supabase did. Investors got quite a bit more tight
| fisted between January and April.
| vcryan wrote:
| Deno overstates the problem it is intended to solve because its
| founders needed to justify achieving funding by being developer-
| famous.
|
| Let's say a company were to adopt this tech over Node, well, it
| seems like it would be slightly better, but probably not much of
| a game-changer.
|
| I'll leave it to y'all to talk about what tech is truly
| interesting as I don't want to seem ideological/biased, I just
| don't see how Deno is particularly notable.
| Androider wrote:
| It's usually not enough to be a bit better than what you're
| trying to displace, you have to be 10X better than the status
| quo to have any real impact. For example, SVN tried to be a
| better CVS, while Git came out of left field and destroyed the
| competition by being 10X better.
|
| In that, Deno reminds me of the once-hyped Meteor.js. Meteor.js
| also though that funding could be answer, but it wasn't.
| They're both clever, great for demos, but not sufficiently so
| to overcome the sheer inertia of Node+NPM et al. When something
| truly 10X better arrives, it will be quite apparent. Just like
| how React spawned a new generation of frameworks, nothing has
| unseated it yet because all the competition is React-like and
| not 10X better.
| blobbers wrote:
| It will be interesting to see if Deno can provide the level of
| productivity improvement node.js delivered (was supposed to
| deliver? continues to deliver?).
|
| It's one thing for it to claim supremacy over node, but can it
| attract the TJ Holowaychuk's of the world and truly generate a
| full ecosystem.
| azangru wrote:
| > but can it attract the TJ Holowaychuk's of the world and
| truly generate a full ecosystem
|
| Something like this?
| https://twitter.com/dassurma/status/1407048553768402949
| dirtyaura wrote:
| Can someone more knowledgeable highlight what kind of security
| model do these Deno deployments have compared to virtual machines
| and containers, if they are isolated at the process level.
| blocked_again wrote:
| Is Deno going to be the first runtime environment to IPO?
| vaishnavsm wrote:
| I think Sun Microsystems IPOd
| andruby wrote:
| Were they not making & selling hardware at the time of IPO?
| didip wrote:
| heh, I knew for sure Deno would be successful from the first
| moment it appeared on HN and people here were critical of it.
|
| My rule of: The more HN criticizes it, the more likely it
| succeeded, still rings true.
| eyberg wrote:
| I don't know if marketing was involved with using the term
| 'isolate' or not but if they are isolates as described by
| companies such as Cloudflare and Google, it might help to speak a
| bit more about the actual implementation at the infrastructure
| level.
|
| Isolates are a really interesting approach to deal with the
| inherent nature of scripting languages to deal with the lack of
| threads as most scripting languages are inherently single-
| thread/single-process. If you have a 2000 line ruby class named
| 'Dog' you can easily overwrite it with the number 42. This is
| awesome on one hand, however it makes scaling the vm through the
| use of threads too difficult as threads will share the heap and
| then you have to put mutexes on everything removing any
| performance gain you would have normally gotten. Instead the end-
| user has to pre-fork a ton of app vms with their own large memory
| consumption, their own network connections, etc and stick it
| behind a load balancer which is not ideal to their compiled,
| statically typed cousins and frankly I just don't see the future
| allowing these languages as we continuously march towards larger
| and large core count systems. I'd personally like to see more of
| the scripting languages adopt this construct as it addresses a
| really hard problem these types of languages have to deal with
| and makes scaling them a lot easier. To this note - if you are
| working on this in any of the scripting languages please let me
| know because it's something I'd like to help push forward.
|
| Having said that, they should never be considered as a multi-
| tenant (N customers) isolation 'security' barrier. They are there
| for scaling _not_ security.
| kentonv wrote:
| > Having said that, they should never be considered as a multi-
| tenant (N customers) isolation 'security' barrier. They are
| there for scaling not security.
|
| V8 isolates are absolutely designed for security. For 10 years
| V8 was the only security barrier between sites in Chrome. Now
| they have retrofitted strict site isolation for defense-in-
| depth, but that doesn't mean the V8 team suddenly doesn't care
| about security. Chrome wants both layers to be secure and will
| pay a bug bounty if you break either one.
| [deleted]
___________________________________________________________________
(page generated 2022-06-21 23:00 UTC)