discordAug 6, 2026

General Availability of Mobile Platform Support Arrives in Discord Social SDK Version 1.10 (opens in new tab)

Discord Social SDK 1.10 makes mobile support generally available for iOS and Android, extending Discord’s social features into mobile games. The update focuses on reducing friction through improved Account Linking, richer Rich Presence options, and mobile commerce. Early partners including Tencent, Scopely, and Ninja Kiwi report stronger social engagement, easier squad formation, and increased community activity. ## Mobile Platform Support - The SDK supports: - Android 7.0 and later - iOS 15.1 and later - C++, Unreal Engine, and Unity projects - The goal is to bring desktop-like Discord social experiences to smaller screens and on-the-go play. - Discord says the SDK was refined with launch partners and tested against real mobile player behavior. ## Rich Presence on Android - Android games can now share live Rich Presence through multiple methods: - Account Linking - Remote Procedure Call (RPC) - These integrations improve game visibility and help players share what they are playing with their Discord communities. ## Faster Mobile Account Linking - Deeplink support simplifies the account-linking process. - Players can connect their Discord accounts directly and with fewer steps. - The reduced friction is intended to improve retention, engagement, onboarding, and campaign activation. ## Discord Social Commerce on Mobile - Discord is expanding Social Commerce to mobile games. - Developers can sell in-game items through Discord to existing players, friends, and potential new customers. - Early Marvel Rivals pilot results showed: - 41% of purchases were gifts. - 25% of gift buyers were lapsed or new players. - These results suggest Discord’s social graph can support both monetization and player acquisition. ## Tencent: Arena Breakout - Arena Breakout used the SDK to address fragmented cross-platform friend networks and slow squad formation. - Its integration included: - A Unified Friends List - Game Invites - Improved mobile Account Linking - Reported outcomes included faster squad formation, more cross-platform messaging, and increased activity in the game’s official Discord server. - Tencent plans to combine Discord social features with limited-time in-game events. ## Scopely: Marvel Strike Force - Scopely integrated Discord into its turn-based RPG to support: - Player communication - Alliance management - Community interaction - Customer support and moderation - The integration produced immediate account linking among new players and rapid creation of alliance channels. - Community feedback was strongly positive, with players mainly wishing the integration had arrived earlier. ## Tencent: Delta Force - Delta Force used Discord to connect in-game play with its broader player community. - The initial integration focused on Account Linking and the Unified Friends List. - Single-tap mobile linking replaced browser redirects and manual logins, improving onboarding and campaign activation. - The integration supported squad formation and community-created content, with future plans for Discord discoverability and Rich Presence invites. ## Ninja Kiwi: Bloons TD 6 - Bloons TD 6 began integrating the SDK with Account Linking and the Unified Friends List. - The provided article text ends before describing the full integration or its results. The update positions Discord’s Social SDK as a way for mobile developers to strengthen retention, social discovery, community participation, and monetization. Developers targeting mobile games should consider the SDK’s deeplink Account Linking, Android Rich Presence, Unified Friends List, invites, and emerging commerce capabilities.

c++androidiosaccount-linking+4

cloudflareMay 18, 2026

Project Glasswing: what Mythos showed us (opens in new tab)

