Author: Bruno Couriol

Thomas Steiner, Developer Relations Engineer at Google, recently published a blog post announcing that JSON module scripts were now available in all modern browsers. Developers using the latest version of modern browsers can now directly import JSON modules into their JavaScript code. The feature builds on the Import Attributes proposal. Native CSS modules import may soon follow.

Import attributes tell the runtime how a particular module should be loaded. The primary use case is to load non-JS modules, such as JSON modules and CSS modules.

Steiner provides the following code sample to illustrate the syntax:

import astronomyPictureOfTheDay from "./apod.json" with { type: "json" };

const {explanation, title, url} = astronomyPictureOfTheDay;

document.querySelector('h2').textContent = title;
document.querySelector('figcaption').textContent = explanation;
Object.assign(document.querySelector('img'), { src: url, alt: title });

Non-browser runtimes such as Deno align with browser semantics:

import file from "./version.json" with { type: "json" };
console.log(file.version);
const module = await import("./version.json", {
  with: { type: "json" },
});
console.log(module.default.version);
{
  "version": "1.0.0"
}

In both cases, there is no JSON parsing needed as all major browsers implemented the native parsing as part of Interop 2025 (Baseline Newly available). Previously, web developers’ options included using a bundler, an extra transpilation step, or using polyfills to support those browsers that had not implemented the feature yet.

On the web, each import statement results in an HTTP request. The response is then prepared into a JavaScript value and made available to the program by the runtime. The specification explicitly calls out type: "json" to be supported. The type attribute however also supports CSS modules:

import styles from "https://example.com/styles.css" with { type: "css" };

As a developer noted on Reddit, CSS module imports are not part of Interop 2025 but may be included in the next Interop:

I proposed it for Interop 2025 but it was rejected, so hopefully next year. Though it is currently supported in Chrome.

With CSS, the result of importing a CSS file would be a constructable stylesheet, something that you could feed directly to a DOM API like adoptedStyleSheets (e.g. custom elements / Web Components)

[…] Just gotta wait for the CFP for Interop 2026

While this was considered in earlier versions of the proposal, JSON modules do not however support named exports. The proposal champions opted not to allow named exports because not all JSON documents are objects, and in their opinion, it made more sense to think of a JSON document as conceptually “a single thing” rather than several things that happen to be side-by-side in a file.

Developers can review the browser compatibility of the Import Attributes syntax, CSS module imports, and JSON module imports on MDN.

The Ecma Technical Committee 39 (TC39), the body responsible for the evolution of JavaScript (ECMAScript), recently advanced nine proposals through its stage process, with three new language features becoming part of the standard: Array.fromAsync, Error.isError, and explicit resource management with using.

Array.fromAsync is a utility for creating arrays from asynchronous iterables. This simplifies collecting data from sources like asynchronous generators or streams, eliminating the need for manual for await...of loops.

The feature explainer provides the following real-world example from the httptransfer module:

async function toArray(items) {
  const result = [];
  for await (const item of items) {
    result.push(item);
  }
  return result;
}

it('empty-pipeline', async () => {
  const pipeline = new Pipeline();
  const result = await toArray(
    pipeline.execute(
      [ 1, 2, 3, 4, 5 ]));
  assert.deepStrictEqual(
    result,
    [ 1, 2, 3, 4, 5 ],
  );
});

With the new syntax, this becomes:

it('empty-pipeline', async () => {
  const pipeline = new Pipeline();
  const result = await Array.fromAsync(
    pipeline.execute(
      [ 1, 2, 3, 4, 5 ]));
  assert.deepStrictEqual(
    result,
    [ 1, 2, 3, 4, 5 ],
  );
});

The Error.isError() method also advances to Stage 4, providing a reliable way to check if a value is an error instance. The alternative instanceof Error was considered unreliable because it will provide a false negative with a cross-realm (e.g., from an iframe, or node’s vm modules) Error instance.

Another proposal reaching Stage 4 is Explicit Resource Management, introducing a using declaration for managing resources like files or network connections that need explicit cleanup. This proposal is motivated in particular by inconsistent patterns for resource management: iterator.return() for ECMAScript Iterators, reader.releaseLock() for WHATWG Stream Readers, handle.close() for NodeJS FileHandles, and more.

There are also several footguns that the proposal alleviates. For instance, when managing multiple resources:

const a = ...;
const b = ...;
try {
  ...
}
finally {
  a.close(); 
  b.close(); 
}

