Chapter 10
2010

The decade of 2010-2020 marked a break in our relationship with the digital world. More than a simple technological turning point, these years witnessed the birth of a society where the digital merged with reality until their boundaries blurred. This globalization took concrete form in our daily lives. Populations, predominantly urban and mobile, demanded instant access to information and online services. This thirst for immediacy shaped the innovations of an entire era.

The early years of this decade revealed the unsuspected power of social networks, with Facebook and Twitter spearheading genuine revolutions. The Arab Spring of 2011 demonstrated how these platforms could bypass traditional media controlled by authoritarian regimes. A simple smartphone was now sufficient to broadcast images of demonstrations, coordinate gatherings, and give voice to those previously silenced. This media leap forward changed our perception of technology’s role in social movements.

The widespread adoption of smartphones, coupled with the deployment of 4G networks, transformed every citizen into a content creator. We began producing and consuming astronomical quantities of data. This avalanche of information gave rise to the phenomenon we called Big Data. Our traditional infrastructures buckled under the weight of these massive flows. New architectures and analytical methods had to be devised to make sense of this information deluge.

At the heart of this transformation, a handful of American companies built empires of unprecedented scale. Google, Apple, Facebook, Amazon, and Microsoft strengthened their grip on the global digital ecosystem. Their strategy relied on the methodical acquisition of any innovative startup that might threaten their dominance. This concentration of digital power raised legitimate concerns about user privacy and information control. Those who hold our data wield considerable power over our lives.

Facing this Western hegemony, China developed its own digital universe. Players like Alibaba, Tencent, and Baidu created a parallel ecosystem under the close supervision of the Chinese government and the Chinese Communist Party. Beijing implemented an ambitious national strategy aimed at dominating future technologies, particularly artificial intelligence and 5G networks. This rise to power transformed technological innovation into a genuine geopolitical issue. The Sino-American rivalry shifted from the oceans to laboratories and data centers.

The year 2013 marked an earthquake in our relationship with digital security. Edward Snowden revealed the staggering extent of surveillance conducted by American intelligence services. The world discovered that our communications were systematically intercepted and analyzed. This shock triggered global awareness about the fragility of our privacy in the digital age. Europe responded by drafting the General Data Protection Regulation, which has since become a global reference. Cybersecurity, previously a marginal technical concern, emerged as a strategic priority for states and organizations.

Social networks gradually colonized our information space. Their influence on public opinion formation became evident during the 2016 U.S. presidential election with the Cambridge Analytica scandal, which revealed how Facebook had enabled the exploitation of millions of users’ data for political purposes. These platforms showed their vulnerability to manipulation attempts. Even more concerning, their recommendation algorithms trap us in "filter bubbles," comfortable but distorted information universes. This fragmentation of public debate raises questions about how our democracies function in the digital age.

Cloud computing transformed the IT infrastructures of businesses and individuals alike. Why invest in expensive and underutilized servers when you can rent computing power on demand? This flexibility accelerated the digital transformation of traditional organizations. But this migration to the cloud also created new dependencies. The question of digital sovereignty arose again with particular urgency, especially in Europe where the dominance of American providers sparked legitimate concerns.

Our daily lives became populated with connected devices. Smartwatches, voice-activated speakers, automatic thermostats—the Internet of Things wove an invisible yet omnipresent network around us. These devices constantly capture information about our habits, movements, and preferences. They introduced new ways of interacting with machines. Voice and gesture gradually replaced keyboard and mouse. This constant collection of personal data fuels increasingly sophisticated artificial intelligence systems.

Bitcoin, born in the shadow of the 2008 financial crisis, truly emerged during this decade. This digital currency, independent of central banks, challenged our financial systems. Financial technologies transformed entire sectors: mobile payments, peer-to-peer lending, automated investment management. Traditional institutions had to adapt to these nimble new competitors. Regulators, often caught off guard by galloping innovation, oscillated between mistrust and fascination for these technologies that promised to democratize access to financial services.

The stunning progress in artificial intelligence and robotics accelerated the automation of numerous tasks. Jobs once thought reserved for humans found themselves threatened by learning machines. This evolution raised questions about the future of work, preparing young generations for a world where skills would become obsolete quickly, and ensuring a just transition for those whose jobs were disappearing. These concerns took on growing political dimensions as digital inequalities widened between different population groups.

The platform economy disrupted entire sectors. Uber, Airbnb, Deliveroo—these names became emblematic of a new economic model based on direct connections between supply and demand. This transformation created hybrid forms of employment, neither traditional employment nor conventional entrepreneurship. While these platforms opened new opportunities and streamlined exchanges, they also generated considerable social tensions. Job insecurity, circumvention of regulations, tax evasion—criticisms multiplied, forcing legislators to rethink legal frameworks overtaken by innovation.

Awareness of the digital world’s environmental impact gradually took hold. The carbon footprint of data centers, Bitcoin mining’s energy consumption, and planned obsolescence of electronic devices became realities that began influencing the technological choices of organizations concerned with their ecological responsibility. Initiatives for a more sustainable digital world emerged, seeking to reconcile innovation and sustainability. This reflection on the environmental ethics of digital technologies would become central in the following years.

The end of the decade experienced brutal and unexpected acceleration. The 2020 global pandemic precipitated the digital transformation of entire sectors. Overnight, remote work became widespread, education moved online, and e-commerce became vital. This health crisis served as a full-scale test for our digital infrastructures, revealing both their resilience and their limits. It also highlighted the urgency of bridging the digital divide. Access to quality connectivity and digital skills emerged as essential conditions for participation in social and economic life.

At the end of these ten years, the digital world no longer appeared as a distinct sector but as the fabric of our social organization. The innovations of this period responded to our thirst for connection and immediacy. But they also generated new ethical, social, and environmental problems that would continue to shape the evolution of computing. The 2010s will be remembered as the period when our world definitively shifted into the digital age, with its dazzling promises and troubling shadows. Computing now shapes our perception of the world and our social interactions.

Top

Elasticsearch

The story of Elasticsearch begins as a love story. In 2004, Shay Banon, a young developer, moved to London to support his wife, who dreamed of becoming a chef. Without employment, he decided to put this time to good use by exploring emerging technologies. His project: to create an application where his wife could store and retrieve all the culinary knowledge acquired during her training.

At the heart of this application, Banon envisioned a simple search box. One would only need to enter a concept, a thought, or an ingredient to immediately explore gastronomic possibilities. This vision led him to Apache Lucene, the reference library for search in Java. His immersion in Lucene gave birth to Compass, a project aimed at simplifying the use of Lucene in conventional Java applications. Conceptually, Compass presented itself as “Hibernate for Lucene”, facilitating the mapping of the domain model to the search index.

The project captivated Banon, who ended up dedicating more time to it than to the initial culinary application. A few months after its creation, he open-sourced Compass. The success was immediate. Developers appreciated the simplicity with which they could now index their domain models in Lucene and perform searches. This freedom gave them access to unexpected and innovative uses.

In 2010, drawing on this experience and user feedback, Banon launched Elasticsearch. This new creation maintained Compass’s philosophy of simplicity while addressing modern needs for distribution and scalability. He left his position at Gigaspaces to devote himself entirely to Elasticsearch development for nearly two years.

The open-source community embraced the project. Developers enriched the features, created an administration console, and developed graphical analysis tools. These collective contributions generated considerable momentum. In 2012, Elasticsearch attracted the attention of chief technology officers from numerous companies who praised its qualities. With 200,000 monthly downloads, an unprecedented figure for enterprise software, Elasticsearch established itself as an essential solution.

The founding team formed around Banon with Steven Schuurman, Uri Boness, and Simon Willnauer, all recognized experts in the search field. Together, they created a company to support the project’s development. The company attracted the best talent from the Lucene community and became the preferred destination for open source in the search domain.

Elasticsearch’s architecture is based on an innovative approach. The system uses JSON and a RESTful interface, making it accessible from any programming language. Its distributed nature gives it the capacity to process large volumes of data by automatically distributing the load across multiple nodes. Schema flexibility allows the storage of complex documents without prior structure definition.

Over the years, the ecosystem expanded. Logstash came to facilitate data ingestion, while Kibana offered advanced visualization capabilities. These tools form the ELK stack (Elasticsearch, Logstash, Kibana), which became a reference for log analysis and infrastructure monitoring. In the 2020s, lighter alternatives such as Fluentd or FluentBit often replaced Logstash for data ingestion.

Elasticsearch use cases multiplied: website search, user interaction analysis, anomaly detection in security systems. Organizations like GitHub, Wikimedia, Foursquare, and CERN adopted it to manage their search and data analysis needs.

In 2018, the company went public, confirming the project’s maturity. The following year marked a significant change. Elastic, the company behind Elasticsearch, modified its license. In January 2021, it abandoned the Apache 2.0 license for a dual proprietary license, including the Server Side Public License (SSPL). This decision prompted a reaction from Amazon Web Services, which created a fork of the project named OpenSearch, maintaining the open-source tradition under the Apache 2.0 license.

Elasticsearch’s impact on the software industry extends beyond its initial objective as a search engine. The technology has redefined how organizations manage and explore their data. Its distributed architecture and API-oriented approach have influenced the design of numerous modern systems. The ease of use, combined with powerful features, gives developers the ability to integrate sophisticated search capabilities without deep expertise in information retrieval. Elasticsearch’s widespread adoption illustrates the growing importance of real-time data analysis in contemporary information systems.

A personal project sometimes evolves into a major infrastructure, used by thousands of organizations around the world.

HEIF

The JPEG format has reigned over the digital imaging world since 1992. Mobile devices, computers, servers—all use this format that has established itself as a de facto standard. But this hegemony conceals technical weaknesses that have been revealed over time: no support for high color depth, no high dynamic range management, no transparency. And then there are those characteristic visual artifacts, that compression which shows its limits in the face of current needs.

In 2013, the technical team at Nokia Technologies began considering an alternative. They defined the requirements, identified use cases. The specification development took a year and a half, until the summer of 2015. But the project’s fate shifted with Microsoft’s acquisition of Nokia. The company transferred its rights and information to Apple, which took over.

HEIF (High Efficiency Image File Format) breaks with traditional image format design. Where JPEG stores a single image, HEIF can contain multiple images, entire sequences, and their metadata. The structure relies on HEVC (H.265) video coding technologies, whose advanced compression techniques are applied to still images. It’s a paradigm shift.

In 2017, Apple took the plunge. The iPhone 7, the sixth generation iPad, Macs running OS X High Sierra adopted the format. The company introduced the .heic extension for HEVC-encoded images, reserving .heif for files using other codecs. Millions of users discovered the format without really noticing.

The gains were immediate: a 50% reduction in file size compared to JPEG, with equivalent or superior visual quality. The format handles burst capture, simultaneous recording of videos and still images, animations, focal and exposure images in a single file. Editing operations on predefined derived images are made possible.

HEIF’s architecture inherits from the ISO/IEC 14496-12 base format. The box system enables data nesting, creating a hierarchy of relationships. The first box, named “ftyp,” contains general encoding metadata. A “meta” box holds the remaining information. The format integrates image tiling, which allows parallel decoding or partial loading of regions of interest in high-resolution images.

