Jarred

15 ms·

1. 151.▲
   by Jarred 3y ago

   I work on Bun. Happy to answer any questions also: there is a bug in `bun build --compile` I am currently working on fixing. Expect a v0.6.1 in a bit
2. 152.▲
   Readfile System Call Revised for Efficiently Reading Small Files(phoronix.com)

   1 points by Jarred 3y ago|0 comments
3. 153.▲
   Bun (YC S19) Is Hiring C/C++/Zig engineers to build a JavaScript cloud(oven.rippling-ats.com)

   1 points by Jarred 3y ago
4. 154.▲
   by Jarred 3y ago

   This looks really good
5. 155.▲
   by Jarred 4y ago

   JavaScriptCore has tail calls
6. 156.▲
   by Jarred 4y ago

   What benchmark did you run where Node outperformed Bun? Happy to take a look. There are still "obvious" things we need to fix, like our EventEmitter implementation is currently around 3x slower than Node due to C++ <> JS cal
7. 157.▲
   by Jarred 4y ago

   Are you still running into segfaults in recent versions of Bun? If so can you file an issue or provide some same code? We try to fix these quickly
8. 158.▲
   by Jarred 4y ago

   Nice
9. 159.▲
   by Jarred 4y ago

   Node-RED is really tough for Bun to support because it relies on sloppy mode features like implicit global variable assignment (assigning a variable without var/let/const) and Bun currently treats every file as ESM (and transpiles
10. 160.▲
    by Jarred 4y ago

    Tests are run single-threaded currently. bun:test is fast mostly because it’s integrated deeply into the runtime. Other test runners typically have to mutate globals and spend a lot of time setting up the environment and tearing it down. Al
11. 161.▲
    by Jarred 4y ago

    Oven (YCS19) | https://bun.sh | Software Engineer | San Francisco or Remote (worldwide) | Full-time or Contract Oven is on a mission to make JavaScript faster and simpler. That's why we launched Bun, a fast all-in-one JavaS
12. 162.▲
    by Jarred 4y ago

    Most of what manifests as a segfault in Bun have been due to assuming a JSValue is a heap allocated value when it is (the JavaScript representation) “null”, “undefined”, “true”, “false” etc. These are invalid pointers, the operating system
13. 163.▲
    by Jarred 4y ago

    Yes, but the GC needs to be scheduled quite a lot for it to work as expected
14. 164.▲
    by Jarred 4y ago

    This sounds like a GC scheduling bug in Bun For now, try doing Bun.gc() and if that doesn’t help enough, try Bun.gc(true). This isn’t a great solution because it will make your code slower The GC schedules automatically on event loop tasks
15. 165.▲
    by Jarred 4y ago

    I suggest not using bun bun right now and trying again after Bun v0.6. We are working on a rewrite of the bundler. The current implementation only bundles node_modules (meaning it doesn’t behave like esbuild —bundle), doesn’t correctly hand
16. 166.▲
    by Jarred 4y ago

    Sorry about this It looks like some code is importing a .png file and then some other issue (likely related to that) is causing a crash in the test runner Can you file an issue on https://github.com/oven-sh/bun/iss
17. 167.▲
    by Jarred 4y ago

    We need to get a musl libc build of Bun to do it properly. The zig part of that is really easy, but we also need to build WebKit and all other dependencies with musl libc If you use glibc-compat, you can download Bun from the github release
18. 168.▲
    by Jarred 4y ago

    Recent versions of Node.js implement many web APIs. The ecosystem is converging on a mix of web APIs and Node.js APIs. Excluding a few cases (like setTimeout), this won’t be a recurring tradeoff for Bun's runtime APIs (module resolutio
19. 169.▲
    by Jarred 4y ago

    I think we are 2 months out from a 1.0 release
20. 170.▲
    by Jarred 4y ago

    I work on Bun. Happy to answer questions
21. 171.▲
    by Jarred 4y ago

    Hack, iirc It’s oh-my-zsh’s default theme
22. 172.▲
    by Jarred 4y ago

    I work on Bun Happy to answer any questions
23. 173.▲
    by Jarred 4y ago

    Oven | Runtime Engineer (Zig, C/C++) | SF-preferred but remote ok | Full-time We are the team behind Bun: https://bun.sh , an incredibly fast all-in-one JavaScript and TypeScript runtime. We are looking for runtime engineers
24. 174.▲
    by Jarred 4y ago

    Constellation’s PRs are incredible. Some of my favorites - 9x faster Array.from({length: N}, map) https://github.com/WebKit/WebKit/pull/2876 - 35% faster Object.entries() https://github.com/We
25. 175.▲
    by Jarred 4y ago

    The problem is that Bun currently treats every file as an ESM module, which means everything uses strict mode but Node-RED relies on sloppy mode features like implicit global variables (if you omit "var", "let", or &quot
26. 176.▲
    by Jarred 4y ago

    Two things about the linked benchmark: 1) That benchmark appears to be bottlenecked by the HTTP client — that’s why the numbers are so close for each runtime. Effectively, it is benchmarking the http client and not the http server. The benc
27. 177.▲
    by Jarred 4y ago

    The memory usage difference you're seeing is likely a GC scheduling issue in Bun (not a JS engine thing) Bun isn't scheduling the garbage collector between microtask ticks and we might need to start doing that to reduce memory usa
28. 178.▲
    by Jarred 4y ago

    > Here's a comparison of a simple job. With lots of concurrency, Bun is 20-30% faster, but uses 60% more memory. That benchmark is out of date. In Bun v0.3, memory usage in situations like that dropped by 4x - https://bun
29. 179.▲
    by Jarred 4y ago

    I love working on Bun and find it very energizing
30. 180.▲
    by Jarred 4y ago

    We spend an absurd amount of time profiling, benchmarking, and making stuff run fast in Bun Most of Bun is written in native code (zig) rather than JavaScript. We leverage modern CPU features like SIMD, closely watch syscall overhead and sp