13 ms·

Bun 1.1

462 points by ksec 3y ago

brap 3y ago
On one hand I like the work Bun is doing, on the other hand the Bun module is starting to look like a messy "utils" module, aka random junk drawer. All of them useful of course, just... incoherent.
Jarred 3y ago
I work on Bun and happy to answer any questions. Note that Bun v1.1 is still compiling at the time of writing (probably for another 20 minutes)
- eddd-ddde 3y ago
  Are there plans for adding concurrent or parallel execution to the test runner? I recently tried looking at the code base to maybe implement it myself, and it looks like it wouldn't be easy without some reworks.
  - Jarred 3y ago
    We need to do some form of this but I’m not exactly sure what yet. I suspect same process but multiple globals might work well. A lot of tests spend time sleeping or waiting for things. They might benefit from that kind of paralellism (like async/await, except between things it runs a whole other global object) Threads could also work but the problem is you have to re parse & evaluate all the code. That’s a lot of duplicate work. It’s probably still worth it for large enough apps
    - eddd-ddde 3y ago
      Isn't there some way of cloning a loaded vm after loading a module? I would imagine that should be possible some how, that way you could parse once then execute in multiple threads.
- theThree 3y ago
  When will `worker` API be ready for production?
- toastal 3y ago
  Now that Discord will start showing ads, is there any chance Bun will support a communication platform that is open & ad-free like IRC, XMPP, or Matrix?
  - dcgudeman 3y ago
    What kind of question is this? He is working on a JavaScript/TypeScript runtime not building a communication product. Why would you run to him to solve your pet grievance with Discord?
    - tbeseda 3y ago
      I imagine the complaint is around Bun's use of Discord as community coordination tooling -- linked in the site's header. The post isn't implying Bun should be involved in the creation of an alternative. (I'm not here to throw shade at using Discord for OSS "communities" - I do as well - And am concerned about the path forward. Just want to clarify the question's intent.)
    - mdeeks 3y ago
      I'm assuming it is because Bun uses Discord? There are Discord links on their site and on Github, though the links don't seem to work.
    - toastal 3y ago
      If open source, free software is a good enough ethos for your code base, it should be good enough for your community communications. Supporting only a proprietary locks out a swath of users & Discord in particular is an information blackhole—and now with ads!
      - fastball 3y ago
        Which users are unable to use Discord? Note that unable is different from unwilling, and "locked out" is not an accurate description of the latter.
        3y ago
- fofolo 3y ago
  GG for Windows support and all the addition in 1.1 :) Thxx
- gr4vityWall 3y ago
  Is there a privacy policy available for the telemetry collected by default by Bun?
  - throwitaway1123 3y ago
    The opt-out telemetry is worrisome. Along with the fact that there doesn't appear to be a way to disable it for single-file executables if you plan to distribute a Bun cli app to users: https://github.com/oven-sh/bun/issues/8927 https://github.com/oven-sh/bun/issues/8927
    - whstl 3y ago
      According to this, it seems they don't actually send the telemetry: https://news.ycombinator.com/item?id=39901755 https://news.ycombinator.com/item?id=39901755 Hope my interpretation is correct.
      - throwitaway1123 3y ago
        Yeah I saw a Github discussion where he mentioned that the code for uploading telemetry data was disabled, but he also said he plans to re-enable that at some point: https://github.com/oven-sh/bun/discussions/2605#discussioncomment-5602971 https://github.com/oven-sh/bun/discussions/2605#discussionco... I would prefer to have the telemetry become opt-in before data collection is turned on.
        whstl 3y ago
        Completely agree.
- txdv 3y ago
  love it, even `bun upgrade` is fast: On my rpi 4 that I capped to 600mhz for performance testing: Bun v1.1.0 is out! You're on 1.0.36 [3.93s] Upgraded.
- cheema33 3y ago
  > I work on Bun and happy to answer any questions. I think I saw somewhere that 1.0 did not support NextJS. Does 1.1?
  - cheema33 3y ago
    I think I answered my own question. According to https://bun.sh/guides/ecosystem/nextjs https://bun.sh/guides/ecosystem/nextjs Bun does not yet support NextJS.
- yolm 3y ago
  Not a question, but wanted to say: Great job!
- rcarmo 3y ago
  When are we getting UDP/dgram support?
- WuxiFingerHold 3y ago
  Yours and the team's performance is so impressive. I'm not brave enough to use Bun in production yet, but count me in in a year or so ... great stuff.
deleted 3y ago
[deleted]
captn3m0 3y ago
Request for the bun team: please provide a clear support policy/EOL timeline. Bonus points for clarity on the stability guarantees that are offered between versions and modules. https://github.com/oven-sh/bun/issues/7990 https://github.com/oven-sh/bun/issues/7990 (Via https://github.com/endoflife-date/endoflife.date/pull/4382 https://github.com/endoflife-date/endoflife.date/pull/4382)
- TheChaplain 3y ago
  Yeah something like this; https://nodejs.org/en/about/previous-releases#release-schedule https://nodejs.org/en/about/previous-releases#release-schedu... or: https://devguide.python.org/versions/ https://devguide.python.org/versions/
  - tempaccount420 3y ago
    No LTS versions please. Release often, but don't break old code. Be more like Rust (v1 forever) than like Node (new major releases every year or so).
    - hnben 3y ago
      > Release often, but don't break old code That may become expensive fast
      - tubthumper8 3y ago
        As far as I'm aware, Rust has been doing this for 9 years now (77 new versions), I'm not sure if that's been "expensive" but people seem to like it and it's working well so far
- fastball 3y ago
  I don't think the bun devs are currently parcelling things up like that so doubt this would be worth the effort at this time, i.e. I don't think they're backporting any fixes from 1.1 into a 1.0.x release.
deleted 3y ago
[deleted]
gr4vityWall 3y ago
Seems like a good release. I watched their video, and some charts were a bit unclear, as in, I didn't know if they were comparing with the previous Bun version or Node.js. My experience with using Bun in side projects has been good. The built-in APIs work well in my experience, and I hope popular runtimes adopt at least a subset of them. The hashing and the SQLite bindings come to mind as APIs that I wish were available in Deno and Node.js as well. They collect some telemetry by default. I don't think the install script tells you that. The only mention of it that I've found is in the Bunfile documentation: https://bun.sh/docs/runtime/bunfig#telemetry https://bun.sh/docs/runtime/bunfig#telemetry I'd prefer if it was opt-in, and that users were given instructions for disabling it if they want to during installation. They offer an option to create a dependency-free executable for your project, which bundles the runtime with your .js entrypoint. That works great if you want a single binary to distribute to users, but at the moment, the file size is still pretty big (above 90MB on GNU/Linux for a small project). Not terrible, but nothing comparable to Go or QuickJS yet. I wonder if in the future, Bun would offer an option to compile itself with certain features disabled, so we'd get a smaller binary. I have been playing with using Bun as a Haxe target. It works pretty well and IMO it's a choice to consider if you like Haxe more than TypeScript, or if you want to add a web server to an existing Haxe project without adding another programming language. You can also to do things like generating validation code at compile time, which seems hard to do with just TypeScript.
- moritzwarhier 3y ago
  > I'd prefer if it was opt-in, and that users were given instructions for disabling it if they want to during installation. So you mean an informed opt-out, right? Thank you for the interesting hands-on experiences and insights regarding Bun. I followed the coverage and posts by Jarred here on HN for quite a while, think since the initial alpha release, but haven't used it. Will keep your examples for helpful added platform APIs in mind for when I hopefully come around to doing sth with Bun! It sounds like a great platform for JS scripting as well - I also think that could be a good and easy way to test the waters. Really, kudos to Bun and Jarred Sumner for living up to the promise he made when the first version was announced!
  - 3y ago
