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.

Still on 0.17.4 btw.

--all-features doesn’t work with that particular crate because two of the features conflict with each other. The features list in my command is the one used for docs.rs from the crate’s Cargo.toml.

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 [package.metadata.docs.rs] 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.

Note: the ᐸᐳ characters used below are Canadian Aboriginal syllabics because Lemmy devs haven’t fixed broken input sanitization yet.

Well, getters are not an official concept in Rust. You can do whatever works best in your case.

Just worth pointing out that a method with a return value of OptionᐸVecᐸStringᐳᐳ wouldn’t be really a getter, as you must be constructing values, or moving ownership, or cloning. None of these actions conceptually belong to a getter.

Also, you should be clear on the what the Option abstraction means. Does it mean the vector is empty? Does it mean the vector does not exist or some sort of null (FFI ore serialization contexts)? And make sure the code does what you expect it to do.

Note: the ᐸᐳ characters used below are Canadian Aboriginal syllabics because Lemmy devs haven’t fixed broken input sanitization yet.

A vec and a string are basically the same thing (a series of bytes)

Everything is a series of bytes! I thought you were going to mention that both are fat pointers. But that “series of bytes” description is quite weird.

This makes handling it much easier because you can still iterate over it

This is not a valid consideration/objection, as Options are iterable and you can flatten them:

fn main() {
  let v = vec![1,2,3];
  for n in Some(&v).into_iter().flatten() {
    eprintln!("{n}");
  }
  for n in None::ᐸ&Vecᐸi32ᐳᐳ.into_iter().flatten() {
    eprintln!("{n}");
  }
}

This might involve the compiler making an allocation of an empty array but most of them (gcc, ghc) will now what you are doing and optimize the null check on the empty array to a bool check

This paragraph appears to be out of place in the context of a Rust discussion.

It might actually be a bug that the thread didn’t end up here as comments

If that’s the case, that’s a good bug in my book.

I will use the Rust Book first.

Good choice. Follow it with this Little Book of Rust Macros. And don’t verge into the unsafe stuff early, and don’t verge into it later unless it’s really necessary.

if you’ve been following us for a while you know we’re passionate about #Rust! 🦀

who’s “us”?
following where?
is there a reason to particularly care about ᐸwhoever you areᐳ’s passion for Rust?

^ only meant half-seriously to point to the silliness of microblogging to a discussion community.

Note: the ᐸᐳ characters are Canadian Aboriginal syllabics because Lemmy devs haven’t fixed broken input sanitization yet.

https://github.com/LemmyNet/lemmy/issues/3827

Because the audiophile is broke, and will have to listen to some music on a lowly device, but the craving for some placebo is still there.

EDIT: btw, the bitrate is missing a k in your command 😉

Not audiophilic enough.

ffmpeg -i in.flac -ar 48000 \
            -af aresample=resampler=soxr:precision=28:cheby=1:dither_method=shibata \
            -c:a libopus -b:a 224k out.opus

There is no need to talk about an imaginary version of IPFS. GNUnet already exists. You can add that to the list of actually superior technologies that long predates IPFS.

As I mentioned, IPFS is nothing but very basic tech that got overhyped to junior/uninformed developers, and crypto scam victims.

If you were on GNU/Linux, my answer to your questions would have had nothing to do with Rust. It would have involved tools like readelf and ldd, maybe strace.

So, maybe check out what equivalent tools exist on Windows, and try using them.

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.

Besides being overhyped basic tech where way more useful and practical solutions existed for decades (Freenet existed since year 2000 btw, and Tahoe-LAFS since 2007), there is nothing private about IPFS. This is a dangerous message to purport.

IPFS is as practically useful as NFTs. No wonder the two crowds connected well!

iroh is an attempt to create a useful and practical IPFS. But none of the bigger practical features is implemented yet. And the design itself doesn’t appear to be finalized. I’m willing to give iroh a chance, although the close proximity to the IPFS crowd doesn’t fill one with confidence.

• I would drop the derive shorthands, and drop the Cypher prefix from the derive macros. They are already namespaced under the crate.
• Regarding the ty::new() impls, I’m not a hardline devotee of the builder pattern, but when there are multiple private fields of the same type, I would absolutely prefer it, to remove the possibility of field-value confusion at construction.

I didn’t dig deeper because I noticed you posted this to Reddit first 😉

Defederation questions/requests should be made in private, at least initially. That is to avoid turning an instance, which may temporarily not be actively administered/moderated, into a hotbed of illegal posting.

As it stands, any concern troll can turn a random small instance, which may not have an admin around for two days or three, into a hotbed of illegal or potentially-illegal activity, simply by bringing attention to it with a public defederation request.

Even with the presumption of genuine concern, the effect and end result will be the same.