Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IPFS 0.5

blog.ipfs.io

Post reply on HN
Print view View original

41–50 of 145 posts

Re: IPFS 0.5

#41

Post by stryan »

echelon wrote: post #18
lachlan-sneff wrote: post #17

I wish they hadn't picked go. Go isn't a bad language really, but it's a huge pain to integrate a go library into an app written in another language.

C or Rust would be perfect. No GC runtime, no name mangling, fast, great ffi story. Rust needs to start edging out Go for new tools. Kubernetes, Envoy, IPFS, etc. would have benefitted from it. It might not have been time four years ago, but it's time now.

Rust will start edging out Go once Rust becomes easier than Go to prototype/start projects.

Rust is a great language, but right now I can start a project in Go and have someone else start a project in Go and have something up and working in a week. Rust still takes significantly longer to learn and/or find skilled developers for. Go is up there with Python in terms of "Get something out now".

Re: IPFS 0.5

#42

Post by carapace »

I really really want to use this, I have used it in the past. It works great as far as I could tell except for one thing: bandwidth limits[1].

Now I can do this myself, because I'm all "+337" and what not. (I used trickle as described in the comment[2]. Seemed to work fine. Nice and stable.) But I can't recommend Joe and Jane Consumer to install IPFS and some other thing with a straight face, because they'll say, "Well bittorrent can do it!?" and I don't have a good answer.

Maybe there's an opportunity there to rent IPFS VMs to normal people? I dunno.

https://github.com/ipfs/go-ipfs/issues/3065

https://github.com/ipfs/go-ipfs/issues/3065#issuecomment-415...

Re: IPFS 0.5

#43

Post by echelon »

spsoto wrote: post #22
echelon wrote: post #18

Earlier quoted context omitted.

C or Rust would be perfect. No GC runtime, no name mangling, fast, great ffi story. Rust needs to start edging out Go for new tools. Kubernetes, Envoy, IPFS, etc. would have benefitted from it. It might not have been time four years ago, but it's time now.

Envoy is written in C++, not Go.

I'm aware. The creator occasionally pokes fun at the Rust folks for arguing that Envoy should have been written in Rust. And rightly so--Rust wasn't mature at the time Envoy was written.

If we revisit that now, C++ is the wrong language to start Envoy in today.

Re: IPFS 0.5

#44

Post by momack2 »

karatestomp wrote: post #35
lachlan-sneff wrote: post #17

I wish they hadn't picked go. Go isn't a bad language really, but it's a huge pain to integrate a go library into an app written in another language.

Same thing that turned me off. There’d have been lots of cool and useful integrations popping up “for free” all over the place if they’d written it in a good library/integration language. Good language for a daemon, bad language for the reference (so, for anything halfway complicated, usually only ) implementation of something intended to become a foundational protocol.

...there are a lot of cool and useful integrations popping up: https://blog.ipfs.io/weekly-84/.

go-ipfs is where the majority of new development happens right now as the desktop/server implementation (compared to js-ipfs=browser & rust-ipfs=IoT) - but if you want to prove that Rust is clearly better/faster _in general_ - have at it: https://github.com/ipfs-rust/rust-ipfs ;)

I think the thing jbenet was selecting for back in 2013 was concurrency support & modularity, and golang is still a decent choice for that. Rust 1.0 didn't happen until 2015 after the go-ipfs alpha was already out - but agree it's made awesome progress since then!

Re: IPFS 0.5

#45

Post by willscott »

jude- wrote: post #39
willscott wrote: post #30

Earlier quoted context omitted.

For BGP partitions / Significant network outage conditions: You may not find content partitioned on the other side of a netsplit from you, but the degraded condition is that you can still query and find content present in the same part of the network as you. This is better than centralized solutions face at present - e.g. google not being available in China, and isn't too far off from what you might hope. For Sybils:…

> You may not find content partitioned on the other side of a netsplit from you, but the degraded condition is that you can still query and find content present in the same part of the network as you. This becomes hugely problematic the minute you start using IPNS. On one side of the split, the name `foo` can resolve to `bar`, but on the other side, it resolves to `baz`. If you're trying to impersonate someone, then…

Censorship / availability is the issue. As you lay out, Sybils can be used to target a specific address / piece of content in an attempt to prevent it from being found. The good news is that there are some pretty mechanical things - like maintaining a consensus of known-trusted nodes that can be used to validate a node/piece of content isn't under attack - that should be sufficient until IFPS is quite a bit larger than it is today

I don't think I see the impersonation / bad resolution problem though. IPNS records are content addressed to the key. Having control of a portion of the network isn't sufficient to compromise that (you can prevent availability though).

Re: IPFS 0.5

#46

Post by fg6hr »

IPFS is really just a mix of a torrent tracker with a torrent client, but once IPFS VMs start paying for themselves, people will sign-up in masses. I guess that's what Filecoin is about.

Edit: The way I see filecoin working is anyone can post a reward for a file and once the file is provided, the reward is paid. In other words, it's bit like a brokerage that connects downloaders with uploaders. The difficultly is that this brokerage needs to be distributed and resilient.

Re: IPFS 0.5

#47

Post by karatestomp »

momack2 wrote: post #44
karatestomp wrote: post #35

Earlier quoted context omitted.

Same thing that turned me off. There’d have been lots of cool and useful integrations popping up “for free” all over the place if they’d written it in a good library/integration language. Good language for a daemon, bad language for the reference (so, for anything halfway complicated, usually only ) implementation of something intended to become a foundational protocol.

...there are a lot of cool and useful integrations popping up: https://blog.ipfs.io/weekly-84/ . go-ipfs is where the majority of new development happens right now as the desktop/server implementation (compared to js-ipfs=browser & rust-ipfs=IoT) - but if you want to prove that Rust is clearly better/faster _in general_ - have at it: https://github.com/ipfs-rust/rust-ipfs ;) I think the thing jbenet was selecting for…

I don't care about performance, exactly, it's just that with (say) a C implementation if you're even halfway popular you'll end up with modules in a dozen languages (wrapping your C lib) and an apache module and a storage backend for a few databases, maybe a Linux kernel module, and so on, in no time, and they'll all be pretty much in sync with what's

Re: IPFS 0.5

#48

Post by thefounder »

stryan wrote: post #41
echelon wrote: post #18

Earlier quoted context omitted.

C or Rust would be perfect. No GC runtime, no name mangling, fast, great ffi story. Rust needs to start edging out Go for new tools. Kubernetes, Envoy, IPFS, etc. would have benefitted from it. It might not have been time four years ago, but it's time now.

Rust will start edging out Go once Rust becomes easier than Go to prototype/start projects. Rust is a great language, but right now I can start a project in Go and have someone else start a project in Go and have something up and working in a week. Rust still takes significantly longer to learn and/or find skilled developers for. Go is up there with Python in terms of "Get something out now ".

>> Rust will start edging out Go once Rust becomes easier than Go to prototype/start projects.

I guess that time will never come...unless Go somehow looses its way

Re: IPFS 0.5

#49

Post by rosywoozlechan »

stryan wrote: post #41
echelon wrote: post #18

Earlier quoted context omitted.

C or Rust would be perfect. No GC runtime, no name mangling, fast, great ffi story. Rust needs to start edging out Go for new tools. Kubernetes, Envoy, IPFS, etc. would have benefitted from it. It might not have been time four years ago, but it's time now.

Rust will start edging out Go once Rust becomes easier than Go to prototype/start projects. Rust is a great language, but right now I can start a project in Go and have someone else start a project in Go and have something up and working in a week. Rust still takes significantly longer to learn and/or find skilled developers for. Go is up there with Python in terms of "Get something out now ".

Rust isn't that difficult to prototype or start projects with? What trouble do you run into? I think the hardest parts to understand are the concepts of borrowing, lifetimes, and ownership, but you don't have to know all the subtleties of that to prototype. A basic understanding is fine to get started with. Just like a developer doesn't have to understand all the subtleties of generics to get started with either, lots of devs don't know what covariant or contravariant means and use generics.

Re: IPFS 0.5

#50

Post by drudru11 »

echelon wrote: post #18
lachlan-sneff wrote: post #17

I wish they hadn't picked go. Go isn't a bad language really, but it's a huge pain to integrate a go library into an app written in another language.

C or Rust would be perfect. No GC runtime, no name mangling, fast, great ffi story. Rust needs to start edging out Go for new tools. Kubernetes, Envoy, IPFS, etc. would have benefitted from it. It might not have been time four years ago, but it's time now.

Rust does name mangling by default. However, you can turn it off per symbol just like in C++.
Post reply on HN