Apple adapted the specifications in its own way. The company systematically uses 512×512 pixel tiles, generating “infe” entries for each tile. These tiles are assembled into a single image via a “grid”-type derived image. Apple exploits auxiliary depth maps, accompanied by XMP metadata.

Format adoption is gradually expanding. Android has integrated it since version 9 (Pie), Samsung offers it on certain models like the Galaxy S10. Windows 10 introduced it in version 1809, but specific extensions must be installed from the Microsoft Store. The transition requires technical and practical adjustments.

For mobile photography, the impact is considerable. Users keep more photos on their devices without sacrificing visual quality. Non-destructive editing is more accessible, metadata management more flexible. Application developers have new possibilities at their disposal.

On the digital forensics side, typically for criminal investigations, HEIF complicates the work. With its structure’s ability to conceal data in different boxes, to manipulate relationships between images, investigators must develop new methodologies, account for multiple data layers, variable implementations across manufacturers.

The ISO/IEC 23008-12 standard now defines the format’s technical specifications. This standardization guarantees interoperability between different implementations. Successive updates have introduced support for predictive image coding, bursts, region annotation. Development continues.

The HEIF format adapts to the performance constraints of modern devices. But the transition from JPEG is gradual. Compatibility issues slow adoption, though the technical advantages are undeniable. Change takes time, and the outcome remains uncertain.

Top

Rust

In 2006, Graydon Hoare was working at Mozilla when he launched a personal project in systems programming. This project, named Rust in reference to rust fungi and the English word robust, remained discreet until 2010. That year, Mozilla recognized the language’s potential and decided to support its development.

The first pre-alpha version of the compiler was released in January 2012. From the start, Rust tackled a contradiction that had plagued developers for decades: how to achieve fine-grained control over hardware resources while guaranteeing memory safety? Existing languages forced a choice between performance and safety. Rust refused this compromise.

Rust’s type system relies on two original concepts: ownership and borrowing. The principle is simple: only one entity can own a resource at any given time. This rule, verified at compile time, eliminates an entire category of bugs in one fell swoop. Concurrency problems, memory leaks, and invalid accesses disappear before the program executes.

Microsoft revealed a striking figure: 70% of security vulnerabilities fixed in its products originated from memory management errors. Mozilla observed the same thing with Firefox. These statistics explain why Rust found its audience. The language has actually earned the title of “most loved language” in the Stack Overflow survey every year since 2016.

The ecosystem has been structured around Cargo, the official package manager. This tool radically simplifies dependency management and project building. The community has developed thousands of libraries, called crates, which cover just about every imaginable need. This richness has facilitated the language’s adoption in industry.

Dropbox was among the first to bet on Rust for its critical infrastructure. Facebook, Amazon, and Cloudflare followed. Microsoft is exploring its use to strengthen the security of its system components. Mozilla has rewritten certain parts of Firefox in Rust, demonstrating that the language could be integrated into monumental projects already in production.

Concurrency management constitutes another strength of Rust. The compiler detects data races before the first execution. It’s impossible to launch a program where multiple threads access shared data simultaneously without appropriate synchronization. This static verification saves hours of nightmarish debugging.

The language evolves with remarkable discipline. The designers introduce advanced features without ever breaking compatibility with existing code. The development process relies on specialized working groups that debate each proposal at length. This governance produces carefully considered decisions.

Rust has established itself in various domains. It can be found in operating systems, web browsers, development tools, and distributed applications. The Internet of Things is adopting the language for its security guarantees and efficiency on limited hardware. Critical embedded systems benefit from a language that combines C’s performance with protections absent from traditional low-level languages.

The Rust language proves that reconciling security and performance can be done without sacrificing productivity. Other language projects are inspired by its innovations. Secure development practices are evolving under its influence. Companies are offering training, consulting, and specialized services, signaling the commercial maturity achieved.

Rust’s sophisticated type system represents a conceptual breakthrough. It demonstrates that a compiler can verify complex properties about code and guarantee their enforcement at runtime. This approach opens new perspectives in language design. Security is no longer a contradictory objective to performance.

New features appear regularly, always respecting the founding principles. Industrial adoption is accelerating. The community remains dynamic, and the language is becoming a lasting part of the computing landscape.

For decades, developers accepted memory bugs and associated security flaws as inevitable. But Rust has shattered this fatalism. It provides concrete solutions to age-old problems while maintaining the performance of established languages. This dual technical and community victory shows that development tools can be rethought to meet contemporary requirements for security and quality.

Top

ChromeOS

In 2009, Google launched development of an operating system that broke with established conventions: ChromeOS, designed to function solely with web applications. The context explains this bold move. Netbooks, those small, affordable laptops oriented toward the Internet, were attracting more and more users. The company chose an unusual method to understand their needs: rather than commissioning traditional studies, engineers distributed 200 ChromeOS machines to Google employees. Matthew Papakipos, who was leading the project technically, installed three devices at home. He observed that sessions were brief: a quick search, a short message sent, then the device was closed.

On July 7, 2009, Google officially announced ChromeOS. In November, the source code became accessible under the name Chromium OS. This duality persists: ChromeOS refers to the commercial product distributed only on specific hardware through partners, while Chromium OS remains the open source project that any developer can compile and modify. The streamlined interface draws inspiration from the Chrome browser, reflecting the system’s primary purpose: accessing the web, quickly and simply.

On November 19, 2009, Sundar Pichai, Google’s vice president overseeing Chrome, presented a preliminary version at a press conference. The demonstration showed a desktop that resembled the Chrome browser, enhanced with application tabs taking up less space and that could be pinned for easier access. Boot time then reached seven seconds. The teams set about reducing it further. Chris Kenyon, vice president of OEM services at Canonical, which publishes Ubuntu, announced a technical contribution under contract. Google wanted to leverage existing components from the open source community rather than reinventing everything.

An interface adapted to touch tablets was presented in January 2010. The design incorporated a virtual keyboard and larger icons, placed above the tabs. In March 2010, Google envisioned two versions: a consumer edition and an enterprise version.

The Cr-48 prototype was unveiled in December 2010. This test machine, produced in 60,000 units, introduced a curious innovation: the Caps Lock key disappeared in favor of a dedicated search key. Criticism arose over the limitations in offline mode. Google responded by demonstrating a version of applications working without connection, such as Google Docs, and announced a 3G plan including 100 MB of free monthly data through Verizon.

ChromeOS architecture is deployed on three levels: firmware, the browser with its window manager, and system services. The firmware accelerates boot time by avoiding detection of obsolete peripherals. Security constitutes a constant concern, with verification at each step of the boot process and integrated restoration capabilities.

Print management illustrates Google’s approach. The Google Cloud Print service allows printing from any device on any printer, escaping the usual complexity of print drivers. The system integrates a media player capable of playing MP3 and JPEG files offline.

Early users of the Cr-48 delivered mixed feedback. Kurt Bakke from Conceivably Tech highlighted its rapid adoption as a family device for quick searches and social media browsing. But performance with Flash disappointed, and the absence of offline features drew criticism.

Hardware integration was achieved through partnerships with Acer, Adobe, Asus, Intel, Samsung, and Dell. In July 2010, Eric Schmidt, Google’s CEO, dismissed the idea of a Google-branded ChromeOS netbook. He preferred to rely on the experience of PC manufacturers accustomed to working with Microsoft.

ChromeOS’s business model differs from traditional systems. Schmidt acknowledged that software compatibility would be more limited than Windows, but the free license allowed manufacturers to offer competitive devices, between 300and400. Glyn Moody of Linux Journal even anticipated free distribution of hardware to develop Google’s advertising model.

ChromeOS adoption accelerated from 2015 onward, particularly in American schools. IDC reported 4.6 million Chromebooks sold in 2014, twice as many as in 2013. Gartner projected 14.4 million units in 2017. The gradual integration of Android applications and the ability to run Windows applications through virtualization solutions expanded the system’s capabilities.

The performance of Chromebooks based on Intel processors demonstrated the importance of hardware optimization. Comparative tests revealed gains of 50% and battery life 58% superior to competing ARM solutions. These results testified to engineers’ continuous investment in improving system efficiency.

ChromeOS offers a web-centric approach that leverages cloud computing. Its simplicity, security, and automatic update model influence the design of modern operating systems today. This operating system is far from having replaced existing systems, but it has charted a different path, proving that a lightweight and connected alternative could find its place in a market dominated by established giants.

Top

NVMe

SSD drives began to spread in the early 2010s, but encountered an unexpected problem. These new storage media exceeded the performance of mechanical hard drives, yet they remained constrained by communication protocols that were not designed for them. SATA and SAS interfaces, conceived for spinning disk drives, imposed their limitations on memories capable of much better performance.

A working group bringing together major industry players decided in 2011 to tackle the problem head-on. Rather than trying to adapt existing solutions, these engineers started from scratch. They published the first specification of NVMe (Non-Volatile Memory Express), version 1.0. The guiding principle was simple: create a native interface for non-volatile memories that directly exploits the PCI Express bus and communicates naturally with modern processors.

The proposal disrupted established practices. Where SATA manages only 32 commands in a single queue, and SAS 256, NVMe creates up to 64,000 queues, each capable of containing 64,000 commands. This multi-queue architecture aligns with the multi-core processors that now equip machines. Each application can have its own queues, without interfering with others.

Version 1.1 arrived in October 2012 with its share of improvements. The protocol integrated multi-path access management and resource sharing, essential functions in professional environments. Autonomous power management mechanisms also made their appearance, anticipating the needs of laptops and mobile devices.

In 2014, the creation of NVM Express, Inc. structured the standard’s governance. This organization brought together over a hundred companies and accelerated development. Version 1.2 was released in November with notable improvements: advanced namespace management, memory buffer optimization, and the ability to update firmware without interruption.

Physical formats multiplied to adapt to different uses. PCIe expansion cards equipped servers and workstations. M.2 modules found their place in laptops and compact machines. U.2 drives, in 2.5-inch format, installed in traditional storage bays. This diversity facilitated NVMe adoption across all market segments.

The protocol integrated security mechanisms compliant with Trusted Computing Group specifications. Data encryption at rest and secure erasure addressed growing confidentiality requirements. These functions are essential in a context where data protection has become a priority.

The year 2015 brought the NVMe-MI (Management Interface) specification. This extension standardized out-of-band device management, unifying configuration, monitoring, and maintenance commands. System administrators gained simplicity and consistency in managing their storage infrastructures.

The turning point of 2016 saw the birth of NVMe over Fabrics. This evolution extended the protocol to storage networks, whether using Ethernet, Fibre Channel, or InfiniBand. NVMe thus moved beyond direct connections to integrate into complex network architectures, without losing its advantages in terms of performance and latency.

Version 1.3, published the same year, enriched the standard with functions intended for mobile devices. Power management optimization and integration of mechanisms adapted to embedded systems made NVMe the first truly universal storage interface. From phone to data center, a single protocol now covers all needs.

The numbers speak for themselves. NVMe cuts in half the number of processor instructions required for input-output processing compared to SATA or SAS. This efficiency translates into reduced latency and higher throughput. NVMe devices exceed one million operations per second, where previous interfaces plateaued well below.

Software support followed. Windows, Linux, and MacOS integrated native drivers. Virtualization environments like VMware ESXi adopted the protocol, enabling its use in virtualized infrastructures that form the core of modern data centers.