Import Attributes (formerly Import Assertions) advances to Stage 3. This feature allows developers to add metadata to import declarations to provide information about the expected type of the module, such as JSON or CSS.

Other proposals moving forward at various stages include Promise.try, aimed at simplifying error handling in promise chains, RegExp.escape for safely escaping strings within regular expressions, and more. Developers may review the full list in a blog article online.

TC39 is the committee that evolves JavaScript. Its members include, among others, all major browser vendors. Each proposal for an ECMAScript feature goes through the following maturity stages:

• Stage 0: Strawman
• Stage 1: Proposal
• Stage 2: Draft
• Stage 3: Candidate
• Stage 4: Finished

A feature will be included in the standard once its proposal has reached stage 4 and thus can be used safely. Browser support may however lag behind adoption of the features in the standard.

A new open-source AI-powered code editor, Void IDE, was recently released in beta, positioning itself as a privacy-focused and free alternative to popular closed-source AI editors like Cursor and GitHub Copilot. Backed by Y Combinator, Void IDE is a fork of Visual Studio Code. While Microsoft recently announced plans to open Source its GitHub Copilot Chat Extension possibly in a few months, the beta release is available now for the community to fiddle with.

The primary motivation behind Void IDE is to address concerns surrounding the privacy and cost associated with proprietary AI coding tools. Closed-source editors may require sending private code data through their backends, raising privacy issues and leading to ongoing subscription costs. While the backend may often keep only embeddings computed from the code, the original code may sometimes be recoverable. As the authors of the paper Mitigating Privacy Risks in LLM Embeddings from Embedding Inversion explain:

The surge in popularity of embedding vector databases in LLMs has been accompanied by significant concerns about privacy leakage. Embedding vector databases are particularly vulnerable to embedding inversion attacks, where adversaries can exploit the embeddings to reverse-engineer and extract sensitive information from the original text data.

Void IDE aims to provide options for keeping developers in control of their data. Void IDE can leverage various Large Language Models (LLMs), supporting direct integrations with services like Claude, GPT, and Gemini, as well as local model hosting via Ollama. This ensures that AI processing can happen locally or via direct API calls, avoiding a third-party middleman.

Void IDE offers a range of AI-centric features familiar to users of tools like Cursor. These include inline code editing, contextual AI chat, and code generation. The editor also features advanced capabilities like file system awareness for codebase-wide context and the ability to view/edit the underlying prompts sent to the AI.

Being a fork from VS Code, Void IDE is able to let its users migrate their themes, key bindings, and settings.

Developers on Hacker News and Reddit expressed interest, particularly regarding its open-source nature and privacy stance. Discussions include comparisons to other AI coding tools and editors. Some developers expressed skepticism about the proliferation of VS Code forks, with others asking why not use an extension instead. The project is actively developed, with the team encouraging contributions from the community to shape its future roadmap.

Deno Land recently released Deno 2.3, an update of the Deno runtime that adds support for local NPM packages. Deno 2.3 also brings improvements to deno compile.

Deno 2.3 makes testing and developing an npm package locally possible. Deno thus provides mechanisms to override dependencies, enabling developers to use custom or local versions of libraries. The mechanism is similar to npm link in Node.js, and is configured through the patch field in deno.json:

{
  "patch": [
    "../path/to/local_npm_package"
  ]
}

Developers can review the provided example.

deno compile compiles a project into a single standalone binary, thus facilitating the executable distribution. This allows distributing Deno applications to systems that do not have Deno installed. Under the hood, it bundles a slimmed-down version of the Deno runtime along with the JavaScript or TypeScript code.

Deno 2.3 extends deno compile to support programs that use Foreign Function Interface (FFI) and Node native add-ons. FFI provides a bridge between Deno’s JavaScript runtime and native code, allowing developers to use existing native libraries within Deno applications, implement performance-critical code in languages like Rust or C, or access operating system APIs and hardware features not directly available in JavaScript.

Developers can additionally now reduce the size of executables by excluding specific files from being embedded during the compilation process (e.g., exclude development or test files from production builds).

To upgrade to Deno 2.3, developers need simply run the following command in the terminal:

deno upgrade

Deno 2.3 includes additional features, including improvements to deno fmt (allowing developers to format embedded CSS, HTML, and SQL in tagged templates), expanded OpenTelemetry support (basic event recording, span context propagators, and more), faster dependency installation, and more. For the full list of features, developers are invited to review the release note.