Project Glasswing found that Anthropic’s Mythos Preview represents a major advance in AI-assisted vulnerability research. Unlike conventional scanners, it can combine multiple low-level bugs into a credible exploit chain and generate working proofs by writing, compiling, and testing code iteratively. However, inconsistent refusals and a high rate of speculative findings mean capable models still require strong safeguards and human-led validation before large-scale deployment. ## Exploit Chain Construction - Mythos Preview can combine several seemingly minor vulnerabilities into a complete attack. - It can reason from primitives such as use-after-free bugs to arbitrary read/write access, control-flow hijacking, and ROP-based system takeover. - Earlier frontier models often identified individual bugs but failed to connect them into a working exploit. - This ability can elevate low-severity findings that might otherwise remain ignored in vulnerability backlogs. ## Automated Proof Generation - The model does more than describe suspected vulnerabilities: - Writes proof-of-concept code. - Compiles it in a scratch environment. - Executes it and checks whether the expected behavior occurs. - Revises its hypothesis when testing fails. - This feedback loop distinguishes plausible speculation from demonstrated exploitability. ## Inconsistent Model Refusals - Mythos Preview lacked the additional safeguards used in generally available models, but still developed emergent refusals around some offensive security tasks. - These refusals were inconsistent: - The same research task could succeed after an unrelated environmental change. - The model might confirm serious memory bugs but refuse to create an exploit. - Rephrasing the request or repeating it could produce a different result. - Organic model guardrails are therefore not reliable enough to act as a complete safety boundary. - Future publicly available cyber-capable models will need additional, deliberate safeguards beyond their learned behavior. ## The Signal-to-Noise Problem - Vulnerability research still requires determining which findings are real, exploitable, and urgent. - AI tools increase the volume of speculative findings, making triage more difficult. - Two major factors affect noise levels: - **Programming language:** C and C++ expose developers to memory bugs such as buffer overflows and out-of-bounds access, while memory-safe languages such as Rust eliminate many of these classes at compile time. Memory-unsafe projects produced more false positives. - **Model bias:** Models tend to report possible vulnerabilities even when evidence is weak, using qualifications such as “possibly” or “could in theory.” - Exploratory over-reporting may help discover novel issues, but it is costly in a production triage queue because each speculative finding consumes analyst time and model resources. ## Scaling AI-Assisted Security Research - Mythos Preview’s capabilities justify treating it as a different class of security tool rather than simply a better conventional scanner. - Scaling these systems will require: - Post-validation stages to filter speculative findings. - Sandboxed environments for compiling and testing proofs. - Human review of exploit chains and severity. - Explicit safety controls that do not depend solely on model refusals. - The main challenge is no longer only whether models can find vulnerabilities, but whether organizations can reliably validate, prioritize, and safely manage their output. Organizations should use advanced security models in controlled environments with layered safeguards and rigorous validation. Their ability to construct exploits is powerful, but their inconsistent safety behavior and noisy findings make unsupervised use inappropriate.

c++rustmemory-safetyllm-security+4

metaApr 9, 2026

Escaping the Fork: How Meta Modernized WebRTC Across 50+ Use Cases (opens in new tab)

Meta escaped the “forking trap” by replacing its divergent WebRTC fork with a modular architecture based on the latest upstream release. The system builds legacy and current WebRTC versions side by side, enabling runtime A/B testing across more than 50 use cases before rollout. This improved performance, binary size, and security while establishing a repeatable process for continuous upstream upgrades. ## Why the WebRTC Fork Became a Problem - Meta’s RTC stack supports Messenger, Instagram video calls, Cloud Gaming, and Meta Quest casting. - Internal optimizations and bug fixes gradually caused its WebRTC fork to diverge from upstream. - As the fork accumulated custom changes, merging community improvements became increasingly expensive and risky. - A one-time upgrade was impractical because WebRTC serves billions of users across diverse devices and environments. ## Requirements for a Sustainable Upgrade Strategy - Meta needed to: - Run legacy and upstream-based WebRTC implementations simultaneously. - Dynamically assign users to either version for safe A/B testing. - Statically link both versions into the same application. - Maintain custom patches in a monorepo without repeatedly rebuilding the migration process. - Standard patch-file workflows were considered difficult to scale for Meta’s large codebase. ## Shim Layer and Dual-Stack Architecture - A shim library was placed between application code and WebRTC. - Applications call a unified, version-neutral API rather than calling either WebRTC implementation directly. - A runtime “flavor” configuration routes each call to either the legacy or latest implementation. - Shimming at the lowest practical layer avoided duplicating the higher-level call orchestration library: - Full duplication would have added about 38 MB uncompressed. - The shim-based design added roughly 5 MB, an 87% reduction. ## Resolving C++ Symbol Collisions - Linking two WebRTC copies normally violates the C++ One Definition Rule and creates thousands of duplicate symbols. - Meta automated namespace rewriting: - `webrtc::` in the current version became `webrtc_latest::`. - The legacy version became `webrtc_legacy::`. - Global functions, variables, and classes outside namespaces were moved into namespaces where possible or assigned flavor-specific names. - Macro conflicts, including `RTC_CHECK` and `RTC_LOG`, were addressed by: - Removing unnecessary includes. - Renaming infrequently used macros. - Sharing modules such as `rtc_base` between versions to reduce duplication and shimming work. ## Preserving Backward Compatibility - Renaming symbols could have broken existing call sites, especially code built for only one WebRTC flavor. - An initial solution forward-declared every required symbol, but this created a large and fragile maintenance burden. - The improved approach used C++ `using` declarations to bulk-import a flavor namespace into the familiar `webrtc::` namespace. - This preserved existing source-level APIs without adding binary overhead, while allowing Meta to migrate selected call sites incrementally. ## Runtime Flavor Dispatch - Shim adapters and converters must instantiate objects from either the legacy or current namespace. - A template-based helper library keeps shared adapter logic in one place. - Template specializations handle version-specific behavior. - A global flavor enum, initialized during application startup, determines which WebRTC implementation is used. - The design also supports single-flavor builds during the transition. Meta’s approach demonstrates that large internal modifications do not have to require a permanent fork. A low-level shim, automated renamespacing, compatibility imports, and template-based dispatch provide a practical foundation for continuously rebasing custom functionality onto upstream WebRTC while safely validating each release through A/B testing.

