Not that I'm not always eager to see something get rewritten in Rust, but I'm curious whether web browsers have advanced to the point where a bittorrent client could exist as a webapp rather than requiring native installation. Could the bittorrent protocol operate over WebRTC?
Synapse is not designed for people who want this use-case. It's primarily designed for seedbox users who want a daemon to control remotely. It's also designed to efficiently work at scale, and takes advantage of native features like mmap to download quickly.
Also, it wasn't rewritten in Rust from some other language, it was written in Rust in the first place.
Not the author, but I think that the point is to make disk I/O async with respect to requesting and receiving blocks. I.e. request for the next block does not wait for the write of the previous block to complete.
And this makes sense when disk is slow and you have much more RAM than network traffic. If RAM is small, while net traffic and disk are both fast, mmap writes may result in poor file layout due to arbitrary OS flush order.
Is a seedbox basically a torrent-focused media server? Probably worth submitting a PR to note this focus in the readme. And yes, I'm joking about the rewritten-in-Rust part. :)
To clarify further, a seedbox is a server used to continually "seed" (or share) any content downloaded to it.
Seedboxes are mostly used on private torrent trackers, simply because the majority require users to maintain a high seed/leech ratio. In other words, users need to upload more than they download.
Ergonomics? I love rust as much as the next guy but ergonomics was the one recurring pain point for me. So much of the language is inconsistent/incomplete and the debuggers barely work sometimes.
When was this? We've been putting a lot of work into ergonomics. We're not done yet; more stuff is coming. But depending on when you last used it, that may explain the discrepancy.
Or maybe not.
> inconsistent/incomplete
I'd be interested in hearing more about this, if you have the time. Rust is certainly incomplete, but I wonder if our perspectives line up here or not regarding how exactly it's not complete.
I wrote a few hundred lines about bout a year or two ago and about 2k the last few months. It's definately gotten better and there's something in the works for most of the things I took issue with which is kind of nice but doesn't really help if you're not on nightly.
Specific pain points for me were:
- the lack of traits for numeric primitives/types without pulling in the num crate
- the difficulty working with floating point types
- the inconsistent type annotations in fn signatures
- the type annotations are a bit clunky no easy way to alias
- and auto deref mechanics especially via match statement
- having to fully specify a type in a match statement or use Self::Type
- the use mechanism makes no sense
- no optional/default arguments without macros leads to a lot of shimming/boilerplate
- having to split operations because the borrow checker can't do partials or non lexical lifetimes
- the clunky range syntax wich makes writing invertible/reversible functions really ugly and error prone due to lack of inclusive range and I really can't believe the committee decided to go ahead with ..= instead of ... It's really out of line compared to pretty much every other language is doing
- doesn't seem like there's a good way to nicely format long lines
Overall I still really like the language but I really don't see it taking off until these issues are fixed because it makes it so hard to start up.
Cool, thanks. Some of these things are being fixed, some of them, not, or at least not any time soon. (FWIW, I agree with you regarding =. We'll see...) I could go through the exact details if you care, but I won't bore you with it otherwise. Thanks for the feedback; it's really helpful.
It is impressive, and in a sense it's a very... effective... demo. The problem is that not all of us are in a position to spend that much bandwidth by accident.
What if I'd argue otherwise - that download managers (including plain HTTP(S) downloads) shouldn't be a part of browser, but a separate pieces of software?
I suspect that in modern "we don't download anything, we watch/read/run this on the web" times in-browser downloading is bound to be second-class citizen that vendors would not pay any significant attention to beyond the simplest scenarios. Basically, the torrent support will be barely functional, just like the current HTTP downloads are. If they're split in a separate program (buzzword: microservice) they still have a chance, though.
What if I'd argue otherwise - that download managers (including plain HTTP(S) downloads) shouldn't be a part of browser, but a separate pieces of software?
Well, they used to be, but now they aren't anymore, so you'll probably want to start somewhere around there. In the early days of resumable HTTP downloads and simpler browsers, there were lots of download managers.
So, if I understand this correctly, Rust would be a good fit for bittorrent, right?
Handling lots of stuff simultaneously, peers, trackers etc, to me a bittorrent that actually does more than download and quit always seems like something quite heavy...
Rust would be a good fit, yes, but many other languages could be a more comfortable fit. For example since we're just doing a simple data processing task, a simple language like Go would work perfectly. Since the realtime constraints are not super strict, you can build fine BT clients in comfortable languages such as C# or Java as well.
An advantage of Rust however is that it's easy to expose a C api from it, so it can easily be integrated into a project done in a more comfortable language.
Let's brainstorm ways to solve the seeders/leechers problem via cryptocurrency: how much would it cost to encode a complete feature-length film in the bitcoin blockchain? :P
The user would torrent a scrambled file, once some conditions were met the user would receive the mechanism for unscrambling the file. While the user is seeding the scrambled file they would have an alternate metadata that describes that file. The version that is served could be based on consensus of the network.
It would be great to have a client that works well for seeding massive amounts of torrents (100,000+) on weak hardware (like a Raspberry). The main problem seems to be memory usage.
How is the memory usage of this one?
It says it is light-weight. What kind of light-weight is it and are there some metrics?
Please help test it! We currently mean lightweight in terms of design, but we also want it to be lightweight in terms of performance. But we haven't had many opportunities to test it with truly huge numbers of torrents (though we have tested it on large torrents (1.5T+) with lots of files (1000+)).
As far as memory usage goes, I don't think low-memory devices have been a use-case Luminarys has had in mind yet, but he's probably on board with tuning with that in mind. On my client right now I have 45 torrents, 3 seeding, and one is that huge one I mentioned before - and synapse is using 1.2G of RAM, and 41G of virtual memory.
That's a lot of memory...my little NAS has 512mb IIRC.
I run Transmission (from the Debian repo) on it and never even thought about memory usage before now, it just works. Admittedly I don't really let a bunch of torrents run at once though.
I recently selected an ODROID-C2 for a NAS because of its dedicated Ethernet controller. Cute device. My fingers are crossed for the performance test early this week.
Someone ought to write a website that scrapes popular OSS hosting sites and package repositories and comes up with a list of English words that haven't been taken already. :P
The python API for transmission is pretty simple, I wrote a RSS feed reader that adds new torrents in something like 20 lines of code (not counting my custom rss parser module automagically generated from the schema).
For (a simple) example, actix-web uses actix, a library that largely changes the nature of writing Rust code. This might be called Rust-a or Rust', or something.
My point is that Rust is a really cool language where "the(/some) (sub)community(ies)" are developing and coalescing around great libraries outside of core std, making a very* robust language, or rather robust language dialect.
I'm not all that familiar with actix, but surely not every Rust program is written using a library that largely changes the nature of Rust code. Like, would you say there's a name for the dialect this program is written in?
Programming dialects don't seem to get names. I think a pattern of [language-name]-[dominant-principles] might make a good name scheme. Suffixes would then work across languages. Other suffix namespaces could coexist, though I'm not sure what they'd be.
My point wasn't so much about any one program, so much as it was about an invisible programming ethnology. I like when Show HNs say what language they speak; I would like even more if they say how they speak it.
Having name for program dialects would allow prospective users and contributors to gain deep insight about its intended structure, vision, scope, limits, etc, etc, etc, etc from a distance.
It may have seemed narrow focused, but I didn't want my point to be limited to one set of principles, patterns, and libraries, even though I like what actix adds to Rust-std(?), especially since any code spoken in it can itself make, or through some elements factored out be made into, other libraries that then build on or toward another powerful dialect / speaker communities.
