You may want to lookup Freenet(Hyphanet) first.
BB_C
0…max_retries
Good thing Rust replaced ... with ..= for inclusive range syntax. Otherwise, the webshit markdown implementation used by Lemmy UI replacing .. with the … ligature would have been confusingly problematic 😉.
And this seems to be yet another case showing that federation was poorly designed, and should have been designed as pull-based (and batchable/packable), instead of endlessly spam-pushing individual messages and hoping for the best.
--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
^I^ ^don't^ ^know^ ^if^ ^someone^ ^wrote^ ^that^ ^blogpost^ ^for^ ^me^
- Use
zramso swapping doesn't immediately slow things to a crawl. - Use
cargo check, often. You don't need to always compile. - Add a
release-devprofile that inheritsrelease, use cranelift for codegen in it, and turn offlto.
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.
Only skimmed quickly.
[u8; 3]. You can create a "mapped" struct with those representations if caching them is somehow useful for the use-case. And since we're micro-optimizing memory usage,Box<str>instead ofString(for the two fields with actual string data) would be more efficient since those values are not meant to be mutable. You can then serialize to one of the many efficient binary formats around (e.g. borsh). This is not JavaScript, so you can oftentimes not be bound to JSON.