c++monorepoab-testingwebrtc+4

tossMar 17, 2026

Embracing the Software 3.0 Era (opens in new tab)

Software 3.0 replaces hand-written rules with natural-language instructions to LLMs, but models alone cannot reliably perform real-world work. The missing piece is the harness: tools, context, and environments that connect an LLM to codebases, commands, databases, and users. Claude Code illustrates how familiar Software 1.0 architecture can guide agent design while adding a new capability—asking humans for judgment when uncertainty arises. ## From Software 1.0 to Software 3.0 - **Software 1.0:** Developers explicitly write logic using languages such as Python, Java, or C++. - **Software 2.0:** Data and training produce neural-network weights that function as the program. - **Software 3.0:** Prompts and natural-language instructions direct LLM behavior. - Karpathy’s central claim is that Software 3.0 is increasingly absorbing both traditional code and trained models. ## Harnesses Make LLMs Useful - A raw LLM cannot independently read a codebase, execute commands, modify files, or access databases. - A **harness** supplies the tools and environment needed to turn model capability into practical work. - Claude Code is presented as a harness for Claude: it transforms a language model into an agent capable of completing and shipping tasks. ## Mapping Agent Concepts to Layered Architecture The terminology of agent systems can be understood through familiar Software 1.0 design patterns: - **Slash commands → Controllers** - They serve as entry points for user requests, such as `/review` or `/refactor`. - **Sub-agents → Service layer** - They coordinate multiple skills to complete a workflow. - Each sub-agent has an independent context and acts as a self-contained unit of work. - **Skills → Domain components** - Each skill should have one focused responsibility, such as reviewing code, generating tests, or writing documentation. - **MCP → Infrastructure or adapters** - MCP provides abstraction boundaries for external systems such as APIs and databases. - **CLAUDE.md → Project constitution** - It records stable project information: technology choices, conventions, and build commands. - Frequently changing task details should be provided through the conversation or injected into an agent’s context instead. ## Agent Design Has Familiar Anti-Patterns Traditional code smells also apply to agent systems: - **Feature Envy:** A skill relies excessively on another skill’s data. - **Duplication:** Prompts are copied across multiple skills. - **Long Method:** A single sub-agent performs an overly long sequence of many skills. - Clear boundaries, single responsibility, and limited coupling remain valuable. ## The Difference: Agents Can Ask Humans Layered architecture generally requires every failure and edge case to be handled through predefined exceptions, policies, or branches. - Traditional code must decide what to do when an unusual case occurs. - An agent using human-in-the-loop interaction can pause and ask the user for clarification. - In this model, exceptions become questions, allowing the agent to continue after receiving a decision. Agents should ask when: - An action is difficult to reverse, such as deletion or deployment. - Several valid options exist without a clear best choice. - The decision has significant consequences. They should proceed automatically when: - The operation is safely repeatable. - Existing conventions provide a clear answer. - The action is easy to undo. ## What Carries Forward into Software 3.0 The new paradigm does not make established engineering practices irrelevant. - Move away from explicitly coding every possible rule and edge case. - Do not reduce LLMs to simple autocomplete tools. - Preserve layered design, single responsibility, abstraction, dependency management, and interface design. - Continue emphasizing testability, debugging, code review, and iterative improvement. The practical approach is to combine Software 3.0’s flexible reasoning with Software 1.0’s architecture and engineering discipline, while giving agents a clear way to involve humans when decisions require judgment.

