• BB_C@programming.dev
    link
    fedilink
    arrow-up
    8
    arrow-down
    13
    ·
    9 days ago

    Bun is a TypeScript runtime, like a faster NodeJS.

    I guess the target audience is non-coding AI skeptics looking for pseudo-intellectual takes, which appears to be a growing market. Because getting the very first technical detail, and a very basic one at that, this wrong is not a good look.

    • assaultpotato@sh.itjust.works
      link
      fedilink
      arrow-up
      16
      ·
      8 days ago

      https://bun.com/

      HTML title: Bun: A fast all-in-one JavaScript runtime

      Bun is designed as a drop-in replacement for Node.js

      https://bun.com/docs/runtime

      execute javascript/typescript files […] with Bun’s fast runtime.

      Am I missing something? How is that claim incorrect? I’ve never used Bun but their marketing material lines up exactly with the claim.

      • BB_C@programming.dev
        link
        fedilink
        arrow-up
        4
        arrow-down
        10
        ·
        edit-2
        8 days ago

        First of all. Strictly speaking, there is no such a thing as a TS runtime. TS compiles to JS.

        Second of all, bun binds against JavaScriptCore, which is the JS engine used in Safari. Node binds against V8, which is the engine used by Blink (Chromium et al). Both are implemented in C++. And the latter is considered the fastest engine.

        Ironically, both engines are mentioned by name in the very bun blog post being discussed, which points to a problem that is almost bigger than mere tech literacy from the pseudo-intellectual OP.

        • assaultpotato@sh.itjust.works
          link
          fedilink
          arrow-up
          13
          arrow-down
          1
          ·
          edit-2
          8 days ago

          Saying there’s no typescript runtime is (imo) a bit pedantic - if you JIT transpile TS down to JS at run time with hot-reloading you’re effectively a TS runtime. For a non-technical one-liner on Bun, I feel that is a very reasonable simplification to make.

          Perhaps bun would be even faster if they bound against another JS API, but that doesn’t mean that Bun isn’t faster than Node.js. They claim it’s 3x faster than Node in aggregate, and that can potentially be true even if they use slower machinery under the hood. Python is a slow language but a fast framework can outperform a poorly written C++ implementation.

          I’m not going to defend the article, I have no horse in that race, but until I see benchmarks that say Bun isn’t faster than Node in aggregate, I don’t think the claim can be called “wrong” on its face.

          E: that’s exactly what Bun does: “Bun supports TypeScript and JSX with no configuration. Bun transpiles every file on the fly with its native transpiler before running it.”

    • TehPers@beehaw.org
      link
      fedilink
      English
      arrow-up
      4
      ·
      7 days ago

      Which part of the statement is wrong? Bun is a TypeScript (and JavaScript) runtime and can execute TypeScript directly. Node.js can also execute TypeScript directly on relatively newish versions.

      Sure, internally they execute JavaScript, but the statement as-is isn’t incorrect, unless you’re saying that Bun is slower.

      • BB_C@programming.dev
        link
        fedilink
        arrow-up
        1
        arrow-down
        1
        ·
        7 days ago

        can execute TypeScript directly.

        Did the word “directly” get the same fate the word “literally” got? As in, it completely lost its real meaning?

        Bundling a compiler/transpiler and directing inotify at a source directory (for glorious hot-reloading) doesn’t a language “runtime” make. Otherwise, I can create “runtimes” for any language in three lines of code right now.

        unless you’re saying that Bun is slower.

        Are you saying JavaScriptCore is faster than V8? Or is the majority of time in webshittery operations not spent on actually running code, and that’s how bun “wins” ?

        • TehPers@beehaw.org
          link
          fedilink
          English
          arrow-up
          2
          ·
          7 days ago

          Are you saying JavaScriptCore is faster than V8?

          No. Are you saying it isn’t? Please cite your source if so.

          Bundling a compiler/transpiler and directing inotify at a source directory (for glorious hot-reloading) doesn’t a language “runtime” make. Otherwise, I can create “runtimes” for any language in three lines of code right now.

          My bad, they’re x86/ARM64 runtimes.

          • BB_C@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            7 days ago

            You could have searched for some benchmarks yourself, instead of thinking you’re winning an argument in such a stupid manner.

            Note that Jarred himself (bun creator) wouldn’t push against this either. Instead, he will sell you the aggregate performance talking point (as another user did), which is why I made my deliberately facetious comment about webshittery.

            • TehPers@beehaw.org
              link
              fedilink
              English
              arrow-up
              3
              ·
              7 days ago

              You could have searched for some benchmarks yourself, instead of thinking you’re winning an argument in such a stupid manner.

              Why would I do that? I made no claims to its speed. You’re the one making claims, so the burden of proof lies with you.

              Note that Jarred himself (bun creator) wouldn’t push against this either. Instead, he will sell you the aggregate performance talking point (as another user did), which is why I made my deliberately facetious comment about webshittery.

              I don’t really care what Jarred says though. He hasn’t exactly left a good impression with the direction he’s taken Bun.