12 Feb 2026

feedPlanet Mozilla

Hacks.Mozilla.Org: Launching Interop 2026

The Interop Project is a cross-browser initiative to improve web compatibility in areas that offer the most benefit to both users and developers.

The group, including Apple, Google, Igalia, Microsoft, and Mozilla, takes proposals of features that are well defined in a sufficiently stable web standard, and have good test suite coverage. Then, we come up with a subset of those proposals that balances web developer priorities (via surveys and bug reports) with our collective resources.

We focus on features that are well-represented in Web Platform Tests as the pass-rate is how we measure progress, which you can track on the Interop dashboard.

Once we have an agreed set of focus areas, we use those tests to track progress in each browser throughout the year. And after that, we do it all again!

But, before we talk about 2026, let's take a look back at Interop 2025…

Interop 2025

Interop dashboard showing browser scores. At the top are two large circles: ‘Interop’ with a score of 95 in green, and ‘Investigations’ with a score of 36 in orange. Below are four browser scores in green circles: Chrome 99, Edge 98, Firefox 99, and Safari 98, each shown with their respective browser icons.

Firefox started Interop 2025 with a score of 46, so we're really proud to finish the cycle on 99. But the number that really matters is the overall Interop score, which is a combined score for all four browsers - and the higher this number is, the fewer developer hours are lost to frustrating browser differences.

The overall Interop score started at 25, and it's now 95. As a result, huge web platform features became available cross-browser, such as Same-Document View Transitions, CSS Anchor Positioning, the Navigation API, CSS @scope, and the URLPattern API.

That's the headline-grabbing part, but in my experience, it's way more frustrating when a feature is claimed to be supported, but doesn't work as expected. That's why Interop 2025 also focused on improving the reliability of existing features like WebRTC, CSS Flexbox, CSS Grid, Pointer Events, CSS backdrop-filter, and more.

But it's not just about passing tests

With some focus areas, in particular CSS Anchor Positioning and the Navigation API, we noticed that it was possible to achieve a good score on the tests while having inconsistent behavior compared to other browsers.

In some cases this was due to missing tests, but in some cases the tests contradicted the spec. This usually happens when tests are written against a particular implementation, rather than the specified behavior.

I experienced this personally before I joined Mozilla - I tried to use CSS Anchor Positioning back when it was only shipping in Chrome and Safari, and even with simple use-cases, the results were wildly inconsistent.

Although it caused delays in these features landing in Firefox, we spent time highlighting these problems by filing issues against the relevant specs, and ensured they got priority in their working groups. As a result, specs became less ambiguous, tests were improved, and browser behavior became more reliable for developers.

Okay, that's enough looking at the past. Let's move on to…

Interop 2026

Over 150 proposals were submitted for Interop 2026. We looked through developer feedback, on the issues themselves, and developer surveys like The State of HTML and The State of CSS. As an experiment for 2026, we at Mozilla also invited developers to stack-rank the proposals, the results of which we used in combination with the other data to compare developer preferences between individual features - this is something we want to expand on in the future.

After carefully examining all the proposals, the Interop group has agreed on 20 focus areas (formed of 33 proposals) and 4 investigation areas. See the Interop repository for the full list, but here are the highlights:

New features

As with 2025, part of the effort is about bringing new features to all browser engines.

Cross-document View Transitions allow transitions to work across documents, without any JavaScript. The sub-features rel="expect" and blocking="render" are included in this focus area..

Scroll-driven animations allow you to drive animations based on the user's scroll position. This replaces heavy JavaScript solutions that run on the main thread.

WebTransport provides a low-level API over HTTP/3, allowing for multiple unidirectional streams, and optional out-of-order delivery. This is a modern alternative to WebSockets.

CSS container style queries allow you to apply a block of styles depending on the computed values of custom properties on the nearest container. This means, for example, you can have a simple --theme property that impacts a range of other properties.

JavaScript Promise Integration for Wasm allows WebAssembly to asynchronously 'suspend', waiting on the result of an external promise. This simplifies the compilation of languages like C/C++ which expect APIs to run synchronously.

CSS attr() has been supported across browsers for over 15 years, but only for pseudo-element content. For Interop 2026, we're focusing on more recent changes that allow attribute values to be used in most CSS values (with URLs being an exception).

CSS custom highlights let you register a bunch of DOM ranges as a named highlight, which you can style via the ::highlight(name) pseudo-element. The styling is limited, but it means these ranges can span between elements, don't impact layout, and don't disrupt things like text selection.

Scoped Custom Element Registries allow different parts of your DOM tree (such as a shadow root) to use a different set of custom elements definitions, meaning the same tag name can refer to different custom elements depending on where they are in the DOM.

CSS shape() is a reimagining of path() that, rather than using SVG path syntax, uses a CSS syntax, allowing for mixed units and calc(). In practice, this makes it much easier to design responsive clip-paths and offset-paths.

And more, including CSS contrast-color, accent-color, dialog closedby, popover="hint", fetch upload streams, IDB getAllRecords(), media pseudo-classes such as :playing, and the Navigation API's precommitHandler.

Existing feature reliability improvements

Like in previous years, the backbone of Interop is in improving the reliability of existing features, removing frustrations for web developers.

In 2026, we'll be focusing these efforts on particular edge cases in:

Some of these are carried over from 2025 focus areas, as shortcomings in the tests and specs were fixed, but too late to be included in Interop 2025.

Again, these are less headline-grabbing than the shiny new features, but it's these edge cases where us web developers lose hours of our time. Frustrating, frustrating, hours.

Interop investigations

Sometimes, we see a focus area proposal that's clearly important, but doesn't fit the requirements of Interop. This is usually because the tests for the feature aren't sufficient, are in the wrong format, or browsers are missing automation features that are needed to make the feature testable.

In these cases, we identify what's missing, and set up an investigation area.

For interop 2026, we're looking at…

Accessibility. This is a continuation of work in 2025. Ultimately, we want browsers to produce consistent accessibility trees from the same DOM and CSS, but before we can write tests for this, we need to improve our testing infrastructure.