NVMe’s success stems from a comprehensive approach. By completely rethinking the interface between processors and non-volatile memories, the protocol eliminates bottlenecks inherited from old architectures. This redesign fully exploits the performance of new memory technologies, without compromise linked to obsolete constraints.

Within a few years, NVMe established itself as an essential standard, supported by a rich ecosystem of products and solutions. Its continuous evolution guarantees its relevance for future storage technologies, confirming its central place in the architecture of contemporary computer systems.

Top

Dart

In October 2011, during the GOTO conference in Aarhus, Denmark, Lars Bak and Kasper Lund introduced a new programming language developed at Google to the public: Dart. The stated ambition was clear: to offer a credible alternative to JavaScript for web development, a language that would escape the flaws and limitations that developers criticized in the venerable JavaScript.

The two Google engineers designed Dart with one idea in mind: to unify software development across different platforms without sacrificing performance. The language’s syntax deliberately borrows from established languages like Java, C, and JavaScript, to avoid disorienting developers who would make the transition. This calculated familiarity aims to facilitate adoption: no need to relearn everything from scratch.

On November 14, 2013, Google released version 1.0 of Dart. This was the first stable release, the one that had to convince the community that Dart could indeed replace JavaScript in web applications. The following year, in July 2014, Ecma International validated the language during its 107^th General Assembly and created the ECMA-408 standard. This official recognition conferred on Dart a legitimacy that a simple corporate project would not have had.

But the beginnings were not as glorious as hoped. Google harbored the ambition to integrate a Dart virtual machine directly into Chrome to boost application performance. The idea caused concern. Web developers feared a fragmentation of the web, where each browser would impose its own virtual machine. Faced with this resistance, Google backed down. In 2015, with version 1.9, the project for native browser integration was abandoned.

The story of Dart could have ended there, relegated to yet another unremarkable web language. But in 2017, Google launched Flutter, a framework for creating user interfaces that work on mobile, web, and desktop from the same source code. And Flutter chose Dart as its primary language. This alliance gave new life to the language, which finally found its true purpose: to serve as the foundation for cross-platform development.

August 2018 marked a turning point with the arrival of Dart 2.0. This version restructured the language, notably through the introduction of a much stricter type system. The code gained in safety and readability, two essential qualities for complex applications. The compiler was also overhauled to produce performant native code, enabling Flutter applications to achieve performance comparable to solutions developed specifically for iOS or Android.

Dart offers two distinct compilation modes. Ahead-of-Time (AOT) compilation transforms code into optimized JavaScript for the web, or into native machine code for mobile applications. Just-in-Time (JIT) compilation facilitates more fluid development through hot code reloading: you modify the code, and the application updates instantly without a complete restart. This flexibility considerably accelerates the development cycle.

The language adopts a resolutely object-oriented approach: everything is an object, including numbers and functions. Classes, interfaces, mixins, generics... Dart incorporates the familiar concepts of modern languages. Automatic memory management frees the developer from the tedious tasks of manual resource allocation and deallocation.

Flutter’s success pulled Dart upward. Version 2.7 introduced extension methods, which allow adding new functionality to existing types without modifying their source code. This technique proved valuable for enriching user interfaces developed with Flutter.

The ecosystem gradually expanded. The Dart SDK integrates a dart2js compiler to generate JavaScript, a static analyzer that detects errors before execution, a code formatter, and a package manager. These tools support the developer throughout the entire creation process.

Flutter’s technical approach distinguishes Dart from other cross-platform solutions. Instead of compiling to native iOS or Android code, Flutter directly draws each pixel on screen through its own rendering engine. This strategy guarantees an identical user experience across all platforms, without depending on the native graphical components of each system.

Dart’s virtual machine was designed to make the most of the language. The garbage collector manages memory efficiently, while the compiler produces code optimized for each target platform, enabling Dart applications to achieve high performance while maintaining a single codebase.

Companies of all sizes use Dart and Flutter to develop their applications. The ability to reuse code between mobile, web, and desktop represents considerable savings in time and money. Write once, deploy everywhere, with performance delivered.

Dart’s future remains closely tied to that of Flutter. Google continues to invest in both technologies, regularly releasing updates that enrich functionality and improve performance. The language evolves to meet the needs of modern development, with a constant objective: to make developers more productive.

Started as an alternative to JavaScript, Dart ultimately found its way in cross-platform development. Its association with Flutter gave it a second life and a true playground.

Top

Kotlin

In 2010, JetBrains, a Prague-based company specializing in development tools, embarked on creating a new programming language. The objective was to design an alternative to Java that would be more concise and safer, while maintaining compatibility with the Java Virtual Machine. This compatibility is no trivial detail, as it ensures developers can gradually adopt the new language without rewriting their existing code.

The project emerged from the shadows in July 2011 under the name “Project Kotlin.” A few months later, in February 2012, JetBrains opened the source code under the Apache 2.0 license. This choice of openness was not insignificant: it reflected a desire to involve the developer community from the project’s earliest stages. Four years later, on February 15, 2016, version 1.0 arrived. This first stable version marked Kotlin’s true launch, as it began to attract attention with its streamlined syntax and pragmatic approach. One figure immediately stood out: Kotlin reduces the number of lines of code needed by an average of 40% compared to Java for accomplishing the same task.

The year 2017 changed everything. In May, Google announced its official support for Android development, making Kotlin a credible alternative to Java. This recognition propelled the language to the heart of mobile development. But Kotlin didn’t stop there. In April, it reached a new milestone by becoming multiplatform through Kotlin/Native and stabilized support for JavaScript. Six months later, version 1.2 introduced the ability to share code between backend, web frontend, and Android mobile applications. This capability addressed a growing need: reusing code across different platforms without rewriting everything.

In October 2018, Google and JetBrains jointly created the Kotlin Foundation. This structure guarantees the language’s independence and ensures transparent governance. A year later, in 2019, Google went further by declaring Kotlin as the preferred language for Android. Concretely, this means that new Android features and APIs arrive first in Kotlin. The language received the “Breakout Project of the Year” award at the O’Reilly Open Source Software convention, recognition of its meteoric rise.

What appeals in Kotlin is first its approach to handling nullability. The type system directly integrates this management, drastically reducing errors related to null references that plague Java developers. Lambda expressions and extension functions enrich the possibilities for functional programming. As for data classes, they simplify the creation of objects intended for storing information.

The language evolved rapidly. Version 1.1 brought coroutines that facilitate asynchronous programming. Version 1.3 introduced contracts and inline classes, improving code performance and safety. The compiler transforms source code into JVM bytecode, making its execution possible on all platforms supporting Java.

The numbers speak for themselves. In 2020, more than 4.7 million developers used Kotlin, with 65% in production. For 56% of them, it had become their primary language. Giants like Google, Uber, Atlassian, Pinterest, and Square integrated it into their production code. Kotlin is the 13^th most popular programming language, surpassing Scala and Swift. GitHub’s 2018 report already ranked it as the fastest-growing language. Stack Overflow places it fourth in the ranking of professional developers’ favorite languages.

The community grew. In 2020, more than 100 people worked on the language at JetBrains, supported by over 350 independent contributors participating in its evolution. This collective enthusiasm fuels the ongoing development of the language and its ecosystem.

Kotlin reduces the boilerplate code that weighs down Java, prevents common errors, and simplifies complex tasks. Its multiplatform approach meets current software development expectations.

Top

WebRTC

WebRTC is a technology born from the convergence of web browsers and real-time communication. Its roots run deep through several decades of Internet protocol evolution.

Back to 1996. The publication of the Real-time Transport Protocol (RTP) in RFC 1889 laid the foundations for what would become WebRTC. Ron Frederick, one of the protocol’s authors, had begun experimenting with the Sun VideoPix video capture card as early as October 1992. His goal was to create an IP multicast-based network videoconferencing tool. The project was called “nv” (Network Video tool) and was inspired by “vat”, an audio conferencing tool developed by LBL that used a lightweight session protocol to manage participants.

Video compression represented a considerable technical challenge. Frederick wanted to achieve an acceptable stream within bandwidth limited to 128 kbps, the capacity of a standard ISDN line. This required a compression factor of approximately 20 for the targeted image size and frame rate. Frederick succeeded in developing an innovative technique that became the subject of a patent (US5485212A) on software video compression for teleconferencing.

The first version of nv was released in November 1992. It broadcast certain IETF sessions worldwide. The impact was immediate: approximately 200 subnets in 15 countries could receive this broadcast, and between 50 and 100 people used nv during this period. The success was confirmed at various international workshops, notably the Australian NetWorkshop and the MultiG workshop on distributed virtual realities in Sweden.

Frederick released the source code publicly in February 1993. He then introduced a new wavelet-based compression system and added color video support. The network protocol used by nv and other Internet conferencing tools served as the basis for the RTP protocol that the IETF standardized. RTP became an essential standard, first published in RFCs 1889-1890, then revised in RFCs 3550-3551.

The evolution of nv continued with ports to different hardware platforms and video capture devices. NASA chose this tool to broadcast live coverage of space shuttle missions. In 1994, Frederick enhanced nv with compression algorithms developed by others, including hardware systems such as the CellB format from the SunVideo capture card.

This early history of real-time Internet communications foreshadows WebRTC. The challenges encountered by pioneers like Frederick established the foundations of modern protocols. IP multicast enabled efficient data distribution to multiple recipients, a different approach from the unicast architecture later adopted by WebRTC.

The shift from multicast to unicast can be explained by practical reasons. The complexity of implementing multicast in existing networks led to favoring simpler-to-deploy solutions. This evolution required the introduction of new architectures, such as SFUs (Selective Forwarding Units), to manage media stream distribution among participants.

WebRTC’s history took a turn with the arrival of Serge Lachapelle. His passion for communication software dates back to the 1990s, when he developed a project to join video calls directly from a browser. This experience led him to co-found Marratech, a company specializing in group videoconferencing. Google acquired Marratech in 2007 and integrated valuable expertise into its team.

The development of Gmail’s voice and video messaging represented a significant intermediate step. This achievement involved the complex integration of different components: audio under GIPs license, video from Vidyo, and networking via libjingle. Justin Uberti took on the technical challenge of making these systems with disparate APIs work together, which required extensive knowledge in networking, cryptography, and media.

The launch of the Chrome project at Google opened a new chapter. The ambition to enhance browser capabilities, combined with a desire to abandon the NPAPI API for security reasons, created a favorable context for WebRTC’s emergence. Chrome’s sandbox architecture, which isolates potentially dangerous operations in separate processes, influenced WebRTC’s secure design.

WebRTC’s birth addressed three main objectives. First, simplifying the development of real-time communication experiences. Second, promoting open and unhindered human communication. Finally, ensuring security by default. To realize this vision, Google acquired and open-sourced several key technologies, notably those from On2 for video and Global IP Solutions for real-time communications.

WebRTC’s standardization represented an unprecedented effort. It required collaboration between two standardization bodies (IETF and W3C) and hundreds of international experts. Harald Alvestrand, with his IETF experience, initiated the process. An informal meeting in Maastricht in 2010 brought together developers from Google, Cisco, Ericsson, Skype, Mozilla, and Linden Labs. The specification’s foundations were laid.

WebRTC built upon the legacy of existing technologies. It avoided reinventing already proven solutions. The decision not to standardize signaling, handled by SIP and other protocols, illustrates this pragmatic approach. This strategy concentrated efforts on innovation rather than redefining established concepts.