c++llmk8sreact+4

figmaOct 14, 2024

The Infrastructure Behind AI Search in Figma | Figma Blog (opens in new tab)

Figma’s AI search lets users find designs and components through text, screenshots, or layer selections. It relies on multimodal embeddings, vector nearest-neighbor search, and large-scale indexing of frames and components. The main infrastructure challenge was generating and indexing billions of embeddings efficiently while controlling costs. ## AI-Powered Search Flows - **Search for designs** indexes frames across users’ files, including unlabeled frames buried in complex files. - Users can search designs: - Lexically with a text description - Visually with a screenshot - By selecting similar Figma layers - **Search for components** enhances the Assets panel with semantic matching. - A component representing 😀 can be found with terms such as “smiley,” “happy,” “face,” or “grin.” - Designers no longer need to manually add every possible keyword to component descriptions. - Components can also be found using visual queries. ## Multimodal Embeddings - An embedding model converts text or images into numerical vectors that represent their meaning. - Figma uses the open-source **CLIP** model, which places text and images in the same embedding space. - The embedding for the word “cat” should be numerically close to an embedding generated from an image of a cat. - Figma’s models were not trained on private customer files or data. - Fine-tuning used interface images from public, free Community files. - Search works by: - Generating embeddings for indexed content - Creating an embedding for the user’s query - Finding indexed vectors that are nearest to the query vector - Figma tested embeddings based on textual representations such as JSON, but image-based embeddings produced better results and supported the same workflow as screenshot search. - Layer selections are converted into screenshots before being passed to the embedding model. ## Populating the Vector Search Index - Each searchable item requires: - A thumbnail or rendered screenshot - An embedding - Metadata stored in the search index - Figma uses DynamoDB for metadata and embeddings because the workload primarily requires high-throughput key-value reads and writes. - Identifying searchable frames is difficult because unpublished frames are not directly enumerable. - Figma runs a headless, server-side version of its C++ editor in asynchronous jobs to discover frames within files. - These jobs use server-side sandboxing techniques to safely run the editor. Figma’s approach combines CLIP-based multimodal representations, server-side rendering, asynchronous processing, and scalable vector storage to make visual and semantic search practical across large design systems.

c++multimodal-aivector-dbembeddings+2

datadogMay 21, 2024

Engineering VP spotlight: Ivo Dimitrov (opens in new tab)