Deno is open-source software that is available under the MIT license. Contributions are encouraged via the Deno Project and should follow the Deno contribution guidelines.

The latest version of Svelte includes a new functionality dubbed attachments that enhances a web application’s DOM with interactive and reactive features. Svelte Attachments replace Svelte Actions.

Just like with Svelte Actions, developers use attachments to provide code to run when a component or DOM element is mounted or unmounted. Typically, the provided code would provision a listener for an event of interest, and remove that listener when the attachment target is unmounted. Attachments can also be used in conjunction with third-party libraries that require a target DOM element. Attachment that depends on reactive values will rerun when those values change.

Follows an example using the ScrambleTextPlugin from the GSAP animation library:

<script>
  import { gsap } from 'gsap'
  import { ScrambleTextPlugin } from 'gsap/ScrambleTextPlugin'

  gsap.registerPlugin(ScrambleTextPlugin)

  
  function scramble(text, options) {
    return (element) => {
      gsap.to(element, {
        duration: 2,
        scrambleText: text,
        ...options
      })
    }
  }

  let text = $state('Svelte')
</script>


<input type="text" bind:value={text} />
<div {@attach scramble(text)}></div>

When the DOM is mounted for the first time, the text Svelte will be scrambled. Additionally, any further change to the text value will also cause the text to be scrambled. Developers can experiment with the example in the Svelte playground.

Thus Svelte Attachments extend Svelte Actions which did not provide similar reactivity to its parameters. Additionally, Svelte Attachment can be set up on Svelte components, while Svelte Actions can only be declared on DOM elements. The release provides a mechanism to create attachments from actions, thus allowing developers to reuse existing libraries of actions.

Attachments can be used to encapsulate behavior separately from markup (as done in other UI frameworks, e.g. hooks in React). Examples of behaviors that were already implemented as actions and can now benefit from attachment affordances include clipboard copying, clickboard pasting into an element, capturing a click outside an element, masking user input, animating an element, pointer drag-to-scroll behavior, provisioning of shortcut keys, make an element swipeable, download on click, and many more.

Developers are invited to read the full documentation article online for an exhaustive view of the feature, together with detailed examples and explanations. Developers may also review the corresponding pull request for details about the motivation behind the feature and comments from developers.

OpenAI recently announced rewriting its Codex CLI in Rust. Codex CLI stack originally features React, TypeScript and Node. The rewrite seeks security and performance gains on top of improved developer experience.

The announcement explains the motivation for the rewrite as follows:

Our goal is to make the software pieces as efficient as possible and there were a few areas we wanted to improve:

• Zero-dependency Install — currently Node v22+ is required, which is frustrating or a blocker for some users
• Native Security Bindings — surprise! We already ship a Rust for Linux sandboxing since the bindings were available
• Optimized Performance — no runtime garbage collection, resulting in lower memory consumption
• Extensible Protocol — we’ve been working on a “wire protocol” for Codex CLI to allow developers to extend the agent in different languages (including Type/JavaScript, Python, etc) and MCPs (already supported in Rust)

Rust is a system language that prioritizes performance, memory usage, reliability, and resource consumption as design goals. Rust’s rich type system and ownership model guarantee memory safety and thread safety — thus eliminating many classes of bugs at compile-time. On the downside, Microsoft (which mandated the use of Rust for new developments that do not require garbage collection) developers reported a steep initial learning curve, and the reliance on some non-stabilized Rust features. While there are no further details at the moment, the ability to extend the Codex CLI with languages with a larger developer base such as JavaScript and Python will be key to community contributions.

Codex CLI’s Rust version is ongoing. The team continues work on the original TypeScript version in parallel to fix vulnerabilities until the Rust version reaches parity in terms of experience and functionality. Developers can try the new version as follows:

npm i -g @openai/codex@native
codex

Rust rewrites news are becoming commonplace, in particular for tooling in search of performance gains. Microsoft itself recently announced porting the TypeScript compiler to Rust with 10x performance improvement. There is additionally ongoing research to use Rust for safety-critical environments such as space onboard systems.

In the words of OpenAI, Codex is a cloud-based software engineering agent that can work on many tasks in parallel. Codex can perform tasks such as writing features, answering questions about a codebase, fixing bugs, and proposing pull requests for review; with each task running in its own sandbox environment.