pritambarhate 3y ago
What's the revenue model for Bun? What happens when the VC funding runs out?
- marviel 3y ago
  I'm not sure why this is being downvoted -- it feels like a valid question for anything that enjoys wide adoption.
  - fastball 3y ago
    It's a valid question, but does it matter for anyone except the dev team? Bun is open source, so VC-backing is mostly a helpful jumpstart. If they find a viable business model – great, development can be funded in perpetuity. If they don't, development was funded for a while by someone else's money and then Bun is just like any other open source project that lacks direct funding (most of them).
    - marviel 3y ago
      I suppose you're right -- the MIT model makes it a non-issue
    - toastercat 3y ago
      I think it does matter. Open-source software can still suffer from "enshittification" when there is constant need to generate profit. Fortunately it is open source, so it can be forked when things get bad, but even then there still may be lots of tech debt to undo.
      - erhaetherth 3y ago
        Right...but if you're going to fork it and create fragmentation, then we might as well go back to Node which has at least been stable for the past few years.
- eddd-ddde 3y ago
  I imagine some hosted service like everyone does is a likely option.
tjenkinsqs 3y ago
We've been using bun for a while now. We love the speed, but we love the integration even more. No need to use node, npm, nodemon, tsx, esbuild and jest. Bun is our one-stop-shop for Typescript. Thank you!
- fastball 3y ago
  Can I ask what you use it for specifically?
  - ivanjermakov 3y ago
    I use Bun as a test and dev build runner for TS programs. I still compile with tsc though.
  - tjenkinsqs 3y ago
    Bun is used in github.com/yolmio/boost as a Typescript runner to build a complete system. We use it also for all kinds of other scripts.
modeless 3y ago
Hooray for Windows support! That was keeping me from using Bun since I'm on Windows a fair bit. My experience with Bun has been excellent so far and I'm looking forward to using it more.
pier25 3y ago
Is Bun executing TS or is it also compiling down to JS and executing that? Edit: The docs mention: > Because Bun can directly execute TypeScript, you may not need to transpile your TypeScript to run in production. Bun internally transpiles every file it executes (both .js and .ts), so the additional overhead of directly executing your .ts/.tsx source files is negligible. https://bun.sh/docs/runtime/typescript https://bun.sh/docs/runtime/typescript The idea I'm getting from this is that both JS and TS are transpiled to something else. Are types preserved in this bytecode, AST, or whatever it is?
- emmanueloga_ 3y ago
  "TypeScript & JSX support. You can directly execute .jsx, .ts, and .tsx files; Bun's transpiler converts these to vanilla JavaScript before execution." -- https://bun.sh/docs#design-goals https://bun.sh/docs#design-goals
- Kognito 3y ago
  It’s not running TS directly, it’s just preconfigured to transpile TS to JS without the user having to bring extra tooling. Neat, but you’ll see the docs still recommend tsc for type checking at build.
  - galaxyLogic 3y ago
    I wonder what's the benefit of TS if there's no type-checking? If types are not checked that means the TS type-declarations could be totally wrong and nobody would know. In other words they could be misleading. Why incur the type-declaration overhead if they are not used after all?
    - pfg_ 3y ago
      This is how typescript is run today. Typescript types never exist at runtime regardless of how typescript is run. There is no overhead defining types because they are deleted at runtime. The purpose of typescript is to make the editor experience better (autocomplete, error highlight). Typically typechecking is run in addition to tests to make sure there aren't a bunch of errors no one saw in editor.
afavour 3y ago
I feel like such a downer when I ask this about Bun and Deno, but: why should I use them instead of Node? I don’t mean to take away from the obviously impressive engineering effort here. But VC funding always gives me pause because I don’t know how long the product is going to be around. I was actually more interested in Deno when it promised a reboot of the JS ecosystem but both Bun and Deno seem to have discovered that Node interoperability is a requirement so they’re all in the same (kinda crappy) ecosystem. I’m just not sure what the selling point is that makes it worth the risk.
- solumunus 3y ago
  I don't know how you're using Node and not thinking "I wish there was a better option than this". I can't wait to jump ship but Bun/Deno aren't quite there yet, for my needs.
  - eddd-ddde 3y ago
    Curious what you are missing to make the jump.
