I will let you expand on this before responding to both:

And also, cargo.toml has inconsistencies and double-standards.

Not cargo per se, but even the tutorial for a cli-tool is like “setup clap, which has 20 dependencies and a kitchen sink”. The whole (cargo-centric) ecosystem is much like Node, with the same problems.

cargo new with-clap
cd with-clap
cargo add clap --no-default-features

% cargo tree
with-clap v0.1.0 (/tmp/with-clap)
└── clap v4.6.0
    └── clap_builder v4.6.0
        ├── anstyle v1.0.14
        └── clap_lex v1.1.0

And also, cargo.toml has inconsistencies and double-standards.

Can you expand on that?

Why do you think cargo is a problem?

Not sure how are you and @[email protected] coming up with these concerns.

The only correct way to package such software is to vendor dependencies (packaged together or separately). And you can trivially change the sonames of vendored deps in your build scripts so that there are no conflicts whatsoever (I dual-package some stuff against an upstream and a fork and do just that). So dynamic vs. static is not the crux of the issue. The primary concerns are that distributors hate vendoring, irrespective of whether the vendored libs are linked in statically or dynamically. Distributors also hate potentially diverging forks maintained by random downstreams, which is what “patched dependencies” effectively are.

There is always room for some leeway of course, but that would depend on how relevant your software is, and/or whether a maintainer would want to take that burden on.

And finally, sometimes, such dependencies may provide added value that trumps all these concerns. So judging these things is always situational.

Then you could be forced to vendor everything. And if it’s open-source and relevant for distros to pickup, then you will need to find out if distros would be willing to take your library with its vendored libs (or package them separately just for your library)…etc.

And you may need to figure out if there are bus factor concerns with your direct dependency, since such libraries are not necessarily maintenance free, even from a mere compiling/building stand point (what if a patched indirect dependency no longer builds with new compilers…etc).

This would depend on the language/ecosystem. It’s worse for C and C++ than for example Rust because of packaging policies and ease of distributability.

I didn’t read your post. But note that ? depends on traits /type classes with associated types (Try, FromResidual, and From), and is often implemented for sum types (e.g. Result, Option) with at least two variants containing Output and Residual type values.

The FromResidual part does value conversion for the Residual, which is how you e.g. get auto-converted error values matching the return Result value. These converted error values are often themselves contained in variants in an enum/sum Error type.

So neither an actual equivalent in C++ is possible, due to type system limitations/differences, nor whatever you tried to do is an apples-to-apples match, or even represents two fruits from the same basket.

how many real-world attacks happened since the XZ fiasco outside of the webshit ecosystem?

Off-topic: The switching between light background for text and dark background for code is stupid and annoying. Either use dark for both, or light for both (so I can apply my custom inverse shader without hurting my eyes or breaking the reading flow). This back and forth switching is almost as stupid as using a background color with middle lightness, which I’ve also seen.

This has been irking me for a while, so I decided to randomly whine about it now.

As for the blog content. It’s a weird collection of clippy bugs which covers basically the first half of the blog, then a couple of miri bugs and limitations. Then it finally gets to actual rust compiler stuff which just involves cfg_select (a nice to have) and c_variadic support (ffi use-case). So, IMHO, that title is a bit over the top, and it almost does a disservice to a lot of actual good and interesting work that is being done.

(I guess zsh, dash and probably oil?)

zsh doesn’t even share var eval syntax with bash (${(P)foo} vs. ${!foo})

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.

@[email protected] ^^

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.