4 ms·

For context: Deno's lead is Ryan Dahl, the creator of Node. In the past, Dahl's expressed regrets over choices he made early on in Node's development, and on

• lghh 6y ago
  And now, he'll make a whole different set of good and bad choices to potentially regret later.
  • gen220 6y ago
    such is the curse of having the audacity to develop software :)
    • lghh 6y ago
      Not necessarily. I prefer trying to improve what we have verses making a new thing every time we have a relatively minor disagreement, even if that disagreement is with our past self. EDIT: I'd like to add that clearly he is able to spend his time as he wishes.
      • gen220 6y ago
        I generally agree. Although, some of these are pretty "opinionated" breaking changes (promises all the way down, package manager changes). It would be hard to convince the whole node community that these upgrades are worth the risk forking in a python 2/3-esque way. Forcing TS is a change node could adopt in the next major version if everybody agreed, but the node community might be too big and diverse at this point, to make such an opinionated switch.
      • uryga 6y ago
        afaik modifying node doesn't make sense here – it'd be so incompatible that it'd effectively be "a new thing" anyway
    • nkozyra 6y ago
      Sure, but there's a tendency to start over when the development gets hard to maintain or support instead of just fixing the mistakes. This really feels like the fundamental response in the js world and why we see much churn.
      • polishdude20 6y ago
        But isn't this an inherent problem in software development that is really super hard to not do? Let's say you are deciding how to make node when it was first conceived and how it would work. You've made decisions about how the thing fundamentally works. Then after using it and developing for it many years and after having millions of critical software projects dependant on it, you slowly start to see the shortcomings of the software that you could only see at this stage. The problem is that these shortcomings come from a false assumption or solution to the fundamental problems you had to solve when making node. Now, the only way to fix node is to change how it fundamentally works. But if you do that, millions of users' code will break. So, do you require everyone now to fix their broken code and potentially piss everyone off? Or do you give people a choice? Stick with node if you aren't noticing any of those fundamental problems you found, or switch to the new thing on your own time? It's a question of how to affect the least number of people in the least negative way.
        • nkozyra 6y ago
          I think the answer is a break in backwards compatibility on a major version release. People in JS/frontend world are willing to drop the world for the latest new thing, I see this as less jarring than, say, Python 2 -> Python 3.
          • alessioalex 6y ago
            > People in JS/frontend world are willing to drop the world for the latest new thing Except there aren't any breaking changes in JavaScript, are there? Even in Node if anything is deprecated that is done over time in many years.
          • haack 6y ago
  • pulposus 6y ago
    Good that it’s called Deno, not Done!
• rosywoozlechan 6y ago
  > which we should probably think of as bourne-again node. Or maybe as Perl 6
• ignoramous 6y ago
  > The last 10 minutes are a pitch for what a "better Node" would look like, if he were to start from scratch in 2018. Is it fair to say (a managed) deno is what Cloudflare Workers is? If not, what would be key differences between them?
  • steveklabnik 6y ago
    PM on part of Cloudflare Workers and someone who was in physical attendance for this talk here. They're not really directly comparable other than "A JavaScript runtime built on top of V8." Workers doesn't support TS directly, though you can compile TS to JS and run it, of course. (My team maintains a worker and this is what we do, and it works well) Deno has its own APIs, as does Workers. Worker's main API is the Service Worker API, Deno's is not. Workers is focused on V8 isolates as a means of achieving multi-tenency. I don’t believe Deno does anything specific here. Deno is mostly implemented in Rust, the Workers runtime is written in C++. Deno is open source, Workers is not. Workers is being used at scale in production, Deno just launched its 1.0. I am very excited to see what happens with Deno. :) Fun history: I had been dreaming about doing "Chakra Core + Tokio" a few years back, but didn't find the time. I'm skeptical of the dependency approach Deno is taking, we'll see what happens!
    • mrkurt 6y ago
      > Workers is focused on V8 isolates as a means of achieving multi-tenency. I don’t believe Deno does anything specific here. Deno implements the web worker API, which launches different isolates. You could implement something kind of like CF Workers in pure TypeScript, but probably not replicate your resource enforcement. It's also a pretty good Rust v8 implementation. Before we (fly.io) abandoned our JS runtime we were rebuilding it with that. Ironically, we also tried Chakra Core + Tokio. It sure would be nice to have a not-google JS engine.
      • steveklabnik 6y ago
        Thanks for confirming, that’s what I meant by “specific”, I was guessing they implemented the spec. It’s just a very big focus of Workers, and I don’t think it’s a focus of Deno. Not good or bad, just a difference. Ah interesting! Did you abandon it for reasons other than “deno exists”? Would love to hear more about how it turned out, good or bad.