WebRTC’s use in cloud gaming demonstrates its versatility. Advances in artificial intelligence improve communication quality, notably through background noise suppression. This expansion of use cases testifies to the robustness and flexibility of WebRTC’s architecture. International collaboration and commitment to open standards have created a platform that continues to innovate and adapt to new use cases.

Top

WebSocket

In the early 2000s, web developers faced a recurring problem. The applications they were building—instant messaging systems, online games, collaborative dashboards—required constant exchanges between browsers and servers. However, the Web as it existed at the time couldn’t really handle this type of dialogue. HTTP, the protocol governing Internet communications, operated on a rigid model: the client requests, the server responds. No room for fluid two-way conversation.

Engineers found workarounds. The most common, "HTTP polling," consisted of bombarding the server with regular requests to check if it had anything new to say. A variant, "long polling," kept the connection open until information arrived. These makeshift solutions worked, certainly, but generated considerable network traffic. Each HTTP request carried bulky headers—hundreds of bytes each time—sometimes to transport just a few bytes of useful information.

RFC 6455, published by the IETF in December 2011, put an end to this era of improvisation. WebSocket proposed a radically different approach. The protocol starts with a standard HTTP handshake, then switches to a permanent connection. Once established, this channel sends messages in both directions with minimal overhead—a few control bytes instead of the hundreds previously required. The protocol handles text and binary data indifferently, and integrates connection monitoring mechanisms via "ping" and "pong" messages.

Browsers adopted this innovation. Chrome, Firefox, and Safari deployed experimental implementations as early as 2010. Internet Explorer joined the movement in 2012. This rapid convergence among vendors testified to a genuine market need. Developers could finally create responsive web applications without resorting to complex and fragile workarounds.

The numbers speak for themselves. On a trading site displaying real-time stock prices, WebSocket reduces traffic by 417 bytes per update per client. With 4,835 simultaneous visitors, the bandwidth savings climb to 16 megabits per second. The impact is also measured in adoption statistics: 1.6% of the top million sites in 2018, 6.3% in 2020. This growth testifies to a technology that has reached maturity.

The ecosystem structured itself around the protocol. Socket.io and SockJS offer high-level APIs that simplify its use. Chat services, collaborative platforms, and financial applications made it their workhorse. Web analytics tools use it to collect real-time data on user behavior. WebSocket finds its place in the Internet of Things and microservices architectures, where its lightness and bidirectionality offer tangible advantages.

The technology doesn’t escape misuse. Some developers neglect security best practices—Origin header verification, systematic TLS encryption. Malicious actors misuse the protocol for tracking or distributing unwanted software. These shadow areas remind us that no technical innovation is neutral.

HTTP/2, standardized in 2015, introduced the Server Push feature. Servers can now send resources to clients without waiting for a request. This capability doesn’t replace WebSocket, however: it doesn’t create a true bidirectional channel. Google implicitly acknowledged this by dropping support for Server Push in Chrome in 2020, confirming WebSocket’s unique position in the web landscape.

Competing technologies emerged, such as Server-Sent Events. WebSocket nonetheless retains its relevance. The stabilization of its adoption rate since 2019 suggests it has found its place in the palette of available tools. Modern frameworks integrate it by default, developers master it, use cases multiply.

The protocol didn’t revolutionize anything: it simply made possible what previously required acrobatics. This conceptual simplicity, combined with measurable operational efficiency, explains its success.

Top

Go

In 2007, at Google, engineers faced a problem that had become commonplace in the company. Existing languages no longer met the needs of modern applications: intensive networking, multicore processors, distributed environments. Rob Pike, one of the designers of the future Go language, summed up this technical impasse with some frustration. The industry had numerous tools, certainly, but none truly fit the bill.

Cloud computing had just emerged from infancy, service-oriented architecture was finding its footing in large organizations, and continuous integration was beginning to transform development practices. The computing landscape already resembled today’s. Go was not born in a laboratory cut off from the real world; it emerged at the heart of the constraints faced by development teams.

One striking detail in this story: among Go’s creators is Ken Thompson, who had designed UNIX and the C language decades earlier. This lineage is far from anecdotal. It traces a direct line between two eras of computing, with Go embodying a contemporary reinterpretation of the principles that guided C’s creation.

Java, which appeared in 1991, had established itself through its portability. But its proprietary status until 2006 created complications: the 2012 Oracle lawsuit against Google attests to this. As for C, born in 1972 to rewrite UNIX, it had spread for lack of alternatives; it was one of the few fast and cross-platform languages accessible to early programmers. Go, on the other hand, was designed from the outset for current needs.

The language stands out through its thoughtful design. Compilation times remain short, machine code is generated directly, strong typing imposes a discipline that makes programs readable and reliable. Comprehensive and free documentation accompanies the whole. In a development team, often large and with varied skills, these characteristics take on another dimension: collaboration becomes more fluid, build times are reduced, existing code is more easily deciphered.

With automatic memory management, developers no longer need to explicitly program memory allocation and deallocation, unlike in C or C++. This automation improves productivity, certainly, but above all it strengthens security by reducing vulnerabilities related to memory handling errors.

Native concurrency support represents perhaps the most significant innovation. Applications can execute multiple tasks simultaneously rather than sequentially, thus exploiting multicore processors. For applications distributed across multiple servers or microservice architectures, this functionality proves invaluable.

Deploying Go applications remains simple. Unlike Java, which requires local interpreters or virtual machines, Go programs compile into standalone binaries. The Get tool downloads and installs an application via a single command. This approach perfectly matches DevOps practices that prioritize consistency in development pipelines and simplicity of updates.

In the field of data science, Go demonstrates its versatility. It easily integrates algorithms written in Python into microservice applications. The resulting performance often eliminates the need for optimization in C or C++, low-level languages known for their complexity.

The developer community around Go has continued to grow. In 2016, more than 700 programmers contributed to its development. The TIOBE programming language index illustrates this rise: Go moved from 55^th to 10^th place between 2016 and 2017.

Many open source platforms have adopted Go. Cloud Foundry chose it for components like gorouter, which manages connectivity for microservice applications. Docker, which transformed application deployment, is written entirely in this language. Docker developers opted for Go in 2013, attracted by its ease of installation, testing, and adoption. InfluxDB, a high-performance storage system, leverages the language’s efficiency and reliability.

Leading technology companies have integrated Go into their infrastructures. Dropbox migrated a significant portion of its infrastructure from Python to Go to improve its scalability. Netflix uses Go to create microservices requiring performance and scalability. Uber developed its real-time geolocation service in Go, which displays the best performance among all its services.

Go’s success is explained by its alignment with modern software development needs. Its design takes into account cloud environments, distributed processing, and microservice architectures. Ease of use, combined with high performance and facilitated maintenance, makes it a relevant choice for companies modernizing their applications.

Go’s emergence marks the evolution of programming languages toward solutions adapted to cloud computing and distributed architectures. Contemporary software development needs have led to rethinking programming tools, creating a language that meets the requirements of current computing while maintaining an elegant and pragmatic approach.

Top

Julia

For the past twenty years, researchers using scientific computing have lived with a constraint that slows down their work: they must choose between a language that’s easy to use for testing ideas and a language that runs fast for producing results. When prototyping, they use Python or MATLAB. But as soon as serious calculations are needed, they start over in C++ or Fortran. This constant back-and-forth between two languages wastes time and complicates projects unnecessarily.

This is the problem that Jeff Bezanson, Alan Edelman, Stefan Karpinski, and Viral Shah decided to tackle in 2009 at MIT. They wanted to create a language that would combine the simplicity of dynamic languages with the speed of compiled languages. A bold bet, since these two qualities seem inherently contradictory.

The first version of Julia was released in 2013. From the beginning, the language targeted scientific computing with an architecture designed for operations on multidimensional arrays, in the manner of Fortran. The engine relies on LLVM, which generates machine code adapted to different hardware architectures. Julia compiles code on the fly, as it executes. This just-in-time compilation reconciles two worlds previously thought separate: the responsiveness of an interpreted language and the speed of a compiled program.

Julia’s originality lies primarily in its multiple dispatch system. Unlike traditional object-oriented languages where a method depends on the type of a single object, Julia selects the right function based on the types of all arguments. This mechanism makes code much more flexible and facilitates the composition of libraries that weren’t designed together. The language also integrates powerful macros, native parallel computing, and seamless interaction with existing C or Fortran code.

The community took shape. In 2014, the first JuliaCon took place, quickly becoming an annual event. Three years later, the registry already contained over 1,000 packages. Major companies began taking interest: Aviva and the Federal Reserve Bank of New York in finance, Pfizer, Moderna, and AstraZeneca in pharmaceuticals, ASML for semiconductors.

The performance is impressive. Benchmarks show that certain mathematical functions written in pure Julia run faster than their optimized equivalents in C or Fortran. The implementation of the inverse error function beats MATLAB’s by a factor of 3 to 4, and SciPy’s by 2 to 3. This speed comes from metaprogramming and code generation techniques that Julia exploits naturally, where a low-level language would require contortions.

The name of the Jupyter environment recalls the connection with Julia (along with Python and R). These notebooks, which mix code, results, graphics, and text, fit well with the needs of teaching and reproducible research. MIT and other universities now use it for their numerical computing courses.

Julia runs on various architectures: ARM processors and GPUs. The integrated package manager simplifies dependency management and ensures environment reproducibility. Tools automate the creation of bridges to C++ libraries, providing access to a considerable software heritage.

In 2022, Julia tackled large-scale scientific projects. The Climate Modeling Alliance uses it for climate modeling, the Celeste project for astronomical image processing, and high-energy physics teams for data analysis. These applications demonstrate that the language performs well on complex and massive calculations without sacrificing code readability.

Development follows a classic open-source approach, with code on GitHub. Between 2009 and 2017, over 40,000 commits accumulated. Contributions go through strict review that maintains quality. Comprehensive documentation and online tutorials help newcomers get into the language without too much difficulty.

The initial design choices proved sound for following the evolution of scientific computing. The team continues to improve compilation times, automatically optimize code, and support new architectures. The common thread remains the same: a single language that combines ease of use and performance.

Julia shows that programming languages can be rethought to transform scientific practices. By elegantly solving the two-language problem, it changed what we expect from a computational tool: productivity without compromise on speed.

Top

TypeScript

When Microsoft launched TypeScript in 2010, the web development landscape was undergoing rapid transformation. JavaScript, once relegated to simple browser interactions, had become an essential language. Execution engines were gaining performance, single-page web applications were proliferating, and Node.js was paving the way for server-side JavaScript. This expansion brought with it a problem: maintaining large JavaScript codebases was a real headache.

Anders Hejlsberg, the architect behind C#, led the project with a clear ambition. The goal was not to replace JavaScript, but to enhance it. TypeScript presents itself as a syntactic superset of JavaScript: any valid JavaScript code remains valid TypeScript code. The core idea was to add an optional static type system. Developers can annotate their code, and these annotations disappear at compilation. The generated JavaScript retains no trace of the typing.

This technical decision reflects a keen understanding of real needs. The type system adopts a structural approach rather than a nominal one, which better suits JavaScript developers’ habits. In this ecosystem, objects often emerge directly, without going through formal classes. TypeScript embraces this practice instead of fighting it.

