-
-
Notifications
You must be signed in to change notification settings - Fork 311
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Running Lodestar using Bun #7280
Comments
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. |
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). 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.
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) |
if bun has a bus factor > 1 at some point then sure
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. |
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. |
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 |
I guess what we need to figure out here is what sort of milestones/markers we need to see for:
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 |
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
branchIssues
@chainsafe/prometheus-gc-stats
:SyntaxError: Export named 'GCProfiler' not found in module 'v8'.
@chainsafe/blst
0.2.0
in light-client packageNumber(bytesToBigint(...))
returning0.5
, wtfclassic-level
: this stacktraceThe text was updated successfully, but these errors were encountered: