What does HackerNews think of torrent?

Full-featured BitTorrent client package and utilities

Language: Go

#33 in Go
#7 in P2P
It has some small latency but only when resources are spread across many different infos. If you can constrain your resources to a single DHT traversal, it's pretty quick. I run several services that stream from BitTorrent on demand, using https://github.com/anacrolix/torrent which are surprisingly quick to start. However it does choke up when you try to start many different resources at once, which multiplies horizontally the number of DHT traversals, and per-torrent related overhead to get started.

It is solvable, but any solution that spreads resources out across many different targets in the DHT is slow. Basically anything that was inspired by BitTorrent, but isn't BitTorrent itself does this, because they get overly excited by deduplication of data.

For whatever reason the ARM version of Transmission does not work well on my M2 laptop - it downloads quickly at first and then drops off to zero, and had some other bugs (the x86 version always worked flawlessly). I tried playing around with different settings, running their nightly builds, etc, and nothing fixed it for me. In the end I searched for other clients and found them all filled with ads and bloatware, and decided to use this excellent open source command line client instead:

https://github.com/anacrolix/torrent

It has a few frontends built on top of it (linked in the project readme), but I just run `torrent download ` and it downloads at full speed / with no issues.

There are two other WebTorrent implementations (possibly more that I don't know about!)

* https://github.com/anacrolix/torrent (Golang)

* https://github.com/arvidn/libtorrent (C++)

An implementation in Rust would be amazing, but there is a quite a bit of work to make that happen in pure Rust though! If you want to use FFI/unsafe code it is totally do-able :)

I wrote https://github.com/anacrolix/torrent specifically to address the on-demand and streaming requirements of some products I created. It also doesn't make assumptions about how you store the data as you stream, so there's no requirement that the files exist on disk as they're described in the metainfo, like other clients.
A BitTorrent client https://github.com/anacrolix/torrent, and several projects using it. The original idea started in Python which just didn't cope. Things are probably better now in Python with green-threading being a standard concept, but you just can't easily get the throughput you need without minimal overhead, and that overhead is just too high in Python.
I wrote a BitTorrent client that specifically only downloads the parts you need to perform some operation: https://github.com/anacrolix/torrent
The porting was pretty straightforward, the actual heavy lifting was provided by the https://github.com/anacrolix/torrent library.

One insight that I got from it is that the io.Reader and io.Writer interfaces can work very similar to node streams.

If you work with binary data at any point, it makes a lot of sense to provide those interfaces as there is a tremendous amount of code that can make use of it.