One design choice deserves attention. TypeScript’s creators deliberately chose not to guarantee complete type safety. They preferred to facilitate gradual adoption and maintain compatibility with existing libraries. This flexibility allows teams to introduce TypeScript into their projects without rewriting everything at once.

Steve Ballmer, Microsoft’s former CEO, had compared open source licenses to “a cancer that attaches itself to everything it touches.” He denounced the lack of accountability in free software. Yet the TypeScript team knew they would never win over the JavaScript community without embracing open source. In 2012, Microsoft released TypeScript under the Apache-2.0 license, first on CodePlex, then on GitHub in 2014.

Adoption grew gradually. In 2025, the GitHub repository has garnered over 107,000 stars and ranks among the platform’s twenty most popular projects. The NPM package records over 100 million weekly downloads. More than 61,000 other packages depend on it. These figures reflect established trust.

The language introduces structural concepts: interfaces, classes, modules. Its type inference system reduces required annotations while preserving the benefits of static typing. Development tools are enriched with autocompletion and code navigation. The compiler, written in TypeScript, demonstrates the language’s capacity to handle complex projects. It analyzes source code, verifies types, and generates standard JavaScript while preserving program semantics.

The community has built a rich ecosystem around TypeScript. The DefinitelyTyped repository gathers thousands of type definition files for traditional JavaScript libraries. These declarations enable the use of existing libraries with the advantages of static typing. Successive versions bring advanced features: generic types, conditional types, utility types. These additions allow the expression of complex constraints and reinforce code safety. A new version is released every two months, ensuring constant evolution.

TypeScript has established more rigorous practices in the JavaScript ecosystem. Certain concepts have enriched JavaScript itself, as evidenced by new ECMAScript versions. This success testifies to Microsoft’s transformation toward a less closed approach to software development.

Top

Docker

About fifteen years ago, a young startup named dotCloud made a decision that would upend the IT industry. By releasing the code of its containerization engine to the public, the company offered Docker to the world. The way we build, distribute, and run applications would never be the same again. Yet the history of containers doesn’t begin with Docker, far from it.

Let’s go back to 1979. UNIX introduced chroot, a mechanism that allowed changing the root directory of a process. A modest building block that laid the groundwork for an idea: isolating application storage from one another. FreeBSD took a leap forward in 2000 with its jails, providing true system-level virtualization. Linux-VServer followed suit the next year, followed by OpenVZ in 2005. All these technologies explored a similar path: partitioning system resources to compartmentalize applications.

But none really took off. Too complex, too rigid, they remained confined to niche uses. LXC arrived in 2008 and for the first time, there was a complete container manager that relied on the standard Linux kernel, without hacks or risky modifications. Lightweight virtualization was finally accessible, at least in theory.

dotCloud used LXC to run its cloud platform. Its engineers had cobbled together an in-house tool in Python, called “dc”, which was used to manipulate LXC containers. Create, start, stop, expose network ports: the basic functions were there. Except the architecture was problematic. Concurrent access to container metadata created lock conflicts. The system held together, but fragility lurked.

In 2013, Solomon Hykes and his team took the plunge: they released their engine under the name Docker. Docker didn’t just make containers usable, it made them simple. The standardized image format packages an application with everything it needs. Read-only layered stacks allow sharing common parts between images. The Docker Hub registry made sharing images a breeze.

The architecture evolved quickly. Docker broke free from LXC as early as 2014 by developing libcontainer, its own library for communicating with the Linux kernel. No external dependencies, more control, more stability. The technical foundations rested on cgroups that limit resources, namespaces that isolate processes, and storage drivers like AUFS or OverlayFS that manage image layers with finesse.

The modular design took shape. The dockerd daemon exposes the API and orchestrates everything. containerd handles container execution. runc standardizes their creation. This architecture built from blocks allows replacing what doesn’t fit and adapting the tool to specific needs.

Docker’s success raised a question: how to guarantee interoperability? The Linux Foundation launched the Open Container Initiative in 2015 to establish open standards. Docker contributed by providing the specifications of its image format and runc as a reference. That same year saw the birth of the Cloud Native Computing Foundation, which would host Kubernetes, Prometheus, and containerd. The ecosystem structured itself, standards took hold.

In April 2015, Docker raised $95 million in a Series D round led by Insight Venture Partners. Prestigious names joined the venture: Goldman Sachs, Coatue, Northern Trust. Six months later, an additional $18 million came in. The valuation exceeded one billion dollars. Docker became a “unicorn”, all the heavyweights of Silicon Valley were betting on this technology that promised to revolutionize software deployment. The company went through successive funding rounds until reaching nearly $280 million raised. In 2017, a new round brought in $75 million more, pushing the valuation to $1.3 billion.

Docker disrupted practices. A containerized application behaves the same way everywhere: on the developer’s machine, on test servers, in production. Resources consumed remain reasonable, far from the heaviness of traditional virtual machines. Server density improved as a natural consequence.

The company also developed Docker Swarm, its native orchestrator. The idea seemed sound: managing entire fleets of containers distributed across multiple machines while maintaining the simplicity of the Docker API. A few commands were enough to deploy a cluster. No steep learning curve, just a natural extension of what developers already knew. In 2016, Docker integrated Swarm directly into the engine with “Swarm Mode”. It was in the box, ready to use.

Except Google had released Kubernetes in 2014. The fruit of a decade of experience with Borg, its internal orchestration system, Kubernetes grew at breakneck speed. The open source community was on fire. The three major cloud providers adopted Kubernetes: Google of course, but also Amazon with EKS and Microsoft with AKS. VMware and Red Hat rallied to it. By 2017, the battle was already lost for Docker Swarm. Docker’s leadership acknowledged this by announcing that the platform would support Kubernetes. A barely disguised admission of defeat.

Tensions mounted internally. Three CEOs in a single year. The company was flying blind. It had two distinct activities that operated according to incompatible logics: on one side Docker Desktop and Docker Hub, beloved by developers but difficult to monetize; on the other Docker Enterprise, a suite of tools for large enterprises with integrated orchestration, lucrative contracts, but growing complexity.

In November 2019, Mirantis, a cloud specialist looking for direction after the waning of OpenStack, purchased Docker’s entire enterprise business. The transaction included Docker Enterprise Engine, Docker Trusted Registry, Docker Unified Control Plane, the CLI, and 750 large enterprise customers including a third of the Fortune 100. Three hundred employees joined Mirantis. The amount wasn’t disclosed, but it was paltry compared to the $280 million raised. Observers spoke of a fire sale.

The same day, Docker announced $35 million in funding from Benchmark Capital and Insight Partners. Scott Johnston, product director since 2014, became the third CEO of the year. The company restructured, refocused on developers, keeping Docker Desktop and Docker Hub. The team went from several hundred people to about sixty. Many saw it as the end of an era. Commentators declared Docker dead.

Docker and Mirantis agreed to collaborate on open source development. Mirantis committed to supporting Docker Swarm for at least two years, but the message was clear: Kubernetes would be the main orchestrator. The acquisition of Docker Enterprise assets allowed Mirantis to position itself against giants like VMware and Red Hat. Two years after the acquisition, Mirantis announced annual revenue exceeding $100 million, half of which came from assets purchased from Docker. The graft had taken.

For its part, Docker rose from the ashes. Focused on its core business, the company found a growth trajectory again. Annual recurring revenue climbed from $6 million in 2020 to $50 million in 2021, then to over $135 million in 2023. In March 2022, Docker raised $105 million in a Series C round led by Bain Capital Ventures, with a valuation of $2.1 billion. The workforce doubled to reach 150 people. In 2021, Docker Business was born, an offering for large enterprises, and Docker Desktop’s license terms changed. The refocusing bet paid off.

What’s striking about Docker’s story is less the pure technical innovation than the democratization of an idea. Containers existed, but nobody really used them. Docker made them accessible, almost obvious. This simplification paved the way for microservices architectures, accelerated the DevOps movement, and transformed how we think about software deployment.

Components separated, giving users the choice of elements that suited them. New tools constantly emerge to optimize image building, strengthen security, and orchestrate containers. Docker’s legacy lies in the open standards it established, in the foundations it laid for the industry, and in its ability to reinvent itself after nearly disappearing. Docker Inc. still exists, smaller but viable, while Docker technology permeates the entire modern cloud ecosystem.

Top

SHA-3

In the late 1970s, cryptographic hash functions began to take shape. These algorithms transform any data into a fixed-size digital fingerprint, used to verify data integrity and create digital signatures. In 1976, Diffie and Hellman published their seminal paper on public-key cryptography; they identified the need for a one-way hash function to construct digital signature schemes.

Between 1978 and 1979, Rabin, Yuval, and Merkle laid the theoretical foundations. Rabin proposed a design based on DES encryption with a 64-bit output. Yuval demonstrated that collisions for an n-bit hash function could be found in 2^n∕2 time using the birthday paradox. Merkle introduced the requirements for collision resistance, preimage resistance, and second preimage resistance, which remain the fundamental properties expected of a cryptographic hash function.

The 1990s saw the emergence of MD4 and MD5, designed by Ron Rivest, which became widely used standards. SHA-1, published by the NSA in 1995, established itself as MD5’s successor with a 160-bit output. SHA-2 arrived in 2001 with variants producing digests from 224 to 512 bits. These algorithms are based on the Merkle-Damgård construction: the input message is divided into fixed-size blocks to which a compression function is iteratively applied.

In 2004, Xiaoyun Wang’s team revolutionized the field by refining differential cryptanalysis to the point of making collision discovery for MD5 trivial. This work also significantly reduced SHA-1’s security. In 2008, a team managed to create a rogue CA certificate by exploiting MD5 weaknesses. The cryptographic community grew concerned about the robustness of existing hash functions. SHA-2 uses construction principles similar to SHA-1, raising questions about its future resistance.

NIST launched a public competition in 2007 to select a new algorithm that would become SHA-3. The specifications required that candidates support outputs of 224, 256, 384, and 512 bits to ensure compatibility with SHA-2. Submissions had to be royalty-free and usable worldwide without restrictions.

64 candidates were submitted in 2008, with 51 selected for the first round. By mid-2009, approximately half of the algorithms had been broken. This carnage demonstrated the difficulty of designing a secure and efficient hash function. In July 2009, NIST selected 14 candidates for the second round: Blake, Blue Midnight Wish, CubeHash, ECHO, Fugue, Grøstl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD, and Skein.

The Keccak algorithm, developed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche, stood out for its innovative architecture based on the sponge construction. Unlike the Merkle-Damgård construction, this approach absorbs the message block by block with a portion called the “rate” of 1,152 bits, while the remaining 448 bits serve as a security parameter. The internal state forms a 5×5×64-bit cube totaling 1,600 bits.

In October 2012, NIST designated Keccak as the winner of the SHA-3 competition. The decision was based on its excellent hardware performance, comfortable security margin, and architecture distinct from other SHA algorithms. Standardization was completed in August 2015 with the publication of FIPS 202. SHA-3 includes four conventional hash functions (SHA3-224, SHA3-256, SHA3-384, and SHA3-512) as well as two extendable-output functions SHAKE128 and SHAKE256.