- vbezhenar 3y ago
  Node is safe choice, IMO. I tried deno and I think it's cool, but I'm staying on node for the time being. Things that deno makes easier are not that hard with node and stability matters for me. For example I had to spend few hours rewriting my tiny service with changed deno API. Don't have any experience with bun, though.
  - mmastrac 3y ago
    If there are any specific places where Deno didn't support a node API, please file a bug -- we definitely shoot for as close to node.js as possible, and if you have to modify your code that's most often on us. (I'm a deno core dev)
    - vbezhenar 3y ago
      No, I wrote my service some time ago (basically GitHub Webhook which does some crypto to validate payload and invokes kubectl) using Deno API and few months ago I took some time to update dependencies but found out that with new standard library version some APIs are either deprecated or removed, I don't really remember, but I felt the need to rewrite it. Don't take it as a criticism, I totally understand that you need to iterate on API and nobody promised me that it'd be stable till the end of time, but still work is work.
blackhaj7 3y ago
Bun churning out the good stuff, yet again. So often I read the release notes and think “what a great idea, why wasn’t this already a thing” e.g. syntax highlighted errors
peter_d_sherman 3y ago
[dead]
preommr 3y ago
Huge fan of Bun. Came for the ts interoperability, stayed for the performance. Also seems like the most sensible project in the space - I tried Deno and it was... rough. Bun on the otherhand was easy to intergrate and a very pleasant experience.
- woutr_be 3y ago
  I started using Bun by default for small personal projects. Having to set up Node, with Typescript and reloads always took the fun out of quickly prototyping something. Have yet to run Bun in production tho.
earslap 3y ago
Did not realize Bun had (even if rudimentary) macros - bundle time executing code support. That is pretty neat! https://bun.sh/docs/bundler/macros https://bun.sh/docs/bundler/macros
- Waterluvian 3y ago
  Wow that’s pretty neat. Because of that I also learned about import attributes (https://github.com/tc39/proposal-import-attributes https://github.com/tc39/proposal-import-attributes) which is probably going to be quite useful and make the 50 lines of imports in some of my files look even dumber.
  - Valodim 3y ago
    Some loaders already encode stuff in the path url style, e.g. vite-svg-loader import iconUrl from './my-icon.svg?url' Maybe I'm not imaginative enough but this seems like a reasonably restricted (i.e. simple) way of parametrizing imports.
    - erhaetherth 3y ago
      That's what I've been waiting for too. The URL params always seemed rather sketch to me. No bundlers seem to be using it that way though.
- agos 3y ago
  this is one of the most interesting new things in the bundler space - Parcel is introducing some form of macro too. It's way overdue to have some way to program what happens at bundling time (without writing your own bundler plugin)
- FlorianRappl 3y ago
  Yes its neat - I wish more bundlers adopt it! In the past I've written a little plugin that is available for almost all bundlers allowing you to do that: https://dev.to/florianrappl/getting-bundling-superpowers-using-codegen-2no8 https://dev.to/florianrappl/getting-bundling-superpowers-usi...
ericyd 3y ago
Not sure I see the benefit of the bun shell. I use shell scripts when I know that the other people using the script will be able to run it in a similar shell to me, in order to cut down on dependencies. If I need it to be cross platform I just use a scripting language like JS. Bun shell keeps the more esoteric syntax of Unix-like shells but also requires a dependency (Bun itself). If you already have Bun installed why wouldn't you just write a JS script?
- zamadatix 3y ago
  I can definitely see the value of not wanting to write the boilerplate kind of stuff you need to do for more shell like scripting. I can also see wanting to emulate the traditional syntax while abstracting away whether you are on a Unix system and still allowing traditional JavaScript syntax in between the sheep-y parts. On the dependency side it'd be slick if you could bun --compile these like normal bun apps.
- pfg_ 3y ago
  It's realy nice when I need to do shell stuff - much nicer to be able to use js to write a shell script than either go look up shell syntax again or use js with child_process.spawn()
- CuriouslyC 3y ago
  I mandate WSL when working with windows developers, and GNU coreutils for mac developers so that I can assume some things about their dev environments. This solves that problem for shell scripts, there are still other ways where it's useful but a scripting environment is probably the biggest one. The velocity of writing filesystem and file manipulation files in shell is many times greater than in javascript. Bun shell lets you leverage the power of shell for that stuff while being able to leverage your javascript code at the same time, with fairly minor downsides in exchange.
  - ericyd 3y ago
    > The velocity of writing filesystem and file manipulation files in shell is many times greater than in javascript. I think you're right, after achieving a level of expertise. I've never gotten there myself which probably explains my bias, but I appreciate hearing your perspective.
MarkSweep 3y ago
I was quite curious about the .bunx file format. I think this could be a quite a useful thing, a universal binary format. Then I see the shim DLL: https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c3afdd53b437770e1/src/install/windows-shim/bun_shim_impl.exe https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c... Even before this past week's XZ backdoor revelation, checking binaries into source control rather than building from source seems quite questionable. In fairness to the Bun developer's, they have a comment in their build.zig file acknowledging that this shim should be built more normally rather than being checked in. Then I look into the source for it: https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c3afdd53b437770e1/src/install/windows-shim/bun_shim_impl.zig https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c... For no discernible reason, it is using a bunch of undocumented Windows APIs. The source cites this Zig issue as one reason for why they think it is OK to use undocumented APIs: https://github.com/ziglang/zig/issues/1840 https://github.com/ziglang/zig/issues/1840 I don't see any good reasons here cited for using undocumented, unstable interfaces. For Zig's part, there seems to be some poorly-explained interest in linking against "lower level" libraries without any motivating use case (just some hand waving about security and drivers, neither of which makes much sense. Onecore.lib is a thing if you wanted a documented way of linking an executable that run on a diverse set of Windows form factors. And compiling drivers may as well be treated as a seperate target, since function names are different). For Bun, I assume they are trying to have low binary size. But targeting NTDLL vs. Kernel32 should not make a big difference, especially when the shim is just doing basic file IO. For an example of making small executable with standard API, you can make hello world 4kb using MSVC just by using /NODEFAULTLIB and /ENTRY:main with link.exe and this program : #include <Windows.h> #define MY_MSG "Hello World!\n" int main() { WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), MY_MSG, sizeof(MY_MSG), nullptr, nullptr); return 0; } So it should be possible to make a .bunx shim of small size without having to resort to undocumented API. (Current exe is 12kb). But even if the shim exe was 100kb, that would be still be an acceptable tradeoff for me than having to debug any problem that results from using non-standard APIs.
- nektro 3y ago
  the motivation behind zig#1840 is that while the functions in ntdll aren't as well documented as the kernel32 functions, theyre not unstable and not having our binaries depend on kernel32.dll would lead to faster startup times as well as allow us to do things like use more performant algorithms for UTF-8 <-> UTF-16 conversion. on top of the things mentioned in the issue like having APIs with more powerful features.
galaxyLogic 3y ago
Looks like a great development. One thing I miss in Node.js is ability to run a HTTPS -server in a simple way without having to muddle with generating & installing a correct type of certificate. I understand there can be a "self-signed certificate" but there doesn't seem to be any npm-module I could install to take care of that. Since Bun is a "server-side" JavaScript platform it would be great if it could support https out of the box too.
- Aspos 3y ago
  Curious how do you actually see this working. Care to elaborate?
- pests 3y ago
  caddy supports self signed certs by default https://caddyserver.com/docs/automatic-https https://caddyserver.com/docs/automatic-https
  - francislavoie 3y ago
    More precisely, it runs its own local CA to issue certs for itself. Not exactly the same as self-signed certs (which is a cert whose key was used to sign itself), but better because leaf certs are short-lived and easily cycled. This allows for setting up trust easily, just need to trust the one root CA cert and every leaf cert for any domain served will be trusted.
  - galaxyLogic 3y ago
    Does it work with Node.js or Bun or Deno?
    - pests 3y ago
      You can proxy to internal services with a few lines of config.... :2080 reverse_proxy :9000 Then access https://localhost:2080 https://localhost:2080 and you'll be accessing whatever is on port 9000, be it node or bun or anything else. https://caddyserver.com/docs/quick-starts/reverse-proxy https://caddyserver.com/docs/quick-starts/reverse-proxy
fleetfox 3y ago
Faster this, faster that. Is it finally segfault free? I've tried it like 3 times in span of last year with different projects only to find out it segfaults at runtime or when installing package.
- QuinnyPig 3y ago
  But look how quickly it segfaults!
- dimgl 3y ago
  Same. Tons of tooling breaks and segfaults. Our codebase has a dylib unknown symbol error that hasn't been fixed since before v1.
- CuriouslyC 3y ago
  I only use bun for tests/builds/storybook, but I haven't had it segfault at all. I suspect that you've got a dependency that is hitting an undocumented node API that isn't fully implemented. They talk about those in the blog post, they're a known thing.
yoavm 3y ago
I just tried using Bun to run one of our more complex projects. Did the same with Deno a week ago and too many things weren't working. with Bun everything loaded perfectly, and I could immediately drop ts-node and nodemon because they're essentially redundant when using Bun. great stuff!
bluelightning2k 3y ago
This guy ships!
dgellow 3y ago
Really impressive list of changes. Bun sounds like the dream node alternative, I hope they succeed in their mission. And I’m glad they spent time on Windows support, that’s something neglected in the web development world
- madsbuch 3y ago
  I am curios, why do you think they did not succeed yet?
  - WuxiFingerHold 3y ago
    There's been some polls on social media: Overall picture was 80-90% using Node. Then Bun, then Deno. I'd bet in the real world it's 99% Node for production. If in 3 years 5% were using Bun, it would be a great success (Node usage is huge). I think they're on track, but would not recommend Bun for production backends as of now.
  - dgellow 3y ago
    From their website: > The goal of Bun is to run most of the world's server-side JavaScript and provide tools to improve performance, reduce complexity, and multiply developer productivity. Bun is still pretty young and experimental, and not really production ready, though it’s getting there fast. If it grows enough to force node to improve, or if it takes over node, that would be a success based on their own goal
- deleted 3y ago
  [deleted]
liampulles 3y ago
"...Bun on Windows passes 98% of our own test suite for Bun on macOS and Linux." Does this mean the release was made with failing tests, or am I misunderstanding?
- vallode 3y ago
  Looks like it, it seems the 2% are mostly odd platform specific issues that the authors' did not deem very important (my assumption for the release happening anyway). AFAIK this[1] PR tries to fix them. [1]: https://github.com/oven-sh/bun/pull/9729 https://github.com/oven-sh/bun/pull/9729
- basil-rash 3y ago
  Skipping particular tests depending on platform is a very common practice, for better or worse.
  - CaptainOfCoit 3y ago
    That's not what's happening. Bun has tests that are supposed to work on the platform, but currently doesn't. Skipping tests from a Linux suite that doesn't make sense to run on Windows is very common. Skipping tests that should pass on a platform but doesn't just in order to cut a release isn't as common.
    - basil-rash 3y ago
      Every growing project has things thing the maintainers would like to work but that do not currently. The job of the maintainer is to balance the value of releasing a cut of the software as stands and learning about other unknown issues while continuing to work on the known, or to work on the known and ignore the unknown until finished with the known. Neither way is strictly good or bad.
- sharas- 3y ago
  [flagged]
madsbuch 3y ago
I use both Deno and Bun in production (albeit, on different projects). They are both great upgrades from node. In particular with the first class support for TypeScript. Bun is great for large projects with the enhanced DX over any node based environments I have worked on - I use it for a mono-repo project with several frontends and a GraphQl backend. Involved test suites run in 5 seconds, etc. Deno seems to work really well i lambda style environment (I use them with Supabase) due to their module approach that are entirely stand alone. This is great for small scripts to glue things together.
- erhaetherth 3y ago
  Bun has -i/--install=fallback which I thought was pretty similar to Deno but I haven't used Deno much to compare. I was thinking about starting to write my scripts with `#!bun -i` but haven't fiddled with it much yet.
rcarmo 3y ago
Still can’t use it without dgram support. But it’s nice to see it adding batteries.
thatguyagain 3y ago
I find it hilarious that we now present runtimes and other programming stuff like it was Apple presenting a new iPhone. This would be satire 15 years ago. No disrespect to Bun tho, I love Bun.
- yurishimo 3y ago
  I feel like it’s meant to be satire here as well.
  - erhaetherth 3y ago
    If it is... they're doing a really good job staying composed, because I couldn't tell. It would be amusing if true.
- madsbuch 3y ago
  The audience for these types of announcement is bigger. My intuition is that there are many more consumers of node-like environments today than any runtimes 15 years ago.
- CuriouslyC 3y ago
  That's because there's so much cacophony emanating from internet that you have to shout to be heard today.
- daredoes 3y ago
  I find these articles useful when migrating a legacy system, as they sometimes contain migration notes or rare minor details from the developers. This combined with the Wayback machine makes for a great way to keep track of detailed information
WuxiFingerHold 3y ago
The energy and velocity behind Bun is mind blowing.
gregoriol 3y ago
Is it me or does this project tries to do too many things at once? "Bun is an npm-compatible package manager", and an http server, and a websocket server, and a test library, and a bundler, and... why?
- dimitrisnl 3y ago
  That's the selling point
  - gregoriol 3y ago
    That's the scary point
    - norman784 3y ago
      I like their selling point and if there is enough demand, I think the node community will implement at least a few of those features.
    - dimitrisnl 3y ago
      Migrating bundlers and changing test-runners is no fun. If bun can handle that with consistent performance and no goofy upgrade paths, I'm happy.
- dgellow 3y ago
  Because that’s what people want. That’s how you can get a really good developer experience similar to golang or other languages. Just install one tool to build, lint, format, run tests, run your local project. No time spent trying to setup a bundler when what you want is to build a new project. Regarding runtime libraries, it’s similar to the battery-included approach of go or python, you get what you need to get started out of the box and only reach for dependencies when you want to go further. Testing library, an http server, a websocket server that’s perfectly reasonable to have as core library of a runtime developed to run web servers.
- deleted 3y ago
  [deleted]
misiek08 3y ago
So able to optimize node.js and be $x times faster, but not able to calculate percentage of speedup correctly? 1.3s vs 2s it's not 58% speedup - it's 35%... Such approach makes those projects looks like unicorns, not production stuff - even they are.
- anonymoushn 3y ago
  Using the numbers given, it's a 53% speedup.
- dgellow 3y ago
  You can communicate the same without the snarky tone
sharas- 3y ago
Bun is run by a little prince
- __jonas 3y ago
  could you elaborate?
ptx 3y ago
The API for the shell function is kind of neat, in that it seems to prevent you from accidentally creating shell injection vulnerabilities by calling it without properly quoting the arguments. For example, in Python you could easily do this: message = '; cat /etc/passwd' # Whoops, shell injection vulnerability! subprocess.run(f'echo Message: {message}', shell=True) # Correct (assuming sh-compatible shell). subprocess.run(f'echo Message: {shlex.quote(message)}', shell=True) # Correct (without using shell). subprocess.run(['/bin/echo', 'Message:', message]) But the Bun API doesn't separate quoting from executing the command, so you can't make that kind of mistake: let message = '; cat /etc/passwd'; // Works correctly. await $`echo Message: ${message}`.text(); // Fails safely by throwing error about incorrect usage. await $('echo Message: ' + message).text();
- thingification 3y ago
  It uses types to get quoting right? Or it quotes everything (regardless if it's already quoted)? Ironically, the first time I saw the former was in a Python templating library (in the early 2000s -- from distant memory I think it might have been the work of the MemsExchange team?)
  - eddd-ddde 3y ago
    Formatters basically differentiate the literal parts of the string and the template arguments. There's also a neat postgres library that does the same for sql quoting.
- erhaetherth 3y ago
  It is very cool, but not new. zx does that too. And I did the same thing for MySQL years ago.
  - ptx 3y ago
    Tagged templates[0], the language feature that enables this, were introduced in ECMAScript 2015 apparently – arguably at least somewhat new in the lifespan of JavaScript. :) Java is getting a similar feature with template processors[1], currently in preview. It would be nice to have it in Python as well – i.e. not just f-strings, but something that (like tagged templates) allows a template function process the interpolated values to properly encode them for whatever language is appropriate (e.g. shell, SQL, HTML, etc.). Apparently someone is working on a proposal[2], although there doesn't seem to be much recent progress. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1] https://openjdk.org/jeps/459 https://openjdk.org/jeps/459 [2] https://github.com/jimbaker/tagstr/blob/main/docs/pep.rst https://github.com/jimbaker/tagstr/blob/main/docs/pep.rst
atonse 3y ago
I admire your video production values :) Nice job there, One thing is, what gear do you guys use? The audio was really good for what was probably a shotgun mic? Can you tell I don't use bun yet? Because none of my questions are about the release. But I tried it out a few weeks ago on my NextJS project and it didn't work, but will try bun 1.1.
CuriouslyC 3y ago
Lots of good changes here, Bun shell + windows support solves a real problem. Is `remix run dev` fully working now with the additional node API support?
MrResearcher 3y ago
Are there any measurements or statistics how many times a particular npm package was downloaded for usage in Node.js vs Bun vs Deno? E.g. I see 9m downloads for vite: https://www.npmjs.com/package/vite https://www.npmjs.com/package/vite What proportion of that is currently for Bun?
XCSme 3y ago
Could I use this with Parcel.js for my local development of a React app? Or Bun also replaces ParcelJS?
ojosilva 3y ago
One of my favorites: Bun has a working FFI that is also fast. https://bun.sh/docs/api/ffi https://bun.sh/docs/api/ffi So has Deno, but Bun's feel more evolved as it comes bundled with tools and sufficient examples for working with pointers. The only thing Bun is missing right now is the Deno equivalent of non-blocking FFI calls, ie `await mylib.myFunc()`. Another one on my wishlist for Bun: embedded Bun. A library distribution would be nice, so that we can call into Bun as ie "libbun.so" from other languages. It would be more resourceful than just embedding WebKit/SpiderMonkey/v8 as these lack any real capabilities besides running vanilla JS.
meekaaku 3y ago
What's he hosting story for Bun? Is any major platforms offering bun hosting?

462 points by ksec 3y ago

brap 3y ago

On one hand I like the work Bun is doing, on the other hand the Bun module is starting to look like a messy "utils" module, aka random junk drawer. All of them useful of course, just... incoherent.

Jarred 3y ago

I work on Bun and happy to answer any questions. Note that Bun v1.1 is still compiling at the time of writing (probably for another 20 minutes)

eddd-ddde 3y ago
Are there plans for adding concurrent or parallel execution to the test runner? I recently tried looking at the code base to maybe implement it myself, and it looks like it wouldn't be easy without some reworks.
- Jarred 3y ago
  We need to do some form of this but I’m not exactly sure what yet. I suspect same process but multiple globals might work well. A lot of tests spend time sleeping or waiting for things. They might benefit from that kind of paralellism (like async/await, except between things it runs a whole other global object) Threads could also work but the problem is you have to re parse & evaluate all the code. That’s a lot of duplicate work. It’s probably still worth it for large enough apps
  - eddd-ddde 3y ago
    Isn't there some way of cloning a loaded vm after loading a module? I would imagine that should be possible some how, that way you could parse once then execute in multiple threads.
theThree 3y ago
When will `worker` API be ready for production?
toastal 3y ago
Now that Discord will start showing ads, is there any chance Bun will support a communication platform that is open & ad-free like IRC, XMPP, or Matrix?
- dcgudeman 3y ago
  What kind of question is this? He is working on a JavaScript/TypeScript runtime not building a communication product. Why would you run to him to solve your pet grievance with Discord?
  - tbeseda 3y ago
    I imagine the complaint is around Bun's use of Discord as community coordination tooling -- linked in the site's header. The post isn't implying Bun should be involved in the creation of an alternative. (I'm not here to throw shade at using Discord for OSS "communities" - I do as well - And am concerned about the path forward. Just want to clarify the question's intent.)
  - mdeeks 3y ago
    I'm assuming it is because Bun uses Discord? There are Discord links on their site and on Github, though the links don't seem to work.
  - toastal 3y ago
    If open source, free software is a good enough ethos for your code base, it should be good enough for your community communications. Supporting only a proprietary locks out a swath of users & Discord in particular is an information blackhole—and now with ads!
    - fastball 3y ago
      Which users are unable to use Discord? Note that unable is different from unwilling, and "locked out" is not an accurate description of the latter.
      - 3y ago
fofolo 3y ago
GG for Windows support and all the addition in 1.1 :) Thxx
gr4vityWall 3y ago
Is there a privacy policy available for the telemetry collected by default by Bun?
- throwitaway1123 3y ago
  The opt-out telemetry is worrisome. Along with the fact that there doesn't appear to be a way to disable it for single-file executables if you plan to distribute a Bun cli app to users: https://github.com/oven-sh/bun/issues/8927 https://github.com/oven-sh/bun/issues/8927
  - whstl 3y ago
    According to this, it seems they don't actually send the telemetry: https://news.ycombinator.com/item?id=39901755 https://news.ycombinator.com/item?id=39901755 Hope my interpretation is correct.
    - throwitaway1123 3y ago
      Yeah I saw a Github discussion where he mentioned that the code for uploading telemetry data was disabled, but he also said he plans to re-enable that at some point: https://github.com/oven-sh/bun/discussions/2605#discussioncomment-5602971 https://github.com/oven-sh/bun/discussions/2605#discussionco... I would prefer to have the telemetry become opt-in before data collection is turned on.
      - whstl 3y ago
        Completely agree.
