20 Feb 2026
Planet Mozilla
Mozilla Privacy Blog: Behind the Velvet Rope: The AI Divide on Display at the India AI Impact Summit 2026
TLDR: No one could agree what 'sovereignty' means, but (almost) everyone agreed that AI cannot be controlled by a few dominant companies.
This past week, droves of AI experts and enthusiasts descended on New Delhi, bringing their own agendas, priorities, and roles in the debate to the table.
I scored high for my ability to move between cars, rickshaws and foot for transport (mostly thanks to colleagues), but low for being prepared with snacks. So, based on my tightly packed agenda combined with high hunger levels, here's my read out:
The same script, different reactions
As with any global summit, the host government made the most of having the eyes of the world and deep pockets of AI investors in town. While some press were critical of India seeking deals and investments, it wasn't notable - or outside of the norm.
What should be notable, and indeed were reflected in the voluntary agreements, were the key themes that drove conversations, including democratisation of AI, access to resources, and the vital role of open source to drive the benefits of AI. These topics were prominent in the Summit sessions and side events throughout the week.
In the name of innovation, regulation has become a faux pas
The EU has become a magnet for criticism given its recent attempts to regulate AI. I'm not going to debate this here, but it's clear that the EU AI Act (AIA) is being deployed and PRed quite expertly as a cautionary tale. While healthy debate around regulation is absolutely critical, much of the public commentary surrounding the AIA (and not just at this Summit) has been factually incorrect. Interrogate this reality by all means - we live in complex times - but it's hard not to see invalid criticisms as a strategic PR effort by those who philosophically (and financially) opposed governance. There is certainly plenty to question in the AIA, but the reality is much more nuanced than critics suggest.
What's more likely to kill a start up: the cost of compliance, or the concentration of market power in the hands of a few dominant players? It's true that regulation can absolutely create challenges. However, it is also worth looking at whether the greater obstacle is the control a small number of tech companies hold. A buy-out as an exit is great for many start-ups, but if that is now the most hopeful option, it raises important questions about the long-term health and competitiveness of the larger tech ecosystem.
A note of optimism: developing global frameworks on AI may still seem like a pipe dream in today's macro political climate, but ideas around like-minded powers working together and building trust makes me think that alignment beyond pure voluntary principles may be something we see grow. Frequent references to the Hiroshima Process as a middle ground were notable.
AI eats the world
There were pervasive assumptions that bigger - and then bigger still - is the inevitable direction of AI deployment, with hyperscale seen as the only viable path forward, in terms of inputs needed. However, the magnitude of what's required to fuel the current LLM-focused market structure met a global majority-focused reality: hyperscaling isn't sustainable. There were two primary camps at the Summit - the haves and the rest of us - and while the Summit brought them together, the gulf between them continues to grow.
Open source has to win
At the first AI Safety Summit in the UK, the concept of open source AI was vilified as a security risk. At the France AI Action Summit, the consensus began to shift meaningfully. At the India AI Impact Summit, we saw undeniable recognition of the vital role that open source plays in our collective AI future.
With proprietary systems, winning means owning. With open source approaches, winning means we're not just renting AI from a few companies and countries: we're working collectively to build, share, secure and inspect AI systems in the name of economic growth and the public interest. Before the Paris Summit, this was a difficult vision to push for, but after New Delhi, it's clear that open source is on the right side of history. Now, it's time for governments to build out their own strategies to promote and procure this approach.
Consolidation ≠ Competition
Global South discussions made one message clear: dependency orientated partnerships are not true partnerships and they're not a long term bet. Many countries are becoming more vocal that they want autonomy of their data and choice in their suppliers to lessen harmful impacts on citizens, and increase their impact to responsibly govern.
That is not today's reality.
I was, however, encouraged to find that attendees were far less starry-eyed over big tech than at previous Summits. The consensus agreed that it met no one's definition of sovereignty for a select few companies to own and control AI.
Despite agreement amongst the majority, addressing market concentration remained an elephant in the room. The narrative deployed against regulation became a blanket mantra, applied to anything from AI governance to competition action. However, it fails to address the fact that the AI market is already skewed toward a small number of powerful companies and traditional competition rules that act only after problems arise (and often through long legal processes) are not enough to keep up with fast-paced digital industries.
Some participants were downbeat and questioned if it was too late. The challenge is in demonstrating that it isn't. There is no single approach. But we know that concentration can be countered with a mix of technical and legal interventions. Options can be sweeping, or lighter touch and surgical in their focus. We are currently seeing is a wave of countries pass, draft, debate and consider new ex ante rules, providing learnings, data and inspiration.
It's important that we watch this space.
Whose safety are we talking about exactly?
The India AI Impact Summit has been criticised for letting safety discussions fall off the radar. That's not necessarily true. Instead of focusing on the view that AI is a cause for human annihilation, discussions focused on impacts that we can evidence now: on language, culture, bias, online safety, inclusion, and jobs.
Less headline-grabbing, less killer robots, far more human.
The path forward
It's difficult to know if these Summits will continue in the long term. There is a lot of fuss, expense, marketing, diplomacy, traffic and word salads involved. However, the opportunity to convene world leaders, businesses, builders, engineers, civil society and academics in one place, for what we are constantly reminded is a transformational technology, feels needed. Tracking progress on voluntary commitments over time might be illustrative. And while many of the top sessions are reserved for the few, witnessing the diverse debates this past week gives me hope that there is an opportunity for the greater voice to shape AI to be open, competitive and built for more than just the bottom line.
The post Behind the Velvet Rope: The AI Divide on Display at the India AI Impact Summit 2026 appeared first on Open Policy & Advocacy.
20 Feb 2026 8:47pm GMT
19 Feb 2026
Planet Mozilla
The Rust Programming Language Blog: Rust participates in Google Summer of Code 2026
We are happy to announce that the Rust Project will again be participating in Google Summer of Code (GSoC) 2026, same as in the previous two years. If you're not eligible or interested in participating in GSoC, then most of this post likely isn't relevant to you; if you are, this should contain some useful information and links.
Google Summer of Code (GSoC) is an annual global program organized by Google that aims to bring new contributors to the world of open-source. The program pairs organizations (such as the Rust Project) with contributors (usually students), with the goal of helping the participants make meaningful open-source contributions under the guidance of experienced mentors.
The organizations that have been accepted into the program have been announced by Google. The GSoC applicants now have several weeks to discuss project ideas with mentors. Later, they will send project proposals for the projects that they found the most interesting. If their project proposal is accepted, they will embark on a several months long journey during which they will try to complete their proposed project under the guidance of an assigned mentor.
We have prepared a list of project ideas that can serve as inspiration for potential GSoC contributors that would like to send a project proposal to the Rust organization. However, applicants can also come up with their own project ideas. You can discuss project ideas or try to find mentors in the #gsoc Zulip stream. We have also prepared a proposal guide that should help you with preparing your project proposals. We would also like to bring your attention to our GSoC AI policy.
You can start discussing the project ideas with Rust Project mentors and maintainers immediately, but you might want to keep the following important dates in mind:
- The project proposal application period starts on March 16, 2026. From that date you can submit project proposals into the GSoC dashboard.
- The project proposal application period ends on March 31, 2026 at 18:00 UTC. Take note of that deadline, as there will be no extensions!
If you are interested in contributing to the Rust Project, we encourage you to check out our project idea list and send us a GSoC project proposal! Of course, you are also free to discuss these projects and/or try to move them forward even if you do not intend to (or cannot) participate in GSoC. We welcome all contributors to Rust, as there is always enough work to do.
Our GSoC contributors were quite successful in the past two years (2024, 2025), so we are excited what this year's GSoC will bring! We hope that participants in the program can improve their skills, but also would love for this to bring new contributors to the Project and increase the awareness of Rust in general. Like last year, we expect to publish blog posts in the future with updates about our participation in the program.
19 Feb 2026 12:00am GMT
18 Feb 2026
Planet Mozilla
This Week In Rust: This Week in Rust 639
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
- Announcing Rust 1.93.1
- crates.io: an update to the malicious crate notification policy
- This Development-cycle in Cargo: 1.94
Newsletters
Project/Tooling Updates
- stochastic-rs: stochastic/quant simulations (and more)
- Banish v1.1.4: rule-based state-machine DSL
- Building Volatility Surfaces in Rust
- diesel-guard v0.6.0: custom checks for Postgres migrations
- Selium WebAssembly Hypervisor is in Alpha
- FerroTunnel: high-performance reverse tunnel
- Compendium: strace like tracer
- Containerized shell sessions with Shell-Cell
- Introducing SurrealDB 3.0 - AI agent memory
- sighook 0.9.0: prepatched hook APIs
Observations/Thoughts
- How Rust and Its Compiler Have Revolutionized Software Engineering and Reliability
- Async/await on the GPU
- The Evolution of Async Rust: From Tokio to High-Level Applications
Rust Walkthroughs
- Introduction to writing RISC-V contracts in Rust on Polkadot
- Shipping My Rust CLI to Windows: Lessons Learned (feat. Windows 98 and APE Bonus)
- Visualizing Persistent Vectors with Rust and WebAssembly
- Recreating PlanetScale's pg_strict in Rust: A Build Log
- [series] Part 5: A Witless Fool, Building an LLM from Scratch in Rust
Miscellaneous
Crate of the Week
This week's crate is banish, a proc macro to build rule-driven state machines using a declarative DSL.
Thanks to Logan Flaherty 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.
- Rust India Conference 2026 | CFP open until 2026-03-14 | Bangalore, IN | 2026-04-18
- 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
564 pull requests were merged in the last week
Compiler
- handle race when coloring nodes concurrently as both green and red
- implement RFC 3678: Final trait methods
- replace
box_newwith lower-level intrinsics - shallow resolve ty and const vars to their root vars
- show what lint was overruled
Library
- implement feature
float_exact_integer_constants - implement
BinaryHeap::from_raw_vec - implement
carryless_mul - support ADT types in type info reflection
- optimize indexing slices and strs with inclusive ranges
- stabilize
assert_matches
Cargo
lints: Don't run on-by-default lints when MSRV is too oldlockfile-path: Respect the config in fix, installscript: Load config relative to the scriptscript: Make the lockfile script-specific independent of build-dir- changed build script run
outputdir tostdoutin new build-dir layout - suggest a
workspace.membersentry even from outside the workspace root
Rustdoc
Clippy
- assume that any external function might return a type alias
- do not lint main function in
must_use_candidates - extend
iter_kv_mapto coverflat_mapandfilter_map - fix
RustcCallbacks::config()inclippy-driver
Rust-Analyzer
- improve hover too long parameter list
- fix
smol_strcompilation error - fix complete semicolon in array expression
- fix incorrect Self path expand for
inline_call - do not resolve proc macros in value ns (as functions), only in macro ns, outside their defining crate
- don't assume
extern fns parameters are patterns - handle
ref mutbindings incontains_explicit_ref_binding - use
ExprIsRead::Yesfor rhs of ordinary assignments - migrate
covert_tuple_return_typetostructassist to syntax editor - migrate
generate_implassist to use AstNodeEdit - migrate
introduce_named_lifetimeassist to SyntaxEditor - migrate destructure tuple binding assist to syntaxEditor
- remove mutable edit in place with
edit::AstNodeEditin migrated assist handlers
Rust Compiler Performance Triage
Several pull requests introduced (usually very small) regressions across the board this week. On the other hand, #151380 provided a nice performance win in the inference engine. I would also like to bring attention to #152375, which improved the parallel frontend. It is not shown in this report, because we don't yet have many benchmarks for the parallel frontend, but this PR seemingly improved the check (wall-time) performance with multiple frontend threads on several real-world crates by 5-10%!
Triage done by @kobzol. Revision range: 39219ceb..3c9faa0d
Summary:
| (instructions:u) | mean | range | count |
|---|---|---|---|
| Regressions ❌ (primary) |
0.7% | [0.2%, 3.1%] | 96 |
| Regressions ❌ (secondary) |
1.1% | [0.0%, 5.7%] | 62 |
| Improvements ✅ (primary) |
-0.4% | [-0.9%, -0.2%] | 8 |
| Improvements ✅ (secondary) |
-2.6% | [-7.0%, -0.0%] | 45 |
| All ❌✅ (primary) | 0.6% | [-0.9%, 3.1%] | 104 |
2 Regressions, 0 Improvements, 9 Mixed; 4 of them in rollups 36 artifact comparisons made in total
Approved RFCs
Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:
- No RFCs were approved 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
- Inhibit all-absent-variant optimization for all enum reprs that inhibit layout optimization, not just repr(C).
- stabilize
cfg_select! - ptr::replace: make calls on ZST null ptr not UB
- Never break between empty parens
No Items entered Final Comment Period this week for Rust RFCs, Cargo, Language Team, Language Reference, 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-18 - 2026-03-18 🦀
Virtual
- 2026-02-18 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
- 2026-02-18 | Virtual (Girona, ES) | Rust Girona
- 2026-02-19 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
- 2026-02-24 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- 2026-02-24 | Virtual (London, UK) | Women in Rust
- 2026-02-25 | Virtual (Girona, ES) | Rust Girona
- 2026-02-26 | Virtual (Berlin, DE) | Rust Berlin
- 2026-03-04 | Virtual (Indianapolis, IN, US) | Indy Rust
- 2026-03-05 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
- 2026-03-05 | Virtual (Nürnberg, DE) | Rust Nuremberg
- 2026-03-07 | Virtual (Kampala, UG) | Rust Circle Meetup
- 2026-03-10 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
- 2026-03-10 | Virtual (London, UK)| Women in Rust
- 2026-03-12 | Virtual (Berlin, DE) | Rust Berlin
- 2026-03-17 | Virtual (Washington, DC, US) | Rust DC
- 2026-03-18 | Virtual (Vancouver, BC, CA) | Vancouver Rust
Asia
- 2026-02-21 | Bangalore, IN | Rust Bangalore
- 2026-02-23 | Tel Aviv-yafo, IL | Rust 🦀 TLV
Europe
- 2026-02-18 - 2026-02-19 | London, UK | Rust Nation UK
- 2026-02-19 | Mountain View, CA, US | Hacker Dojo
- 2026-02-24 | Bergen, NO | Rust Bergen
- 2026-02-24 | Manchester, UK | Rust Manchester
- 2026-02-25 | Copenhagen, DK | Copenhagen Rust Community
- 2026-02-26 | Prague, CZ | Rust Czech Republic
- 2026-02-28 | Stockholm, SE | Stockholm Rust
- 2026-03-04 | Barcelona, ES | BcnRust
- 2026-03-04 | Hamburg, DE | Rust Meetup Hamburg
- 2026-03-04 | Oxford, UK | Oxford ACCU/Rust Meetup.
- 2026-03-12 | Geneva, CH | Post Tenebras Lab
- 2026-03-18 | Dortmund, DE | Rust Dortmund
North America
- 2026-02-18 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
- 2026-02-19 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
- 2026-02-19 | Nashville, TN, US | Music City Rust Developers
- 2026-02-21 | Boston, MA, US | Boston Rust Meetup
- 2026-02-25 | Austin, TX, US | Rust ATX
- 2026-02-25 | Los Angeles, CA, US | Rust Los Angeles
- 2026-02-26 | Atlanta, GA, US | Rust Atlanta
- 2026-02-26 | New York, NY, US | Rust NYC
- 2026-02-28 | Boston, MA, US | Boston Rust Meetup
- 2026-03-05 | Saint Louis, MO, US | STL Rust
- 2026-03-07 | Boston, MA, US | Boston Rust Meetup
- 2026-03-14 | Boston, MA, US | Boston Rust Meetup
- 2026-03-17 | San Francisco, CA, US | San Francisco Rust Study Group
Oceania
- 2026-02-24 | Canberra, AU | Rust Canberra
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
Clearly there is such a thing as too much syntactic sugar (as one of my professors put it, "syntactic sugar causes semantic cancer"), but at the same time also clearly some syntactic sugar is worth having.
Thanks to robofinch for the suggestion!
Please submit quotes and vote for next week!
This Week in Rust is edited by:
- nellshamrell
- llogiq
- ericseppanen
- extrawurst
- U007D
- mariannegoldin
- bdillo
- opeolluwa
- bnchi
- KannanPalani57
- tzilist
Email list hosting is sponsored by The Rust Foundation
18 Feb 2026 5:00am GMT