I was thinking the same thing when I was trying to use the new base64 code instead of the deprecated version: it's unnecessarily complicated. I remember thinking "why is this so hard, so convoluted?".

@canismajoris I wanted to learn rust, but I'm all set for toxic communities, so ...

Here is an alternative Piped link(s):

https://piped.video/sfFQrhajs6o?si=uQOMf7-pwKx6w6pu

Piped is a privacy-respecting open-source alternative frontend to YouTube.

I'm open-source; check me out at GitHub.

I disagree. Async Rust is fine, but it does have some baggage, not least of which is Pin/Unpin which I still don't fully understand. But that aside, I prefer writing async Rust to any other language because the rest of Rust comes along for the ride!

It's actually amazing that I can use the same mental model for async code on a small MCU or a large server.

Is Arc really the worst GC? Doesn't Swift use reference counting also? I did a few minutes of searching but couldn't really find any benchmarks comparing Arc with Swift RC or some other GC.

I feel that async Rust is a good set of tradeoffs that allows it to scale to a lot more than just writing web servers. Rust seems to be pretty good for web servers too though.

(Reposting my comment here from the lemmy crosspost)

Just pointing out that the pawb.social people are/were also planning on forking Lemmy for similar reasons: https://pawb.social/post/147036 . Not entirely sure how much work has gone into it, but might be worth syncing up with them. Although I'm not sure if it's the "right" thing to do to fork just for ideological reasons, especially since the main lemmy.ml instance seems to be fairly neutral.

I've been thinking about how a single "community" could exist across multiple instances, especially given that the landscape right now is that communities are basically:

• Undiscoverable.
• Hosted on lemmy.world, which is a problem in case something happens to it.
• Hosted on lemmy.ml, which is a problem given that the community can be a bit trigger happy with defederation.

Communities following others seems an elegant solution, honestly. Although, I would say that moderators should be able to remove posts of communities they follow, just in case.

However, something stuck out to me when reading the design discussion:

Users who post to a community that follows other communities are offered the choice of whether to post directly to the community they're following, or to one of the communities that are followed by that community. They need not post multiple times, because posting to a more 'upstream' community would cause it to be seen by users of that community as well.

Why not? The lemmy web client at least does a good job at de-duplicating crossposts, and the client used for posting could give you a bullet list of communities you want to send it to. Imagine instances a, b and c where a defederates c, but a also has the largest community for bespoke hatwear or whatever. If you (who is on none of those instances) send your post to just a (because it's the largest), then your content will be unavailable to c. But if you post to both a and c, you reach both communities.

Another thing that confused me while trying to wrap my head around things is this diagram, which I don't think covers a common case:

If a user on b makes a post 1 to the community on c... What happens?

Option 1:

• funny@c boosts post 1 as message 2.
• funny@b is sent 2 and boosts post 1 as message 3.
• user2@a can see 1 through message 3 because it is posted on b, which they federate with.

Option 2:

• funny@c boosts post 1 as message 2.
• funny@b is sent 2 and boosts post 2 as message 3.
• user2@a cannot see 2 through message 3 because 2 is on c which they do not federate with.

I already commented this on programming.dev, but I would like to be able to use rust's domain in the fediverse. ex. [email protected].

It could provide as a method for better identity verification across the fediverse. I also think it just makes sense for rust's governance to control a fediverse instance, as they're more knowledgeable to the content that is posted. As an example, it doesn't make sense for a movies forum to host a community for surgeons. While programming.dev is relevant to programmers, it might be beneficial for rust's governance to be able expand communities on the instance for rust in the future.

Is anyvec crate of relevance?

The more I think about it, the more I'm convinced the immutable slice version is safe. I'm pretty sure the mutable version in the playground is also safe because you can't turn it into a mutable reference without consuming it and it requires a mutable reference to build.

The mutable version is pretty inconvenient to actually use if you want to store the AnySliceMut and pass it to other functions. The other function would have to reconstruct it and pass it back once it was done with the mutable reference. But what if:

 undefined

    
// ^ impl AnySliceMut
    pub unsafe fn as_slice_mut(&mut self) -> Option<&'a mut [T]> {
        if TypeId::of::() != self.tid {
            return None;
        }
        Some(unsafe { std::slice::from_raw_parts_mut(self.ptr as *mut T, self.len) })
    }

  

Obviously it's possible to abuse but if I just do something like pass it to a function that takes a mut ref and that function doesn't do anything weird like save the reference is this okay? MIRI is apparently okay with it: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=149ad441a1c66b3f1fd7f2107acbeccf

Neat! And for anyone not familiar Lib.rs is a package repository, described as an alternative [frontend] to Crates.io.

Previous years:

• 2021
• 2020
• 2019

I continue to be a little disappointed how brief these have become since 2019, given how exhaustive the questions are.

I prefer data as is rather than having to double guess every search result

What's the bad scenario you're worried about here? What type of data you're specifically worried about? Do you expect me to maliciously manipulate the data, or is even well-intentioned curation and use of heuristics somehow not acceptable?

