scudo has been the default allocator for Android since Android 11, and we are hoping to make it mandatory for the few remaining places that don't use it. Using an allocator without memory protections in 2026 (especially after we have closed nearly all known performance gaps with jemalloc) is really not a great choice.

Gah! Typo there. It's over 50% (66.8%) in 2 months. And over 80% in 4 months. The chart is correct, not the text :facepalm:

I'll see about whether I can push an update. Thanks for the catch!

Actually, it's complicated stuff pulling together two data points: 1) 2/3 of people are confident contributing in 2 months or less 2) And 50% of people are AS PRODUCTIVE IN RUST as they were in their other language within four months

Given that #2 is talking about people who are all professional programmers and where only a small percentage of respondents previously knew Rust, that's pretty amazing to me.

Thanks for all of your work (in addition to that of others) - it really shows! We do encourage people to create minimal repro cases and open bugs whenever possible. And, even more ideally, to consider contributing a PR upstream...

That's exactly right. Today, the focus is on making it possible to use Rust to write pieces of the Android platform itself.

Certainly, there are some _apps_ on Android today that use Rust (shout-out to my Firefox friends!), but that's not something I'm investing in right now.

If you haven't seen, I'd highly recommend checking out what we did for IEEE VR: https://blairmacintyre.me/2020/04/02/completely-online-ieee-...

and in particular some of the notes on poster sessions: https://blairmacintyre.me/2020/04/10/doing-a-poster-session-...

In practice, people consumed the keynote/talk content in a variety of formats (streamed, recorded, and in-VR) and there was a fantastic networking and meeting-new-people effect in the poster, hallway (post-talk), and demo sessions. There's a bunch of formal research that was done there along with post-conference surveys to track down specific data (e.g., how many new people did you meet?) but it will take some time for those teams to rigorously collect & report.

Hi! As we mentioned in the recent Quest release blog post, https://blog.mozvr.com/firefox-reality-for-oculus-quest/, we have some designs for multi-window support and synchronization of content between platforms. We're still working on options around tabs / additional content beyond the number of windows you have open, alongside our really awesome Seattle-based design partners, Podipo: http://podipo.com/

Once we have some concrete designs, we'll have issues open and on our public roadmap for comment and we often have early builds available in our releases page for sideloading if people are interested in testing and giving feedback.

Thanks! We also find that a lot of our users really like watching 360 or even 2D videos, taking advantage of the ability to resize the screen to get their own personal theater.

Right now, we only have Firefox Reality available for standalone VR headsets, but we're bringing the experience to desktop VR and a variety of standalone AR headsets in the second half of this year.

Unfortunately, we don't currently support phone-based Daydream or Gear VR devices. There's both a bunch of extra work to support all of the phone in/out/notification lifecycle scenarios and we have a pretty small engineering team and the long tail of phone/chipset-specific bugs is pretty substantial. We might evaluate support for it or Cardboard in the future, but for right now we're mainly focused on standalone headsets.

That said, we're all in favor of people who want to sideload and play with it! https://github.com/MozillaReality/FirefoxReality/wiki/Sidelo...

Thanks! We don't currently have a build of Firefox Reality available for desktop devices, but that work is currently underway. We announced it as part of our deal with HTC and are excited to show it off soon: https://blog.mozilla.org/blog/2019/01/08/mozilla-announces-d...

If you're interested in this topic, I'd highly recommend watching Stephanie Balzer's sessions at the Oregon Programming Language Summer School on “Session-Typed Concurrent Programming”. The lectures are available online (https://www.cs.uoregon.edu/research/summerschool/summer18/to...).

Her recent work (sponsored, in part, by Mozilla Research) really advances session types and the ability to get termination/progress guarantees: http://www.cs.cmu.edu/~balzers/publications/manifest_deadloc...

In what sense does this work really advance session types? Prima facie it looks like yet another tiny delta on Honda's original work that cannot and does not get around session types' core problem of data-dependent communication topology. Let me quote from the paper (Page 22, Section 6):

"The typing discipline presented in the previous sections, while rich enough to account for a wide range of interesting programs, cannot type programs that spawn a statically undetermined number of shared sessions that are then to be used."

That has been the problem of this approach to typing message passing for nearly 3 decades, and like all predecessor papers in this theory tradition, an ad-hoc approach is proposed that makes core session types incredibly complicated without solving the problem. In order to get a publication out of this, a different problem is solved, a yet another Curry-Howard corresponce for some small delta of Linear Logic is given.