- 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.
lemmy deleted everything between the “less than” character and “>”.
Lemmy also escaped the ampersands in their comment’s link 😉
Isn’t broken sanitization great!
Next Day Edit: Sorry. Forgot to use my Canadian Aboriginal syllabics again. Because apparently it’s too hard to admit HTML-sanitizing source markdown was wrong!
One thing that irks me in these articles is gauging the opinion of the “Rust community” through Reddit/HN/Lemmy😉/blogs… etc. I don’t think I’d be way off the mark when I say that these platforms mostly collectively reflect the thoughts of junior Rustaceans, or non-Rustaceans experimenting with Rust, with the latter being the loudest, especially if they are struggling with it!
And I disagree with the argument that poor standard library support is the major issue, although I myself had that thought before. It’s definitely current lack of language features that do introduce some annoyances. I do agree however that implicit coloring is not the answer (or an answer I want to ever see).
Take this simple code I was writing today. Ideally, I would have liked to write it in functional style:
async fn some_fn(&self) -> OptionᐸMyResᐸVecᐸu8ᐳᐳᐳ {
(bool_cond).then(|| async {
// ...
// res_op1().await?;
// res_op2().await?;
// ...
Ok(bytes)
})
}
But this of course doesn’t work because of the opaque type of the async block. Is that a serious hurdle? Obviously, it’s not:
async fn some_fn(&self) -> OptionᐸMyResᐸVecᐸu8ᐳᐳᐳ {
if !bool_cond {
return None;
}
let res = || async {
// ...
// res_op1()?;
// res_op2()?;
// ...
Ok(bytes)
};
Some(res().await)
}
And done. A productive Rustacean is hardly wasting time on this.
Okay, bool::then()
is not the best example. I’m just show-casing that it’s current language limitations, not stdlib ones, that are behind the odd async annoyance encountered. And the solution, I would argue, does not have to come in the form of implicit coloring.
Practically speaking, you don’t have to.
Your executor of choice should be doing tokio
compat for you, one way or another, so you don’t have to worry about it (e.g. async-global-executor with the tokio
feature).
async-std
is dead.
are there any hurdles or other good reasons to not just adding this to every create?
I’m no expert. But my guess would be that many crate authors may simply not be aware of this feature. It wasn’t always there, and it’s still unstable. You would have to reach the “Unstable features” page of the rustdoc book to know about it.
Or maybe some know about it, but don’t want to use an unstable feature, or are just waiting for it to possibly automatically work without any modifications.
Of course, I would assume none of this applies to the embassy
devs. That Cargo.toml
file has a flavors
field, which is something I’ve never seen before 😉 So, I’m assuming they are way more knowledgable (and up-to-date) about the Rust ecosystem than me.
So, this is being worked on. But for now, that crate needs this line in lib.rs
#![cfg_attr(docsrs, feature(doc_auto_cfg))]
And this line in Cargo.toml
’s [
section: ]
rustdoc-args = ["--cfg", "docsrs"]
With these changes, feature gating will be displayed in the docs.
To replicate this locally:
RUSTDOCFLAGS='--cfg docsrs' cargo doc --features=nightly,defmt,pender-callback,arch-cortex-m,executor-thread,executor-interrupt
I constantly seem to include something from the docs, only to be told by the compiler that it does not exist, and then I have to open the source for the create to figure out if it’s hidden behind a feature flag.
As others mentioned, the situation is not perfect. And you may need to check Cargo.toml
. Maybe even the source.
But as for the quoted part above, the docs should definitely indicate if a part of the API is behind a feature. Let’s take rustix
as an example.
Here is the module list:
Here is the view from inside a module:
Here is the view from a function page:
This is also true for platform support. Take this extension trait from std
:
Now, it’s true that one could be navigating to method docs in the middle of a long doc page, where those indicators at the top may be missed. But that’s a UI issue. And it could be argued that repeating those indicators over and over would introduce too much clutter.
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.
While this is indeed paranoid and not well informed, I’m kind of appreciating… the GNU appreciation.
Makes a good change from all the hypernormalized Twitter/Mastadon non-coders, or self-proclaimed coders (the kind that uses terms like “imposter syndrome” every day), always bitching about how GNU was a mistake, and all it did was provide free labor for corporations, and how the FSF and Stallman are all kinds of bad and wrong.
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.
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
;)