Mobile testing. Another continuation from 2025. In particular, in 2026, we want to figure out an approach for testing viewport changes caused by dynamic UI, such as the location bar and virtual keyboard.

JPEG XL. The current tests for this are sparse. Existing decoders have more comprehensive test suites, but we need to figure out how these relate to browsers. For example, progressive rendering is an important feature for developers, but how and when browsers should do this (to avoid performance issues) is currently being debated.

WebVTT. This feature allows for text to be synchronised to video content. The investigation is to go through the test suite and ensure it's fit for purpose, and amend it where necessary.

It begins… again

The selected focus areas mean we've committed to more work compared to the other browsers, which is quite the challenge being the only engine that isn't owned by billionaires. But it's a challenge we're happy to take on!

Together with other members of the Interop group, we're looking forward to delivering features and fixes over the next year. You can follow along with the progress of all browsers on the Interop dashboard.

If your favorite feature is missing from Interop 2026, that doesn't mean it won't be worked on. JPEG XL is a good example of this. The current test suite meant it wasn't a good fit for Interop 2026, but we've challenged the JPEG XL team at Google Research to build a memory-safe decoder in Rust, which we're currently experimenting with in Firefox, as is Chrome.

Interop isn't the limit of what we're working on, but it is a cross-browser commitment.

If you're interested in details of features as they land in Firefox, and discussions of future features from spec groups, you can follow us on:

Partner Announcements

This is a team effort, and we've all made announcement posts like this one. Get other members' take on it:

The post Launching Interop 2026 appeared first on Mozilla Hacks - the Web developer blog.

12 Feb 2026 5:07pm GMT

Mozilla Localization (L10N): Pontoon Translation Search: Unifying Localization Across Mozilla

Here at Mozilla, we are tirelessly working to bring our products to a global audience. Pontoon, our in-house translation management system plays a central role, where volunteer localizers work to bring translations for Firefox, Thunderbird, SUMO and other Mozilla products.

Recently, we have been working to unify localization tools and give localizers and developers smoother, more streamlined workflows. This is why we are excited to introduce Pontoon's new Translation Search feature, where everyone can search for strings across all projects and locales at Mozilla.

What is the Translation Search Feature?

Translation Search is Pontoon's latest way to access our extensive collection of translations, built up through years of localization work by fellow Mozillians. This new feature allows localizers to search for strings across all projects and all locales at Mozilla. Inspired by the functionality of Transvision, it is intended to be a suitable replacement and includes many of the various features that localizers rely on.

Let's go through some of its features and how they can apply to your localization workflows.

Searching for Translations

Pontoon's new Translation Search, where users can search for strings through all projects and locales.

Searching for strings in Translation Search is simple. Similar to how Transvision operates, you can search within a specific project and locale, as well as filter by string identifiers, case sensitivity and whole word search. Unlike Transvision, Pontoon Translation Search covers all products localized at Mozilla. It is also completely integrated with other Pontoon elements, including Translate, such that you can seamlessly navigate to Translate after your search.

Transvision's search functionality, which we intend to replace.

Finding Entity Translations

Pontoon's new Entity Translations page, which lists available translations for a source string.

If you want to get a better picture of a source string with different translations, go to the Entity Translations page. By clicking the "All Locales" button in Translation Search for a string, you can see the source string translated into every available locale. This is useful for comparing similar locale translations and getting a broader picture of a string's context. This feature is intended to replace Transvision's translation list for a particular entity.

Transvision's string translation list, which we intend to replace.

Searching from Firefox Address Bar

If you have the Pontoon Add-on installed to the latest version, you can now search for strings directly from the address bar in Firefox: you can select Pontoon from the list of search engines, or start typing pontoon and press TAB.

How to use Translation Search with Pontoon Add-on.

Pontoon Translation Search is Live!

This feature is available now and ready for you to use. Head over to pontoon.mozilla.org/search to try out the new search experience and streamline your localization work! If you have any questions or concerns about Translation Search, do not hesitate to contact us on Matrix or file an issue. You can also consult the documentation here.

12 Feb 2026 8:14am GMT

The Rust Programming Language Blog: Announcing Rust 1.93.1

The Rust team has published a new point release of Rust, 1.93.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, getting Rust 1.93.1 is as easy as:

rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website.

What's in 1.93.1

Rust 1.93.1 resolves three regressions that were introduced in the 1.93.0 release.

Contributors to 1.93.1

Many people came together to create Rust 1.93.1. We couldn't have done it without all of you. Thanks!

12 Feb 2026 12:00am GMT

11 Feb 2026

feedPlanet Mozilla

Thunderbird Blog: Thunderbird Monthly Development Digest: February 2026

Welcome back to the Thunderbird blog and the first post of 2026! We're rested, recharged, and ready to keep our community updated on all of our progress on the desktop and mobile clients and with Thunderbird Pro!

Hello again from the Thunderbird development team! After a restful and reflective break over the December holidays, the team returned recharged and ready to take on the mountain of priorities ahead.

To everyone we met during the recent FOSDEM weekend, thank you! The conversations, encouragement, and thoughtful feedback you shared were genuinely energizing, and many of your insights are already helping us better understand the real-world challenges you're facing. The timing couldn't have been better, as FOSDEM provided a strong early-year boost of inspiration, collaboration, and perspective.

FOSDEM - Collaboration, learning and real conversations

This year, a larger contingent of the Thunderbird team joined our Mozilla colleagues in Brussels for an intense and rewarding FOSDEM weekend. Across talks, hallway chats, and long discussions at the Thunderbird booth, we dug into standards, shared hard-won lessons, debated solutions, and explored what's next for open communication tools.

The highlight, as always, was meeting users face-to-face. Hearing your stories about what's working, what's painful, and what you'd like to see next continues to be one of the most motivating parts of our work.

Several recurring themes stood out in these discussions, and we're keen to help move the needle on some of the bigger, knottier challenges, including:

These conversations don't end when FOSDEM does but help shape our priorities for the months ahead, and we're grateful to everyone who took the time to stop by, ask questions, or share their experiences.

Exchange Email Support

After releasing Exchange support for email to the Monthly release channel, we've had some great feedback and helpful diagnosis of edge case problems that we've been prioritizing for the past few weeks