Ivo Dimitrov’s career evolved from low-level systems programming into engineering leadership focused on large-scale distributed storage. His experience at Microsoft and LinkedIn shaped his approach to building scalable data platforms, while Datadog attracted him with its talented people, modern technology, and culture of experimentation. Today, he leads Datadog’s Distributed Data Systems organization, supporting the company’s metrics, events, query, alerting, and analytics infrastructure. ## From Electrical Engineering to Systems Programming - Dimitrov initially studied electrical engineering and became interested in software while working on digital control systems. - His early work included contributing to a real-time operating system kernel. - He spent roughly a decade as an individual contributor, specializing in: - High-performance systems - Low-level programming - C and C++ - System software ## Transition from Individual Contributor to Manager - At Microsoft, Dimitrov worked on an early version of Azure Blob Storage. - Following a reorganization, he accepted an opportunity to lead his team despite having no prior management experience. - Microsoft supported the transition through: - Leadership mentorship - Formal management training - Guidance on communication, conflict resolution, and interpersonal leadership - He discovered that management allowed him to expand his ownership beyond individual projects and influence broader organizational outcomes. - The role combined his technical background with responsibilities such as cross-functional coordination, team development, and engineering strategy. ## Building Internet-Scale Storage at Microsoft and LinkedIn - At Microsoft, Dimitrov worked on storage systems supporting Hotmail. - After joining LinkedIn in 2014, he adapted to a technology environment centered on open source tools such as MySQL and Java. - He led development of Espresso, LinkedIn’s proprietary key-value storage platform. - The platform matured into a core system supporting approximately 95 percent of LinkedIn’s data sets. - He also helped oversee several other large-scale storage projects: - **Venice**, an open source platform for serving derived data - **Ambry**, an open source blob storage system - **Helix**, an open source cluster manager - These systems supported critical parts of LinkedIn’s internet-scale infrastructure. ## Why Datadog Was Appealing - Dimitrov was drawn to Datadog by three main factors: - Highly capable engineers and leaders - Interesting, modern technology - The opportunity to contribute to a rapidly growing company - Compared with the legacy systems and processes that had accumulated at LinkedIn, Datadog offered less bureaucracy and more freedom to: - Take thoughtful risks - Experiment - Deliver quickly - Fail fast and learn - Iterate and innovate - He was particularly interested in Datadog’s Kubernetes-based Metrics and Events platforms and the challenge of building best-in-class infrastructure during the company’s growth. ## Distributed Data Systems at Datadog - Dimitrov leads the Distributed Data Systems organization, which owns a portfolio of storage and data technologies. - Its responsibilities include: - **Metrics**, supporting metrics and time-series data - **Events**, handling semi-structured data such as logs, profiles, and traces - **Driveline**, a main-memory database optimized for online analytics - The **Cross-Platform Queries** team provides a unified query interface across systems that historically exposed separate, domain-specific APIs. - This reduces the learning curve for engineers and customers. - It abstracts the underlying data stores behind a common API. - The organization also operates Datadog’s Alerts platform, which generates a large share of the queries sent to the Metrics and Events systems. Dimitrov’s experience demonstrates how deep systems expertise can translate into effective engineering leadership. His recommendation by example is to remain technically engaged while expanding one’s scope—from writing individual components to shaping teams, platforms, and long-term engineering direction.

c++database-designk8spostgresql+4

figmaApr 24, 2024

Speeding Up C++ Build Times | Figma Blog (opens in new tab)

Figma cut C++ build times roughly in half by addressing unnecessary header inclusion rather than relying solely on faster hardware or caching. The team found that compiled bytes were growing much faster than the codebase itself, making transitive header dependencies the main culprit. They combined automated include analysis with CI-based measurement to prevent both unused includes and costly dependency regressions. ## Why Build Times Were Getting Worse - In 2023, Figma’s codebase grew by about 10%, but build times increased by 50%. - C++ builds were a major productivity problem and a top concern in internal developer surveys. - Faster M1 Max machines, Ccache, and remote caching provided only temporary or insufficient improvements. - The team observed that build times were closely related to the amount of code passed to the compiler after preprocessing. ## How C++ Header Inclusion Affects Builds - The preprocessor expands every `#include` into a single large file before compilation. - Transitive dependencies are included as well: - If file C includes B, and B includes A, C receives the contents of both A and B. - As a result, a small source change can cause the compiler to process a very large amount of unrelated code. ## Removing Unnecessary Includes - Figma suspected that many files included headers they did not use directly or relied on headers only for transitive dependencies. - Removing unnecessary includes from the largest files produced: - A 31% reduction in compiled bytes. - A 25% reduction in cold build time. - These results confirmed that compiled byte volume was strongly correlated with build performance. ## DIWYDU: Automating Include Cleanup - Google’s Include What You Use (IWYU) tool was considered but proved difficult to apply retroactively to Figma’s large codebase. - Figma created a less strict alternative called **Don’t Include What You Don’t Use (DIWYDU)**. - DIWYDU: - Uses Python bindings for `libclang`. - Parses source and header files into Clang Abstract Syntax Trees. - Identifies types, functions, and variables directly used by each file. - Flags headers that are included but provide no directly used symbols. - The tool runs on feature branches to prevent unnecessary includes from accumulating. ## DIWYDU’s Limitations - It analyzes Figma-owned files but excludes Standard Template Library headers. - STL headers may define symbols through private internal includes, making direct dependency analysis difficult. - Python’s `libclang` bindings expose less of Clang’s AST than the compiler’s native C++ APIs, sometimes producing `UNEXPOSED_EXPR` nodes. - A future C++ implementation could provide more accurate AST access. - DIWYDU cannot detect cases where an included header is genuinely required but excessively large. - Such regressions may need forward declarations or header decomposition instead. ## Measuring Dependency Growth with `includes.py` - Figma built `includes.py` to measure the transitive bytes associated with each source file. - The tool is written entirely in Python and typically runs in a few seconds without invoking Clang. - It: - Crawls first-party source, header, and generated files. - Counts file sizes. - Builds a dependency graph. - Estimates the total bytes passed to the compiler for each source file. - Standard library includes are treated as zero bytes because Figma mainly accesses them through internal wrapper directories. - CI uses the measurements to compare pull requests and warn authors when changes significantly increase compiled bytes. Figma’s approach demonstrates that controlling header dependencies can deliver larger and more durable gains than simply adding hardware or cache capacity. Teams working on large C++ codebases should automate unused-include checks, measure transitive dependency size in CI, and use forward declarations or smaller headers when necessary.

