You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a few projects in rust which use ethers-rs and also have started a few more which I started with alloy-rs I want to share a few takeaways in the migration processes:
Starting a new project using alloy is excellent and easy; it is my go-to, and you guys have made an incredible library.
I have one project called rindexer, in which I spent 3-4 hours trying to migrate to Alloy from Ethers, but some methods i just struggled to find the way you do it in Alloy; this made me think that larger existing projects which use more low-level Ethers will struggle to migrate without a significant investment in time. Most of the time, it was purely trying to find it, and in turn, as I don't have another 3-4 hours to spend on this migration, I have stopped for now and stayed with Ethers which I would rather not do.
I have another project, which I started with Ethers and again struggled with the same issues above. Still, as it was less dependent on Ethers for a bunch of stuff, it was not as hard (still took 2-3 hours+), but I kept seeing myself jumping between Github Alloy and Github Ethers trying to find it—it was not straight forward and painful to do.
I know you have the docs https://alloy.rs/migrating-from-ethers/reference.html, but it touches only on the high-level bits if you want people to migrate away from Ethers on the existing large codebase fully, I suggest throughout the entire ethers-rs codebase attaching #[deprecated with a note pointing to where this exists now in the Alloy codebase, I know this may seem an big undertaking but as Ethers was the core rust library for a while and you want to deprecate it entirely IMHO it would be an excellent investment of time and allow people to not struggle as much in the migration, I know things change and things move but overtime you tend not to make breaking changes so even if a few deprecated get out of date on ethers it doesn't matter IMHO. I know this alone would have taken my migration time down quickly and would have allowed me to migrate 3-4x faster probably leaving me impressed once I was done. Once you do this nobody has an excuse not to migrate.
I created it here because it's directly linked to me using Alloy itself and feels like an Alloy task, even if it's done in Ethers codebase. Let the code explain to the developer how to migrate over developers searching the codebase to find where it exists now.
The text was updated successfully, but these errors were encountered:
Component
meta-crate, contract, consensus, eips, genesis, network, json-rpc, node-bindings, provider, pubsub, rpc, serde, transports
Describe the feature you would like
I have a few projects in rust which use
ethers-rs
and also have started a few more which I started withalloy-rs
I want to share a few takeaways in the migration processes:rindexer
, in which I spent 3-4 hours trying to migrate to Alloy from Ethers, but some methods i just struggled to find the way you do it in Alloy; this made me think that larger existing projects which use more low-level Ethers will struggle to migrate without a significant investment in time. Most of the time, it was purely trying to find it, and in turn, as I don't have another 3-4 hours to spend on this migration, I have stopped for now and stayed with Ethers which I would rather not do.I know you have the docs https://alloy.rs/migrating-from-ethers/reference.html, but it touches only on the high-level bits if you want people to migrate away from Ethers on the existing large codebase fully, I suggest throughout the entire
ethers-rs
codebase attaching#[deprecated
with a note pointing to where this exists now in the Alloy codebase, I know this may seem an big undertaking but as Ethers was the core rust library for a while and you want to deprecate it entirely IMHO it would be an excellent investment of time and allow people to not struggle as much in the migration, I know things change and things move but overtime you tend not to make breaking changes so even if a few deprecated get out of date on ethers it doesn't matter IMHO. I know this alone would have taken my migration time down quickly and would have allowed me to migrate 3-4x faster probably leaving me impressed once I was done. Once you do this nobody has an excuse not to migrate.I created it here because it's directly linked to me using Alloy itself and feels like an Alloy task, even if it's done in Ethers codebase. Let the code explain to the developer how to migrate over developers searching the codebase to find where it exists now.
The text was updated successfully, but these errors were encountered: