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.

I would bad mouth Axum and Actix just because of the overhype. But then, the latter is powering this very platform, and the former is used in the federation crate examples 😉

So let me just say that I tried poem and it got the job done for me. Rusty API. Decent documentation. And everything is in one crate. No books, extension crates, and towers of abstractions needed.

I try to avoid tokio stuff in general for the same reason, although a compatible executor is unfortunately often required.

From your list, I use bat, exa and rg.

delta (sometimes packaged as git-delta) deserves a mention. I use it with this git configuration:

[core]
  # --inspect-raw-lines=false fixes issue where some added lines appear in bold blue without green background
  # default minus-style is 'normal auto'
  pager = "delta --inspect-raw-lines=false --minus-style='syntax #400000' --plus-style='syntax #004000' --minus-emph-style='normal #a00000' --plus-emph-style='normal #00a000' --line-buffer-size=48 --max-line-distance=0.8"

[interactive]
  diffFilter = "delta --inspect-raw-lines=false --color-only --minus-style='syntax #400000' --plus-style='syntax #004000' --minus-emph-style='normal #a00000' --plus-emph-style='normal #00a000' --line-buffer-size=48 --max-line-distance=0.8"

[delta]
  navigate = true  # use n and N to move between diff sections
  light = false    # set to true if you're in a terminal w/ a light background color (e.g. the default macOS terminal)

[merge]
  conflictstyle = diff3

Still on 0.17.4 btw.

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.

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.

I’m not sure about the impl thing, care to elaborate?

See this serde-derive code.

Basically, you’re wrapping your impl in a dummy const, so your impl lives in its own lexical scope.

You can set attributes on that scope, define consts/statics, import stuff that will not interfere with anything outside the generated code…etc.

So, just add your use lines. You can allow unused imports on the scope too, no conditional imports needed to avoid warnings. You don’t have to worry about anything 😉

If you don’t mind a quick review:

Another thing worth noting is that it’s as if the proc macro literally injects a bit of source code in-line where you call derive. This means that if you are going to refer to any structs/crates/modules etc… it makes things a lot easier to refer to them via their full path.

I since that someone doesn’t know about putting their impls in a:

const _: () = {
}

Also, using quote!{} instead of quote!() will make your indentation life easier.

anyhow instead of thiserror in your API is…

Otherwise, good, if very basic, write-up.

PS: How dare you post this to Reddit you Fediverse traitor 😉

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.

After testing LC3Plus, Opus, and AAC personally for bluetooth, LDAC claims are BS

How did you test Opus for bluetooth?

latency is significantly better then AAC (tested against libfdk) and marginally better then opus

In case you didn’t know, you can use 10ms (or even 5ms) frames with Opus instead of the default (20ms). 10ms should roughly match LC3plus’s default latency while still retaining high quality.

LDAC claims are completely bullshit.

LC3plus is worse than AAC quality wise (to be expected). Lower latency is the only thing going for it. And that’s just because AAC is a very high-latency codec. Opus (as a format) would win on both fronts, although there could be issues with creating a high-quality encoder for it that is not too complex, and power-efficient.

This should be de-stickied. The instance appears to be receiving zero maintenance (still on 0.17.4, enough said).

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.