txdv 3y ago
love it, even `bun upgrade` is fast: On my rpi 4 that I capped to 600mhz for performance testing: Bun v1.1.0 is out! You're on 1.0.36 [3.93s] Upgraded.
cheema33 3y ago
> I work on Bun and happy to answer any questions. I think I saw somewhere that 1.0 did not support NextJS. Does 1.1?
- cheema33 3y ago
  I think I answered my own question. According to https://bun.sh/guides/ecosystem/nextjs https://bun.sh/guides/ecosystem/nextjs Bun does not yet support NextJS.
yolm 3y ago
Not a question, but wanted to say: Great job!
rcarmo 3y ago
When are we getting UDP/dgram support?
WuxiFingerHold 3y ago
Yours and the team's performance is so impressive. I'm not brave enough to use Bun in production yet, but count me in in a year or so ... great stuff.

deleted 3y ago

[deleted]

captn3m0 3y ago

Request for the bun team: please provide a clear support policy/EOL timeline. Bonus points for clarity on the stability guarantees that are offered between versions and modules. https://github.com/oven-sh/bun/issues/7990 https://github.com/oven-sh/bun/issues/7990 (Via https://github.com/endoflife-date/endoflife.date/pull/4382 https://github.com/endoflife-date/endoflife.date/pull/4382)

