We already knew it was from mastoclowns, for mastoclowns.
The details and which “e-celebs” are involved is immaterial.
No one relevant (or merely sane) cared, cares, or will ever care about that scene’s rage-circlejerk choice of the day.

Regarding Cargo.lock, the recommendation always was to include it in version control for application/binary crates, but not library ones. But tendencies changed over time to include it even for libraries. If a rust-toolchain file is tracked by version control, and is pinned to a specific stable release, then Cargo.lock should definitely be tracked too [1][2].

It’s strictly more information tracked, so there is no logical reason not to include it. There was this concern about people not being aware of --locked not being the default behaviour of cargo install, giving a false sense of security/reliability/reproducibility. But “false sense” is never a good technical argument in my book.

Anyway, your crate is an application/binary one. And if you were to not change the "*" dependency version requirement, then it is almost guaranteed that building your crate will break in the future without tracking Cargo.lock ;)

• Don’t use "*" dep version requirements.
• Add Cargo.lock to version control.
• Why read to string if you’re going to base64-encode and use Vec<u8> later anyway?

Here is an originally random list (using cargo tree --prefix=depth) with some very loose logical grouping. Wide-scoped and well-known crates removed (some remaining are probably still known by most).

mime data-encoding percent-encoding textwrap unescape unicode-width scraper
arrayvec bimap bstr enum-iterator os_str_bytes pretty_assertions paste
clap_complete console indicatif shlex
lz4_flex mpeg2ts roxmltree speedy
aes base64 hex cbc sha1 sha2 rsa
reverse_geocoder trust-dns-resolver
signal-hook signal-hook-tokio
blocking
fs2
semver
snmalloc-rs

My quick notes which are tailored to beginners:

Use Option::ok_or_else() and Result::map_err() instead of let .. else.

• let .. else didn’t always exist. And you might find that some old timers are slightly triggered by it.
• Functional style is generally preferred, as long as it doesn’t effectively become a code obfuscater, like over-using Options as iterators (yes Options are iterators).
• Familiarize yourself with the ? operator and the Try trait

Type inference and generic params

let headers: HashMap = header_pairs
        .iter()
        .map(|line| line.split_once(":").unwrap())
        .map(|(k, v)| (k.trim().to_string(), v.trim().to_string()))
        .collect();

(Borken sanitization will probably butcher this code, good thing the problem will be gone in Lemmy 0.19)

Three tips here:

1. You don’t need to annotate the type here because it can be inferred since headers will be returned as a struct field, the type of which is already known.
2. In this pattern, you should know that you can provide the collected type as a generic param to collect() itself. That may prove useful in other scenarios.
3. You should know that you can collect to a Result/Option if the iterator items are Results/Options. So that .unwrap() is not an ergonomic necessity 😉

Minor point

• Use .into() or .to_owned() for &str => String conversions.
  • Again, some pre-specialization old timers may get slightly triggered by it.

make good use of the crate echo system

• It’s important to make good use of the crate echo system, and talking to people is important in doing that correctly and efficiently.
  • This post is a good start.
  • More specifically, the http crate is the compatibility layer used HTTP rust implementations. Check it out and maybe incorporate it into your experimental/educational code.

Alright, I will stop myself here.

Blog announcement.

https://github.com/LemmyNet/lemmy/pull/4024

Broken input sanitization probably.

Issue will thankfully no longer exist in the next lemmy release.

I only participated in two surveys, the first, then the second or third (don’t remember).

I am here. So, while I’m not sure, I think I’m still interested 😑

Maybe gauging level of interest based on the number of survey participants is not a sound strategy 🤔

I think there used to be a question about how long you’ve known/used Rust. And you would find that new or relatively new users were always overrepresented. Although, maybe that over-representation was read wrongly at times.

If I had to speculate something based on this decline, I would guess that most people who were to give Rust a try at some point, have actually done so already. So the influx of people new to the language, where for them the novelty (and the excitement/resentment that comes with it) hasn’t worn off already, has slowed down.

I’d say that’s understandable, and is to be expected after many years of hyped existence.

keep in mind that it’s hard to get real numbers on LDAC because decoding is proprietary

I used to think the same. But as it turns out, a decoder exists. Maybe some people don’t want anyone to know about it to keep the myths alive ;)

EDIT: Also, as a golden rule, whenever anyone sees the words High-Res in an audio context, they should immediately realize that they are being bullshitted.

I do think it is the future of filesharing

In internet years, Torrenting is old. I2P is old. Even torrenting in I2P is old. Nothing about this is “the future”.

Ideally, the future of file sharing would involve a fully/natively integrated anonymous network with content-addressable distributed filesystem.

But this will probably not happen, as that architecture didn’t see large scale success before, except in Japan where at least some elements of this architecture are used in their popular P2P networks.

The I2P crowd themselves tried with Tahoe-LAFS, but that was never really a network, even aMule over I2P had more traction, and by traction I mean tens or hundreds of users, not thousands or beyond.

Ironically, the one content-addressable distributed filesystem that gained some attraction (outside Japan) is IPFS, which doesn’t offer anonymity, or replication, or anything special really. Yet for some reason, some hype-susceptible techies liked it, together with the NFT crowd, a great fit.

The future of file sharing will depend on where most content will land where it will be easily accessible and quickly grabbable. How those networks will look like? Nobody knows.