Work completed during this period includes:

Work on supporting the Graph API protocol for email is moving steadily through the early stages, with these basic components already shipped to Daily:

Keep track of our Graph API implementation here.

Account Hub

The team met in person following FOSDEM and have planned out work to allow the new Account Hub UX to be used as the default experience in our next Extended Support Release this summer, which will ensure users benefit from changes we've made to enable custom Oauth settings and configuration specific to Microsoft Exchange.

Follow progress in the meta bugs for the last few pieces of phase 3 and telemetry, as well as the work we've defined to enable an interim experience for users setting up Thunderbird for the first time.

Calendar UI Rebuild

The new Calendar UI work has advanced at a good pace in recent weeks and the team met in person to break the work apart into chunks which have been prioritized alongside some of the "First Time User Experience" milestones. The team has recently:

Stay tuned to our milestones here:

Maintenance, Upstream adaptations, Recent Features and Fixes

Over the past couple of months, a significant portion of the team's time has gone into responding to upstream changes that have impacted build stability, test reliability, and CI. Sheriffing continues to be a challenge, with frequent breakages requiring careful investigation to separate upstream regressions from Thunderbird-specific changes.

Alongside this ongoing maintenance work, we've also benefited greatly from contributions across the wider development community. Thanks to that collective effort, a steady stream of fixes and improvements has landed.

More broadly and focusing on our roadmap, the last two months have seen solid progress on Fluent migrations, as well as planning and early groundwork for rolling out Redux and the Design System more widely across the codebase.

Support from the community and team has resulted in some notable patches landing in recent weeks, with the following of particular help:

If you would like to see new features as they land, and help us find some early bugs, you can try running daily and check the pushlog to see what has recently landed. This assistance is immensely helpful for catching problems early.

Toby Pilling

Senior Manager, Desktop Engineering

The post Thunderbird Monthly Development Digest: February 2026 appeared first on The Thunderbird Blog.

11 Feb 2026 5:50pm GMT

Support.Mozilla.Org: What’s up with SUMO – H2 2025

Hi everyone,

We may already be a few weeks into 2026, but it's never too late to say Happy New Year! As we dive into the year ahead, we also want to take a moment to reflect on everything we accomplished together in the second half of 2025.

In this recap, you'll find highlights from community campaigns, major platform updates and product launches, as well as forum and Knowledge Base data that offer a clearer picture of how the community performed. We hope this snapshot helps celebrate what went well, while also shining a light on areas where we can continue to grow together.

Let's jump in!

Highlights

Community stats

Forum Support

General stats

The forum continues to show encouraging signs of community growth and maturity. Most notably, the solve rate more than doubled, jumping by 124% to reach 11.9%. This is a clear signal that contributors are not only engaging with users, but successfully resolving their issues at a much higher rate. We also saw a 9.8% increase in OP reply rate, suggesting stronger two-way engagement between users and contributors.

Improvements in speed reinforce this trend: first response time dropped by nearly 30%, while time to resolution was cut in half, falling by 48.9%. Combined with a 12.7% rise in reply rate and 15.7% more threads being actively supported, these results point to a community that's not just growing, but becoming more efficient, responsive, and impactful.

With the automatic spam moderation introduced in the first half of year, we've seen fewer total questions coming in H2 2025 but higher quality interactions overall. This shift suggests a more focused and intentional support environment. Taken together, these trends suggest that it's time to elevate solve rate from a "nice to have" to a core success metric, a meaningful reflection of contributor expertise, community trust, and the maturity of our Community Forums.

Total valid questions 14803 (-20%)
Reply rate 63.5 (+12.67%)
Solve rate 11.9% (+124%)
Total responses posted 14191 (+20.4%)
Total threads interacted 9599 (+15.7%)
Average first response time (in hour) 22.4 (-29.8%)
Average time to resolution (in day) 2.55 (-48.9%)
Total new registration 455k (+0.5%)
Total contributors 963 (-1.3%)
Helpful rate 60.8% (+3.92%)
OP reply rate 27% (+9.8%)

Top forum contributors

All credit for this impressive performance goes to our incredible forum community, who continue to raise the bar with each quarter. Their dedication, consistency, and responsiveness are what make these results possible.

We're proud to highlight the top 3 contributors on the English forum, along with the leading contributors across other locales. This shows a true reflection of the global impact of our support network.

Contributor name Total responses Total threads engaged
Paul Wright (en-US) 1900 1395
Denyshon (en-US) 1284 924
Jefferson Scher (en-US) 930 871
@next (it) 557 438
Gerardo (es) 523 457
Mark Heijl (nl) 186 155
Selim (tr) 126 87
Ansamb (cs) 87 65
Poljos-moz (cs) 81 59
Sandromonteiro (pt-BR) 15 15
Balázs Meskó (hu) 51 48
Vexi (sl) 5 5

Emerging forum contributors

Contributor name Total responses Total threads engaged
George Kitsoukakis 202 171
Mark 136 110
sjohnn 65 45
t.r.ernst 64 60
Jeff-g 61 54

Knowledge Base

General stats

We've seen an impressive uptick in article contributions in the second half of 2025, with 925 revisions submitted to the English Knowledge Base, a 21.9% increase compared to the previous period. This continued growth reflects not just dedication, but real momentum of the growing spirit to keep our Knowledge Base fresh and helpful for users worldwide.

This level of participation directly supports our broader direction towards improving and streamlining the content request workflow. As we continue investing in clearer processes and better documentation, it's clear that contributors are willing to step up when the pathway to impact is well defined.

Total en-US revisions 925 (+21.9%)
Total articles 248 (+2.9%)
Total revisions reviewed 821 (+19.9%)
Total revisions approved 778 (+17.7%)
Total authors 97
Total reviewers 19 (+11.8%)

Top KB contributors

The numbers may show progress, but the real story is the people behind them. Behind these revisions, 97 unique contributors stepped in to create the updates and 19 reviewers helped guide their contributions. And here's just a glimpse of the top 5 contributors:

Contributor name Total revisions Total articles Total reviews
AliceWyman 467 246 334
Pierre Mozinet 125 100 -
Mark Heijl 101 88 -
Michele Rodaro 50 46 35
Paul Wright 26 21 5

Article Localization

The localization community delivered an outstanding performance in H2 2025, despite undergoing significant changes. We saw 4807 non-English revisions submitted, a 37.5% increase, covering 2664 articles across locales (+29.7%). In total, 4,259 revisions were approved and 4,296 reviewed, reflecting consistent contributor dedication to quality and accuracy. Most notably, 314 unique contributors stepped up to author content, representing a 54.7% increase from earlier this year.

These results are especially meaningful given the rollout of Machine Translation in August, a major shift in localization workflow that understandably sparked concern and discussion across the community. Adjusting to MT required both flexibility and trust, and we're grateful that many contributors responded by showing up in full force. Your continued involvement ensured that translations remained thoughtful, context-aware, and aligned with Mozilla's values of openness and quality. This success is a testament to the strength, resilience, and care of our contributor base, and we're deeply grateful for your ongoing contribution.

General stats (minus sumoBot)

Total non en-US revisions 4807 (+37.5%)
Total articles 2664 (+29.7%)
Total revisions reviewed 4296 (+33.5%)
Total revisions approved 4259 (+33.6%)
Total authors 314 (+54.7%)
Total reviewers 45 (-6%)

Top localization contributors

Contributor name Total revisions Total articles Total reviews
Michele Rodaro (it) 819 393 801
Jim Spentzos (el) 727 566 555
Valery Ledovskoy (ru) 627 400 635
Mark Heijl (nl) 575 359 -
Milupo (dsb & hsb) 460 224 330

Emerging localization contributors

Contributor name Total revisions Total articles
普莱是袋熊 (zh-CN) 35 31
Zhengyang3552 (zh-CN) 22 21
xanhAD (vi) 13 11

Stay connected with the community

Join the Conversation

Attend Our Monthly Community Call

Stay Informed

Explore What We're Building

You can also view our latest release notes to stay informed about recent changes and improvements.

11 Feb 2026 7:00am GMT

This Week In Rust: This Week in Rust 638

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Newsletters
Project/Tooling Updates
Observations/Thoughts
Rust Walkthroughs

Crate of the Week

This week's crate is zedbar, a crate to read QR codes and a bunch of other barcode formats from images.

Thanks to Brian Donovan for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

No Calls for participation were submitted this week.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

569 pull requests were merged in the last week

Compiler
Library
Cargo
Clippy
Rust-Analyzer
Rust Compiler Performance Triage

This week we saw quite a few improvements. Largest one comes from adding two targeted with_capacity calls in #151929. Another source of multiple improvements is the ongoing migration away from using external files to store diagnostic messages.

Triage done by @panstromek. Revision range: a60d12cb..39219ceb

Summary:

(instructions:u) mean range count
Regressions ❌
(primary)		 2.0% [2.0%, 2.0%] 1
Regressions ❌
(secondary)		 0.6% [0.0%, 2.0%] 22
Improvements ✅
(primary)		 -0.8% [-2.8%, -0.2%] 179
Improvements ✅
(secondary)		 -3.1% [-31.1%, -0.0%] 211
All ❌✅ (primary) -0.7% [-2.8%, 2.0%] 180

1 Regression, 6 Improvements, 7 Mixed; 9 of them in rollups 36 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

Rust

Compiler Team (MCPs only)

Cargo

No Items entered Final Comment Period this week for Rust RFCs, Language Team, Language Reference, Leadership Council, or Unsafe Code Guidelines.

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

Upcoming Events

Rusty Events between 2026-02-11 - 2026-03-11 🦀

Virtual
Asia
Europe
North America
Oceania

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

Unpopular opinion: error handling in Rust is actually fantastic. Once you know the right patterns, which regrettably are NOT always obvious 😂

- Ian Wagner on fosstodon

Despite another week with a lamentable lack of suggestions, llogiq is pleased with what he found.

Please submit quotes and vote for next week!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

11 Feb 2026 5:00am GMT

Niko Matsakis: Dada: moves and mutation

Let's continue with working through Dada. In my previous post, I introduced some string manipulation. Let's start talking about permissions. This is where Dada will start to resemble Rust a bit more.

Class struggle

