> in practice the closure syntax and logical or do not lead to confusion (imho, ymmv).
That's true. But put your self in the mind of a C developer looking at Rust code for the first time:
if a || b {
println!("True");
}
Cool.
Then:
thread::spawn(|| println!("Hello from a thread!"););
What? What is the logical or doing there?
----
IIRC, there are also cases where you have to write `& &`
instead of `&&` to not confuse the compiler. That's
a design/practical issue.
Both those issues would have been avoided if literal `and`/`or` were used.
I find it interesting how the only thing that momentarily confused me, as a C developer, about Rust syntax, was caused by Rust authors not wanting to syntactically deviate too much from C.
I only knew(and liked) C reasonably well before Rust. And nothing felt obscure when I started learning it.
I can only remember not getting what `||` meant (in the context of defining a closure without args). The positional meaning of `||` and `&&`
is the only thing, I can recall right now, that can be considered obscure syntactically (for C developers at least) . They should have gone with literal `and`/`or` for the operators IMHO.
Christian Grothoff is an excellent academic. In fact, he is one of the most knowledgeable in the field worldwide.
Unfortunately, that's why ,IMHO, GNUnet didn't succeed. To build a successful product/network, you need to be practical, and you need to make useful features/services available as early as possible (without compromising security of course). Designing with pluggability and forward-compatibility in mind helps in this regard.
Academic perfectionism, however, can delay your product/network launch indefinitely. And that's what seems to have happened with GNUnet.
Are there any plans to support archiving Web 2.0 pages?
More and more people are starting to rely on "archive.is" as it handles Web 2.0 content without issue. But I'm concerned about the survivability of that survice, and whether it can handle big growth.
Suppose there is only one seeder and 2-3 leechers. All leechers managed to get 50+%. Now, if the seeder disappears, the leechers should be able to finish the download from each other. If all initial leechers are streamers, that download will never finish for them or anyone else.
Supposedly long seed intervals will not help the swarm in that case.
I'm deeply concerned about popularizing torrent streaming.
A few leechers breaking "rarest-first" might not cause much harm. But if most leechers become streamers, torrents will lose their efficiency in distributing less-popular content.
Transmission implemented a "streaming" feature once, that didn't actually stream. It just stopped fetching pieces "with the same rarity" randomly. They still got too much heat for adding that not very usefull feature. And they reverted the commits soon after.
The URL does not work right now. But I tried another one from the same site.
No client can get this right, always. aria2c is not more reliable. It's just choosing to take
the filename from the redirect URL. It appears to be
the right thing to do in this case. But it would fail if the start URL was actually the one that had the right filename.
Hosts can use the Content-Disposition header if they want to make sure all (capable) clients get the right filename.
In saldl, I implemented `--filename-from-redirect` to handle your use-case. But It's not set by default.
Besides the UI, "reviewable.io" is a memory hog. It's simply unusable if you try to browse the site from a device without a lot of free memory (e.g. older tablets, ARM SoCs, etc).
Feedback welcome.
[1] https://github.com/rust-alt/cargo-esr