c++pythoncontinuous-integrationstatic-analysis+4

figmaOct 23, 2023

Server-side Sandboxing: An Introduction | Figma Blog (opens in new tab)

Server-side sandboxing helps contain the damage caused by vulnerabilities in software that processes untrusted user input. This is especially important for image processing, parsing, compression, and thumbnailing libraries often written in memory-unsafe languages, as demonstrated by ImageTragick. Figma argues that sandboxing complements—rather than replaces—secure coding by limiting a compromised workload’s access to data, services, and infrastructure. ## Why Server-Side Sandboxing Matters - Modern SaaS applications must process user-generated content using complex libraries. - Many of these libraries are written in C or C++, which are vulnerable to memory-corruption bugs. - ImageTragick showed how a vulnerability in ImageMagick could enable remote code execution when processing user-supplied images. - Preventing every vulnerability through rewrites, memory-safe languages, or program analysis is expensive and imperfect. - Sandboxing provides defense in depth by containing failures when vulnerabilities are exploited. ## Figma’s Server-Side Risk - Figma uses server-side components such as RenderServer, a C++ version of the editor, along with third-party libraries for graphical data. - Malicious input processed directly inside production infrastructure could allow an attacker to: - Access data belonging to other jobs - Make requests to internal production services - Move laterally through the environment - Compromise additional systems - Sandboxing reduces the external interfaces and resources available to potentially compromised workloads. ## Common Sandboxing Approaches - The article introduces three major sandboxing primitives: - **Virtual machines (VMs):** Isolate workloads through a hypervisor and separate guest operating systems. - **Containers:** Isolate workloads using operating-system-level mechanisms and container engines. - **Seccomp:** Restricts the system calls a program is permitted to make. - Each approach involves trade-offs in security properties, operational complexity, performance, and suitability for different workloads. - The article’s broader goal is to help teams compare these options and select an appropriate combination of isolation techniques. ## Choosing an Appropriate Strategy - Sandboxing technologies have historically been expensive, immature, or difficult to operate at scale. - Recent improvements have made virtualization, containment, and workload isolation more practical for a wider range of security teams. - Teams should evaluate sandboxing based on their workload’s risk, required interfaces, resource needs, and acceptable operational trade-offs. Teams should treat sandboxing as a practical layer of defense around risky processing workloads, rather than relying solely on preventing vulnerabilities.

c++webassemblyapplication-securitycontainers+3

figmaMay 2, 2023

How Figma Draws Inspiration From the Gaming World | Figma Blog (opens in new tab)

