431–440 of 446 posts
>>> Our investors are Dan Scholnick from Four Rivers Ventures, Guillermo from Rauch Capital, Lee Jacobs from Long Journey Ventures, the Mozilla Corporation, Shasta Ventures, and our long-time collaborator Ben Noordhuis. Why is the Mozilla Corporation an investor in a Chrome based technology startup ?
Earlier quoted context omitted.
Heck yeah
Was does a TS runtime means anyway? Doesn't checking types at run time rather than at compile time a pure loss?
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.
Earlier quoted context omitted.
Wasn't a TypeScript runtime the original Deno selling point? Didn't the project have to pivot away from that?
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.
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.
Earlier quoted context omitted.
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
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.
Earlier quoted context omitted.
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…
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.)
Earlier quoted context omitted.
Yes. Every Lodash function is available in its own npm package too. I use it like this, I rather have 4 lodash packages than the big whole lodash library in one package with almost everything left unused.
These will go away in v5 (if a v5 is ever released) and is not recommended if using a bundler as it'll end up wasting space rather than saving as it'll include duplicate code that each individual function could share. https://lodash.com/per-method-packages
Many developers, I think, don’t look past web-first abstraction layers.
I can’t tell you how many times I’ve seen CLI tools which are huge chunks of node wrapping a thin bash command. They are multiple files, orders of magnitude larger than they need to be, and require external dependencies because these developers are fixated on their proverbial hammer.
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 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.
Earlier quoted context omitted.
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 TypeS…
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.
Earlier quoted context omitted.
util.promisify() seems to work for many of the node stuff I use a lot, like pipeline(), readFile(), etc. Perhaps require('xyz/promises') is a newer development.
do you really want to keep util.promisifying everything? I know I don't. Streams (and event emitters, and the ecosystem bits that rely on them) still haven't fully caught up with promises either, e.g. async iterators and generators are still quite awkward
I mean, I don't mind using util.promisify or just importing the "to be" xyz/promises paths. The code exists clearly, either behind a symbol or otherwise.