TheChaplain 3y ago
Yeah something like this; https://nodejs.org/en/about/previous-releases#release-schedule https://nodejs.org/en/about/previous-releases#release-schedu... or: https://devguide.python.org/versions/ https://devguide.python.org/versions/
- tempaccount420 3y ago
  No LTS versions please. Release often, but don't break old code. Be more like Rust (v1 forever) than like Node (new major releases every year or so).
  - hnben 3y ago
    > Release often, but don't break old code That may become expensive fast
    - tubthumper8 3y ago
      As far as I'm aware, Rust has been doing this for 9 years now (77 new versions), I'm not sure if that's been "expensive" but people seem to like it and it's working well so far
fastball 3y ago
I don't think the bun devs are currently parcelling things up like that so doubt this would be worth the effort at this time, i.e. I don't think they're backporting any fixes from 1.1 into a 1.0.x release.

deleted 3y ago

[deleted]

gr4vityWall 3y ago

Seems like a good release. I watched their video, and some charts were a bit unclear, as in, I didn't know if they were comparing with the previous Bun version or Node.js. My experience with using Bun in side projects has been good. The built-in APIs work well in my experience, and I hope popular runtimes adopt at least a subset of them. The hashing and the SQLite bindings come to mind as APIs that I wish were available in Deno and Node.js as well. They collect some telemetry by default. I don't think the install script tells you that. The only mention of it that I've found is in the Bunfile documentation: https://bun.sh/docs/runtime/bunfig#telemetry https://bun.sh/docs/runtime/bunfig#telemetry I'd prefer if it was opt-in, and that users were given instructions for disabling it if they want to during installation. They offer an option to create a dependency-free executable for your project, which bundles the runtime with your .js entrypoint. That works great if you want a single binary to distribute to users, but at the moment, the file size is still pretty big (above 90MB on GNU/Linux for a small project). Not terrible, but nothing comparable to Go or QuickJS yet. I wonder if in the future, Bun would offer an option to compile itself with certain features disabled, so we'd get a smaller binary. I have been playing with using Bun as a Haxe target. It works pretty well and IMO it's a choice to consider if you like Haxe more than TypeScript, or if you want to add a web server to an existing Haxe project without adding another programming language. You can also to do things like generating validation code at compile time, which seems hard to do with just TypeScript.

moritzwarhier 3y ago
> I'd prefer if it was opt-in, and that users were given instructions for disabling it if they want to during installation. So you mean an informed opt-out, right? Thank you for the interesting hands-on experiences and insights regarding Bun. I followed the coverage and posts by Jarred here on HN for quite a while, think since the initial alpha release, but haven't used it. Will keep your examples for helpful added platform APIs in mind for when I hopefully come around to doing sth with Bun! It sounds like a great platform for JS scripting as well - I also think that could be a good and easy way to test the waters. Really, kudos to Bun and Jarred Sumner for living up to the promise he made when the first version was announced!
- 3y ago

