It's a string in a well specified string format. That's typically what you want for serialization.

Temporal is typed; but its serialization helpers aren't, because there's no single way to talk about types across serialization. That's functionality a serialization library may choose to provide, but can't really be designed into the language.

E.g. in a game you can force collection to run between frames, potentially even picking which frames it runs on based on how much time you have. I don't know if that's a good strategy, but it's an example of the type of thing you can do.

It's useful to have when you have complex graph structures. Or when implementing language runtimes. I've written a bit about these types of use cases in https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe...

And there's a huge benefit in being able to narrowly use a GC. GCs can be useful in gamedev, but it's a terrible tradeoff to need to use a GC'd language to get them, because then everything is GCd. library-level GC lets you GC the handful of things that need to be GCd, while the bulk of your program uses normal, efficient memory management.

Also, Diplomat supports traits and callbacks so you could actually make the timezone impl pluggable. Though we don't currently have JS support for that.

But also tz info isn't that big I think...

Most of the graphs here are about new code.

[1]: https://security.googleblog.com/2021/04/rust-in-android-plat...

GATs allow traits to abstract over associated types that are themselves to some degree abstract. In this case, it's necessary to do the relevant trait machinery around lifetime transformation since we need to be able to talk about "a replaceable lifetime of a type" in a generic way.

The bugs in part 1 all around using higher ranked trait bounds. I'd disagree with the characterization that they're "feature requests": five years ago, yes, I would agree, but this entire area of the compiler needs to be bug-free for an upcoming feature (GATs) anyway, and indeed, the issues I found were often fixed by people working on fixing related GAT bugs. Ultimately, my use of higher ranked trait bounds is an attempt to emulate some of what GATs get you in stable Rust, so it's not surprising that the bugs are in the same area of the code.

This has been the case at both my current and previous (American tech) jobs.

And it's pretty racist to assume that a person is working or has worked in India just because they have an Indian name.

The "Linux" there is more of an indicator of its origins than its purpose.

The VR focus was because it was a good way to get servo out to end users early without needing to be fully web compat -- WebXR doesn't require complex layout. We didn't drop our focus on full web compat during this, but full web compat has always been a more long term goal given how complex the web platform is.

The important thing is that gravitation is a distortion in space-_time_, which is way trickier to model as a rubber sheet because you end up with one dimension of space and one of time. If you distort _those_ (also, they don't distort quite like a ball-in-a-rubber-sheet), you can get the results of a ball being thrown up. It's also possible to visualize this for 2 spatial dimensions with a distorted 3d space, but tricky.

However, Rust lifetimes are stretchy-squeezy, and a free lifetime is basically the same as 'static when it comes to covariant lifetimes, since both are "I can be whatever you want me to be".

However if the lifetime is invariant (e.g. in https://play.rust-lang.org/?version=stable&mode=debug&editio...), it is actually not 'static and will map to whatever lifetime is requested by the context.

(Rust does maintain a fork of LLVM, but it's just a couple minor patches that typically get upstreamed eventually)

The blog post was drafted by the core and foundation team, however we did get sign-off from Mozilla on it.

Mozilla currently owns the trademarks that the Rust foundation plans to take ownership of, so they have to be involved to some extent. They have agreed to transfer it as mentioned in the blog post, and are going to work with us to make that happen.

The Rust project as an open source project with open governance has been pretty independent of Mozilla for quite a while now. However, Mozilla did provide some crucial services including trademark ownership, which is _extremely_ relevant to the discussion of forming a foundation.

Trademark ownership and is rarely impactful to the day-to-day workings of the Rust project, which is why I consider these irrelevant to whether or not Rust is still being "incubated" by Mozilla.

Make no mistake, Mozilla has contributed a lot to the Rust project, but the particular stage of maturity you mention was achieved some years ago :)