← Back to context

Comment by eddiewithzato

1 day ago

I can hope this will lead to little to no memory issues in using bun as a web server

I'd be surprised if they could eliminate memory issues completely, especially considering the amount of `unsafe` the codebase seems to contain.

    git rev-parse HEAD && ag "unsafe" src | wc -l
    19d8ade2c6c1f0eeae50bd9d7f2a4bf4a2551557
    14865

  • On the other hand - now it should be possible to tackle some of those one by one?

    • Oh yes, I don't doubt they'd eventually be able to seriously reduce that number, probably to a handful of places. I don't doubt the strategy employed here, rewriting it keeping it similar, then slowly change it. I do still doubt they'd be able to completely eliminate memory issues in the end regardless.

  • That's picking up all the "bunsafety" references in there :P

    • When I read what you wrote, I was like "of course, duh, I'm stupid" but running `ag "unsafe" src | grep -i "bunsafety"` it doesn't seem to be the case actually, I see zero bunsafety mentions from it.

      However, `ag unsafe` does over-count anyways, just in a different way, matching stuff like SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION and _unsafe_ptr_do_not_use and others.

      Better command with same previous commit, `ag -w unsafe src | wc -l`, reports 13914 "unsafe" usages now, slightly better but pretty awful still.

      2 replies →