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.

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 😉

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.

Don’t know if this will be relevant at all, but I’m almost hoping this will force Lemmy devs to abandon the obscure markdown crate they use for pulldown-cmark.

Using an obscure markdown implementation just because it supports spoiler tags always sounded like a silly decision to me!