In my experience, beginners often make the mistake of assuming just because you can do things with references and lifetimes that you should. Unless you’ve done profiling, just start with the easy thing and clone an `Arc` (or whatever other data structure helps you avoid lifetime problems)!

Also, it’s worth saying, you probably don’t need async.

oh, believe me, cloning and Arc-ing is something i realized very early that i was going to use. But that's the point: you still end up with things like : Arc<tokio::RwLock<dyn MyTrait>> for every single dependency.

Then you want to declare an async function that takes an async closure over that dependency. And you end up with a total garbage of a method signature.

As for async, the ecosystem for server-side is totally filled with async everywhere now. I don't think it's realistic to hope escaping those issues anyway in any real-world project. i thought i might as well learn to get comfortable with async.

The entire problem is that what the programmer wants to do and what the program actually does isn't always clear to the programmer.

"our compensation is not merely transparent, but uniform"

second paragraph

Is equity compensation also uniform?

No.

This is also covered in their original blog (linked from this post in the first paragraph).

"As for how equity is determined, it really deserves its own in-depth treatment, but in short, equity compensates for risk – and in a startup, risk reduces over time: the first employee takes much more risk than the hundredth."

The dependency injection framework provided by Bevy also particularly elides a lot of the problems with borrow checking that users might run into and encourages writing data oriented code that generally is favorable to borrow checking anyway.

This is a valid point. I've played a little with Bevy and liked it. I have also not written a triple-A game in Rust, with any engine, but I'm extrapolating the mess that might show up once you have to start using lots of other libraries; Bevy isn't really a batteries-included engine so this probably becomes necessary. Doubly so if e.g. you generate bindings to the C++ physics library you've already licensed and work with.

These are all solvable problems, but in reality, it's very hard to write a good business case for being the one to solve them. Most of the cost accrues to you and most of the benefit to the commons. Unless a corporate actor decides to write a major new engine in Rust or use Bevy as the base for the same, or unless a whole lot of indie devs and part-time hackers arduously work all this out, it's not worth the trouble if you're approaching it from the perspective of a studio with severe limitations on both funding and time.

Thankfully my studio has given me time to be able to submit a lot of upstream code to Bevy. I do agree that there's a bootstrapping problem here and I'm glad that I'm in a situation where I can help out. I'm not the only one; there are a handful of startups and small studios that are doing the same.

Isn't the persistent failure of developers to "know" that their code is correct the entire point? Unless you have mechanical proof, in the aggregate and working on any project of non-trivial size "knowing" is really just "assuming." This isn't academic or pedantic, it's a basic epistemological claim with regard to what writing software actually looks like in practice. You, in fact, do not know, and your insistence that you do is precisely the reason that you are at greater risk of creating memory safety vulnerabilities.

A left pad incident isn't possible on crates.io. Yanking a package from the registry doesn't remove the code if you have an existing lockfile.

left-pad is symbolic of dependency and supply chain issues generally. If all you took away from that incident is that there's risk only from someone unpublishing the module then you probably need to go back and think about it some more.

I think it'd be more productive to say that instead, since it's strictly more correct than comparing it to left-pad.

(An interesting thing to consider: the worst "supply-chain" type attack in recent memory is probably xz, which has a much more traditional maintenance, development, and distribution model than the median Rust package does. I don't think Rust's ecosystem is even remotely immune to the risk of malicious packages, but I imagine the kinds of dependencies that exist in the current coreutils are much more appealing to a high-sophistication attacker because of their relative lack of publicity/transparency.)

Why would I take anything away beyond the specific scope of the vulnerability to supply chain issues that NPM had? Cargo offers a variety of tools for auditing and managing dependencies that specifically mitigate supply chain issues. If your only suggestion is to not use dependencies at all, that's an extreme opinion.

Don't chide people for failing to read your mind. If you wanted people to take that away, you should've said that. Using a specific example as a metonym for a larger phenomenon is a poor choice in terms of clarity. Of course people responded to the specific example.

The important note here is that you can't rely on Drop running in order to satisfy the SAFETY comment of an unsafe block. In practice, in safe Rust, this knowledge shouldn't really change how you write your code.

> without risk factors like obesity

40% of Americans are obese.

42% after the holidays :)

That's not entirely true. There's a thread pool of workers underneath libuv. Tasks that would block do indeed execute concurrently.

Oh, I know. But the code used in this test doesn’t utilize that thread pool at all. It just uses setTimeout.

The functional interface changes are huge. Clojure is always at its best when staying close to Java via judicious use of interop and this solves one of the major missing links.