My view on data cleanup is probably very different than other people's, because I've spent a lot (likely too much) time with the crates' data. The pure unadulterated source data is… bad. It's very sparse (most crates don't fill it in). It's full of outdated information (set once and forgotten, wrong for forks). Some crates-io category slugs are pretty misleading, so tons of crates are miscategorized by their own authors: parsing is not for file parsers, database is not for databases. accessibility …I can't even. Who put ogg parsers, gRPC, garrysmod, RFID readers in there?

There are tons of name-squatted crates, ferris guessing games, or just people's baby steps in Rust. If you search on crates.io you often get the pure data of someone publishing a crate years ago and forgetting about it. This is pure, this is ranked objectively, this is curated and subjective.

crates-io shows you plainly only the license of the crate you're looking at. lib.rs goes further and checks if the crate has any dependencies which are GPL, because if a crate says it's MIT but has GPL deps, it actually is GPL.

crates-io shows you repository URL exactly as-is specified in the metadata, which could be inaccurate (in case of forks) or outright fake (someone else's repo). lib.rs checks if the repository URL actually contains the crate or has the same owner as the crate, and will add a link to the true source code if the repo url is suspicious.

crates-io shows owners' names from the free-form name field, so somebody malicious could pretend to be a well-known trusted user. lib.rs only allows display names for established/reputable accounts, and uses login name for new/untrusted accounts.

Ah, I didn't recognize the username. My previous comments were on mobile, so I didn't have both pages open to draw the comparison. Now, I'm not looking to contribute toward giving you more grief than you've already gotten, I'm basically just expressing an opinion on the situation and that's about it. So I'll justify my opinion a little, but leave it at that.

I would agree that originally, asking him how you should phrase the notice was a good gesture. He suggests "'This user requested their work be removed from this web site.' And then link it to this issue?"

Then you respond and recommend "BurntSushi disagrees with sneering at cryptocurrencies, and in protest asked his crates to be removed." in which, while he did say something to that effect, and that is related to the reason, you asked him what he wanted and then completely disregarded his wish to recommend a more snarky message.

BurntSushi actually responds and gives an okay to a more accurate version of what he said.

Then you respond with "[...] so I plan to develop "making a stance for cryptocurrencies" dedicated feature and move both of you there. [...]"

And I read the first portion of how BurntSushi responded to that, and stopped at about that point because the whole thing seemed asinine. It would appear to me that you made him out to be the party in the wrong throughout the entire exchange to that point because he didn't want to take part in your site.

I was going to say it's a shame, and in a way, I guess it kind of still is. But then I saw the gitlabb issue where the creator treated burntsushi like crap for wanting his packages removed. That makes me feel less bad about it.

@manpacket I hate if open source devs do this kind of thing.

It's not exactly what you are looking for, but you could check emacs-ng. It tries to replace some of emacs' internals with rust and expand the possible scripting lenguajes that can be used with it.

It's weird how much difference a year makes in the Rust world. I had some initial pushback in this PR from 11 months ago, which only expanded the scope of recommendation for tracking Cargo.lock a little.

This is not how the resolver works. A comment from the GitHub thread explains it well:

Cargo.lock is not active when you simply use some software, for libraries used as a dependency it's completely ignored, for applications installed via cargo install it's ignored by default but can be enabled with cargo install --locked. Only when you are building from within the source tree is it active (e.g. via cloning the repo, or manually downloading and extracting the archive).

One of the founders of Ferrous Systems has answered some questions about it on Hacker News. See here and here.

The spec they created for the certification process is open source. There is some "tiny" amount of the patches that aren't public but it sounds like it is essentially a recent stable release of Rust because the other major changes have been contributed upstream. It's not clear if they definitely plan to eventually release the rest of thier changes as open source or not but they will consider it.

Here is an alternative Piped link(s): https://piped.video/watch?v=SqT5YglW3qU

Piped is a privacy-respecting open-source alternative frontend to YouTube.

I'm open-source, check me out at GitHub.

async is broken. Some basic examples:

1. a "something 3 levels deep in your dependency tree is not Send error when trying to do something like tokio::spawn for

   <reasons>

2. tokio is quite bloaty, but also consider hiding sync behind async such as postgres (which started as pure sync crate) now just doing a block_on behind the scenes and forcing tokio on people that don't even want async
3. combining IO wait tasks with CPU busy-wait tasks can be quite tricky. tokio::task::spawn_blocking works but you are forced to do it at the lowest granularity level
4. closures vs async vs async closures, nuff said
5. async traits vs sync traits
6. sync vs async code duplication

I could go on. Just like some commenters on the HN thread, I think removing async and forcing nice library abstractions on top of epoll/kqueue/io_uring would be a better way to go about this.

I've been there when C10k became a thing, I coded a Free Pascal networking non-blocking library lNet and added epoll and kqueue support to free pascal for that purpose. I understand non-blocking and IO wait issues, and I think async is wrong.