Figma’s technology shares more with a game engine than a traditional web application. Like games, it combines graphics rendering, interaction, multiplayer, animation, and other systems to create a responsive digital world. This architecture, along with close collaboration across engineering, design, product, and research, enables Figma and FigJam to support complex creative work in real time. ## Engineers as Digital World-Builders - Game engines combine foundational systems such as: - Graphics and rendering - User controls - Multiplayer - Physics and collisions - Animation - Artificial intelligence - Combat or other specialized mechanics - Figma similarly builds a 2D graphics and rendering system for the web. - Engineers ensure that text, shapes, and lines appear correctly while users pan and zoom across a canvas. - Collaboration is central to Figma, so its real-time collaboration engine is called “multiplayer,” inspired by cooperative games. - Figma and FigJam are built from many interacting “systems,” including: - Multiplayer editing - Spring animations - Audio and cursor chat - Component Variants - Plugins and widgets - Because these systems must run efficiently in browsers and mobile apps, Figma uses a game-engine-like stack rather than a conventional web stack. - The canvas is written in C++ and compiled to WebAssembly, helping address memory and performance constraints. ## Creativity Requires Systems-Level Collaboration - Game developers work closely with artists and designers to refine both technical behavior and user experience. - Figma follows a similar model, with engineers collaborating across product management, design, data science, and research. - Interdependent systems create emergent behavior: changing one system can affect many others. - The article compares this to *The Legend of Zelda: Breath of the Wild*, where fire can provide warmth and food, cause damage, or help defeat enemies. - Figma’s complexity produces comparable interactions, where an apparent problem in one feature may actually result from behavior elsewhere in the system. - This systems-level collaboration helps teams investigate unexpected failures and improve the overall product rather than treating each feature in isolation. Figma’s game-inspired approach is both architectural and cultural: build modular, interacting systems, optimize for real-time performance, and involve diverse disciplines in solving problems. Teams building similarly complex collaborative tools can benefit from treating the product as a living digital world rather than as a collection of disconnected web features.

c++real-time-collaborationrustwebassembly+3

figmaSep 22, 2020

Inside Figma: my time as a new grad | Figma Blog (opens in new tab)

The post argues that choosing a first job should involve more than checking boxes such as “interesting problems,” “smart people,” and “good culture.” Josh Shi reflects on joining Figma as a new graduate and encourages readers to examine how work fits into their broader lives, interests, and changing goals. His conclusion is that the most useful job-search framework is built around personal questions rather than universal criteria. ## Rethinking Work-Life Balance - Work and life are not opposing forces in a zero-sum equation. - The hours spent working and not working together constitute a person’s life, and each affects the other. - Job satisfaction can influence life outside work, just as personal circumstances can affect satisfaction at work. - Measuring balance only by the number of hours worked ignores the nature and meaning of the work. - The author acknowledges that treating work as a career is a privilege, especially during economic hardship or when employment is uncertain. - People who have the opportunity to choose should ask: - What kinds of work interest me? - Does this workplace support those interests? - Will I be able to learn and develop? - Can the role adapt as my interests change? - What skills or crafts can I build? - Does the job leave room for other interests? ## Learning as a New Graduate - At Figma, Shi gained new technical experience, including: - Full-stack development - Writing C++ for the web - More significantly, he learned to own features and participate in the full product-development process. - This included scoping projects, clarifying ambiguous goals, and taking ideas from inception through launch. - Mentorship and support from colleagues made it possible for him to challenge himself and take ownership. - The same people he met during his interview continued to provide guidance and expertise after he joined. ## Company Growth and Change - Figma had changed substantially during Shi’s first few years as the company and product expanded. - The company began transitioning toward a hybrid model, illustrating that workplaces evolve over time. - This reinforces the importance of considering not only whether a company fits current interests, but also whether it can accommodate future growth and changing priorities.

c++design-systemsproduct-developmentweb-development+1

figmaAug 5, 2020

Inside Figma: reflections on a remote internship | Figma Blog (opens in new tab)