Codex CLI is open source on GitHub and runs on MacOS, Linux, or Windows via WSL (Windows Subsystem for Linux).

At its Build 2025 conference, Microsoft announced plans to open source over the next few months the code behind the GitHub Copilot Chat extension under the MIT license and refactor core AI capabilities directly into the main VS Code codebase. The move, if completed, may affect the ability of current for-pay AI code editors to compete purely on features.

Microsoft cited several reasons for open-sourcing Copilot Chat. They noted the significant advancements in large language models, which have reduced the need for and value of proprietary prompting strategies. In fact, the company Anthropic regularly releases the system prompts for its Claude models. Keeping prompts secret for long remains a challenging endeavor in the face of community-led transparency efforts. AI prompts can additionally be protected by copyright only under certain restrictive circumstances. The same applies to patenting.

Microsoft’s open-sourcing decision also addresses requests from extension authors who needed tighter integration into VS Code than is currently offered by the public extension APIs. The Copilot Chat extension utilised VSCode’s Proposed APIs, a set of unstable APIs implemented in VS Code but not exposed to the public as stable. Regular extension authors, on the other hand, were not able to publish extensions using the Proposed APIs on the Visual Studio Code Marketplace.

The alternative was, as Cursor, Windsurf, et. al. did, to fork Visual Studio Code. As those forks grew in popularity and raised a significant amount of venture capital, Microsoft started to enforce its extension marketplace rules so that forks like Cursor could no longer fetch Microsoft-licensed extensions (e.g., C/C++ extension). By moving the Copilot Chat extension to an MIT license, with its core features integrated into the VS Code core, Microsoft may severely restrict the ability of forks with limited software development teams to compete purely on features against the broader community of extension authors.

Microsoft also quoted the need for increased transparency regarding data collection and improved community-driven security as driving factors for open-sourcing the extension.

This initiative positions VS Code to evolve beyond supporting AI extensions to becoming an “AI-native editor” by default.

Initial developer reactions on platforms like Reddit and Hacker News have shown general approval for the open-sourcing. Discussions often focus on the potential for integrating local AI models, the impact on the competitive editor landscape, and the potential for community contributions to the core AI features. The move is largely seen as a positive step for transparency and the broader developer tools ecosystem.

Visual Studio Code’s product manager chimed in on Reddit:

(vscode pm here)
We do want to open-source the Github Copilot suggestion functionality as well. The current plan is to move all that functionality to the open-source Copilot Chat extension (as step 2). Timeline – next couple of months.
[…] See the engineering plan here

Chat is compatible [with ollama]!

See https://code.visualstudio.com/docs/copilot/language-models#_bring-your-own-language-model-key

Suggestions are not yet compatible – if you want that, we have a feature request that you can upvote. I do want us to add this https://github.com/microsoft/vscode-copilot-release/issues/7690

Microsoft made a flurry of announcements at its Build 2025 conference regarding future products and improvements on current products. The TypeScript team has announced an experimental native port of the TypeScript compiler (tsc), aimed at providing a 10x improvement in build time, drastically reducing cold editor startup times, and substantially improving memory usage. Microsoft has announced Edit, a new open-source command-line text editor, which will be distributed in the future as part of Windows 11. Edit aims to provide a lightweight, native, modern command-line editing experience similar to Nano and Vim.

Microsoft’s TypeScript team has announced an experimental native port of the TypeScript compiler (tsc), dubbed tsc-go, aimed at providing 10x improvement on build time, drastically reducing cold editor startup times, and substantially improving memory usage. This initiative explores running the compiler (written in Go) without the Node.js runtime overhead.

Anders Hejlsberg, lead architect of the TypeScript project, explained the motivation behind the port as follows:

The core value proposition of TypeScript is an excellent developer experience. As your codebase grows, […] in many cases TypeScript has not been able to scale up to the very largest codebases. Developers working in large projects […] have to choose between reasonable editor startup time or getting a complete view of their source code […] New experiences powered by AI benefit from large windows of semantic information that need to be available with tighter latency constraints. We also want fast command-line builds to validate that your entire codebase is in good shape.

The standard tsc compiler running on Node.js, incurs noticeable startup time, especially on initial execution, for large projects or frequent, small builds. The new, experimental TypeScript compiler is written in Go and compiled to native code that runs without Node.js startup overhead.

