- 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
later anyway?
"*"
dep version requirements.Cargo.lock
to version control.Vec
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:
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.Option
s as iterators (yes Option
s are iterators).?
operator and the Try
traitlet 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:
headers
will be returned as a struct field, the type of which is already known.collect()
itself. That may prove useful in other scenarios.Result
/Option
if the iterator items are Result
s/Option
s. So that .unwrap()
is not an ergonomic necessity 😉.into()
or .to_owned()
for &str => String
conversions.
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.
Broken input sanitization probably.
Issue will thankfully no longer exist in the next lemmy release.
From a technical point of view, I’d rather Lemmy didn’t federate except with itself, and maybe possibly also with similar networks, but only as long as that doesn’t hold Lemmy back from doing its own thing.
Getting ActivityPub federation to work reliably between Lemmy instances alone is already proving challenging for developers.
From a personal point of view, I have zero interest in what I consider a shit paradigm of social communication. The “micro” lie in micro-blogging, as you quickly conceded, is long gone. The interface is horrible for effective exchange of well-thought ideas. The social networks formed are hypernormalized echo chambers of unhinged ranting faux intellectuals and champagne activists, usually led by a cult of personality or two who are tasked with making sure the one-upping posturing game continues forever.
When you are about to "micro"blog, presumably you will be writing something coherent enough that it relates to a certain subject of interest to a section of the public. It is also presumably meant to be viewable by the public since you’re not sharing it in a private group chat.
If that’s the case, there should be a community in Lemmy where those interested in that subject congregate. That community would either be low-traffic, then you can make your "micro"blog a post there breathing more live into it. Or it would be a high-traffic one, in that case a lounge/chat/MegaThread post should exist where you can chat with people interested in that subject, in an interface that actually facilitates good discussion.
Imagine if media in Lemmy was all hosted in a distributed network filesystem like Iroh, where instances only function as inserters and exit nodes for that media.
This way, smaller instances can have a smaller cache corresponding to the media that was actually needed by it (recently). And independent peers can help by participating in the distributed file-system network without running instances themselves.
Would you have escaped them a priori?
Do you consider markdown-it
’s typographic replacements common knowledge, and thus intuitively escapable?
Should lemmy apps be pushed to use markdown-it, in your opinion?
While it may seem nice
No, it really doesn’t, its a horribly bad design choice.
I wanted to give some balance to my argument. I guess I was over-cautious with that one.
And btw, that’s '../lemmy'
in the comment above with two dots. I didn’t write it wrong. The third dot comes from markdown-it
(confirmed using their live demo)!!
Good, because I speak Rust, so, if there is an itch to scratch, I will scratch it, even though I’m not a UI guy.
I tried running the UI yesterday standalone and had ‘error loading’ message or something like that.
btw, mentioning needing ‘…/lemmy’ available in path, and needing the wasm target installed (via rustup target install wasm32-unknown-unknown
) may help non-rustaceans in particular, if added to the contributing instructions.
Also, the UI was listening on *:1237
, not just localhost, so maybe a WARNING regarding that is advisable, together with explaining the purpose behind leptos also listening to port 3001.
Will there be a way to run the UI in client mode only, without being attached to a running instance?
The codec is basic, uses decades-old tech, and was trivially REed.
Lemmy instance choice does not check out ;)
and for testing you get a wackload of SBCs and Bluetooth chips and test that
I asked because I wasn’t aware of any consumer buds supporting Opus. I wasn’t aware of PineBuds, thank you for mentioning them.
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.
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 arust-toolchain
file is tracked by version control, and is pinned to a specific stable release, thenCargo.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 ofcargo 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 trackingCargo.lock
;)