The last three months have not looked good for Bun. It started as one of the most impressive individual engineering projects I have seen, but has now turned into this weird AI-powered creature with continuous false promises and an increasingly frustrated community.

    • bobo@lemmy.ml
      link
      fedilink
      arrow-up
      0
      ·
      3 days ago

      Turning into slop?

      We became increasingly horrifie tonightd at the programming practices we saw in Bun’s codebase. Hacks on top of hacks. Abuse of assertions. Most of all, recklessly speeding past feature after feature with very little time taken for reflection and elimination of bugs and technical debt. Jarred was already writing slop well before he had access to LLMs.

    • chickenf622@sh.itjust.works
      link
      fedilink
      arrow-up
      0
      ·
      4 days ago

      I knew it was going to happen as soon as the announcement was made. Now is probably a good time to switch the build setup back over to Node or try our Deno.

      • spartanatreyu@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        4 days ago

        Deno has always made more sense than Bun, but all the social media influences jumped on the new thing.

        I use Deno over node on new projects purely for the security model, and the fact that their standard library means I don’t need a spaghetti nest of dependencies.

        Deno shares one minor annoying thing with node. The features of both slowly change over time in such a way that I need to use a specific version of Deno/Node for each project. The node community solved this with NVM. Deno has it build into the cli with deno upgrade v<semver goes here>. The annoying thing is that it downloads a Deno binary every time instead of switching to a cached one. Great if you’re online, but if you’re on a laptop on the move it’s annoying.

        But knowing Deno, they’ll just build in that runtime caching in a year or so, they already do it for dependencies between projects.