The blog announcement mentions a reduction in type-checking time of VS Code’s 1 MLOC codebase from 77 seconds, down to 7.5 seconds, i.e., a 10x improvement. The same ratio is observed on the Playwright codebase (356,000 LOC) with a time reduced from 11s to 1s. Microsoft also reports maintaining this ratio on smaller codebases, with RxJS (2,100 LOC) seeing a reduction in type-checking time from 1,1s to 0,1s. The blog post does not provide Improvement figures related to incremental builds.

The TypeScript team also reports an 8x improvement in project load time in editor scenarios for the Visual Studio codebase and expects the same ratio to be constant over other codebases. Developer experience is poised to be improved as the time between opening the code editor and being ready to type into a fully loaded codebase is significantly reduced.

The native port (codename Corsa) is still considered experimental and still misses many features, including incremental builds (cf. What works so far). The blog announcement explains that when the native codebase has reached sufficient parity with the current TypeScript, it will be released as TypeScript 7.0, with a mindful migration path to former versions:

We’ll still be maintaining the JS codebase in the 6.x line until TypeScript 7+ reaches sufficient maturity and adoption.

Developer reactions on platforms like Reddit and Hacker News asked about the rationale behind choosing Go over Rust. Ryan Cavanaugh, TypeScript dev lead, provided a detailed answer that developers are invited to check. To quote an excerpt:

In the end, we had two options – do a complete from-scratch rewrite in Rust, which could take years and yield an incompatible version of TypeScript that no one could actually use, or just do a port in Go and get something usable in a year or so and have something that’s extremely compatible in terms of semantics and extremely competitive in terms of performance.

In addition to the blog post, developers are encouraged to review the YouTube video in which Hejlsberg details the ongoing TypeScript port effort. Developers can also visit the GitHub repository for the development of the native port of TypeScript. A preview build is available on npm as @typescript/native-preview. A preview VS Code extension is available on the VS Code marketplace.

The project is released under the Apache License 2.0 and welcomes contributions and suggestions. For details, visit Contributor License Agreements. The project follows the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ.

At its Build 2025 conference, Microsoft announced Edit, a new open-source command-line text editor, to be distributed in the future as part of Windows 11. Edit aims to provide a lightweight native, modern command-line editing experience similar to Nano and Vim.

Microsoft explained developing Edit because 64-bit Windows lacked a default command-line text editor, a gap since the 32-bit MS-DOS Edit. Microsoft opted for a modeless design to be more user-friendly than modal editors like Vim (see Stackoverflow’s Helping One Million Developers Exit Vim) and built its own tool after finding existing modeless options either unsuitable for bundling or lacking Windows support.

Microsoft positions Edit as a simple editor for simple needs. Features include mouse support, the ability to open multiple files and switch between them, find and replace capabilities (including regex), and word wrap. The user interface features a modern interface and input controls similar to Visual Studio Code. There is however no right-click menu in the app.

Written in Rust, the editor stands small, at less than 250KB in size.

Discussions among developers on platforms like Reddit and Hacker News show varied reactions. Many commenters debated the necessity of a new CLI editor on Windows, questioning its use case given existing options. Some feel it’s redundant for those already using WSL with Nano or Vim or other tools like Git Bash, while others see it as potentially useful for quick, basic edits in a native Windows context without needing third-party installs or WSL.

Edit’s main contributor chimed in with a detailed rationale behind the in-house development:

We decided against nano, kilo, micro, yori, and others for various reasons. What we wanted was a small binary so we can ship it with all variants of Windows without extra justifications for the added binary size. It also needed to have decent Unicode support. It should’ve also been one built around VT output as opposed to Console APIs to allow for seamless integration with SSH. Lastly, first-class support for Windows was obviously also quite important. I think out of the listed editors, micro was probably the one we wanted to use the most, but… it’s just too large.

Microsoft has released Edit’s source code under the MIT license. Edit is not currently available in the stable channel of Windows 11. However, users can download Microsoft Edit from the project’s GitHub page.

Mark Russinovich, Chief Technology Officer for Microsoft Azure, delved in a recent talk at Rust Nation UK into the factors driving Rust adoption, providing concrete examples of Rust usage in Microsoft products, and detailing ongoing efforts to accelerate the migration from C/C++ to Rust at Microsoft by leveraging generative AI.

The original motivation for recommending Rust originated from a detailed review of security vulnerabilities. Russinovick says:

