BB_C

--no-default-features --features=foo,bar is fine. The harmful part is replacing established crates with smaller ones solely because of ze size.

And the whole dance doesn't even do what many people think it does, as covered in some comments in that linked old thread.

Note that I made that jerk thread when min-dependency-ing was sort of trending. A trend that was often (not always) as stupid and counter-productive as the other related(-ish) trend min-binary-sizing.

Also note that the harmfulness of that trend went beyond bad ecosystem dynamics and dependants ending up with less quality/reliability. That semi-obsession also encouraged bad coding practices like pervasive use of dyn where it's not needed. Compromising idiomaticity, and removing zero-cost abstractions to win a faster compiling dependency prize!

I will stop here, because I really don't want to write that blog post.

Nah. There was space for simple (in a good way) native (no VM) GC languages to set between scripted (python) and VM(-first) languages (java) on one side, and no-GC languages on the other. Not doing OOP and not doing exceptions were good decisions as a starting point. But the problem is that this was based on following C (instead of C++) and nothing else, making no use of decades of programming language research and development*. And it's the (un)design that followed that ended up creating a horrible simple (in a bad way) language. And this google-branded language hogged that space where other better languages could have been developed, or those which got developed could have flourished more and gained more momentum. And the corporate marketing actually tried to sell every bad design aspect as a "akshually a feature". For example, lack of generics was celebrated for years as great simplicity, until an almost deliberately bad implementation of generics got added later as you mentioned.

tl;dr: The surface premise of the language was good and arguably needed at the time. What got delivered was bad.

* An observant historian would point out here that some good (arguably better even) languages predate C itself (e.g. the ML family).

Go is not even good. It's horribly designed (or rather, un-designed, since its creators actually boasted about deliberately doing the core part in what? a couple of weeks IIRC). If it wasn't for the associated corporate brand, it would have been a dead meme in the eyes of everyone by 2015 when Rust hit v1.0 (It was born a meme in the eyes of those who know).

And I mentioned that date to point out that we can't call these languages new forever 😉 . In fact, if you took a snapshot of street tech talk from 10 years ago, you would see that these generic conventional unwisdom comparisons have been done to death already. Which then begs the question: what newfound "wisdom" needed to be added to these "muh best tool for the job" talking points? Or are we just testing the wisdom of our new best tool for all jobs, LLMs?

trimming down your dependencies

is considered harmful.

^I^ ^don't^ ^know^ ^if^ ^someone^ ^wrote^ ^that^ ^blogpost^ ^for^ ^me^

• Use zram so swapping doesn't immediately slow things to a crawl.
• Use cargo check, often. You don't need to always compile.
• Add a release-dev profile that inherits release, use cranelift for codegen in it, and turn off lto.

Otherwise, it would be useful to know what kind of system you're running, and how is the system load without any rust dev involvement. It would also be helpful to provide specifics. Your descriptions are very generic and could be entirely constructed from rust memes.

The majority of actual rustaceans don't care about these polls (or any "official community" activity for that matter).

If you want actually relevant (and objective) stats, look here.

Were those nonsensical Difference percentages obtained via an existence that claims intelligence by any chance?

One can use custom viewers via core.pager and interactive.diffFilter in git configuration, not to mention defining custom difftools directly.

I primarily use delta for this (sometimes packaged as git-delta), which itself is implemented in Rust too.

For example, save this as a script called delta-s somewhere in $PATH:

#!/bin/bash

delta -s \
  --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 $@

Then, in ~/.gitconfig, add

[difftool "d-sbs"]
  cmd = diff -u $LOCAL $REMOTE | delta-s

And the you can just

git difftool --tool d-sbs HEAD~

You can further create an alias for that too of course.

Didn't read the whole thing because I had to stop at the right column at the start.

Federated is "decentralized". The correct word the author is looking for is "distributed". And even then, direct exclusive P2P is only one form of "distributed". Hybrid/Multiple approaches are also wide-spread (torrents anyone!).

Not sure how a technical writer gets such a basic aspect wrong.

Also, beyond the closed source aspect, and being a closed up platform in general, Discord was always literal spyware. And pretending like open-source projects who chose to use it didn't know what they were doing, and glossing over the actions that ranged from collective nagging to almost literal fights in some communities because of such choices, reeks of willful blindness.

It's laughable before you even get to the code. You know, doing "eval bad" when all the build scripts are written in bash 🤣

There is also no protection for VCS sources (assuming no revision hash is specified) in makepkg (no "locking" with content hash stored). So, if an AUR package maintainer is malicious, they can push whatever they want from the source side. They actually can do that in any case obviously. But with VCS sources, they can do it at any moment transparently. In other words, your primary concern should be knowing the sources are coming from a trustable upstream (and hoping no xz-like fiasco is taking place). Checking if the PLGBUILD/install files are not fishy is the easier part (and should be done by a human). And if you're using AUR packages to the extent where this is somehow a daunting time-consuming task, then there is something wrong with you in any case.

Edit: That is not to say the author of the tool wouldn't just fit right in with security theater crowd. Hell, some of them even created whole businesses using not too dissimilar theater components.

@kadu@scribe.disroot.org

So try_from(&**p) is not a code smell/poor form in Rust?

No. It's how you (explicitly) go from ref to deref.

Here:

• p is &PathBuf
• *p is PathBuf
• **p is Path (Deref)
• And &**p is &Path.

Since what you started with is a reference to a non-Copy value, you can't do anything that would use/move *p or **p. Furthermore, Path is an unsized type (just like str and [T]), so you need to reference it (or Box it) in any case.

Another way to do this is:

let p: &Path = p.as_ref();

Some APIs use AsRef in signatures to allow passing references of different types directly (e.g. File::open()), but that doesn't apply here.

Cool.

Is it all in rust-mail repo?

And how much of "Rust" in this image is actually open?