pritambarhate 3y ago

What's the revenue model for Bun? What happens when the VC funding runs out?

marviel 3y ago
I'm not sure why this is being downvoted -- it feels like a valid question for anything that enjoys wide adoption.
- fastball 3y ago
  It's a valid question, but does it matter for anyone except the dev team? Bun is open source, so VC-backing is mostly a helpful jumpstart. If they find a viable business model – great, development can be funded in perpetuity. If they don't, development was funded for a while by someone else's money and then Bun is just like any other open source project that lacks direct funding (most of them).
  - marviel 3y ago
    I suppose you're right -- the MIT model makes it a non-issue
  - toastercat 3y ago
    I think it does matter. Open-source software can still suffer from "enshittification" when there is constant need to generate profit. Fortunately it is open source, so it can be forked when things get bad, but even then there still may be lots of tech debt to undo.
    - erhaetherth 3y ago
      Right...but if you're going to fork it and create fragmentation, then we might as well go back to Node which has at least been stable for the past few years.
eddd-ddde 3y ago
I imagine some hosted service like everyone does is a likely option.

tjenkinsqs 3y ago

We've been using bun for a while now. We love the speed, but we love the integration even more. No need to use node, npm, nodemon, tsx, esbuild and jest. Bun is our one-stop-shop for Typescript. Thank you!

fastball 3y ago
Can I ask what you use it for specifically?
- ivanjermakov 3y ago
  I use Bun as a test and dev build runner for TS programs. I still compile with tsc though.
- tjenkinsqs 3y ago
  Bun is used in github.com/yolmio/boost as a Typescript runner to build a complete system. We use it also for all kinds of other scripts.

modeless 3y ago

Hooray for Windows support! That was keeping me from using Bun since I'm on Windows a fair bit. My experience with Bun has been excellent so far and I'm looking forward to using it more.

pier25 3y ago

Is Bun executing TS or is it also compiling down to JS and executing that? Edit: The docs mention: > Because Bun can directly execute TypeScript, you may not need to transpile your TypeScript to run in production. Bun internally transpiles every file it executes (both .js and .ts), so the additional overhead of directly executing your .ts/.tsx source files is negligible. https://bun.sh/docs/runtime/typescript https://bun.sh/docs/runtime/typescript The idea I'm getting from this is that both JS and TS are transpiled to something else. Are types preserved in this bytecode, AST, or whatever it is?

emmanueloga_ 3y ago
"TypeScript & JSX support. You can directly execute .jsx, .ts, and .tsx files; Bun's transpiler converts these to vanilla JavaScript before execution." -- https://bun.sh/docs#design-goals https://bun.sh/docs#design-goals
Kognito 3y ago
It’s not running TS directly, it’s just preconfigured to transpile TS to JS without the user having to bring extra tooling. Neat, but you’ll see the docs still recommend tsc for type checking at build.
- galaxyLogic 3y ago
  I wonder what's the benefit of TS if there's no type-checking? If types are not checked that means the TS type-declarations could be totally wrong and nobody would know. In other words they could be misleading. Why incur the type-declaration overhead if they are not used after all?
  - pfg_ 3y ago
    This is how typescript is run today. Typescript types never exist at runtime regardless of how typescript is run. There is no overhead defining types because they are deleted at runtime. The purpose of typescript is to make the editor experience better (autocomplete, error highlight). Typically typechecking is run in addition to tests to make sure there aren't a bunch of errors no one saw in editor.

afavour 3y ago

I feel like such a downer when I ask this about Bun and Deno, but: why should I use them instead of Node? I don’t mean to take away from the obviously impressive engineering effort here. But VC funding always gives me pause because I don’t know how long the product is going to be around. I was actually more interested in Deno when it promised a reboot of the JS ecosystem but both Bun and Deno seem to have discovered that Node interoperability is a requirement so they’re all in the same (kinda crappy) ecosystem. I’m just not sure what the selling point is that makes it worth the risk.

solumunus 3y ago
I don't know how you're using Node and not thinking "I wish there was a better option than this". I can't wait to jump ship but Bun/Deno aren't quite there yet, for my needs.
- eddd-ddde 3y ago
  Curious what you are missing to make the jump.