[The] journey actually begins with us looking at the problems we’ve had with C and C++ [… Looking at a] summary of Microsoft security response centers triaging of the vulnerabilities over the previous 10 years across all Microsoft products, 70% of the vulnerabilities were due to unsafe use of memory specifically in C++ and we just see this trend continuing as the threat actors are going after these kinds of problems. It also is causing problems just in terms of incidents as well.

Other major IT companies and security organizations have expressed similar conclusions. Google’s security research team, Project Zero, reported that out of the 58 in-the-wild 0-days for the year, 39, or 67% were memory corruption vulnerabilities. Memory corruption vulnerabilities have been the standard for attacking software for the last few decades and it’s still how attackers are having success. Mozilla also estimated a few years back that 74% of security bugs identified in Firefox’s style component could have been avoided by writing this component in Rust. In fact, Rust’s language creator, Graydon Hoare, contended at the Mozilla Annual Summit in 2010 in one of the earliest presentations about Rust that C++ was unsafe is almost every way, and featured no ownership policies, no concurrency control at all, and could not even keep const values constant.

Microsoft’s “Secure Future Initiative”, which Russinovich links to breaches performed by two nation-state actors, commits to expanding the use of memory-safe languages. Microsoft recently donated $1 million to the Rust Foundation to support a variety of critical Rust language and project priorities.

Russinovich further detailed examples of Rust in Microsoft products. In Windows, Rust is used in security-critical software. That includes firmware development (Project Mu), kernel components, a cryptography library (e.g. rustls symcrypt support), and ancillary components (e.g., DirectWrite Core).

In Office, Rust is being used in some performance-critical areas. The Rust implementation of a semantic search algorithm in Office, delivered to customers on CosmosDB and PostgreSQL, proved to be more performant and memory efficient than the C++ version, providing a significant win for large-scale vector searches.

Following a directive mandating that no more systems code be written in C++ in Azure, Rust is used in several Azure-related software. Caliptra is an industry collaboration for secure cloud server firmware. Key firmware components are written entirely in Rust and are open-sourced. Azure Integrated HSM is a new in-house security chip deployed in all new servers starting in 2025. The firmware and guest libraries are written in Rust to ensure the highest security standards for cryptographic keys. Russinovich also mentioned Azure Boost agents, Hyper-V (Microsoft’s hypervisor), OpenVMM (a modular, cross-platform Virtual Machine Monitor recently open-sourced), and Hyperlight as partly or entirely written in Rust.

Developer feedback at Microsoft has generally been positive but also included negatives. On the positive side, developers liked that if Rust code compiles, it generally works as expected, leading to faster iteration. Reduced friction in development leads to more motivation to write tests. Developers become more conscious of memory management pitfalls. The Rust ecosystem and Cargo are appreciated for dependency management. Performance increases are often observed (though not always the primary goal). Data-race-related concurrency bugs are reduced. Memory-safety-related vulnerabilities are significantly reduced.

On the negative side, developers mentioned that C++ interop remains difficult. The initial learning curve for Rust is further perceived as steep. Dynamic linking is a challenge. Reliance on some non-stabilized Rust features is a concern. Integrating Cargo with larger enterprise build systems requires effort. Foreign Function Interface (FFI) is tough to do safely, even in Rust. Tooling is still behind when compared with other languages.

Russinovich further describes Microsoft’s efforts to accelerate the migration of C/C++ legacy code to Rust. One area is verified crypto libraries, using formal verification techniques for C and then transpiling to safe Rust (see Compiling C to Safe Rust, Formalized). Microsoft is also exploring using large language models for automated code translation.

Russinovich concluded by reiterating Microsoft’s strong commitment to Rust across the company and emphasizing Rust’s increasing maturity and adoption:

You know people will come and say, hey wait, there’s this new language that’s even better than Rust. It’s more easy to use than Rust and I say well when is it going to be ready? Because we’re over 10 years into Rust and you know we’re finally ready because it takes a long time for a language to mature, for the tooling to mature, and we’re not even finally, you know, completely done with maturing the Rust toolchain. Anybody that wants to come along at this point and disrupt something that’s already as good as Rust has a very high hill to climb. So I don’t see anything replacing Rust anytime soon […] We’re 100% behind Rust.

Readers are strongly encouraged to view the full talk on YouTube. It contains abundant valuable examples, technical explanations, and demos.

Rust Nation UK is a multi-track conference dedicated to the Rust language and community. The conference features workshops, talks, and tutorials curated for developers of all levels. The conference is held annually at The Brewery.