8 ms·

I have been incredibly impressed with Bun after using it in some smaller projects. Compared to Deno, it feels like a true alternative to Node.js. It’s so nice t

I have been incredibly impressed with Bun after using it in some smaller projects. Compared to Deno, it feels like a true alternative to Node.js. It’s so nice to have a TS-native runtime.

Waterluvian 2y ago
Is it native in any significant way or is it just also transpiling but hiding that step enough to make it feel native? I guess this really hinges on how we define native. I really want a runtime that actually leverages the type hints for JIT optimization.
- mrighele 2y ago
  Bun uses JavaScriptCore (the js engine of Safari) so I doubt they are doing anything fancy with typescript types.
- dgb23 2y ago
  There are certainly cases where type hints could be leveraged. But ultimately the way a JIT like Turbofan works is that it will do better optimizations if your JS code is already monomorphic (functions signatures, object fields and so on). Now TS sort of nudges you that way if you write simple TS code. But due to structural typing, expressive type golf features and the fact that TS is generally unsound I doubt it would be easy to leverage type hints much beyond that. Here are two talks that are very much related and give some insights into how difficult these kinds of problems are: https://thestrangeloop.com/2022/of-javascript-ahead-of-time-compilation-performance.html https://thestrangeloop.com/2022/of-javascript-ahead-of-time-... https://www.thestrangeloop.com/2019/typing-the-untyped-soundness-in-gradual-type-systems.html https://www.thestrangeloop.com/2019/typing-the-untyped-sound...
- wruza 2y ago
  Does it make sense though? What should happen if a type hints a string and there’s a number in a received json? We gonna segfault?
  - Waterluvian 2y ago
    Yeah, exactly. You would need to handle deserialization like all the other strong/static languages. It would be an extra constraint for an extra layer of guarantee and ideally performance.
    - wruza 2y ago
      I see, good point. Although my feeling is that typescript’s idea of a type system living on a separate plane was one of the greatest ideas of all time. Never felt so good about something that is basically js. With strict semantics like Rust/C++/Zig/Go it would be just a weaker clone of those with all the usual strings attached.
      - Waterluvian 2y ago
        Oh I fully agree. The ability to turn the type system off when you’re testing or hacking and want to be quick, or to gradually type a JavaScript project… it’s really the best. But I’ve got projects that are now as “correct” as possible, with full validation at deserialization and such and I just wish a compiler could take things an extra mile.
- mst 2y ago
  Native as in "if you import a .ts file it Just Works" I'm afraid. Roughly it strips the TS type syntax and hands the result off to JavaScriptCore - so it's not 'native' in the sense you might have been hoping for, and perhaps you'd find 'built-in' or 'seamless' or maybe 'out of the box' a better description of what it actually has. (I find the experience of -using- what it actually has to be excellent but 'native' is definitely an overloaded usage here)
Yoric 2y ago
In which way is Bun superior to Deno? Asking as someone who has yet to try either.
- stevage 2y ago
  I use it to run typescript projects. It seems to just work. whereas TSC and tsx and ts-node all seem to complain a lot about configuration and module setup and stuff.
  - vmfunction 2y ago
    The parent is asking about how bun compare to Deno, not node. TSC, tsx, and ts-node are nodejs related. I also would like to know. Deno seems to be mature and ready. It runs .ts files from command line. Of course there is no point of picking one JS runtime over another. I would follow the WinterCG group, and use something that is runtime agonistic like hono. It already has a React like front end built in (jsx-lite type).
    - stevage 2y ago
      My understanding was that Deno has compatibility issues with Node - it can't necessarily run all normal Node code. Whereas Bun definitely can.
      - Pozzuh 2y ago
        I don't think Bun "definitely can" run most Node code. Both Deno[1] and Bun's[2] Node compatibility are incomplete. Bun being perceived as more compatible is mostly clever marketing. [1] https://docs.deno.com/runtime/manual/node/compatibility https://docs.deno.com/runtime/manual/node/compatibility [2] https://bun.sh/docs/runtime/nodejs-apis https://bun.sh/docs/runtime/nodejs-apis
        deleted 2y ago
        [deleted]
        2y ago
prmph 2y ago
I stopped using Bun, because it provides a nice API and just works and all, but it seems to be just a thin wrapper over Node, hiding the messy stuff underneath. I got some problems and it started leaking Node diagnostic messages all over the place. Was not impressed with how easily the facade fell over when I tried to do things just a little bit different from the happy path.
- 698969 2y ago
  I'm guessing this was from a time when they invoking bun on a script was just an alias to run it with node instead, and you had to do a more specific incantation like `bun run index.ts` to actually use the bun runtime. When did you use it?
  - prmph 2y ago
    This is probably what happened; it was like almost 2 years ago. Thanks for the explanation I do think it's a gotcha to run a script with another runtime than the one I launched from the terminal, though. If I launch a script directly with a runtime, I expect it to disregard any shebangs.
- mst 2y ago
  bun is a completely separate piece of code - it uses JavaScriptCore rather than v8, there's no 'wrapper' involved. I strongly suspect that what you saw was from running a script with a #! line that specifies node, because bun honours #! lines by default. If you use <bun run --bun> that will tell it to use bun instead when it sees a node shebang.
  - prmph 2y ago
    This was probably it. Thanks.
- Jarred 2y ago
  Bun does not wrap Node. Bun is a JavaScript runtime and suite of tools separate from Node. We do implement Node APIs and spend an enormous amount of time on compatibility. We have to use the same `code` property on many errors or libraries that rely on it break. It’s also possible you ran a package.json script that had the #!/usr/bin/env node shebang at the top, which Bun by default respects. You can force it to use bun by prefixing the command with “--bun”, like “bun --bun my-executable” What error did you run into?