The first implementations of SHA-3 revealed interesting characteristics. On FPGA, the algorithm requires more hardware resources than SHA-1 but offers better cryptographic resistance. Performance tests indicate that SHA-3 is approximately 5.5 times slower than SHA-1 due to its increased complexity. For password cracking by brute force, a 6-character password requires a few minutes with SHA-1 versus over an hour with SHA-3.

The introduction of SHA-3 marks an evolution in the history of cryptographic hash functions. Its sponge construction breaks with the traditional approach and inspires new modes of use. The extendable-output functions SHAKE bring innovation: the digest size can be adapted to specific application needs. SHA-3 complements the SHA-2 family by providing architectural diversity that strengthens overall resilience against future cryptanalytic advances.

To date, SHA-3 has not suffered any significant attack undermining its security. Research continues to explore the possibilities offered by the sponge construction, particularly for designing authenticated cryptographic primitives. The success of the SHA-3 competition demonstrates the effectiveness of an open and collaborative approach to developing robust cryptographic standards. This methodology now serves as a model for other standardization initiatives in cryptography.

Top

Spark

In 2009, a group of researchers at the University of California, Berkeley began developing Spark. Their goal was to create a distributed computing system capable of surpassing MapReduce’s limitations. The problem had become evident: modern data processing applications needed to constantly reuse the same datasets across multiple parallel operations, whether for machine learning or interactive analysis.

The project’s central idea lies in an abstraction called RDD, for Resilient Distributed Datasets. These are collections of objects distributed across multiple machines, accessible only in read mode, but capable of rebuilding themselves if a partition were to disappear. This approach provides fault tolerance without duplicating data, elegantly solving reliability issues in distributed environments.

The first public version arrived in 2010. Spark stood out for its ability to keep data in memory between operations, whereas traditional systems systematically rewrote everything to disk. For iterative algorithms, those that process the same data over and over, the performance gain is spectacular.

The choice of Scala as the programming language proved decisive. This statically typed language, which runs on the Java virtual machine, offers expressiveness that simplifies writing distributed applications. Developers manipulate RDDs with functional constructs, making the code more readable.

The project joined the Apache Software Foundation ecosystem in 2013, thereby strengthening its adoption. Features multiplied. SparkSQL emerged to execute relational queries on distributed data. Spark Streaming arrived to process real-time streams.

The system’s modular design allows progressive addition of specialized libraries. MLlib offers machine learning algorithms adapted to distributed environments. GraphX provides tools for processing large-scale graphs. These extensions enrich the ecosystem while preserving interface consistency.

The architecture integrates an optimizer named Catalyst, introduced in 2014. This component analyzes and improves SQL queries as well as data transformations. It exploits Scala’s characteristics to generate high-performance code, merge operations, and reduce transfers between cluster nodes.

The unified programming interface represents a breakthrough. Developers combine different types of processing in the same application: SQL, streaming, machine learning. No more juggling between different specialized systems. This approach streamlines data pipeline complexity.

The community experienced exceptional growth. In 2015, more than 1,000 contributors participated in development, making Spark one of the most dynamic open source initiatives in data processing. Companies like Databricks, founded by the original creators, built commercial services on this technology.

The performance is impressive. For iterative algorithms, Spark can be up to 100 times faster than Hadoop MapReduce thanks to keeping data in memory. In the domain of SQL queries, it rivals specialized systems like Impala, while providing greater flexibility.

Banks use it for risk analysis, e-commerce sites for their recommendation systems, research centers to process their experimental data. This diversity of uses demonstrates the system’s versatility.

In 2016, Spark became the Apache Foundation’s most active project. Some organizations deployed clusters of more than 8,000 nodes. The introduction of DataFrames, inspired by R and Python, simplified usage for data scientists manipulating tabular data.

Spark’s design influences the evolution of distributed systems. The programming model based on functional transformations and efficient memory management inspires numerous subsequent projects. Its unified approach for different types of processing is an industry reference.

Development continues by integrating advances in optimization and accessibility. The project maintains its orientation toward ease of use while improving its technical capabilities. Abundant documentation and learning tools train a new generation of developers in distributed processing principles.

By offering a solution to the limitations of existing approaches, while maintaining a balance between power and ease of use, this project transforms how organizations process their data at scale. Its continued evolution reflects the ever-changing nature of the distributed data processing field.

Top

Kubernetes

In 2006, Google faced a difficult equation. The company offered Gmail, YouTube, and its search engine for free to millions of users. How could they manage a colossal infrastructure without costs spiraling out of control? Engineers then developed Borg, an internal system capable of running thousands of applications across their fleet of machines. The name paid homage to an alien race from Star Trek, creatures connected by a collective consciousness. The analogy fit the project well. Borg optimized the use of hardware resources by orchestrating the execution of applications in containers, a technology that was only beginning to emerge. Google kept this treasure secret for years, aware of the technical advantage it represented.

In 2013, three engineers from the company – Craig McLuckie, Joe Beda, and Brendan Burns – had an insight. Docker had just made containers popular among developers, but the technology remained limited. It could only manage containers on a single machine. The experience gained with Borg opened the way to something more ambitious. Why not create a system capable of orchestrating containers at the scale of an entire data center?

They named their idea “Project Seven,” a reference to the character Seven of Nine from Star Trek, a former Borg drone. This nod established a link to the original system while marking a break toward greater openness. For that was where the real gamble lay. Making this project open source represented a risk. Urs Hölzle, Google’s chief technical officer, saw this container management expertise as a competitive advantage. But the company understood that widespread adoption required an active community of external developers.

The project ultimately took the name Kubernetes, from the ancient Greek kubernētēs, which designates the pilot or helmsman of a ship. This choice continued the maritime theme of Docker. The system was to steer containers, as a helmsman guides his ship. The logo displays seven spokes, a discreet trace of the initial name “Project Seven.”

The designers built Kubernetes drawing on lessons learned from Borg and its successor Omega. The architecture is based on clusters, with worker nodes on one side executing containerized applications, and control plane nodes on the other managing orchestration. The system uses labels to organize and manage containers flexibly, abandoning Borg’s rigid sequential numbering.

Version 1.0 was unveiled in 2015 at the OSCON conference. From launch, Microsoft, Red Hat, and IBM provided their support. Google entrusted the project to the Cloud Native Computing Foundation (CNCF), a nonprofit organization hosted by the Linux Foundation. This transfer guaranteed the project’s neutrality and collaborative development.

Kubernetes’ technical capabilities address the requirements of modern applications. Automatic container replication, load balancing, service discovery, application health monitoring, automatic repair in case of failure. The system pools multiple machines to efficiently distribute workload.

Kubernetes’ approach to APIs marks a notable evolution from Borg. Each object has three fundamental fields: metadata, desired state specification, and current status. This standardization simplified the development of tools and extensions by the community.

The management of “pods” brings a new dimension. A pod can contain multiple containers sharing resources. This design helps break down complex applications into smaller, better-isolated components without losing coordination between them.

Kubernetes’ rise is part of a broader transformation in software development. The system accompanied the growth of cloud computing and microservices architectures. Companies can now deploy their applications consistently, on their own servers as well as on AWS, Microsoft Azure, or Google Cloud.

The impact on the computer industry proved massive. In 2020, Kubernetes ranked among the ten most popular open source projects on GitHub. According to the CNCF, it became the second largest open source project after Linux. 71% of Fortune 100 companies use it.

This story shows how a technology developed to solve Google’s internal problems transformed into an industry standard through open source. It underscores the role of developer communities in large-scale technology adoption. Kubernetes has transformed how companies develop, deploy, and manage their applications, giving them the agility needed to innovate quickly without sacrificing service stability.

Top

Swift

In 2014, the mobile application market was experiencing spectacular growth. Mobile device sales were approaching one billion units, double that of personal computers. Apple seized this moment to announce, in June, the release of Swift, a new programming language blending imperative, object-oriented, and functional approaches.

Since 1996, the company had relied on Objective-C to develop its applications. But the language had aged. Swift arrived as an answer to this need for renewal: simplifying code without sacrificing power, making programming more fluid, more intuitive. The designers sought to create something expressive, where interaction with the code feels almost natural.

The success was immediate. In less than a year and a half, Swift joined the club of the twenty most used languages in the world. This rise can be explained first by iOS’s immense installed base: over 700 million devices sold. Apple’s dominance in its segment and the announcement of Objective-C’s gradual replacement did the rest. Developers had little choice, but the language proved appealing enough to win them over.

Swift brought its share of innovations. Optional types, for example, represented a real advance. This feature, common in functional languages but rare elsewhere, forces developers to explicitly handle null values. Fewer errors, greater clarity. Version 2.0 introduced a new system for error handling with do-try-catch, abandoning the old NSError approach inherited from Objective-C.

Experienced developers adapted without too much difficulty. Some characteristics recalled Objective-C, like those named parameters that make code readable almost like an English sentence. Yet an analysis of questions asked on StackOverflow revealed gray areas. Nearly 17.5% of queries concerned fundamental concepts: type manipulation, array handling. The language wasn’t as simple as it appeared.

Development practices showed interesting patterns. Optional chaining became popular. This elegant technique avoids dereferencing errors while keeping code compact. Instead of stacking conditions, operations are chained with a question mark. The program becomes safer and more pleasant to read.

The early years were not free from criticism. The compiler, in particular, was frustrating. It lacked stability, its error messages remained obscure. Xcode, the development environment, had bugs that slowed down teams. These technical problems contrasted with the promises of an improved development experience.

Integration with Objective-C was a major challenge. Apple had provided mechanisms to make both languages coexist within the same application. This compatibility was vital: impossible to rewrite everything at once, and existing libraries were too numerous to do without. The transition happened in stages, project by project.

Faced with the language’s limitations, developers devised workarounds. The error handling system, for instance, didn’t always suit asynchronous code. Some then adopted result enumerations, circumventing the restrictions. This creativity testified to a community taking ownership of the tool, shaping it to their needs.

The App Store generated considerable revenue. In January 2015, developers had earned 25 billion dollars, more than on other platforms. This financial windfall attracted both companies and independents. Swift was a profitable investment, not just a matter of technical preference.

The language evolved based on feedback. Each new version corrected flaws, optimized features. Documentation expanded, tutorials multiplied, and learning became less arduous for newcomers. Apple listened, adjusted, improved.

Swift represented a turning point in Apple’s strategy. The company didn’t just follow trends; it forged a modern language integrating current best practices. This approach preserved the ecosystem’s stability while propelling it toward the future. No abrupt break, but a controlled transformation.

Introducing a new programming technology is delicate. One must innovate without losing what’s been gained, attract without imposing, renew without breaking. Swift succeeded, establishing itself as an essential player in mobile development. The following years would confirm this position, making the language far more than a simple replacement for Objective-C.

Top

Kafka

In 2008, at LinkedIn, Jay Kreps faced a challenge that no one had really anticipated. The professional social network was generating millions of messages each day, and traditional systems struggled to keep pace. Classic transactional data—profiles, user relationships—remained manageable. But it was primarily the mass of behavioral information that posed problems: profile views, keyword searches, various interactions. These digital traces, essential for understanding member expectations, literally overwhelmed the existing infrastructure.

Kreps then decided to develop a new solution. He partnered in 2010 with Neha Narkhede and Jun Rao to finalize what would become Apache Kafka. The name references writer Franz Kafka, a nod to the software’s primary purpose: efficiently managing message stream writing. The team designed a distributed platform capable of broadcasting events in real time, with an architecture designed to handle considerable volumes.

