Hacker News new | ask | show | jobs
by stoplying1 1333 days ago
Holy thank god. These things deserve to be written in Rust (see also, matrix-rust-sdk and the entire ecosystem rebasing on it). And ipfs-go and the existing ipfs ecosystem, I'm just so disappointed. They've had so much money floating around, so many filecoin adjacent projects with ipfs-adjacent insiders and yet so much low hanging fruit that seems unrealized or locked up in poc nodejs projects.

This is probably the single best thing to happen for ipfs in 3+ years. Bravo, I actually have hope in ipfs again.

The messaging on the site makes me think I'm not alone in feeling this, and that excites me even more.

2 comments

What’s wrong with ipfs in Golang: https://github.com/ipfs/kubo

IPFS runs on Golang. This implementation is not going to change anything.

What do you mean "IPFS runs on Golang"? IPFS is a protocol that had official implementations in Golang and JavaScript.

I'm glad to see another implementation. After trying to run go-ipfs (no Kubo) for years I gave up. The implemention was incredibly low quality. It had tons of bugs, a very quirky CLI and API, and performs horribly. With any decent amount of data it would thrash like crazy for no clear reason.

I'm really glad to see another implementation. It may bring me back to running my own node.

I happen to like Rust and despise Golang but that isn't a big deal, just raises the chance that I can contribute. The go-ipfs code that I read was low quality even go Go.

I'm voting for Zig - after all, Zig is now self-hosting
Doesn’t Zig still allow for C-style memory bugs like dangling pointers?