I have been incredibly impressed with Bun after using it in some smaller projects. Compared to Deno, it feels like a true alternative to Node.js. It’s so nice to have a TS-native runtime.

Waterluvian 2y ago

Is it native in any significant way or is it just also transpiling but hiding that step enough to make it feel native? I guess this really hinges on how we define native. I really want a runtime that actually leverages the type hints for JIT optimization.

mrighele 2y ago
Bun uses JavaScriptCore (the js engine of Safari) so I doubt they are doing anything fancy with typescript types.
dgb23 2y ago
There are certainly cases where type hints could be leveraged. But ultimately the way a JIT like Turbofan works is that it will do better optimizations if your JS code is already monomorphic (functions signatures, object fields and so on). Now TS sort of nudges you that way if you write simple TS code. But due to structural typing, expressive type golf features and the fact that TS is generally unsound I doubt it would be easy to leverage type hints much beyond that. Here are two talks that are very much related and give some insights into how difficult these kinds of problems are: https://thestrangeloop.com/2022/of-javascript-ahead-of-time-compilation-performance.html https://thestrangeloop.com/2022/of-javascript-ahead-of-time-... https://www.thestrangeloop.com/2019/typing-the-untyped-soundness-in-gradual-type-systems.html https://www.thestrangeloop.com/2019/typing-the-untyped-sound...
wruza 2y ago
Does it make sense though? What should happen if a type hints a string and there’s a number in a received json? We gonna segfault?
- Waterluvian 2y ago
  Yeah, exactly. You would need to handle deserialization like all the other strong/static languages. It would be an extra constraint for an extra layer of guarantee and ideally performance.
  - wruza 2y ago
    I see, good point. Although my feeling is that typescript’s idea of a type system living on a separate plane was one of the greatest ideas of all time. Never felt so good about something that is basically js. With strict semantics like Rust/C++/Zig/Go it would be just a weaker clone of those with all the usual strings attached.
    - Waterluvian 2y ago
      Oh I fully agree. The ability to turn the type system off when you’re testing or hacking and want to be quick, or to gradually type a JavaScript project… it’s really the best. But I’ve got projects that are now as “correct” as possible, with full validation at deserialization and such and I just wish a compiler could take things an extra mile.
mst 2y ago
Native as in "if you import a .ts file it Just Works" I'm afraid. Roughly it strips the TS type syntax and hands the result off to JavaScriptCore - so it's not 'native' in the sense you might have been hoping for, and perhaps you'd find 'built-in' or 'seamless' or maybe 'out of the box' a better description of what it actually has. (I find the experience of -using- what it actually has to be excellent but 'native' is definitely an overloaded usage here)

Yoric 2y ago

In which way is Bun superior to Deno? Asking as someone who has yet to try either.

stevage 2y ago
I use it to run typescript projects. It seems to just work. whereas TSC and tsx and ts-node all seem to complain a lot about configuration and module setup and stuff.
- vmfunction 2y ago
  The parent is asking about how bun compare to Deno, not node. TSC, tsx, and ts-node are nodejs related. I also would like to know. Deno seems to be mature and ready. It runs .ts files from command line. Of course there is no point of picking one JS runtime over another. I would follow the WinterCG group, and use something that is runtime agonistic like hono. It already has a React like front end built in (jsx-lite type).
  - stevage 2y ago
    My understanding was that Deno has compatibility issues with Node - it can't necessarily run all normal Node code. Whereas Bun definitely can.
    - Pozzuh 2y ago
      I don't think Bun "definitely can" run most Node code. Both Deno[1] and Bun's[2] Node compatibility are incomplete. Bun being perceived as more compatible is mostly clever marketing. [1] https://docs.deno.com/runtime/manual/node/compatibility https://docs.deno.com/runtime/manual/node/compatibility [2] https://bun.sh/docs/runtime/nodejs-apis https://bun.sh/docs/runtime/nodejs-apis
      - deleted 2y ago
        [deleted]
      - 2y ago

prmph 2y ago

I stopped using Bun, because it provides a nice API and just works and all, but it seems to be just a thin wrapper over Node, hiding the messy stuff underneath. I got some problems and it started leaking Node diagnostic messages all over the place. Was not impressed with how easily the facade fell over when I tried to do things just a little bit different from the happy path.

698969 2y ago
I'm guessing this was from a time when they invoking bun on a script was just an alias to run it with node instead, and you had to do a more specific incantation like `bun run index.ts` to actually use the bun runtime. When did you use it?
- prmph 2y ago
  This is probably what happened; it was like almost 2 years ago. Thanks for the explanation I do think it's a gotcha to run a script with another runtime than the one I launched from the terminal, though. If I launch a script directly with a runtime, I expect it to disregard any shebangs.
mst 2y ago
bun is a completely separate piece of code - it uses JavaScriptCore rather than v8, there's no 'wrapper' involved. I strongly suspect that what you saw was from running a script with a #! line that specifies node, because bun honours #! lines by default. If you use <bun run --bun> that will tell it to use bun instead when it sees a node shebang.
- prmph 2y ago
  This was probably it. Thanks.
Jarred 2y ago
Bun does not wrap Node. Bun is a JavaScript runtime and suite of tools separate from Node. We do implement Node APIs and spend an enormous amount of time on compatibility. We have to use the same `code` property on many errors or libraries that rely on it break. It’s also possible you ran a package.json script that had the #!/usr/bin/env node shebang at the top, which Bun by default respects. You can force it to use bun by prefixing the command with “--bun”, like “bun --bun my-executable” What error did you run into?