vbezhenar 3y ago
Node is safe choice, IMO. I tried deno and I think it's cool, but I'm staying on node for the time being. Things that deno makes easier are not that hard with node and stability matters for me. For example I had to spend few hours rewriting my tiny service with changed deno API. Don't have any experience with bun, though.
- mmastrac 3y ago
  If there are any specific places where Deno didn't support a node API, please file a bug -- we definitely shoot for as close to node.js as possible, and if you have to modify your code that's most often on us. (I'm a deno core dev)
  - vbezhenar 3y ago
    No, I wrote my service some time ago (basically GitHub Webhook which does some crypto to validate payload and invokes kubectl) using Deno API and few months ago I took some time to update dependencies but found out that with new standard library version some APIs are either deprecated or removed, I don't really remember, but I felt the need to rewrite it. Don't take it as a criticism, I totally understand that you need to iterate on API and nobody promised me that it'd be stable till the end of time, but still work is work.

blackhaj7 3y ago

Bun churning out the good stuff, yet again. So often I read the release notes and think “what a great idea, why wasn’t this already a thing” e.g. syntax highlighted errors

peter_d_sherman 3y ago

[dead]

preommr 3y ago

Huge fan of Bun. Came for the ts interoperability, stayed for the performance. Also seems like the most sensible project in the space - I tried Deno and it was... rough. Bun on the otherhand was easy to intergrate and a very pleasant experience.

woutr_be 3y ago
I started using Bun by default for small personal projects. Having to set up Node, with Typescript and reloads always took the fun out of quickly prototyping something. Have yet to run Bun in production tho.

earslap 3y ago

Did not realize Bun had (even if rudimentary) macros - bundle time executing code support. That is pretty neat! https://bun.sh/docs/bundler/macros https://bun.sh/docs/bundler/macros

Waterluvian 3y ago
Wow that’s pretty neat. Because of that I also learned about import attributes (https://github.com/tc39/proposal-import-attributes https://github.com/tc39/proposal-import-attributes) which is probably going to be quite useful and make the 50 lines of imports in some of my files look even dumber.
- Valodim 3y ago
  Some loaders already encode stuff in the path url style, e.g. vite-svg-loader import iconUrl from './my-icon.svg?url' Maybe I'm not imaginative enough but this seems like a reasonably restricted (i.e. simple) way of parametrizing imports.
  - erhaetherth 3y ago
    That's what I've been waiting for too. The URL params always seemed rather sketch to me. No bundlers seem to be using it that way though.
agos 3y ago
this is one of the most interesting new things in the bundler space - Parcel is introducing some form of macro too. It's way overdue to have some way to program what happens at bundling time (without writing your own bundler plugin)
FlorianRappl 3y ago
Yes its neat - I wish more bundlers adopt it! In the past I've written a little plugin that is available for almost all bundlers allowing you to do that: https://dev.to/florianrappl/getting-bundling-superpowers-using-codegen-2no8 https://dev.to/florianrappl/getting-bundling-superpowers-usi...

ericyd 3y ago

Not sure I see the benefit of the bun shell. I use shell scripts when I know that the other people using the script will be able to run it in a similar shell to me, in order to cut down on dependencies. If I need it to be cross platform I just use a scripting language like JS. Bun shell keeps the more esoteric syntax of Unix-like shells but also requires a dependency (Bun itself). If you already have Bun installed why wouldn't you just write a JS script?

zamadatix 3y ago
I can definitely see the value of not wanting to write the boilerplate kind of stuff you need to do for more shell like scripting. I can also see wanting to emulate the traditional syntax while abstracting away whether you are on a Unix system and still allowing traditional JavaScript syntax in between the sheep-y parts. On the dependency side it'd be slick if you could bun --compile these like normal bun apps.
pfg_ 3y ago
It's realy nice when I need to do shell stuff - much nicer to be able to use js to write a shell script than either go look up shell syntax again or use js with child_process.spawn()
CuriouslyC 3y ago
I mandate WSL when working with windows developers, and GNU coreutils for mac developers so that I can assume some things about their dev environments. This solves that problem for shell scripts, there are still other ways where it's useful but a scripting environment is probably the biggest one. The velocity of writing filesystem and file manipulation files in shell is many times greater than in javascript. Bun shell lets you leverage the power of shell for that stuff while being able to leverage your javascript code at the same time, with fairly minor downsides in exchange.
- ericyd 3y ago
  > The velocity of writing filesystem and file manipulation files in shell is many times greater than in javascript. I think you're right, after achieving a level of expertise. I've never gotten there myself which probably explains my bias, but I appreciate hearing your perspective.

MarkSweep 3y ago

I was quite curious about the .bunx file format. I think this could be a quite a useful thing, a universal binary format. Then I see the shim DLL: https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c3afdd53b437770e1/src/install/windows-shim/bun_shim_impl.exe https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c... Even before this past week's XZ backdoor revelation, checking binaries into source control rather than building from source seems quite questionable. In fairness to the Bun developer's, they have a comment in their build.zig file acknowledging that this shim should be built more normally rather than being checked in. Then I look into the source for it: https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c3afdd53b437770e1/src/install/windows-shim/bun_shim_impl.zig https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c... For no discernible reason, it is using a bunch of undocumented Windows APIs. The source cites this Zig issue as one reason for why they think it is OK to use undocumented APIs: https://github.com/ziglang/zig/issues/1840 https://github.com/ziglang/zig/issues/1840 I don't see any good reasons here cited for using undocumented, unstable interfaces. For Zig's part, there seems to be some poorly-explained interest in linking against "lower level" libraries without any motivating use case (just some hand waving about security and drivers, neither of which makes much sense. Onecore.lib is a thing if you wanted a documented way of linking an executable that run on a diverse set of Windows form factors. And compiling drivers may as well be treated as a seperate target, since function names are different). For Bun, I assume they are trying to have low binary size. But targeting NTDLL vs. Kernel32 should not make a big difference, especially when the shim is just doing basic file IO. For an example of making small executable with standard API, you can make hello world 4kb using MSVC just by using /NODEFAULTLIB and /ENTRY:main with link.exe and this program : #include <Windows.h> #define MY_MSG "Hello World!\n" int main() { WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), MY_MSG, sizeof(MY_MSG), nullptr, nullptr); return 0; } So it should be possible to make a .bunx shim of small size without having to resort to undocumented API. (Current exe is 12kb). But even if the shim exe was 100kb, that would be still be an acceptable tradeoff for me than having to debug any problem that results from using non-standard APIs.

nektro 3y ago
the motivation behind zig#1840 is that while the functions in ntdll aren't as well documented as the kernel32 functions, theyre not unstable and not having our binaries depend on kernel32.dll would lead to faster startup times as well as allow us to do things like use more performant algorithms for UTF-8 <-> UTF-16 conversion. on top of the things mentioned in the issue like having APIs with more powerful features.

galaxyLogic 3y ago

Looks like a great development. One thing I miss in Node.js is ability to run a HTTPS -server in a simple way without having to muddle with generating & installing a correct type of certificate. I understand there can be a "self-signed certificate" but there doesn't seem to be any npm-module I could install to take care of that. Since Bun is a "server-side" JavaScript platform it would be great if it could support https out of the box too.

Aspos 3y ago
Curious how do you actually see this working. Care to elaborate?
pests 3y ago
caddy supports self signed certs by default https://caddyserver.com/docs/automatic-https https://caddyserver.com/docs/automatic-https
- francislavoie 3y ago
  More precisely, it runs its own local CA to issue certs for itself. Not exactly the same as self-signed certs (which is a cert whose key was used to sign itself), but better because leaf certs are short-lived and easily cycled. This allows for setting up trust easily, just need to trust the one root CA cert and every leaf cert for any domain served will be trusted.
- galaxyLogic 3y ago
  Does it work with Node.js or Bun or Deno?
  - pests 3y ago
    You can proxy to internal services with a few lines of config.... :2080 reverse_proxy :9000 Then access https://localhost:2080 https://localhost:2080 and you'll be accessing whatever is on port 9000, be it node or bun or anything else. https://caddyserver.com/docs/quick-starts/reverse-proxy https://caddyserver.com/docs/quick-starts/reverse-proxy

fleetfox 3y ago

Faster this, faster that. Is it finally segfault free? I've tried it like 3 times in span of last year with different projects only to find out it segfaults at runtime or when installing package.

QuinnyPig 3y ago
But look how quickly it segfaults!
dimgl 3y ago
Same. Tons of tooling breaks and segfaults. Our codebase has a dylib unknown symbol error that hasn't been fixed since before v1.
CuriouslyC 3y ago
I only use bun for tests/builds/storybook, but I haven't had it segfault at all. I suspect that you've got a dependency that is hitting an undocumented node API that isn't fully implemented. They talk about those in the blog post, they're a known thing.

yoavm 3y ago

I just tried using Bun to run one of our more complex projects. Did the same with Deno a week ago and too many things weren't working. with Bun everything loaded perfectly, and I could immediately drop ts-node and nodemon because they're essentially redundant when using Bun. great stuff!

bluelightning2k 3y ago

This guy ships!

dgellow 3y ago

Really impressive list of changes. Bun sounds like the dream node alternative, I hope they succeed in their mission. And I’m glad they spent time on Windows support, that’s something neglected in the web development world

madsbuch 3y ago
I am curios, why do you think they did not succeed yet?
- WuxiFingerHold 3y ago
  There's been some polls on social media: Overall picture was 80-90% using Node. Then Bun, then Deno. I'd bet in the real world it's 99% Node for production. If in 3 years 5% were using Bun, it would be a great success (Node usage is huge). I think they're on track, but would not recommend Bun for production backends as of now.
- dgellow 3y ago
  From their website: > The goal of Bun is to run most of the world's server-side JavaScript and provide tools to improve performance, reduce complexity, and multiply developer productivity. Bun is still pretty young and experimental, and not really production ready, though it’s getting there fast. If it grows enough to force node to improve, or if it takes over node, that would be a success based on their own goal
deleted 3y ago
[deleted]

liampulles 3y ago

"...Bun on Windows passes 98% of our own test suite for Bun on macOS and Linux." Does this mean the release was made with failing tests, or am I misunderstanding?

vallode 3y ago
Looks like it, it seems the 2% are mostly odd platform specific issues that the authors' did not deem very important (my assumption for the release happening anyway). AFAIK this[1] PR tries to fix them. [1]: https://github.com/oven-sh/bun/pull/9729 https://github.com/oven-sh/bun/pull/9729
basil-rash 3y ago
Skipping particular tests depending on platform is a very common practice, for better or worse.
- CaptainOfCoit 3y ago
  That's not what's happening. Bun has tests that are supposed to work on the platform, but currently doesn't. Skipping tests from a Linux suite that doesn't make sense to run on Windows is very common. Skipping tests that should pass on a platform but doesn't just in order to cut a release isn't as common.
  - basil-rash 3y ago
    Every growing project has things thing the maintainers would like to work but that do not currently. The job of the maintainer is to balance the value of releasing a cut of the software as stands and learning about other unknown issues while continuing to work on the known, or to work on the known and ignore the unknown until finished with the known. Neither way is strictly good or bad.
sharas- 3y ago
[flagged]

madsbuch 3y ago

I use both Deno and Bun in production (albeit, on different projects). They are both great upgrades from node. In particular with the first class support for TypeScript. Bun is great for large projects with the enhanced DX over any node based environments I have worked on - I use it for a mono-repo project with several frontends and a GraphQl backend. Involved test suites run in 5 seconds, etc. Deno seems to work really well i lambda style environment (I use them with Supabase) due to their module approach that are entirely stand alone. This is great for small scripts to glue things together.

erhaetherth 3y ago
Bun has -i/--install=fallback which I thought was pretty similar to Deno but I haven't used Deno much to compare. I was thinking about starting to write my scripts with `#!bun -i` but haven't fiddled with it much yet.

rcarmo 3y ago

Still can’t use it without dgram support. But it’s nice to see it adding batteries.

thatguyagain 3y ago

I find it hilarious that we now present runtimes and other programming stuff like it was Apple presenting a new iPhone. This would be satire 15 years ago. No disrespect to Bun tho, I love Bun.

yurishimo 3y ago
I feel like it’s meant to be satire here as well.
- erhaetherth 3y ago
  If it is... they're doing a really good job staying composed, because I couldn't tell. It would be amusing if true.
madsbuch 3y ago
The audience for these types of announcement is bigger. My intuition is that there are many more consumers of node-like environments today than any runtimes 15 years ago.
CuriouslyC 3y ago
That's because there's so much cacophony emanating from internet that you have to shout to be heard today.
daredoes 3y ago
I find these articles useful when migrating a legacy system, as they sometimes contain migration notes or rare minor details from the developers. This combined with the Wayback machine makes for a great way to keep track of detailed information

WuxiFingerHold 3y ago

The energy and velocity behind Bun is mind blowing.

gregoriol 3y ago

Is it me or does this project tries to do too many things at once? "Bun is an npm-compatible package manager", and an http server, and a websocket server, and a test library, and a bundler, and... why?

dimitrisnl 3y ago
That's the selling point
- gregoriol 3y ago
  That's the scary point
  - norman784 3y ago
    I like their selling point and if there is enough demand, I think the node community will implement at least a few of those features.
  - dimitrisnl 3y ago
    Migrating bundlers and changing test-runners is no fun. If bun can handle that with consistent performance and no goofy upgrade paths, I'm happy.
dgellow 3y ago
Because that’s what people want. That’s how you can get a really good developer experience similar to golang or other languages. Just install one tool to build, lint, format, run tests, run your local project. No time spent trying to setup a bundler when what you want is to build a new project. Regarding runtime libraries, it’s similar to the battery-included approach of go or python, you get what you need to get started out of the box and only reach for dependencies when you want to go further. Testing library, an http server, a websocket server that’s perfectly reasonable to have as core library of a runtime developed to run web servers.
deleted 3y ago
[deleted]

misiek08 3y ago

So able to optimize node.js and be $x times faster, but not able to calculate percentage of speedup correctly? 1.3s vs 2s it's not 58% speedup - it's 35%... Such approach makes those projects looks like unicorns, not production stuff - even they are.

anonymoushn 3y ago
Using the numbers given, it's a 53% speedup.
dgellow 3y ago
You can communicate the same without the snarky tone

sharas- 3y ago

Bun is run by a little prince

__jonas 3y ago
could you elaborate?

ptx 3y ago

The API for the shell function is kind of neat, in that it seems to prevent you from accidentally creating shell injection vulnerabilities by calling it without properly quoting the arguments. For example, in Python you could easily do this: message = '; cat /etc/passwd' # Whoops, shell injection vulnerability! subprocess.run(f'echo Message: {message}', shell=True) # Correct (assuming sh-compatible shell). subprocess.run(f'echo Message: {shlex.quote(message)}', shell=True) # Correct (without using shell). subprocess.run(['/bin/echo', 'Message:', message]) But the Bun API doesn't separate quoting from executing the command, so you can't make that kind of mistake: let message = '; cat /etc/passwd'; // Works correctly. await $`echo Message: ${message}`.text(); // Fails safely by throwing error about incorrect usage. await $('echo Message: ' + message).text();

thingification 3y ago
It uses types to get quoting right? Or it quotes everything (regardless if it's already quoted)? Ironically, the first time I saw the former was in a Python templating library (in the early 2000s -- from distant memory I think it might have been the work of the MemsExchange team?)
- eddd-ddde 3y ago
  Formatters basically differentiate the literal parts of the string and the template arguments. There's also a neat postgres library that does the same for sql quoting.
erhaetherth 3y ago
It is very cool, but not new. zx does that too. And I did the same thing for MySQL years ago.
- ptx 3y ago
  Tagged templates[0], the language feature that enables this, were introduced in ECMAScript 2015 apparently – arguably at least somewhat new in the lifespan of JavaScript. :) Java is getting a similar feature with template processors[1], currently in preview. It would be nice to have it in Python as well – i.e. not just f-strings, but something that (like tagged templates) allows a template function process the interpolated values to properly encode them for whatever language is appropriate (e.g. shell, SQL, HTML, etc.). Apparently someone is working on a proposal[2], although there doesn't seem to be much recent progress. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1] https://openjdk.org/jeps/459 https://openjdk.org/jeps/459 [2] https://github.com/jimbaker/tagstr/blob/main/docs/pep.rst https://github.com/jimbaker/tagstr/blob/main/docs/pep.rst

atonse 3y ago

I admire your video production values :) Nice job there, One thing is, what gear do you guys use? The audio was really good for what was probably a shotgun mic? Can you tell I don't use bun yet? Because none of my questions are about the release. But I tried it out a few weeks ago on my NextJS project and it didn't work, but will try bun 1.1.

CuriouslyC 3y ago

Lots of good changes here, Bun shell + windows support solves a real problem. Is `remix run dev` fully working now with the additional node API support?

MrResearcher 3y ago

Are there any measurements or statistics how many times a particular npm package was downloaded for usage in Node.js vs Bun vs Deno? E.g. I see 9m downloads for vite: https://www.npmjs.com/package/vite https://www.npmjs.com/package/vite What proportion of that is currently for Bun?

XCSme 3y ago

Could I use this with Parcel.js for my local development of a React app? Or Bun also replaces ParcelJS?

ojosilva 3y ago

One of my favorites: Bun has a working FFI that is also fast. https://bun.sh/docs/api/ffi https://bun.sh/docs/api/ffi So has Deno, but Bun's feel more evolved as it comes bundled with tools and sufficient examples for working with pointers. The only thing Bun is missing right now is the Deno equivalent of non-blocking FFI calls, ie `await mylib.myFunc()`. Another one on my wishlist for Bun: embedded Bun. A library distribution would be nice, so that we can call into Bun as ie "libbun.so" from other languages. It would be more resourceful than just embedding WebKit/SpiderMonkey/v8 as these lack any real capabilities besides running vanilla JS.

meekaaku 3y ago

What's he hosting story for Bun? Is any major platforms offering bun hosting?