Jenning Chen reflects on her remote internship at Figma and the process of taking improvements to the style picker from concept to launch. Despite concerns about isolation and communication, Figma’s intentional remote culture helped her build relationships, learn the product, and receive support. Her project added search, a color-style list view, and visible text-style metrics while giving her experience across Figma’s technology stack. ## A Warm Welcome - Slack messages, virtual coffee chats, and a collaborative welcome card helped Chen feel connected from the start. - Although the internship was fully remote, Figma maintained the open and welcoming culture that had first attracted her years earlier. ## Building Relationships Remotely - Chen initially worried that remote work would make it harder to form relationships or ask for help. - Company-wide events created regular opportunities to meet colleagues: - Show-and-tell meetings for sharing work and learnings - Thursday tech talks about coworkers’ interests and projects - One-on-ones about Figma’s product and growth - Virtual cooking classes, escape rooms, and scavenger hunts - These activities helped replace informal office interactions and encouraged connections beyond her immediate team. ## Developing Product Fluency - Before beginning her project, Chen needed to understand Figma’s features and design terminology. - She relied on her mentor, teammates, and Slack channels for answers. - Colleagues were willing to schedule calls and work through obstacles with her, making remote collaboration more effective than she expected. ## Improving the Style Picker - The style picker lets users browse and apply paint, text, effect, and layout-grid styles. - As users accumulated more styles, the original grid-based interface became difficult to navigate: - Important style information was obscured. - Users had to scroll through long lists. - Finding a specific style was inefficient. - Working with product designer Shana Hu, Chen implemented: - **Search:** Lets users find styles with a few keystrokes. - **Color styles list view:** Displays style names clearly beside thumbnails. - **Text style metrics:** Shows font size and line height directly in the picker. ## Technical and Launch Challenges - The project exposed Chen to multiple parts of Figma’s stack: - TypeScript and C++ in the editor - Ruby in the backend - She presented the work at an internal show-and-tell and received supportive feedback from coworkers. - Launch preparation required migrating millions of existing text styles to add font-size and line-height metadata. - The migration took an entire day, alongside the work of incorporating critique feedback and fixing last-minute bugs. The internship demonstrated that a thoughtfully structured remote environment can support mentorship, relationship-building, and meaningful ownership. Chen’s experience also shows how an intern can contribute to a high-impact product feature while gaining broad technical and product knowledge.

c++figmadesign-systemstypescript+2

figmaDec 6, 2015

Building a professional design tool on the web | Figma Blog (opens in new tab)

Figma set out to prove that a professional, high-fidelity design tool could run reliably in the browser. The challenge was that the web exposed specialized features rather than general-purpose graphics primitives, so Figma effectively had to build “a browser inside a browser.” Its solution combined C++ compiled through Emscripten with a custom rendering engine, enabling tighter control over memory, performance, and cross-platform consistency. ## Building Beyond the Web’s Original Design - The web was originally designed for documents, with application features added later as isolated APIs. - This limits advanced applications: - CSS provides sophisticated text layout but does not expose or customize the layout process. - Browsers have optimized GPU compositors, but developers cannot directly modify compositing or add custom blend modes. - Image decoders are highly optimized but offer limited control over details such as EXIF orientation and color-space handling. - Technologies such as WebGL and asm.js began exposing lower-level access to hardware, making demanding browser-based graphics applications practical. ## C++ and Emscripten - Figma’s editor was written in C++ and cross-compiled to JavaScript using Emscripten. - Emscripten targeted asm.js, allowing JavaScript engines to generate predictable and compact machine code. - This approach provided: - Direct control over memory layout, including compact 32-bit floats and bytes instead of JavaScript’s 64-bit numbers. - Manual allocation that avoids garbage-collection pauses and helps maintain 60 fps. - LLVM optimization and C++ template specialization for performance approaching native code. - More predictable execution because asm.js avoids the deoptimization points common in regular JavaScript. ## Memory Constraints and Indirect Buffers - Large contiguous typed-array allocations caused problems, especially in 32-bit Chrome on Windows, where address-space fragmentation from ASLR could prevent allocations as small as 256 MB. - Figma created an `IndirectBuffer` API to reference external typed arrays from C++. - Moving large image and geometry buffers outside the main heap: - Reduced fragmentation during long sessions. - Allowed better use of limited 32-bit address space. - Helped bypass typed-array size limits in 64-bit browsers. - The post also points toward future improvements from WebAssembly, which would reduce asm.js parsing costs, and shared typed arrays, which would enable shared-memory multithreading. ## Custom Rendering - Figma implemented its own rendering engine to achieve fast, consistent output across platforms. - Rather than relying entirely on browser graphics implementations, the team began building the rendering layer needed for a professional design application. Figma’s broader recommendation is to use low-level browser capabilities such as WebGL and compiled code when standard web APIs cannot provide the required performance or control.

c++webassemblywebglasm-js+3