Running Lodestar using Bun

[wemeetagain]

Given the findings in #7237, we would like to run lodestar using bun.

This is a tracking issue to report / collect problems running lodestar using bun.

See the cayman/bun branch

Issues

• @chainsafe/prometheus-gc-stats: SyntaxError: Export named 'GCProfiler' not found in module 'v8'.
• failure loading @chainsafe/blst 0.2.0 in light-client package
• bytesToInt - Number(bytesToBigint(...)) returning 0.5, wtf
• classic-level: this stacktrace

 ✖ Error
    at dlopen (native)
    at load (/home/cayman/Code/lodestar/node_modules/node-gyp-build/index.js:22:10)
    at <anonymous> (/home/cayman/Code/lodestar/node_modules/classic-level/binding.js:1:8)
    at anonymous (native)
    at <anonymous> (/home/cayman/Code/lodestar/node_modules/classic-level/index.js:7:7)
    at <anonymous> (unknown:11:43)
    at processTicksAndRejections (unknown:7:39)

[nflaig]

we would like to run lodestar using bun

We should look into being able to run Lodestar on bun but I think we need to always be able to run on node or at least have the ability to do so even if it's not our preferred runtime.

Bun is still early and less tested / robust, they also have just one maintainer that does most of the work while node has a huge community and has a much more open development process.

[wemeetagain]

I think we need to always be able to run on node

I disagree with this on a longer timespan, though for the sake of derisking the experiment, agree it would be helpful to start with being able to switch between runtimes.

Our top-level cli is an opinionated product (tailored for a specific environment), not a vanilla javascript library (that can / should be run on any environment).
So practically, we just want to use whichever runtime(s) helps us achieve our goals. We shouldn't care ideologically about supporting X or Y runtime just to support as many as possible. (Every abstraction has a cost)
(This doesn't apply to our libraries, which should work in any environment)

If, for example, using bun results in a 100% speedup and 50% reduction in memory usage all else the same, we will always use that.

Swappable runtimes will be helpful for derisking a migration, but ongoing maintenance of supporting a runtime needs to be measured against how useful it actually is. I'm saying that if we aren't running it in production, and we aren't shipping it to users, it becomes a vestigial organ that should be harvested the moment it starts to get in the way.

Bun is still early and less tested / robust

I think we can easily make the case that it is less tested, but I'm not sure the same can be said about robustness. (Depending on how you measure robustness, benchmarks seem show that bun may result in a more robust Lodestar beacon node)
I suppose the more we test it, the more we can assess the robustness.

[nflaig]

I disagree with this on a longer timespan

if bun has a bus factor > 1 at some point then sure

ongoing maintenance of supporting a runtime needs to be measured against how useful it actually is

yeah that's likely gonna be an issue, we go as far right now that we decided to not even run lodestar on different node versions (although we still allow the previous stable version), but with different runtimes it would be too painful.

My concern would mostly be around investing a lot of time in rewriting everything to Bun FFI which would essentially vendor lock us. And last time I checked bun is still solely VC funded (last round August 2022), they likely will get more funding or potentially grants / donations in the future but that's still an additional risk.

[matthewkeil]

I tend to agree with @nflaig on this. I do not think we should hitch ourselves to Bun. Utilizing it to its fullest is a great idea but we should not depend/rely on it. Node has a much more robust development process and will definitely be around for the long haul. Bun is still relatively new to the JS community. Its a great project with huge potential but node is tried and true. We should definitely preserve compatibility with node.

[twoeths]

I think for libraries, I agree that we should support both/all javascript runtimes. For beacon-node, it's just nice to support NodeJS, we don't have to

[philknows]

I guess what we need to figure out here is what sort of milestones/markers we need to see for:

• Bun to be out of an experimental phase in Lodestar and supported alongside nodeJS?
• Bun to transition as our primary development runtime?
• Bun to become "mature enough" that we feel like dropping nodeJS support is minimally risky?

I think for libraries, I agree that we should support both/all javascript runtimes. For beacon-node, it's just nice to support NodeJS, we don't have to

What is the overhead of being able to support both for a transitory period?

[twoeths]

What is the overhead of being able to support both for a transitory period?

@philknows right now we're only at experimental phase, we're not able to run lodestar on Bun yet. We'll consider if it's possible and if it makes sense to support both on the beacon node later