5 ms·

I agree. Since you seem to know the area, do you have any comment on which contender (Bun or Deno) you see as most likely to take the crown, and also which you’

by cal85 3y ago

I agree. Since you seem to know the area, do you have any comment on which contender (Bun or Deno) you see as most likely to take the crown, and also which you’d prefer to take the crown? By ‘the crown’ I mean the status of being the leading JS runtime outside of web browsers. For me, Deno seems very well thought out, I’ve used it a fair bit and found it to work reliably and fast. I like the whitelist approach to system access although I worry that it could be a hurdle for adoption. I haven’t used Bun, just read about it. My sense is that Bun is more of a 1:1 replacement for Node, still tied to npm as a first class citizen, while Deno has a long term strategy to get away from npm (while supporting it as a legacy thing). Overall I’d prefer Deno to win, but I wonder if Bun has a better chance due to its closer parity with Node.

flkenosad 3y ago
I think you're right, Bun has a better chance just because because it's a drop in replacement and because it genuinely outperforms the existing tooling by a good margin. Also, LLMs know Node.js a lot better than they know Deno which may be a significant factor in 2023 and beyond.
- dns_snek 3y ago
  > Also, LLMs know Node.js a lot better than they know Deno which may be a significant factor in 2023 and beyond. I'm not disagreeing necessarily, but wow, I really hope it doesn't come to that. The timeline where languages, runtimes (and by extension libraries, frameworks, and even tools) are chosen based on how well they're supported by LLM tooling sounds horrifying. It would block adoption of better designed languages, tools and frameworks. If evolution is going to be stifled by LLMs, we'll miss out on paradigm shifts like JS Promises and ES6.
  - dragonwriter 3y ago
    > It would block adoption of better designed languages, tools and frameworks. Tooling concerns are already are a major source of friction for adoption, nothing really special about LLMs in that regard.
  - cal85 3y ago
    Humans are always used to working a certain way, and this fact benefits the incumbent technologies/tools/platforms of the day. This benefit must be outweighed by other factors, or we'd still be writing Fortran (or drawing on cave walls). The addition of LLMs to the mix might add to incumbency bias by being trained on whatever ecosystems are most popular, but I think this will be vastly outweighed by all the other things they bring to the table. We know that one thing LLMs are already pretty impressive at is translating between programming languages. So if anything, I can see LLMs launching a new era of diversification by making it easier for programmers to justify choosing a more esoteric/interesting language for a project without worrying so much about whether they will be able to find library code for their needs, as they'll be able to translate it without so much trouble.
  - freedomben 3y ago
    I agree that it sucks, but realistically I think that's the way it already has been, just with stack overflow, blog posts, books, etc. Nobody wants to adopt the new/better stack because it's not mature, so it never gets mature.
  - 8n4vidtmkvmk 3y ago
    I think it'll get better over the next few years and might have the opposite effect. As soon as we figure out how to keep LLMs up to date with recent developments it'll be easier for humans to adopt new things, not harder. The LLM can consume all the docs in a few minutes and then you'll be able to query it very easily.
deleted 3y ago
[deleted]
steve_adams_86 3y ago
I know some projects out there, like windmill.dev, have smarter people than me building things and they consider Bun the successor of Node. They offer support for Deno, but focus more on Bun support because of compatibility. This makes sense for two reasons, I think. One, the future seems brighter due to compatibility. Two, infrastructure work on Node compatibility transfers far more easily to Bun, but not to deno. It’s early still but my sense is that Bun will gradually gain ground as a Node replacement, but Deno will gain ground as something else. I think that’s actually the original intent behind both projects, too. Bun wants to be a better Node, Deno wanted to diverge in order to avoid what the author considers fundamental mistakes in Node’s design.

by cal85 3y ago

flkenosad 3y ago

I think you're right, Bun has a better chance just because because it's a drop in replacement and because it genuinely outperforms the existing tooling by a good margin. Also, LLMs know Node.js a lot better than they know Deno which may be a significant factor in 2023 and beyond.

dns_snek 3y ago
> Also, LLMs know Node.js a lot better than they know Deno which may be a significant factor in 2023 and beyond. I'm not disagreeing necessarily, but wow, I really hope it doesn't come to that. The timeline where languages, runtimes (and by extension libraries, frameworks, and even tools) are chosen based on how well they're supported by LLM tooling sounds horrifying. It would block adoption of better designed languages, tools and frameworks. If evolution is going to be stifled by LLMs, we'll miss out on paradigm shifts like JS Promises and ES6.
- dragonwriter 3y ago
  > It would block adoption of better designed languages, tools and frameworks. Tooling concerns are already are a major source of friction for adoption, nothing really special about LLMs in that regard.
- cal85 3y ago
  Humans are always used to working a certain way, and this fact benefits the incumbent technologies/tools/platforms of the day. This benefit must be outweighed by other factors, or we'd still be writing Fortran (or drawing on cave walls). The addition of LLMs to the mix might add to incumbency bias by being trained on whatever ecosystems are most popular, but I think this will be vastly outweighed by all the other things they bring to the table. We know that one thing LLMs are already pretty impressive at is translating between programming languages. So if anything, I can see LLMs launching a new era of diversification by making it easier for programmers to justify choosing a more esoteric/interesting language for a project without worrying so much about whether they will be able to find library code for their needs, as they'll be able to translate it without so much trouble.
- freedomben 3y ago
  I agree that it sucks, but realistically I think that's the way it already has been, just with stack overflow, blog posts, books, etc. Nobody wants to adopt the new/better stack because it's not mature, so it never gets mature.
- 8n4vidtmkvmk 3y ago
  I think it'll get better over the next few years and might have the opposite effect. As soon as we figure out how to keep LLMs up to date with recent developments it'll be easier for humans to adopt new things, not harder. The LLM can consume all the docs in a few minutes and then you'll be able to query it very easily.

deleted 3y ago

[deleted]

steve_adams_86 3y ago

I know some projects out there, like windmill.dev, have smarter people than me building things and they consider Bun the successor of Node. They offer support for Deno, but focus more on Bun support because of compatibility. This makes sense for two reasons, I think. One, the future seems brighter due to compatibility. Two, infrastructure work on Node compatibility transfers far more easily to Bun, but not to deno. It’s early still but my sense is that Bun will gradually gain ground as a Node replacement, but Deno will gain ground as something else. I think that’s actually the original intent behind both projects, too. Bun wants to be a better Node, Deno wanted to diverge in order to avoid what the author considers fundamental mistakes in Node’s design.