The idea that makes all the difference lies in a counter-intuitive approach to storage. Where classic solutions keep messages in RAM, Kafka writes them directly to hard disk, sequentially. This method takes advantage of the natural optimization of linear input-output operations on hard drives, delivering impressive throughput without sacrificing reliability.

LinkedIn released Kafka as open source in 2011, under the aegis of the Apache Foundation. Silicon Valley giants took interest: Twitter, Netflix, and Yahoo adopted the technology, soon followed by more traditional companies like Goldman Sachs, Walmart, and Cerner. At LinkedIn, the numbers are staggering: over 800 billion messages processed daily, representing more than 175 terabytes of data flowing flawlessly.

In 2014, the three creators founded Confluent. Their objective: develop the ecosystem around Kafka and offer enterprise solutions based on this technology. The impact was immediate: the adoption rate multiplied sevenfold in the eleven months following the company’s launch.

The architecture rests on simple but effective concepts. Messages are organized into "topics," categories that structure data flows. Each topic divides into partitions, replicated across different servers to guarantee availability and fault tolerance. This organization distributes the load and scales the system horizontally, without theoretical limit.

Development continued with major features. Kafka Connect, available since version 0.9, simplifies integration with other systems through a standardized framework for connectors. Kafka Streams offers a stream processing library directly integrated into applications, without additional infrastructure to deploy.

In 2022, KRaft (Kafka Raft) was released, a native consensus mechanism that replaces the historical dependency on ZooKeeper. The architecture becomes simpler and more reliable. This year also saw the introduction of tiered storage: part of the data can now be offloaded to object storage systems like S3, significantly reducing operating costs.

Kafka has transformed how companies think about their real-time data processing architectures. The model has inspired numerous alternatives: RedPanda offers an implementation compatible with the Kafka protocol, while WarpStream develops a radically different architecture favoring S3 storage.

In 2024, Kafka has established itself as a mature technology. Its adoption continues to grow, driven by the constant increase in real-time processing needs and the rise of the Internet of Things. The community that formed around the project regularly contributes to its improvement, ensuring continuous evolution.

The success stems from a solid technical architecture, a precise response to a real need, and a dynamic community supported by a stable company. What started as an internal project at LinkedIn has become a cornerstone of modern architectures.

Top

GraphQL

In 2012, Facebook’s teams hit a technical obstacle threatening the performance of their mobile applications. The News Feed API, designed according to the REST standards of the time, multiplied round trips between client and server. Each screen required multiple requests to different endpoints, and this fragmentation slowed down the user experience. On mobile networks, where every millisecond counts, the situation was critical. GraphQL was born as a pragmatic response to a real problem.

The initial idea rests on a simple observation: why couldn’t the client ask for exactly what it needs, no more and no less, all at once? REST architectures impose a rigid structure where each endpoint returns a predefined set of data. The client often retrieves too much useless information, or not enough, forcing it to chain calls. Facebook’s team reversed the logic: instead of the server dictating what it sends, the client specifies what it wants to receive.

For three years, GraphQL remained confined to Facebook’s servers. Engineers refined the concept, tested different approaches, corrected errors. The language took shape around a schema describing relationships between data as a graph. The syntax drew inspiration from JSON, familiar to web developers. In 2015, Facebook decided to publish the specification and a reference implementation. The community then discovered a radically different way of querying APIs.

The schema constitutes GraphQL’s cornerstone. It defines the available object types, their fields, and how they connect to each other. With this explicit contract between client and server, frontend developers know exactly what data they can request, backend developers understand what they must provide. The strong type system catches errors before queries execute, a safety net appreciated in production.

GitHub was among the first major adopters. The company rebuilt its public API with GraphQL, followed by Pinterest and Coursera. Twitter took a progressive path: TweetDeck and Twitter Lite served as testing grounds before deployment on Android and iOS applications. Each organization adapted the technology to its constraints, forged its own practices, contributed new tools.

Twitter’s case illustrates the necessary adjustments well. The infrastructure relies on microservices communicating via Thrift, a serialization system developed by Facebook. Integrating GraphQL required partial restructuring: a frontend layer intercepts GraphQL queries, validates them, handles authentication. Backend services preserve their business logic but expose their capabilities in a new way. This hybrid architecture preserves existing investments while exploiting GraphQL’s advantages.

Coursera encountered other difficulties. The first migration attempt failed due to synchronization problems between the GraphQL schema and actual data. The team found a clever solution: middleware translates existing REST APIs into GraphQL on the fly. Clients benefit from the new interface while the backend evolves gradually. This pragmatic approach demonstrates that there isn’t just one right way to adopt GraphQL.

The technical benefits didn’t take long. Gone was the under-fetching that forced multiple requests. Gone was the over-fetching that wasted bandwidth transferring superfluous information. A single well-formulated query retrieves exactly what’s necessary, involving multiple related resources if needed. Mobile applications breathe easier, web pages load faster.

The introspection type system opened unexpected possibilities. Development tools query the schema to provide autocompletion, dynamic documentation, real-time validation. IDEs transform into efficient assistants that guide the developer instead of leaving them to navigate through obsolete PDF documentation.

Gradually, the community enriched the language. To reuse query fragments, fragments emerged as an elegant solution. Directives offer a flexible mechanism to adapt behavior without modifying the schema. Subscriptions respond to the growing need for real-time updates, transforming GraphQL from a request-response system into a bidirectional communication channel.

Security represents a particular challenge. Query flexibility is a double-edged sword: a malicious client could formulate extremely complex requests to overload the server. The community developed safeguards: query depth limitation, complexity analysis before execution, granular permission control. These mechanisms allow exploiting GraphQL’s power without exposing infrastructure to abuse.

Gartner predicts that more than 60% of enterprises will use GraphQL in production by 2027, compared to less than 30% in 2024. This progression testifies to the maturity achieved by the technology. Apollo, Hasura, StepZen and other players offer solutions that simplify the deployment and management of GraphQL servers. The ecosystem expands, best practices crystallize, pitfalls are better identified.

Beyond simply replacing REST, GraphQL modifies the way of thinking about client-server interactions. The client no longer endures backend decisions, it expresses its needs. This inversion changes the dynamic between frontend and backend teams, encourages better collaboration, clarifies responsibilities. The shared schema is the common language that aligns everyone’s efforts.

Facebook wasn’t trying to revolutionize the web, just accelerate its mobile application. The solution found proved applicable far beyond the initial context. By publishing the specification and animating an active community, Facebook transformed an internal solution into an industry standard. GraphQL thus joins the list of technologies born from a particular need that ended up redefining the practices of an entire profession.

Top

TensorFlow

Google launched the Brain project in 2011, an initiative designed to explore deep neural networks in an industrial setting. The objective was straightforward: build practical artificial intelligence systems, initially for research, then for the company’s products. This work led to DistBelief, an early machine learning system that provided researchers with a testing ground to experiment with complex neural architectures.

From 2011 to 2015, DistBelief served as the foundation for numerous breakthroughs. Unsupervised learning, language representation, image classification, object detection, video and speech recognition: application domains multiplied. More than fifty teams at Google and other Alphabet subsidiaries deployed neural networks based on this technology. The services that benefited covered a broad spectrum: search engine, online advertising, speech recognition, Google Photos, Maps, StreetView, Translate, YouTube.

Building on this experience, Google designed TensorFlow as DistBelief’s successor. The platform was released in November 2015 under the Apache 2.0 license with a completely redesigned architecture that was a game-changer in the design of learning systems. Its flexibility enabled the expression of highly varied algorithms as computation graphs, all with enhanced performance for both training and model deployment.

TensorFlow’s distinguishing feature lies in its ability to operate on heterogeneous distributed systems. A single model runs seamlessly on a mobile phone or in a computing center equipped with thousands of graphics processors. This adaptability drastically simplifies the practical use of learning systems by eliminating the need to create specialized versions for each environment.

TensorFlow relies on a representation of computations as directed graphs. Nodes represent mathematical operations, edges carry tensors, these typed multidimensional arrays. This abstraction naturally suits learning algorithms, which constantly manipulate matrices and vectors. The system automatically manages the distribution of computations across available processing units.

The architecture is built around several components. The system’s core defines basic operations: elementary mathematical computations, array manipulation, linear algebra, building blocks for neural networks. These operations benefit from optimized implementations according to processor types. Variables maintain the model’s state from one execution to another. Queues ensure synchronization and efficient data transfer.

Developers access TensorFlow through Python and C++ interfaces. They build their models by assembling basic operations into a computation graph. The system then handles distributed execution, memory management, and optimizations. Tools like TensorBoard help understand and debug models by visualizing their structure and the evolution of learning metrics.

TensorFlow integrates symbolic gradient computation. This functionality automates a delicate task: calculating the derivatives required by optimization algorithms such as stochastic gradient descent. The system analyzes the computation graph and automatically generates the operations corresponding to partial derivatives, applying the chain rule of differentiation.

Numerous optimizations improve performance and resource utilization. Common subexpression elimination removes redundant computations. Judicious placement of operations on different processors limits communications. Compression of data exchanged between machines reduces the required bandwidth. These optimizations are critical when training large-scale models.

Deployment in Google products demonstrates TensorFlow’s effectiveness. The speech recognition system’s error rate plummeted from 13.25% to 2.5% over five years. Image classification performance on ImageNet jumped from 63% to 91% accuracy. These dramatic leaps resulted from the combination of more sophisticated architectures and the ability to efficiently process enormous volumes of data.

Google simultaneously developed a range of specialized processors: TPUs (Tensor Processing Units). These integrated circuits, tailored for reduced-precision linear algebra operations, offer substantial gains in performance and energy efficiency compared to conventional CPUs and GPUs. Successive generations of TPUs form massively parallel systems, reaching several exaflops for machine learning.

The open-source release created an active community. Researchers and developers adopted TensorFlow in highly diverse fields: computer vision, natural language processing, robotics, information retrieval, geographic information extraction, drug discovery. Contributors continuously enriched the platform.

The flexible architecture and high performance made TensorFlow a reference for research and deployment of complex models. The availability of mature tools and comprehensive documentation democratized access to deep learning techniques for a broad audience of developers.

TensorFlow’s evolution reflects the rapid progress of artificial intelligence. From early research prototypes to large-scale production systems, the platform has accompanied the development of increasingly sophisticated applications. Its distributed architecture and optimizations fully leverage modern computing resources to train ever more powerful models.

Over the years, TensorFlow has been enriched with various extensions. Support for new model types, performance improvements, addition of development and debugging tools have progressively strengthened its capabilities. The platform continues to evolve to meet the growing demands of machine learning and artificial intelligence.

Top

Accelerated Mobile Pages

In October 2015, Google launched Accelerated Mobile Pages, a technology designed to speed up mobile browsing. The findings are unequivocal: 53% of internet users abandon a page that takes longer than three seconds to load. Faced with this problem, Google sought a radical solution.

The project emerged from discussions between Google and European publishers as part of the Digital News Initiative. The initial idea targeted news sites, the first to be affected by reader frustration on smartphones. The technical solution rests on three pillars: a streamlined version of HTML, a JavaScript library that optimizes resource loading, and a caching system to store content. But this architecture imposes severe constraints. Style sheets cannot exceed 50 KB, custom JavaScript is prohibited, and images must use specific tags such as <amp-img> or <amp-video>.

