I get the sense that you might appreciate golang.

See: https://blog.system76.com/post/cosmic-team-interview-byoux

We considered toolkits like GTK, Flutter, and QT, and though the team was already experienced working with GTK for Pop!_OS, eventually landed on the Rust-based toolkit, Iced.

https://iced.rs/

I’ve read that. Defining a supplier as someone with whom you have a direct business relationship with seems intentionally narrow in an unhelpful way that just further muddies the waters around the issue at hand. Making something generally available to others means that you’re supplying others with that thing. While it’s true that you may have no further obligations to those that receive your software, the person receiving the software needs to evaluate their risks around using and depending on that software regardless of the existence of a business relationship with the supplier. Hence supply chain risk evaluation is always necessary. That risk evaluation, or lack thereof, can result in a security problem. These problems can propagate widely within a software ecosystem. This is true with and without the existence of direct business relationships between suppliers and recipients of software.

The whole article can be summarized by saying if you want support services related to the software written by others, negotiate a support agreement related to that software. That has nothing to do with taking a wide or narrow interpretation of the word supplier.

Developers should think about what libraries they trust, but it seems that most of the time they’ll choose whatever is most convenient for handling the immediate problems they’re working to solve.

I’ve been comparing crates on crates.io against their upstream repositories in an effect to detect (and, ultimately, help prevent) supply chain attacks like the xz backdoor1, where the code published in a package doesn’t match the code in its repository.

The results of these comparisons for the most popular 9992 crates by download count are now available. These come with a bunch of caveats that I’ll get into below, but I hope it’s a useful starting point for discussing code provenance in the Rust ecosystem.

No evidence of malicious activity was detected as part of this work, and approximately 83% of the current versions of these popular crates match their upstream repositories exactly.

Scanner? Like a crawler? Or a more passive logging of activity on a node?

You’re just reinforcing the wall between you and your time with rust.

I simply blocked it. I also blocked it on communities I moderate. It gives bad instructions for many situations. A non-preachy threadiverse link bot would be infinitely more useful.

LOL no

There’s are pinned messages on https://threadiverse.link/c/learningrustandlemmy@lemmy.ml with details of both schedules.

You’ll have to confirm with @Jayjader@jlai.lu, but I believe that your expectations are in line with their plan.

I linked to free resources so you wouldn’t have to buy the book, but I also bought a physical copy as I find it easier to regularly read a physical copy.

Have fun!

Which IDE do you use?

Fair

Getting hung up on the difference between a mirror and a relay is moot. I don’t see how people would be more accepting of that. In fact it seems like more people would object to having their posts mirrored to reddit considering the reason many are here is to stop participating on Reddit.

And it doesn’t eliminate the initial problem which is that the posts will be considered spam by the largest instances.

So you could not care and do it yourself, but I suspect that it will result in the same reduction in community engagement as the prior attempt.

There’s an entire instance that implimented your proposal that was quickly blocked by the largest instances. They were considered spam. It resulted in the opposite of growing community engagement.

You’re talking about adding uncurated noise to the mix. I have a lot of RSS feeds that I browse through, but most of the posts I won’t share because they are just noise.

I don’t think that would be allowed on Programming.dev or Reddit.com

After you read The Rust Programming Language book, read The Rustonomicon book, then What every programmer should know about memory by Ulrich Drepper, then this Stack Overflow comment about what has changed since 2007.

You won’t need to read all of this to be productive, but the more you read the better your understanding will be which should make you more productive.

@sorrybookbroke@sh.itjust.works Would be the best person to answer that question.

A new post will be made with more details to the book club community once they are finalized. Please subscribe.

Current plan is for Tuesdays at 6:30pm EST

Subscribe to the community for updates.

The original post has more discussion.