hey I work on the project. This isn't a "re-write in rust" thing, we intend to iterate on the protocol itself to drive performance improvements. nearly all of our team are veterans of the IPFS ecosystem who want to see IPFS evolve to be more performant. We obviously can't change the overall performance of the network overnight, but we do control interop between nodes that run iroh, where we plan to ship fast-paths that we can propose as spec-level changes to the protocol once proven in the wild.

Our initial research indicates the thing that needs the most attention isn't the DHT (a commonly-cited source of slowness), but the data transfer protocol: bitswap. We plan to tackle that in the coming months.

Yea... i'm a huge fan of Rust and it is my primary language these days, but despite my many complaints with Go.. it's not bad. In fact it's pretty solid. I can't imagine the primary slowness in ipfs-go will be solved by ipfs-rust, at least on language alone. Some, sure, but not primary.. i would think.

Do i think Rust could have a better, more generic library with code that is far more concise than Go? Yes.. but that's not likely the cause for ipfs-go's issues.

I can definitely see a chance for a rewrite producing better code though. As much as i'd love to give Rust that victory, i just can't imagine Rust is _that_ big of contributor in this specific case.

I'm not sure people are claiming that the choice of programming language is the deciding factor? All the website and the comments are saying is "the current client (which happens to be written in go) is slow, maybe this rewrite will be faster". I'm not sure it's fair to read it as an attack on go, or an endorsement of rust.

Based in my experience trying to use the Kubo client and reading the code to try to understand bugs the codebase is just not if a great quality. Any high quality re-write should be able to do a much better job. I'm sure the language choice helps but I don't think that is the biggest factor at play here.