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.
