Maybe I missed it, but you don’t seem to mention anywhere sub-file sync (binary diffing) support (or presumably the lack of it), which is very important for fast syncing when files actually change!

Ask the real poster/dev in one of the lemmy.ml communities.

Fundamentally the issue is that Future is a n+m model where you have n virtual threads executing on m OS threads. As such traditional solutions to associating data to OS threads like thread locals don’t work as there’s no guarantee that a given virtual thread will continue to execute on any given OS thread.

This is fully runtime/platform dependant and not true in many cases. Not only strictly single-thread runtimes exist, but async is already used in places like the embedded world where there is no OS for there to be OS threads, single or otherwise.

It is for this reason that the extra trait bounds on the implicit impl Future return type in async functions have caused a lot of trouble (implicit Send, …etc). If for nothing else, adding context to the equation would make that situation more complex.

In any case, attaching “metadata” to T: Future data (instead of the runtime or some other global context) doesn’t make any sense in my head, as one would be "await"ing around and the concrete return type is often hidden behind that impl Future. And if the data is really special and needs to be attached to T: Future, then it’s (conceptually) just data that is a part of T, not Future.

• Rust doesn’t do implicit transparent structs. The FutureExt trait methods return a wrapper struct WithContext which is where the data (T) and the context are stored. One method takes context directly from an argument, the other clones one from a thread local. Data can’t hang in thin air to be attached to a triat. This also shows that the abstraction you (presumably) were asking about is both possible and already exists.
• Forcing a context on all T: Future types would make the abstraction non-zero-cost in any case.

It’s not about magic, it’s just not how the abstraction works.

Let’s have a concrete example, poem::web::Data utilizes opentelemetry::context::FutureExt which has the trait methods with_context() and with_current_context(). But where is the data/context actually stored? In the WithContext struct of course. Because there is no such a thing as pinning (meta)data to a trait.

@devnev@lemmy.dbzer0.com ^^

struct SomeFuture;

impl Future for SomeFuture {
  // ....
}

where are you going to “pin metadata”?

Stating the obvious: a trait is type class you implement for types. It’s not something you can “pin metadata” (or any data) to.

source traversal != backtrace

you know Future is a trait, right?

May I suggest creating blog.rustfoundation.org where such mostly useless content can be published?!

Faster compilation would be useful.

Wow, thank god someone asked around and wrote that down.

Only skimmed quickly.

• Four different hex representations for the same 3 bytes is extremely wasteful. You don’t need to store more than a [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 of String (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.
• Your parsing code looks both unrobust (potentially fragile hard-coded assumptions) and unnecessarily complex. Something much simpler can probably be done with some trivial regex usage.

You may want to lookup Freenet(Hyphanet) first.

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.

what is character?

--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.