The initial results exceeded expectations. The Washington Post recorded 23% more users returning within a week of their first visit. In Europe, the Plista platform observed an average 220% increase in click-through rates on AMP content, with peaks of 600% for certain publishers. These figures attracted attention. Pinterest, Reddit, Bing, and eBay adopted the technology. Google integrated it into its News section in February 2016, then extended it to all mobile results six months later. A small lightning bolt then appeared to indicate AMP pages in search results.

On the technical front, the performance was spectacular. Pages loaded in under one second and consumed ten times less data than their conventional equivalents. The AMP cache automatically verified page compliance and adapted images to mobile screens. This infrastructure achieved speed levels unattainable by traditional websites.

AMP usage quickly expanded beyond media. In 2018, the technology moved into e-commerce, interactive emails, and narrative content creation with AMP Stories. WordPress, which powers more than a third of the web, offered an official extension to simplify its deployment.

But AMP’s success came with sharp criticism. Despite its open-source code, many criticized Google for tightly controlling this technology. The fact that AMP pages were served from Google’s servers raised questions: who really owns the content? The preference given to AMP pages in search results fueled accusations of anti-competitive practices. These criticisms led Google to announce, in 2018, the standardization of AMP principles through the Web Platform Incubator Community Group. The objective was to allow any site to achieve instant loading without going through AMP, by simply meeting certain performance criteria with more open standards such as Web Packaging and Feature Policy.

In 2020, Google continued developing AMP while gradually opening up the format. AMP E-mail brought interactivity to electronic messages, while AMP Stories created immersive visual content. The project now includes more than 600 million pages across 232 countries and 104 languages.

The technology has undeniably accelerated smartphone browsing, but it has also reinforced centralization around major platforms. Its evolution toward more open standards reflects the search for a balance between performance and decentralization. Beyond technical aspects, with AMP, speed has become a determining factor in the mobile experience.

Natural Language Processing

Since the 1950s, researchers have been trying to teach computers to understand our language. Natural language processing, more commonly referred to as NLP in specialized circles, has long stumbled over the same obstacles: how to capture the subtleties, double meanings, and changing context of a conversation? Early machines worked with fixed dictionaries and rigid grammatical rules. Then came statistical approaches in the 2000s, which brought their share of improvements without truly solving the fundamental problem.

The year 2017 marks a turning point. On the Mountain View campus, Ashish Vaswani and Jakob Uszkoreit are discussing machine translation in a hallway. A seemingly mundane conversation that will lead to something unexpected. Their team consists of eight Google researchers, including Illia Polosukhin, a science fiction enthusiast. It’s precisely a film, Arrival, that gives him an idea. In this story, aliens communicate with symbols that express entire concepts at once, without following our usual sequential logic. Why couldn’t machines do the same with sentences?

This reflection leads to the concept of self-attention: instead of analyzing words one after another like reading a book, the system grasps the sentence as a whole. All words interact with each other simultaneously. Noam Shazeer, who has been working at Google since 2000 and created the famous “Did you mean?” function, hears about the project in the offices. He joins the venture. The first trials on English-German translations yield encouraging results.

The resulting Transformer architecture is faster and more accurate than previous recurrent neural networks, and it’s not limited to text. The model processes images, computer code, DNA sequences. This versatility surprises its creators.

The following year, another team from Google AI publishes BERT. The acronym conceals a simple idea: reading in both directions. The context of a word depends on what comes before, but also on what follows. BERT performs on eleven different language processing tasks, breaking previous records.

Curiously, all eight researchers behind Transformers leave Google in the following years. Each founds their own company, exploits the technology in their own direction. Aidan Gomez launches Cohere for businesses, Jakob Uszkoreit creates Inceptive and applies Transformers to vaccines, Noam Shazeer develops Character.ai where users design their own conversational agents. Vaswani and Parmar establish Essential.ai. We find here a classic pattern: large organizations struggle to transform their discoveries into commercial products. Researchers leave to create elsewhere.

This architectural foundation has since fueled all modern language models. The ability to process enormous volumes of data, to weave complex links between elements of a sequence, makes Transformers an indispensable tool. Applications multiply: more natural translation, coherent text generation, document analysis, high-performing question-answering systems. Machines are approaching the nuances of human language, better understanding the relationships between ideas.

From word-by-word processing of the early days to contemporary attention systems, each step has brought computers closer to our linguistic complexity. Transformers are not just a technical feat. They serve as a foundation for a cascade of innovations in various fields: medicine, scientific research, education. The scientific community constantly develops new variants.

As these models gain sophistication, they alter our relationship with technology. The boundary between human communication and machine interaction becomes blurrier. Future developments promise new possibilities while raising questions of ethics and responsibility. How far will this capacity of systems to understand and produce natural language go? The answer is being written day by day, in laboratories as in our daily uses.

Top

WebAssembly

In 1995, JavaScript emerged as a simple scripting language. No one imagined it would become the engine for sophisticated Web applications. Originally, it was mainly used to validate forms or animate a few page elements. The heavy lifting was done on servers, with browsers only handling display and basic interactions.

Everything changed with the arrival of high-performance engines like V8. JavaScript began handling programs of several thousand lines, applications that would have been unthinkable just a few years earlier. The language found itself being used far beyond what it had been designed for.

This transformation pushed Web stakeholders to seek alternative paths. Microsoft tried its hand with ActiveX, which relied on signing x86 binaries—an approach based on trust rather than genuine technical guarantees. Google then developed Native Client, which introduced sandboxing for machine code on the Web. Performance approached native levels, but developers had to follow strict constraints in their code, such as using binary masks before each memory access.

Emscripten then opened up a new possibility: compiling C or C++ to JavaScript. The system created a runtime environment in JavaScript and translated the code to a specialized subset, which gave birth to asm.js. Low-level code could finally be executed in a browser, but JavaScript remained a constraining intermediary.

It was in 2015 that the story took an unexpected turn. Engineers from Google Chrome, Mozilla Firefox, Microsoft Edge, and Apple Safari sat down at a table to work together. These historical competitors, who had engaged in "browser wars" for years, decided to collaborate. Their goal? Create a portable bytecode format they called WebAssembly.

The project had clear ambitions. It needed a compact representation, fast validation, efficient compilation. And above all, safe execution without performance penalty. The designers made a bold choice: formalize the semantics from the start. WebAssembly thus became the first industrial language designed with formal semantics from its inception.

The resulting architecture has some distinctive features. WebAssembly relies on a stack machine to represent computations. But thanks to its type system, compilers can analyze data flow between instructions without having to physically materialize this stack. Control flow is structured: no wild goto, but classic constructions via nested blocks.

Memory works like a large array of bytes, separated from code and the execution stack. A failing or compromised program can only corrupt its own data. This isolation ensures security: the code executes in a sandbox that prevents it from accessing the host system without authorization.

The binary format was designed for the network. Instructions fit in one byte, integers use the LEB128 format. Browsers can start compilation as soon as the first bytes are received, without waiting for the complete module download.

In 2017, the four major browsers integrated WebAssembly support. Each team chose its own implementation strategy. V8 and SpiderMonkey repurposed their JIT compilers to compile modules before instantiation. JavaScriptCore followed a similar path. Chakra preferred to translate on the fly to an internal bytecode, then compile the most frequently used functions.

WebAssembly often reaches 80 to 90% of native code performance, while maintaining the Web’s portability and security. The generated code is compact: 62.5% of the size of asm.js on average, 85.3% of that of native x86-64.

WebAssembly’s influence extends beyond the browser. Its design makes it usable in other contexts. Standalone implementations exist that transform WebAssembly into a portable format for native applications. This echoes Java’s original ambition of "write once, run anywhere."

Development continues. Zero-cost exceptions have arrived, as have threads and SIMD instructions. Integration with browser garbage collectors is underway, which will facilitate the compilation of languages like Java, C#, Swift, or OCaml to WebAssembly.

Beyond the technical aspects, WebAssembly testifies to the achievement of collaboration in the Web ecosystem. The project shows that a rigorous, almost academic approach can coexist with the realities of industrial development. This technology has redefined what can be run in a browser, without sacrificing the security that lies at the heart of the Web.

Top

WebAuthn

Since the first computer systems emerged, the question of user authentication has been a constant concern. Passwords quickly became the obvious answer: a character string known to the user, simple to implement, easy to understand. Except that this simplicity poorly conceals its weaknesses. Passwords are stolen, guessed, intercepted. In 2024, more than 80% of security breaches still exploit weak or stolen passwords.

Over time, other methods have emerged. Two-factor verification, digital certificates, biometrics. Each contributes its part, but they sometimes remain cumbersome to deploy or lack true uniformity. This is where the W3C and the FIDO Alliance decided to change the game with Web Authentication, more simply called WebAuthn.

Google, Mozilla, Microsoft, and Yubico rolled up their sleeves to develop this specification published in 2019. The idea breaks with what had been done for decades. Instead of sharing a secret between the user and the server, WebAuthn relies on asymmetric cryptography. When you register with a service, a key pair is created. The private key stays securely on your device, while the public key goes to the server with a randomly generated identifier.

In this architecture, the public key stored on the server side is useless for hacking your account. Attackers are increasingly losing interest in databases. Authentication is tied to the exact domain of the site: a key created for example.com will never work on evil-example.com. Phishing attempts lose much of their effectiveness.

WebAuthn rests on three pillars. Robustness first: authentication relies, when possible, on a hardware security module that keeps private keys and performs cryptographic calculations. Scope second: each key pair is only valid for a specific origin, like the cookies we know well. Attestation finally: authenticators can provide a certificate that proves to the server that the public key comes from a trusted source.

Browsers quickly adopted this technology. Chrome, Firefox, Edge, Safari: all support the standard. Developers therefore have the ability to integrate it uniformly. Modern operating systems followed with their own authentication systems: Windows Hello at Microsoft, Touch ID at Apple.

The process itself unfolds in several stages. During registration, the server transmits data that links the user to their credentials, with information about the organization and a random string to counter replay attacks. The browser uses the Web Authentication API to request the creation of a new key pair.

The response contains the authenticator identifier, client data in JSON, an attestation object. The server verifies all this according to a 19-step procedure described in the specification. Once validated, it stores the public key and identifier in its database.

For subsequent logins, you prove that you possess the private key by creating an assertion. The server sends a new random string, the authenticator generates a digital signature that the server verifies with the public key it has kept. No more risk of password theft, and the user experience is improved.

WebAuthn is part of FIDO2, a set of technologies that aims to generalize passwordless authentication. The need is felt: in 2024, only 28% of users enable two-factor authentication on their online accounts.

The specification continues to evolve with new features and implementations that are refined. Developers find code examples and libraries in different languages, notably Python and Go, to integrate WebAuthn into their applications.

The history of WebAuthn shows how authentication methods on the Internet are transforming. By replacing passwords with cryptographic keys, this standard meets current security requirements while simplifying users’ lives. Major web players are increasingly adopting it, and one can bet that in the future, authentication will become both more secure and more convenient.

This evolution is part of a broader movement where asymmetric cryptography is gradually replacing the shared secrets of the past. WebAuthn represents an important milestone in the history of computer security, providing a standardized solution to this authentication problem that has pursued us since the beginning.