Classes in Dada are one of the basic ways that we declare new types (there are also enums, we'll get to that later).

The most convenient way to declare a class is to put the fields in parentheses. This implicitly declares a constructor at the same time:

class Point(x: u32, y: u32) {}

This is in fact sugar for a more Rust like form:

class Point {
    x: u32
    y: u32
    fn new() -> Point {
        Point { x, y }
    }
}

And you can create an instance of a class by calling the constructor:

let p = Point(22, 44) // sugar for Point.new(22, 44)

Mutating fields

I can mutate the fields of p as you would expect:

p.x += 1
p.x = p.y

Read by default

In Dada, the default when you declare a parameter is that you are getting read-only access:

fn print_point(p: Point) {
    print("The point is {p.x}, {p.y}")
}

let p = Point(22, 44)
print_point(p)

If you attempt to mutate the fields of a parameter, that would get you an error:

fn print_point(p: Point) {
    p.x += 1 # <-- ERROR!
}

Use ! to mutate

If you declare a parameter with !, then it becomes a mutable reference to a class instance from your caller:

fn translate_point(point!: Point, x: u32, y: u32) {
    point.x += x
    point.y += y
}

In Rust, this would be like point: &mut Point. When you call translate_point, you also put a ! to indicate that you are passing a mutable reference:

let p = Point(22, 44)     # Create point
print_point(p)            # Prints 22, 44
translate_point(p!, 2, 2) # Mutate point
print_point(p)            # Prints 24, 46

As you can see, when translate_point modifies p.x, that changes p in place.

Moves are explicit

If you're familiar with Rust, that last example may be a bit surprising. In Rust, a call like print_point(p) would move p, giving ownership away. Trying to use it later would give an error. That's because the default in Dada is to give a read-only reference, like &x in Rust (this gives the right intuition but is also misleading; we'll see in a future post that references in Dada are different from Rust in one very important way).

If you have a function that needs ownership of its parameter, you declare that with given:

fn take_point(p: given Point) {
    // ...
}

And on the caller's side, you call such a function with .give:

let p = Point(22, 44)
take_point(p.give)
take_point(p.give) # <-- Error! Can't give twice.

Comparing with Rust

It's interesting to compare some Rust and Dada code side-by-side:

Rust Dada
vec.len() vec.len()
map.get(&key) map.get(key)
vec.push(element) vec!.push(element.give)
vec.append(&mut other) vec!.append(other!)
message.send_to(&channel) message.give.send_to(channel)

Design rationale and objectives

Convenient is the default

The most convenient things are the shortest and most common. So we make reads the default.

Everything is explicit but unobtrusive

The . operator in Rust can do a wide variety of things depending on the method being called. It might mutate, move, create a temporary, etc. In Dada, these things are all visible at the callsite- but they are unobtrusive.

This actually dates from Dada's "gradual programming" days - after all, if you don't have type annotations on the method, then you can't decide foo.bar() should take a shared or mutable borrow of foo. So we needed a notation where everything is visible at the call-site and explicit.

Postfix operators play more nicely with others

Dada tries hard to avoid prefix operators like &mut, since they don't compose well with . notation.

11 Feb 2026 12:29am GMT

09 Feb 2026

feedPlanet Mozilla

Dave Townsend: Can't you do this faster with AI?

I'm hearing this question asked a lot lately. Both within Mozilla and from others in the industry. You come up with a plan for implementing some feature, put your best estimate on how long it will take to implement, and then you get push back from folks several levels removed from the project along the lines of "Wouldn't this be faster if you used AI?", or "Can't Claude Code do most of this?".

09 Feb 2026 6:00pm GMT

Niko Matsakis: Hello, Dada!

Following on my Fun with Dada post, this post is going to start teaching Dada. I'm going to keep each post short - basically just what I can write while having my morning coffee.1

You have the right to write code

Here is a very first Dada program

println("Hello, Dada!")

I think all of you will be able to guess what it does. Still, there is something worth noting even in this simple program:

"You have the right to write code. If you don't write a main function explicitly, one will be provided for you." Early on I made the change to let users omit the main function and I was surprised by what a difference it made in how light the language felt. Easy change, easy win.

Convenient is the default

Here is another Dada program

let name = "Dada"
println("Hello, {name}!")

Unsurprisingly, this program does the same thing as the last one.

"Convenient is the default." Strings support interpolation (i.e., {name}) by default. In fact, that's not all they support, you can also break them across lines very conveniently. This program does the same thing as the others we've seen:

let name = "Dada"
println("
    Hello, {name}!
")

When you have a " immediately followed by a newline, the leading and trailing newline are stripped, along with the "whitespace prefix" from the subsequent lines. Internal newlines are kept, so something like this:

let name = "Dada"
println("
    Hello, {name}!
    
    How are you doing?
")

would print

Hello, Dada!

How are you doing?

Just one familiar String

Of course you could also annotate the type of the name variable explicitly:

let name: String = "Dada"
println("Hello, {name}!")

You will find that it is String. This in and of itself is not notable, unless you are accustomed to Rust, where the type would be &'static str. This is of course a perennial stumbling block for new Rust users, but more than that, I find it to be a big annoyance - I hate that I have to write "Foo".to_string() or format!("Foo") everywhere that I mix constant strings with strings that are constructed.

Similar to most modern languages, strings in Dada are immutable. So you can create them and copy them around:

let name: String = "Dada"
let greeting: String = "Hello, {name}"
let name2: String = name

Next up: mutation, permissions

OK, we really just scratched the surface here! This is just the "friendly veneer" of Dada, which looks and feels like a million other languages. Next time I'll start getting into the permission system and mutation, where things get a bit more interesting.

  1. My habit is to wake around 5am and spend the first hour of the day doing "fun side projects". But for the last N months I've actually been doing Rust stuff, like symposium.dev and preparing the 2026 Rust Project Goals. Both of these are super engaging, but all Rust and no play makes Niko a dull boy. Also a grouchy boy. ↩︎

09 Feb 2026 11:03am GMT

Niko Matsakis: Fun With Dada

Waaaaaay back in 2021, I started experimenting with a new programming language I call "Dada". I've been tinkering with it ever since and I just realized that (oh my gosh!) I've never written even a single blog post about it! I figured I should fix that. This post will introduce some of the basic concepts of Dada as it is now.

Before you get any ideas, Dada isn't fit for use. In fact the compiler doesn't even really work because I keep changing the language before I get it all the way working. Honestly, Dada is more of a "stress relief" valve for me than anything else1 - it's fun to tinker with a programming language where I don't have to worry about backwards compatibility, or RFCs, or anything else.

That said, Dada has been a very fertile source of ideas that I think could be applicable to Rust. And not just for language design: playing with the compiler is also what led to the new salsa design2, which is now used by both rust-analyzer and Astral's ty. So I really want to get those ideas out there!

I took a break, but I'm back baby!

I stopped hacking on Dada about a year ago3, but over the last few days I've started working on it again. And I realized, hey, this is a perfect time to start blogging! After all, I have to rediscover what I was doing anyway, and writing about things is always the best way to work out the details.

Dada started as a gradual programming experiment, but no longer

Dada has gone through many phases. Early on, the goal was to build a gradually typed programming language that I thought would be easier for people to learn.

The idea was that you could start writing without any types at all and just execute the program. There was an interactive playground that would let you step through and visualize the "borrow checker" state (what Dada calls permissions) as you go. My hope was that people would find that easier to learn than working with type checker checker.

I got this working and it was actually pretty cool. I gave a talk about it at the Programming Language Mentoring Workshop in 2022, though skimming that video it doesn't seem like I really demo'd the permission modeling. Too bad.

At the same time, I found myself unconvinced that the gradually typed approach made sense. What I wanted was that when you executed the program without type annotations, you would get errors at the point where you violated a borrow. And that meant that the program had to track a lot of extra data, kind of like miri does, and it was really only practical as a teaching tool. I still would like to explore that, but it also felt like it was adding a lot of complexity to the language design for something that would only be of interest very early in a developer's journey4.

Therefore, I decided to start over, this time, to just focus on the static type checking part of Dada.

Dada is like a streamlined Rust

Dada today is like Rust but streamlined. The goal is that Dada has the same basic "ownership-oriented" feel of Rust, but with a lot fewer choices and nitty-gritty details you have to deal with.5

Rust often has types that are semantically equivalent, but different in representation. Consider &Option<String> vs Option<&String>: both of them are equivalent in terms of what you can do with them, but of course Rust makes you carefully distinguish between them. In Dada, they are the same type. Dada also makes &Vec<String>, &Vec<&String>, &[String], &[&str], and many other variations all the same type too. And before you ask, it does it without heap allocating everything or using a garbage collector.

To put it pithily, Dada aims to be "Rust where you never have to call as_ref()".

Dada has a fancier borrow checker

Dada also has a fancier borrow checker, one which already demonstrates much of the borrow checker within, although it doesn't have view types. Dada's borrow checker supports internal borrows (e.g., you can make a struct that has fields that borrow from other fields) and it supports borrow checking without lifetimes. Much of this stuff can be brought to Rust, although I did tweak a few things in Dada that made some aspects easier.

Dada targets WebAssembly natively

Somewhere along the line in refocusing Dada, I decided to focus exclusively on building WebAssembly components. Initially I felt like targeting WebAssembly would be really convenient:

WebAssembly and on-demand compilation = compile-time reflection almost for free

But I came to realize that targeting WebAssembly has another advantage: it makes compile-time reflection almost trivial. The Dada compiler is structured in a purely on-demand fashion. This means we can compile one function all the way to WebAssembly bytecode and leave the rest of the crate untouched.

And once we have the WebAssembly bytecode, we can run that from inside the compiler! With wasmtime, we have a high quality JIT that runs very fast. The code is even sandboxed!

So we can have a function that we compile and run during execution and use to produce other code that will be used by other parts of the compilation step. In other words, we get something like miri or Zig's comptime for free, essentially. Woah.

Wish you could try it? Me too!

Man, writing this blog post made ME excited to play with Dada. Too bad it doesn't actually work. Ha! But I plan to keep plugging away on the compiler and get it to the point of a live demo as soon as I can. Hard to say exactly how long that will take.

In the meantime, to help me rediscover how things work, I'm going to try to write up a series of blog posts about the type system, borrow checker, and the compiler architecture, all of which I think are pretty interesting.

  1. Yes, I relax by designing new programming languages. Doesn't everyone? ↩︎

  2. Designing a new version of salsa so that I could write the Dada compiler in the way I wanted really was an epic yak shave, now that I think about it. ↩︎

  3. I lost motivation as I got interested in LLMs. To be frank, I felt like I had to learn enough about them to understand if designing a programming language was "fighting the last war". Having messed a bunch with LLMs, I definitely feel that they make the choice of programming language less relevant. But I also think they really benefit from higher-level abstractions, even more than humans do, and so I like to think that Dada could still be useful. Besides, it's fun. ↩︎

  4. And, with LLMs, that period of learning is shorter than ever. ↩︎

  5. Of course this also makes Dada less flexible. I doubt a project like Rust for Linux would work with Dada. ↩︎

09 Feb 2026 2:20am GMT

08 Feb 2026

feedPlanet Mozilla

Jonathan Almeida: Update jj bookmarks to the latest revision

Got this one from another colleague as well but it seems like most folks use some version of this daily that it might be good to have this built-in.

Before I can jj git push my current bookmark to my remote, I need to update where my (tracked) bookmark is, to the latest change:

@  ptuqwsty git@jonalmeida.com 2026-01-05 16:00:22 451384bf <-- move 'main' here.
│  TIL: Update remote bookmark to the latest revision
◆  xoqwkuvu git@jonalmeida.com 2025-12-30 19:50:51 main git_head() 9ad7ce11
│  TIL: Preserve image scale with ImageMagick
~

A quick one-liner jj tug does that for me:

@  ptuqwsty git@jonalmeida.com 2026-01-05 16:03:54 main* 6e7173b4
│  TIL: Update remote bookmark to the latest revision
◆  xoqwkuvu git@jonalmeida.com 2025-12-30 19:50:51 main@origin git_head() 9ad7ce11
│  TIL: Preserve image scale with ImageMagick
~

The alias is quite straight-forward:

[aliases]
# Update your bookmarks to your latest rev.
tug = ["bookmark", "move", "--from", "heads(::@ & bookmarks())", "--to", "@"]

08 Feb 2026 5:14am GMT

06 Feb 2026

feedPlanet Mozilla

Jonathan Almeida: Test a Firefox Android variant alongside your daily driver

In the Mozilla Android team, we want engineers to talk with Product and UX more and hash out ideas sooner. Prototype an idea, then discuss the feature's merits. For this, we built TryFox to make it easier for everyone to get the latest version of Firefox Nightly or install a "try" build with a link to the build on our CI servers.

The downside with using a Try build is that you sometimes have to uninstall your existing version of Nightly before you can install another and that means losing app data. Typically, if you were doing this on your daily driver, you don't want to do that. A quick work around is to add a temporary patch above your stack of commits which changes the App ID suffix (and optionally the application name) so that there is no conflict.

Here is an example diff from a patch that changed an animation, so having it install alongside what we shipped let you compare them easily:

diff --git a/mobile/android/fenix/app/build.gradle b/mobile/android/fenix/app/build.gradle
index 019fdb7ab4..772cc6cc3d 100644
--- a/mobile/android/fenix/app/build.gradle
+++ b/mobile/android/fenix/app/build.gradle
@@ -127,7 +127,7 @@
         debug {
             shrinkResources = false
             minifyEnabled = false
-            applicationIdSuffix ".fenix.debug"
+            applicationIdSuffix ".fenix.debug_animator"
             resValue "bool", "IS_DEBUG", "true"
             pseudoLocalesEnabled = true
         }
diff --git a/mobile/android/fenix/app/src/main/res/values/static_strings.xml b/mobile/android/fenix/app/src/main/res/values/static_strings.xml
index 4f6703eb35..1a57988477 100644
--- a/mobile/android/fenix/app/src/main/res/values/static_strings.xml
+++ b/mobile/android/fenix/app/src/main/res/values/static_strings.xml
@@ -4,7 +4,7 @@
    - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
 <resources xmlns:moz="http://schemas.android.com/apk/res-auto" xmlns:tools="http://schemas.android.com/tools">
     <!-- Name of the application -->
-    <string name="app_name" translatable="false">Firefox Fenix</string>
+    <string name="app_name" translatable="false">Firefox Fenix (animator)</string>
     <string name="firefox" translatable="false">Firefox</string>

     <!-- Preference for developers -->

In the future, we can add mach try support to do this automatically for any push.

06 Feb 2026 12:00am GMT

04 Feb 2026

feedPlanet Mozilla

Mozilla Localization (L10N): Localizer spotlight: Oliver

About You

My name is Oliver Chan, though I am mostly known by my username Olvcpr423. I'm from China, and I speak Mandarin and Cantonese. I have been contributing to Mozilla localization in Simplified Chinese since 2020.

Getting Started

Q: How did you first get involved in localization, and what led you to Mozilla?

A: My localization journey actually began with Minecraft back in 2018, when I was 13. I was an avid player of this globally popular game. Similar to Mozilla, its developer uses a crowdsourcing platform to let players localize the game themselves. I joined the effort and quickly realized that I had a strong interest in translation. More importantly, I found myself eager to use my skills to help bridge language gaps, so that more people could enjoy content from different languages easily.

Firefox was the first Mozilla product I ever used. I started using it relatively late, in 2020, and my connection with Firefox began thanks to my uncle. Although I was aware that Firefox had a long history, I didn't yet understand what made it special. I gradually learned about its unique features and position as I explored further, and from then on, Firefox became my primary browser.

Later that same year, I noticed a typo while using Firefox and suggested a fix on Pontoon (I honestly can't recall how I found Pontoon at the time). That small contribution marked the beginning of my journey as a Mozilla localizer. I believe many people's localization journeys also start by correcting a single typo.

Working on Mozilla Products

Q: Which Mozilla projects do you enjoy working on the most, and why?

A: Firefox, absolutely. For one thing, it's my favorite piece of software, which makes working on it personally meaningful. More importantly, Firefox has a massive Chinese user base, which gives me a strong sense of responsibility to provide the best possible language support for my fellow speakers. On top of that, Firefox's mission as the last independent browser gives me extra motivation when working on its localization.

Aside from Firefox, Common Voice has been the most impactful project I've localized for Mozilla. It collects voices from a diverse range of speakers to build a publicly available voice dataset, which I think is especially valuable in this era. And honestly, working on the text for a voice-collection platform is a wonderful experience, isn't it? 😀

Thunderbird is another project I find especially rewarding. It is popular on Linux, and localizing it means supporting many users who rely on it for everyday communication, which I consider vital work.

Q: How does regularly using these products influence how you approach localization?

A: Regular usage is essential for localization teams (like us) that lack dedicated LQA processes and personnel. Without routinely using the product, it's easy to overlook issues that only become apparent in context, such as translations that don't fit the context or layout problems.

Since we also lack a centralized channel to gather feedback from the broader community, we have to do our best to identify as many issues as we can ourselves. We also actively monitor social media and forums for user complaints related to localization. In addition, whenever I come across a screenshot of an unfamiliar interface, I take it as an opportunity to check for potential issues.

Community & Collaboration

Q: How does the Chinese localization community collaborate in practice?

A: In practice, besides myself, there is only one other active member on Pontoon for our locale. While the workload is still manageable, we do need to seriously think about recruiting new contributors and planning for succession to ensure sustainability.

That said, our community is larger than what you see on Pontoon alone. We have a localization group chat where many members stay connected. Although they may not actively contribute to Pontoon - some work on SUMO or MDN, some are regular users, while others are less active nowadays - I can always rely on them for insightful advice whenever I encounter tricky issues or need to make judgment calls. Oftentimes, we make collective decisions on key terminology and expressions to reflect community consensus.

Q: How do you coordinate translation, review, and testing when new strings appear?

A: Recently, our locale hit 60,000 strings - a milestone well worth celebrating. Completing the translation of such a massive volume has been a long-term effort, built on nearly two decades of steady, cumulative work by successive contributors. I'd like to take this opportunity to thank each and every one of them.

As for coordination, we don't divide work by product - partly because all products already have a high completion level, and the number of products and new strings is still manageable. In practice, we treat untranslated strings a bit like Whac-A-Mole: whenever new strings appear, anyone available just steps in to translate them. Testing is also a duty we all share.

For review, we follow a cross-review principle. We avoid approving our own suggestions and instead leave them for peers to review. This helps reduce errors and encourages discussion, ensuring we arrive at the best possible translations.

Q: Did anyone mentor you when you joined the community, and how do you support new contributors today?

A: When I first joined Mozilla localization, I wasn't familiar with the project's practices or consensus. The locale manager 你我皆凡人 helped me greatly by introducing them. For several years, they were almost the only active proofreader for our locale, and I'd like to take this opportunity to pay tribute to their long-term dedication.

Today, when reviewing suggestions from newcomers, if a translation doesn't yet meet the approval standard, I try my best to explain the issues through comments and encourage them to keep contributing, rather than simply rejecting their work - which could easily discourage them and dampen their enthusiasm.

Q: What do you think is most important for keeping the community sustainable over time?

A: It's all about the people. Without people, there is no community. We need fresh blood to ensure we don't face a succession crisis. At the moment, recruiting from within the Mozilla ecosystem (MDN or SUMO) is the most immediate approach, but I won't give up on trying to draw in more people from the broader community.

Continuity of knowledge is also important. We mentor newcomers so they understand how the project works, along with its best practices and historical context. Documentation becomes necessary as time passes or the community grows; it ensures knowledge is preserved over time and prevents "institutional amnesia" as people come and go.

Background, Skills & Personal Lens

Q: What's your background outside localization, and how does it shape your approach to translation?

A: I'm currently a student majoring in accounting. While accounting and software localization may seem worlds apart, I believe they share similar characteristics. The IFRS (International Financial Reporting Standards) identifies six qualitative characteristics of accounting information, and with a slight reinterpretation, I find that they also apply surprisingly well to localization and translation. For example:

On a personal level, I developed qualities like prudence and precision through localization long before I started my degree, which gave me a head start in accounting. In turn, what I've learned through my studies has helped me perform even better in localization. It's a somewhat interesting interplay.

Q: Besides translation, what else have you gained through localization?

A: I knew very little about Web technologies before I started localizing for Mozilla. Through working on Firefox localization, I gradually developed a solid understanding of Web technologies and gained deeper insight into how the Web works.

Fun Facts

Q: Any fun or unexpected facts you'd like to share about yourself?

A: My connection with Firefox began thanks to my uncle. One day, he borrowed my computer and complained that Firefox wasn't installed - it had always been his go-to browser. So I decided to give it a try and installed it on my machine. That was how my journey with Firefox began.

I love watching anime, especially Bocchi the Rock! and the band Kessoku Band featured in the series. I also enjoy listening to Anisongs and Vocaloid music, particularly songs voiced by Hatsune Miku and Luo Tianyi. And while I enjoy watching football matches, I'm not very good at playing football myself!

04 Feb 2026 10:23pm GMT

Firefox Tooling Announcements: Firefox Profiler Deployment (February 4, 2026)

The latest version of the Firefox Profiler is now live! Check out the full changelog below to see what's changed

Highlights:

Other Changes:

Big thanks to our amazing localizers for making this release possible:

1 post - 1 participant

Read full topic

04 Feb 2026 5:07pm GMT

Ludovic Hirlimann: Fosdem 2026 recap

https://en.wikipedia.org/wiki/SPARCstation_5#SPARCstation_4

This year I was lucky again and was able to attend FOSDEM. This turned out to be more of a social conference than a technical one for me this year. I mean: I had a bunch of really great conversations, with peers and users of Firefox. I was there to man the Mozilla booth. The idea was to engage people and have them fill up a bingo, in exchange they might go back home with a T-shirt a baseball cap or a pair of socks. Most people that I saw on Saturday afternoon and Sunday morning. Some people complained about AI, but not as many as I was expecting. Explaining why and that https://techcrunch.com/2026/02/02/firefox-will-soon-let-you-block-all-of-its-generative-ai-features/ would soon be available made them all understand and think that they could keep Firefox as their main browser. Our sticker stock melts like snow under the sun. The people from mozilla.ai had some pretty interesting discussions with some users that came by the booth.

When the FOSDEM schedule got published, I got exited by the fact that the Mozilla room had been renamed the web browser room. Inclusion done the right, the best way to push for an open web. That dev room was located in the room that had historically served the Mozilla community back in 2004/2005/2006/2007 ... Unfortunately, I woke up 30m past Midnight on Saturday and was unable to get back to sleep. The sessions I had intended to watch were just at the time I got a big tired / want to sleep feeling. This was also true for the other room I was interested in : the BSD dev room.

Last but not least, as I had helped organize the Search dev room, a very nice recap was posted on LinkedIn. I was doing the MC in that room. It was a lot of fun and I learned a lot.

Remember you can view, see again dev room content as they are appearing to videos.fodem.org. You can retrieve more slides from the schedule of the talks like here https://fosdem.org/2026/schedule/event/B7BVVJ-eliza_rewriting_the_original_ai_chatbot_from_60_years_bc_before_chatgpt/, videos are being processed and are not yet all available. If you like a talk or disliked one, make sure to leave feedback.

This year the conference was a social event. I've met plenty of "old" or not so old friend. I've counted 33 people, not counting my previous manager and her daughter. I know I have missed at least 3 people. Very nice conversation with many of these people. I really was a pleasure to meet and interact.

The highlight of this FOSDEM was seeing he Sun sparc station 4 on one of the stands.

More Photos from another Mozillian, https://www.flickr.com/photos/202973669@N04/albums/72177720331827377/

04 Feb 2026 8:40am GMT

This Week In Rust: This Week in Rust 637

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official
Foundation
Newsletters
Project/Tooling Updates
Observations/Thoughts
Rust Walkthroughs
Research

Crate of the Week

This week's crate is vortex, a linux only io_uring based BitTorrent library and TUI.

Thanks to Nehliin for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker. * **Oxidize Conference | CFP open until 2026-03-23 | Berlin, Germany | 2026-09-14 - 2026-09-16

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

530 pull requests were merged in the last week

Compiler
Library
Cargo
Rustdoc
Clippy
Rust-Analyzer
Rust Compiler Performance Triage

Overall a positive week for instruction counts (~1% improvement on check/debug/opt/doc builds). Cycle counts and memory usage remain broadly unchanged across the week though.

Triage done by @simulacrum. Revision range: ebf13cca..a60d12cb

0 Regression, 6 Improvements, 3 Mixed; 3 of them in rollups 33 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

Rust

Compiler Team (MCPs only)

Language Team
Unsafe Code Guidelines

No Items entered Final Comment Period this week for Rust RFCs, Cargo, Language Reference or Leadership Council.

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

Upcoming Events

Rusty Events between 2026-02-04 - 2026-03-04 🦀

Virtual
Asia
Europe
North America
Oceania

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

In C++, the muscle memory you develop over time is avoidant. You learn not to do certain things. It's a negative memory, not in a pejorative sense, but in the sense that you have to remember what not to do rather than what to do: a list of patterns to avoid, of traps to dodge. And this list keeps growing, because the language doesn't prevent you from falling into the traps, you just have to remember they exist.

In Rust, muscle memory is constructive. You learn patterns that are inherently correct. You don't have to remember what to avoid because the compiler won't let you do it. Instead of thinking "I must remember not to leave the door open", you learn to build a door that closes by itself.

- Marco Bollero on dev.to

Given an acute lack of suggestions, llogiq is pretty thankful to himself for having found a quote regardless.

Please submit quotes and vote for next week!

This Week in Rust is edited by:

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

04 Feb 2026 5:00am GMT