4 ms·

How is Rust or any other language supposed to help with this? Unless there is a serious design problem in the current go codebase, removing GC overhead will not

How is Rust or any other language supposed to help with this? Unless there is a serious design problem in the current go codebase, removing GC overhead will not by itself solve the problem of some software having to run all the time

lijogdfljk 4y ago
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.
- rklaehn 4y ago
  We are going to first try to reach feature parity with the go implementation in the areas we care about. But it is quite clear that there are some drastic improvements needed at the protocol level to get the desired performance. We are going to experiment with such improvements, and try to work with protocol labs to standardise them if/when we come up with a good solution.
wongarsu 4y ago
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.
b_fiive 4y ago
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.
- bavell 4y ago
  Very happy to hear this. Best of luck to the team!
kevincox 4y ago
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.

lijogdfljk 4y ago

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.

rklaehn 4y ago
We are going to first try to reach feature parity with the go implementation in the areas we care about. But it is quite clear that there are some drastic improvements needed at the protocol level to get the desired performance. We are going to experiment with such improvements, and try to work with protocol labs to standardise them if/when we come up with a good solution.

wongarsu 4y ago

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.

b_fiive 4y ago

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.

bavell 4y ago
Very happy to hear this. Best of luck to the team!

kevincox 4y ago

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.