Espresso Code: Italian Dev Insights

Insights and guides from an Italian passionate developer

Bar chart: TypeScript 7.0 and 7.1 Beta type-checking times on five codebases, Microsoft data from October 20, 2026

Faster TypeScript: the 7.1 beta in Go and tsrs, the Rust port

By

On 2026-10-22

In News

On October 20, 2026, two pieces of news arrived for anyone who writes TypeScript every day. Microsoft released the beta of TypeScript 7.1, the second version of the compiler rewritten in Go. On the same day, Cloudflare introduced tsrs, a port (that is, a faithful rewrite in another language) of the compiler to Rust.

A port is like a translator’s work: the book moves into another language, but the plot stays the same. For a compiler, the plot is the rules of the language, and the errors it reports should be identical.

But what does this mean, in practice, for anyone who runs tsc on their own code? Just consider that on the mui-docs project, the best of the five cases Microsoft measured, type-checking drops from 22.2 to 11.9 seconds with the beta [1].

The two announcements arrived together, but they are not the same thing. One is an official beta, with the Release Candidate, that is, the version that may become the final release, announced for about a month later; the other is an experimental project. Let’s try to separate the measured facts from the announcements.

In short:

The TypeScript 7.1 beta, released by Microsoft on October 20, 2026, type-checks faster than 7.0 according to Microsoft’s measurements and can be tried on a test branch. For tsrs, the Rust port, Cloudflare claims higher numbers, but measured with its own tests and on an experimental version. For a project in production, as of October 22, 2026, there is nothing to change.

  • TypeScript 7.1 Beta (October 20, 2026): on five real-world codebases, Microsoft measures type-checking 1.2 to 1.9 times faster than 7.0 and 15.8% to 49.6% less memory.
  • tsrs (October 20, 2026): in Cloudflare’s tests, with 4 threads on four projects, tsrs is up to 8 times faster than TypeScript 7.0.2, with about 70% less memory; these are not Microsoft’s tests.
  • Next steps: Microsoft announces the 7.1 Release Candidate “in about a month” from October 20, 2026; tsrs aims for a stable version aligned with TypeScript 7.1.

What was announced on October 20, 2026?

Two different compilers for the same language were announced. Microsoft released TypeScript 7.1 Beta, which on the npm registry corresponds to version 7.1.0-beta. It follows TypeScript 7.0, the first native compiler in Go, released by Microsoft on July 8, 2026 [1] [4] [5].

Cloudflare introduced tsrs in a post signed by Boshen Chen, Dimitri Mitropoulos, and Christoph Nakazawa. The project comes from the work of Max Schwenk, of Owner.com, and Cloudflare writes that it is incubating it within Oxc, a collection of JavaScript tools written in Rust. In the post, Cloudflare says it is working on it together with VoidZero and in close collaboration with the TypeScript team [2] [3].

Besides speed, 7.1 brings some new features for people who write code and for people who build tools [1] [4]:

  • import attributes (metadata such as with { type: "css" } attached to an import) can be declared in ambient modules (the ones described with declare module, usually in .d.ts files);
  • support arrives for source phase imports, that is, import source, useful for example for WebAssembly modules;
  • es2026 becomes a stable --target and --lib;
  • a new API (the interface through which other programs use the compiler) arrives for external tools, different from TypeScript 6’s; 7.0 had none.

For example, anyone importing CSS or Markdown files could declare a module for each extension; with 7.1 the declaration is tied to the import attribute, and TypeScript reports an error if the import is missing the required attribute. For tool authors, what matters instead is the API: with 7.0, Microsoft had made sure TypeScript 6 could run side by side for tools that need to access the compiler from code, such as typescript-eslint [1] [4].

What is the difference between TypeScript 7 in Go and tsrs in Rust?

The main difference is who maintains it and how far along it is. TypeScript 7 is Microsoft’s official compiler, written in Go, and version 7.0 has been stable since July 8, 2026. tsrs is a Rust port of the 7 compiler, maintained by others and, as of October 22, 2026, still experimental [2] [4].

In practice, anyone who installs the typescript package from npm is already using the Go compiler, and the command is still tsc. tsrs is a separate package, with the tsrs command, which compiles like tsc and accepts almost all of its options (the exceptions come later) [3] [4].

Cloudflare writes that the project is not a fork: the TypeScript team remains responsible for the language, and tsrs follows its behavior “in close collaboration” with that team [2].

The repository README, for its part, states two goals. The first is a stable version aligned with TypeScript 7.1, with 100% conformance; the second is to replace, without changes (drop-in), the compiler and language server (the program that gives the editor completions, errors, and code navigation) of TypeScript 7. It does, however, point out that the project is not affiliated with or endorsed by Microsoft [3].

The code is distributed under the Apache-2.0 license, as a derivative work of TypeScript. External pull requests are closed, while the repository’s tracker accepts bug reports [3].

Why a Rust port, if the Go one works? Cloudflare’s answer is WebAssembly, which I cover further on [2].

How much faster is TypeScript 7.1 than 7.0?

According to Microsoft, the TypeScript 7.1 Beta is 1.2 to 1.9 times faster than 7.0 on the five codebases it measured (post of October 20, 2026). The test uses the default configuration of 4 type-checking threads and the --noEmit option, which checks types without generating JavaScript files. So these are times for a type check, not for a continuous integration (CI) pipeline, and the gain varies from project to project [1].

CodebaseTypeScript 7.0TypeScript 7.1 BetaSpeedup (Microsoft)Less memory
bluesky4.48 s3.89 s1.2×15.8%
mui-docs22.2 s11.9 s1.9×49.6%
sentry19.6 s15.1 s1.3×20.8%
t3code-server26.5 s19.1 s1.4×24.6%
vscode21.6 s17.7 s1.2×17.2%
Source: Microsoft, “Announcing TypeScript 7.1 Beta” post, October 20, 2026 [1]. The post does not state the hardware used.

The gain, however, is not the same for everyone: on mui-docs the time is almost cut in half, while on bluesky and vscode the speedup is 1.2 times. So it pays to measure on your own code [1].

For 7.0, Microsoft had written that the Go compiler was often around 10 times faster than TypeScript 6, the previous version, written in TypeScript, as Cloudflare describes it. The two measurements come from different tests, on projects that only partly overlap: multiplying 10 by 1.9 gives a number that no source has measured. The sources give no direct numbers between 7.1 and the 5.x versions [1] [2] [4].

What did the move to TypeScript 7 mean outside the charts? In the 7.0 post, dated July 8, 2026, Microsoft reported that, according to Slack’s engineers, after moving to TypeScript 7, their type-checking in CI had dropped from about 7.5 to 1.25 minutes [4].

So the figure is about the move to TypeScript 7, not 7.1, and Microsoft does not say which version Slack was coming from. It should be taken for what it is: a testimonial collected by Microsoft [4].

Cloudflare, in its post, speaks of a 7.1 beta “up to 2.5x faster” than 7.0. But be careful: in Cloudflare’s charts the version measured is a nightly build (7.1.0-dev.20261019.1), not the beta, and the maximum value there is 2.58× on the MUI docs project [2].

These are two different measurements, not to be put side by side or compared with each other: the same MUI docs, on 7.0, takes 22.2 seconds in Microsoft’s tests and 10.44 in Cloudflare’s [1] [2].

How fast is tsrs, according to Cloudflare?

In Cloudflare’s early benchmarks, tsrs is up to 8 times faster than TypeScript 7.0, with the same number of checker threads. The comparison is between tsrs 0.18.0-ts7.1.0-dev.20260929, which ports a development version of 7.1 to Rust, and TypeScript 7.0.2, with 4 threads (--checkers 4) and --noEmit [2] [3].

The projects are VS Code, MUI docs, webpack, and t3code server, and the measure is real elapsed time (wall time). The post does not state the hardware [2].

In the chart with TypeScript’s default configuration (4 threads), Cloudflare reports type-checking from 3.83 times (VS Code) to 8.10 times (MUI docs) faster. Peak memory drops to between 0.13 and 0.31 times that of 7.0.2, that is, from 87% to 69% less (MUI docs and webpack). In the text, Cloudflare sums it up as “~70% less memory” [2].

The same chart also includes the 7.1 nightly, that is, the nightly build mentioned above: it is the closest comparison to 7.1 to be found there. Cloudflare does not make this comparison, but the times are there:

Projecttsrs7.1 nightly
VS Code1.73 s5.28 s
MUI docs1.29 s4.05 s
webpack0.23 s0.71 s
t3code server1.21 s7.17 s
Source: Cloudflare, “Introducing tsrs: A port of TypeScript to Rust” post, October 20, 2026, chart with TypeScript’s default configuration (4 threads) [2]. The post does not state the hardware used.

Working out the ratio, tsrs comes out about 3 times faster than the nightly on the first three projects and about 6 times faster on t3code server [2].

This should be read with two caveats. tsrs is based on a development version of 7.1 from late September (7.1.0-dev.20260930.4), the nightly is from October 19, and neither of them is the beta. In addition, Cloudflare’s post states neither the machine nor how tsrs was built [2].

As already said for 7.1, it matters who did the measuring: here it is tsrs’s own developers. Cloudflare writes that it worked with the TypeScript team to make sure the tests compare the same configuration, and it publishes the scripts in the repository’s bench folder. It also adds that some of the 7.1 optimizations come from tsrs, while Microsoft’s post does not mention tsrs [1] [2] [3].

A detail for anyone trying it: out of the box, tsrs does not use 4 threads but an adaptive configuration that, according to Cloudflare, is faster but uses more memory. For a like-for-like comparison with tsc, both need the same --checkers value [2].

Why do we need a TypeScript compiler in WebAssembly?

It lets the compiler run where a native program cannot go, such as the browser or an isolated environment (sandbox). WebAssembly is a binary format that browsers and runtimes execute in a portable and secure way. As of October 22, 2026, the tsrs README points to a playground in the browser, where you can try type-checking and code generation [3].

According to Cloudflare, a Go program compiled to WebAssembly has to carry its own garbage collector, the system that frees unused memory. Rust, on the other hand, does not need one, and this simplifies exchanging data with the environment that hosts it. The WebAssembly package is called @tsrs/wasm and, according to the README, uses the wasm32-wasip1 target [2] [3].

Cloudflare mentions three possible uses: sandboxed development tools for AI agents, the browser, and embedded or IoT devices (Internet of Things, connected objects). The first is the closest to its own work: an agent can run the entire development toolchain in an isolated environment on Cloudflare’s platform [2].

Will tsrs replace the official TypeScript compiler?

In a project it can take its place, because it is designed to replace tsc without changes. As the reference for the language, no: Cloudflare writes that it is not a fork and that decisions about the language remain with the TypeScript team [2] [3].

The replacement also covers the editor: the repository documentation explains how to start the language server with tsrs --lsp -stdio. The same document warns that the language server does not yet run content mappers, the plugins through which TypeScript 7.1 checks files such as Vue or Svelte files [1] [3].

There are still known differences, however. The README mentions the order in which some diagnostics appear and the lack of support for --init and --showConfig. Cloudflare also writes that it is working with Theo Browne to merge tsrs and tsc-rs, another Rust port, into a single package with a language server and content mappers [2] [3].

It remains to be seen how such a large project can stay aligned with the original. For tsrs, Cloudflare wants to use the method it already applies to Vinext: an agent that reads the original project’s changes every morning, and compatibility tests rerun every night.

AI also shows up in another part of the post. To explain why a port like tsrs is arriving precisely in 2026, Cloudflare argues that the most advanced AI models can do large ports “almost independently in a matter of days” [2].

Cloudflare, however, does not say how much of tsrs was written this way, nor does it attach any data. In the post, though, it links to the one by Max Schwenk on Owner.com, dated October 19, 2026, which presents tsrs as “A Rust port of TypeScript, written entirely by agents” [2] [7].

I wrote about the limits of these models in A.I. – Artificial Intelligence and Discrimination. An LLM (Large Language Model, the kind of model behind chatbots) picks the most likely word and can produce content that is coherent but false, the so-called hallucinations. For a compiler, then, tests count for more than announcements.

How do you try the TypeScript 7.1 beta and tsrs on your own project?

You install the beta as a development dependency, with the command given by Microsoft [1]:

npm install -D typescript@beta

In a test run on October 22, 2026, on Linux x86_64 (Debian 13, Node.js 20.19.2) and in an empty project, the command prints:

added 2 packages, and audited 3 packages in 2s

found 0 vulnerabilities

To check the version:

npx tsc --version
Version 7.1.0-beta

On October 22, 2026, this is the version that corresponds to the beta tag on npm, while latest is still 7.0.2. Before merging it into the main branch, it is a good idea to run type-checking in CI and read the new errors [5].

Microsoft in fact points out two changes that can make some appear. The first concerns the DOM types (the interfaces through which code uses the web page in the browser) in lib.d.ts. The second is a stricter check on distributive type parameters, with a new error message, which Microsoft explains with a simple image: “a Cat might be a subtype of Animal, but it certainly won’t be a subtype of every type of Animal” [1].

If you use Vue, Svelte, Astro, or MDX, you can also look at content mappers: Microsoft warns, however, that the example package for Vue is not yet on npm [1].

For tsrs, Cloudflare gives the shortest form, npm install tsrs and then npx tsrs. The project README instead recommends installing it as a development dependency and running it with --noEmit, which checks types without generating JavaScript. With npm, it looks like this [2] [3]:

npm install -D tsrs
npx tsrs --noEmit

In the same test run, the installation adds two packages, tsrs and its binary for Linux x64. On a small test file (src/index.ts) with two type errors, npx tsrs --noEmit prints the same lines as tsc 7.1.0-beta and exits with code 2:

src/index.ts(4,7): error TS2322: Type 'string' is not assignable to type 'number'.
src/index.ts(5,20): error TS2345: Argument of type 'number' is not assignable to parameter of type 'string'.

With correct code it prints nothing and exits with 0, and in neither case does it write files. It is a single test file, so it says nothing about conformance in general.

Why --noEmit in particular? Without that option, tsrs behaves like tsc: it reads tsconfig.json and generates the JavaScript files, and in the same test run it generated them even with the type errors. There is a reason for -D too: without it, npm adds tsrs to the production dependencies.

To see which TypeScript version it is based on:

npx tsrs --version
Version 7.1.0-dev.20260930.4 (tsrs 0.18.0-ts7.1.0-dev.20260929, microsoft/TypeScript@b85298b6a81f)

As the output shows, tsrs is based on a development version of TypeScript, 7.1.0-dev.20260930.4, and not on the beta. The package name, on the other hand, carries September 29: as of October 22, 2026, the version published on npm is 0.18.0-ts7.1.0-dev.20260929 [6].

Before trying it, it is worth checking your system. Version 0.18.0 has binaries only for macOS on Apple Silicon and for Linux x64 and arm64, with both glibc and musl (the two most widely used C libraries on Linux; musl is the one Alpine uses). No Windows and no Mac with an Intel processor [6].

If the check fails or gives results different from tsc, the report goes in the tsrs repository’s tracker on GitHub, which accepts bug reports with a minimal reproduction. tsrs is not a Microsoft project [3].

What should you do before the final release of 7.1?

My advice, while waiting for the final release, is to keep production on TypeScript 7.0, which remains the stable version, and to try the 7.1 beta on a separate branch. tsrs is worth following, especially for anyone working with browsers, WebAssembly, or agents, but it should be treated as an experiment [1] [5].

Tool authors, such as those writing plugins or editor integrations, have more reasons to try the beta: Microsoft is asking for feedback on the new API. Anyone working on Linux or on a Mac with Apple Silicon can instead run tsrs alongside tsc with --noEmit and compare the errors, without touching the build [1].

It remains to be seen whether Microsoft’s Release Candidate will confirm the beta’s numbers, and whether tsrs will reach the stable version it has promised.

Frequently asked questions

Why did Microsoft write TypeScript 7 in Go and not in Rust?

To stay as close as possible to the existing code. In the “Why Go?” discussion in the typescript-go repository (March 5, 2025), Ryan Cavanaugh of the TypeScript team explains that a port was needed, not a rewrite, and that Go, written idiomatically, resembles the style of the original code. The garbage collector, he adds, carries little weight in the TypeScript codebase. Cloudflare chose Rust for WebAssembly, where it does not have to carry a garbage collector along.

How much faster is TypeScript 7.1 than 7.0 and earlier versions?

From 1.2 to 1.9 times faster than 7.0, according to Microsoft’s measurements of October 20, 2026 on five codebases, with 4 threads and --noEmit. For 7.0, Microsoft had indicated about 10 times the speed of TypeScript 6: different tests, not to be multiplied. The sources report no direct comparisons with the 5.x versions.

Can I use the TypeScript 7.1 beta in production?

Better not: it is a beta, and Microsoft says nothing about production use. The Release Candidate is announced for about a month after October 20, 2026, with the final release shortly after. It is best to try it on a separate branch and in CI, checking for new errors in the DOM types and on distributive type parameters.

Does typescript-eslint work with TypeScript 7?

Not directly with 7.0, which has no API for external tools. In its July 8, 2026 post, Microsoft explains that it made sure TypeScript 6 can run side by side, with the @typescript/typescript6 package, for tools such as typescript-eslint. The 7.1 Beta brings a new API; in the typescript-eslint tracker (issue #10940), support for 7.1 was a work in progress in late September 2026.

Can I use tsrs instead of tsc in my project?

Yes, for testing: the README presents it as a drop-in replacement for the TypeScript 7 compiler and language server. As of October 22, 2026, the version on npm is 0.18.0, which is based on a development version of 7.1, not on the beta, and has no binaries for Windows or for Macs with an Intel processor. You install it with npm install -D tsrs and run it alongside tsc with npx tsrs --noEmit.

How do I try the TypeScript 7.1 beta on my project?

With npm install -D typescript@beta, the command given by Microsoft on October 20, 2026, on a dedicated branch and with type-checking in CI. For tsrs, the README gives -D and --noEmit: with npm, npm install -D tsrs and npx tsrs --noEmit. Version 0.18.0 binaries exist only for Linux and for macOS on Apple Silicon.

Sources

  1. Microsoft (Daniel Rosenwasser and the TypeScript team), “Announcing TypeScript 7.1 Beta,” October 20, 2026 – https://devblogs.microsoft.com/typescript/announcing-typescript-7-1-beta/
  2. Cloudflare (Boshen Chen, Dimitri Mitropoulos, Christoph Nakazawa), “Introducing tsrs: A port of TypeScript to Rust,” October 20, 2026 – https://blog.cloudflare.com/typescript-rust-port/
  3. Oxc project, oxc-project/tsrs repository on GitHub (README, documentation in docs/, and bench folder), accessed October 22, 2026 – https://github.com/oxc-project/tsrs
  4. Microsoft (Daniel Rosenwasser), “Announcing TypeScript 7.0,” July 8, 2026 – https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/
  5. npm registry, typescript package (dist-tags: beta = 7.1.0-beta, latest = 7.0.2), data read from the registry on October 22, 2026 – https://registry.npmjs.org/typescript
  6. npm registry, tsrs package (latest = 0.18.0-ts7.1.0-dev.20260929, Apache-2.0 license, per-platform binaries in optionalDependencies), data read from the registry on October 22, 2026 – https://registry.npmjs.org/tsrs
  7. Owner.com (Max Schwenk, Head of AI Developer Experience), “tsrs,” October 19, 2026 – https://building.owner.com/tsrs
  8. Microsoft (Ryan Cavanaugh, TypeScript team), “Why Go?” discussion in the microsoft/typescript-go repository, March 5, 2025 – https://github.com/microsoft/typescript-go/discussions/411
  9. typescript-eslint, issue #10940 “Enhancement: Use TS 7 (tsgo / typescript-go) for type information” (update by Josh Goldberg, late September 2026), accessed October 22, 2026 – https://github.com/typescript-eslint/typescript-eslint/issues/10940

A.I. – Artificial Intelligence and Discrimination

By

On 2026-10-21

In Uncategorized

“How can I help you today?” – These are the words of one of the best-known Artificial Intelligences; in fact, few people have never read them and never tried asking it questions.

But what is an AI? What is it capable of doing? Is it impartial, being a machine?

From the first artificial neuron to Big Data

The first step in this field was taken more than 80 years ago, contrary to what one might imagine. It was a neurophysiologist and a logician, Warren McCulloch and Walter Pitts, who proposed the first model in 1943, built by trying to imitate a biological neuron. Since then, efforts have been made to refine the imitation, but the basic model has always remained the same.

But why is it only in recent years that artificial intelligence has captured so much media attention, on everyone’s lips, from governments trying to keep pace in order to regulate it, to companies looking for talent to be able to implement it, to ordinary people who use it widely instead of the more traditional search engines?

The reason why the time is ripe only now comes down to two factors: Big Data and the enormous computing power we now have thanks to technological progress.

Big Data is a vast set of data, which may or may not be structured, and it is only since the advent of the internet that people have begun to write enormous amounts of text and to generate an inconceivable mass of content such as images and videos: just consider that more than 500 hours of video are uploaded to YouTube every minute1.

The human brain and artificial intelligence

Just as a child begins to speak by imitating their parents, who day after day, tirelessly, talk to them and care for them, so too is this tool the result of the “training data” it repeatedly comes into contact with.

But however useful this metaphor may be, we have not yet reached an artificial intelligence as sophisticated as the cognitive abilities of a human being. In fact, the activation functions, the neural structure, the efficiency of operations, the capacity to adapt and the plasticity of the whole are very far from being able to imitate a biological organism.

Biological synapses are much more than simple connections: they are complex structures involved in transmitting, processing and modifying signals. Their strength and behavior change dynamically, contributing to learning, memory and other complex brain functions2.

The parameters of artificial intelligence are mathematical values within a model, adjusted during the learning process. Artificial intelligence models have difficulty reasoning and thinking critically. They are not able to form their own opinions, analyze situations from different points of view or learn from experience in the same way a human brain does. They can analyze enormous amounts of text and generate human-like text by identifying patterns and statistical relationships between words. However, they do not intrinsically understand the meaning of the words they use. In fact, an LLM (Large Language Model) analyzes a very large body of text to predict which word is most likely to follow a sequence of words already written. It considers several factors, such as co-occurrence, that is, how often two words (n-grams) appear together, their syntactic and grammatical role, etc. Although governed by sophisticated processes, it is a purely statistical choice: the model assigns a probability to each different word and usually chooses among the most probable ones according to the patterns it was trained on.

The quality of an AI is closely tied to that of its training data.

Applications and hallucinations

Neural networks can be applied in different sectors and can specialize in different functions:

  • we have talked about text generation, but they can also generate pieces of music and images;
  • they can predict an event and tell us how likely it is to occur, such as the efficacy of a drug or its side effects;
  • they can analyze determining factors, extracting and generating value from data;
  • they are capable of recognizing patterns, highlighting anomalies or understanding a consumer.

They have very broad, many-sided capabilities, but this does not make them immune to errors such as “hallucinations.”

We speak of hallucination when a model generates content that makes no sense or, worse, seems to make sense but is false and not supported by any logical or scientific basis. The more versatile an AI is and the more capable it is of handling different topics, the more insidious the hallucination3. Faithfulness hallucinations occur when the output generated is not consistent with the instructions or the context provided by the user, or contradicts itself. For example, a model asked to summarize a news article might generate a summary that seems realistic and well written, but that contains information absent from the article or that contradicts it.

Factuality hallucinations occur when the text generated is grammatically correct and consistent with the training data, but impossible or highly improbable in reality. For example, a model trained on a dataset of recipes might generate a new recipe that includes nonexistent ingredients or impossible cooking instructions.

One of the main reasons that can lead to hallucinations is the bias hidden in the training data, which favors certain behaviors and discriminates against others, producing a “biased output.”

An impartial algorithm?

There was a time, and perhaps for some it is still so, when, dreaming of an external and impartial system of judgment, people believed that an algorithm could make choices that were based on data and therefore objective4. But software cannot be immune to human influence and partiality, much less an Artificial Intelligence that learns from inequalities entrenched over the years. It is not able to tell good from evil: what is “right” and what is “wrong” is introduced through labels on the data, and the model manages to generalize this concept, becoming able to repeat it on unlabeled data too, without, however, understanding the reason. A simple “mathematical operation.”

Using automated systems to make decisions amplifies discrimination, instead of reducing or eliminating it, taking it to a larger scale.

Inequality: a limitation or an asset?

Although bias plays an important role in the process of discrimination, it does not necessarily cause it: bias is defined as a deviation from the standard, and it is sometimes necessary in order to identify the existence of statistical patterns in data or language. Classifying and finding differences would be impossible without bias5.

Indeed, the relationship between bias and discrimination is not always clear and understandable.

Many claim that by eliminating bias, discrimination can also be eliminated or reduced, but since implementations often ignore the context in which the algorithm will be used, the decision as to whether a biased output results in a case of discrimination is often left to the user to assess.

To explain this concept better, let’s think of a sophisticated algorithm that recommends which candidates are the best to hire after analyzing their résumés. We might notice that it favors candidates aged between 25 and 35, and this could be discrimination; but if instead the goal is precisely to hire younger candidates in order to have generational turnover within the company, then it would not be a case of discrimination by the algorithm, but an expected result.

Measures of bias and awareness

There are different ways of measuring bias; the statistical measure is the most intuitive and comprises three aspects. The first is that different categories should be able to appear in the results with the same probability: for example, if four out of five applicants from the advantaged group were granted a mortgage, the same proportion of applicants from the protected group should obtain the mortgage as well. The second aspect is satisfied if the unprotected and protected groups have an equal probability that a positive classification is correct, while the last aspect is that of well-calibration: the probability estimated by the algorithm must match the actual frequency of outcomes in each group6.

As already mentioned, this is the simplest measure, but other, more complex measures are used in order to have a model that limits inequalities and does not create discrimination, such as the measure of similarity between individuals called “fairness through awareness”7, according to which, for fairness to hold, the distance between the distributions of outcomes for individuals should be at most the distance between the two individuals as estimated by means of a similarity metric.

This shows us how much energy is spent in the field on analyzing a model with the aim of improving it as much as possible and minimizing discrimination. But without the awareness of users, every effort risks being in vain: we must use common sense and intelligence before applying an algorithm or a model to automate decisions on a large scale. Artificial intelligences are powerful tools and, as such, can lead to great benefits or great disparities. There is a growing need for honest, God-fearing people8, aware of the limits and risks of these tools and able to use them wisely.

Originally published in the dossier “Tempo del Creato 2024” of the GLAM commission of the FCEI (Federation of Protestant Churches in Italy)

  1. How YouTube search works – YouTube Help (“over 500 hours are uploaded every minute”; figure reported by YouTube in 2019). See also Statista. ↩
  2. Proverbs 20:5 “A person’s thoughts are like water in a deep well, but someone with insight can draw them out.” (GNT) ↩
  3. L. Huang et al., A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions, arXiv:2311.05232, 2023. ↩
  4. Can an Algorithm Hire Better Than a Human? – The New York Times (nytimes.com) ↩
  5. The definitions and examples in this section and the next are drawn from, and in places closely follow the wording of, X. Ferrer, T. van Nuenen, J. M. Such, M. Coté, N. Criado, Bias and Discrimination in AI: a cross-disciplinary perspective, arXiv:2008.07309, 2020. ↩
  6. Criteria such as calibration within groups and balance for the positive and negative classes cannot, except in very special cases, all be satisfied at the same time: J. Kleinberg, S. Mullainathan, M. Raghavan, Inherent Trade-Offs in the Fair Determination of Risk Scores, 2016 (ITCS 2017). ↩
  7. C. Dwork, M. Hardt, T. Pitassi, O. Reingold, R. Zemel, Fairness Through Awareness, ITCS 2012. ↩
  8. Galatians 3:3 “How can you be so foolish! You began by God’s Spirit; do you now want to finish by your own power?” (GNT) ↩

Scripture quotations marked (GNT) are from the Good News Translation in Today’s English Version – Second Edition Copyright © 1992 by American Bible Society. Used by Permission.

GOOD NEWS TRANSLATION™ is a trademark of the American Bible Society and may be used only under license.

When Faith Inspires Innovation: Ellen White and the Science Behind SuperWood

By

On 2025-05-13

In Uncategorized

Ellen G. White’s nineteenth-century descriptions of antediluvian timber—gigantic trees whose wood was “fine-grained,” “hardly less enduring than stone,” and able to resist decay for centuries—map with surprising fidelity onto the micro-scale architecture and bulk properties now engineered into InventWood’s “SuperWood,” a densified, partially delignified cellulose composite that is 10–12 × stronger and tougher than natural wood, lighter than steel, and highly resistant to rot and biological attack. A systematic comparison shows that the mechanical, durability and sustainability claims White ascribed to pre-Flood wood correspond within the same order of magnitude to peer-reviewed measurements of SuperWood’s strength (≈550 MPa), hardness, dimensional stability and longevity, while the spiritual motif of restoring original creation parallels the biomimetic strategy of restoring wood’s cellulose framework to its theoretical packing density. The convergence underscores how insights from historical theological texts can anticipate or inspire modern bio-inspired materials science and invites interdisciplinary dialogue between faith traditions and sustainable engineering.

Abstract

Ellen G. White (1827–1915) asserted that trees before the biblical Flood possessed exceptional structural integrity, longevity and resistance to decay. SuperWood—developed at the University of Maryland and commercialized by InventWood—achieves comparable performance through chemical delignification and hot compression that densifies cellulose nanofibers. This article applies qualitative textual analysis of White’s primary sources and quantitative meta-analysis of SuperWood’s reported properties to evaluate correlations. Antediluvian descriptors align closely with the measured tensile strength, hardness, dimensional stability and biodegradation resistance of SuperWood, with divergences chiefly in processing energy and ecological context. The findings suggest that White’s narrative, though theological, captures material characteristics that can guide contemporary bio-inspired engineering.

Keywords: Ellen G. White, antediluvian wood, SuperWood, densified cellulose, biomimetic materials, sustainability

Introduction

White’s canonical work Patriarchs and Prophets depicts pre-Flood arboreal species as “majestic trees…their wood…of fine grain and hard substance, closely resembling stone, and hardly less enduring” (ellenwhite.info). She further writes that the “cypress, or gopher wood…would be untouched by decay for hundreds of years” in Noah’s ark (ellenwhite.info).
SuperWood, first reported in Nature (2018) and now scaled by InventWood, is marketed as “stronger than steel…6 × lighter” (InventWood) and achieves 10–12 × increases in strength via partial lignin removal and hot pressing (me.umd.edu). Nature News summarized the breakthrough as “compressing the material and removing some of its polymers can increase its strength tenfold” (Nature). Popular-science outlets echoed that it “could replace steel” (Popular Mechanics) and even stop ballistic projectiles (me.umd.edu).

Materials and Methods

Textual corpus

White’s statements were extracted from digitized editions of Patriarchs and Prophets (Chapter 7) and cross-checked with Spiritual Gifts Vol. 3 for thematic consistency.

Mechanical data set

Mechanical metrics for SuperWood—ultimate tensile strength (UTS), modulus of rupture, toughness, and decay resistance—were taken from the 2018 University of Maryland press release (me.umd.edu); the Nature News report (Nature); the Popular Mechanics summary (Popular Mechanics); the National Geographic education brief (National Geographic Education Blog); and subsequent peer-reviewed densification studies covering hot isostatic pressing (Nature), nanofluidic alignment (Science), and 2025 cell-wall engineering advances (Nature).

Results

Structural endurance

White’s claim that gopher wood resisted decay “for hundreds of years” (ellenwhite.info) parallels InventWood’s statement that SuperWood “resists moisture, termites, rot” (InventWood).

Mechanical strength and toughness

The UTS of SuperWood (~550 MPa) (Nature) exceeds the lower bound of mild steel (≈250 MPa) while maintaining a density of 1.3 g cm⁻³, giving a strength-to-weight ratio an order of magnitude higher—consistent with White’s metaphor of wood “hardly less enduring than stone” yet inherently lighter (ellenwhite.info). Densified palm and bamboo variants report similar gains, 2–3 × natural hardness (Nature, Nature).

Dimensional stability and decay

InventWood cites “minimal expansion and contraction” for facade applications (InventWood), achieved by reducing amorphous regions vulnerable to moisture. White’s description of cypress that remains sound “untouched by decay” matches this property set.

Process parallels

White noted that antediluvian timber preparation required “much more labor…than now” due to tree size and hardness (ellenwhite.info). Modern densification likewise involves energy-intensive compression at about 100 °C and high pressure (smithsonianmag.com), echoing the concept of extraordinary effort to unlock wood’s latent strength.

Discussion

The convergence between White’s pre-scientific narrative and SuperWood’s empirically validated performance suggests two non-exclusive interpretations. First, her observations—rooted in meditative reflection—could express intuitive inference about pristine biological order, resonating with current understanding that optimal cellulose packing yields maximal mechanical performance. Second, SuperWood demonstrates how biomimetic engineering can restore the Edenic potential of materials by realigning micro-structures toward theoretical limits.
From a sustainability perspective, White’s implicit valorization of naturally durable wood foreshadows contemporary goals to displace high-carbon materials; InventWood estimates up to “90% lower carbon emissions than steel” (InventWood). Ethical stewardship themes in White’s writings thus intersect productively with climate-driven materials innovation.

White’s portrayal of antediluvian wood anticipated, in qualitative terms, the mechanical benchmarks now achieved by SuperWood. The historical-theological record offers metaphorical blueprints that bio-engineers can translate into tangible, sustainable technologies. Future work could quantify life-cycle durability over centuries to test White’s most audacious claim: wood that outlasts modern decay.

References

  1. White, E.G. Patriarchs and Prophets, Chapter 7: “The Flood.” (ellenwhite.info)
  2. White, E.G. Patriarchs and Prophets, p. 95. (ellenwhite.info)
  3. InventWood. “Technology—Reinventing Wood.” (InventWood)
  4. University of Maryland Press Release. “Super Wood Could Replace Steel.” (me.umd.edu)
  5. Nature News. “Crushed wood is stronger than steel.” (Nature)
  6. Popular Mechanics. “New chemical treatment makes ‘Super Wood’ that could replace steel.” (Popular Mechanics)
  7. Smithsonian Magazine. “A chemical bath and strong squeeze makes super-dense and strong wood.” (smithsonianmag.com)
  8. National Geographic Education Blog. “Super Wood is Stronger Than Steel.” (National Geographic Education Blog)
  9. Nature Communications. “Bioinspired self-flowing wood chemical treatment” (2025). (Nature)
  10. Scientific Reports. “Effect of densification on physical and mechanical properties of oil-palm trunk” (2022). (Nature)
  11. Scientific American. “Stronger than steel, able to stop a speeding bullet—It’s SuperWood!” (Feb. 7, 2018). (InventWood)
  12. Nature d41586-018-01600-6. “Crushed wood is stronger than steel.” (Nature)
  13. Popular Mechanics TikTok summary (2022) – wood-bending context. (tiktok.com)
  14. Science Advances. “Anisotropic, lightweight, strong, and super thermally insulating nanowood with naturally aligned nanocellulose” (2018). (Science)
  15. Scientific Reports. “Two-step hot isostatic pressing densification of hardwoods” (2023). (Nature)
Grafico a barre del costo livellato dell'idrogeno (LCOH, €/kg) per filiera: H2 grigio, H2 blu, fotovoltaico, eolico, FER, gassificazione e import

Hydrogen and renewables: a look at the future

By

On 2024-11-27

In News

Yesterday a press conference was held in the Auditorium of the Gestore dei Servizi Energetici (GSE) in Rome, where Minister Pichetto shared the National Strategy, which sets the goal of “Net Zero” by 2050.

Italy seems determined to carve out a leading role in the renewable energy landscape, focusing in particular on hydrogen as a strategic energy carrier for the future.

The strategic role of hydrogen

The Italian strategy recognizes hydrogen as a key element for decarbonizing sectors that are hard to electrify, such as heavy transport, shipping and aviation. With its ability to store energy and transport it over long distances at competitive costs, hydrogen represents a complementary solution to renewable sources, which suffer from some intermittency.

Note that hydrogen can mainly be divided into five categories, which are not official but are increasingly used:

  • Green hydrogen: produced through water electrolysis powered by renewable energy (photovoltaic, wind, hydroelectric, etc.)
  • Blue hydrogen: derived from natural gas with CO₂ capture, utilization and storage (CCUS). It could be considered as a transitional option, but Italy does not seem to have a large geological CO₂ storage capacity.
  • Gray hydrogen: produced from fossil sources without CO₂ capture. The most polluting, and therefore not a viable choice in a “green” context.
  • Pink hydrogen: produced from nuclear sources.
  • White hydrogen: of geological origin.

Currently, however, the national landscape is dominated by gray hydrogen, produced mainly through industrial processes such as Steam Methane Reforming (SMR) without CO₂ capture. This type of hydrogen is used mainly in refineries and in the production of ammonia for fertilizers. The transition toward low-emission hydrogen, whether blue or green, is one of the main goals of the plan.

Bar chart of the levelized cost of hydrogen (LCOH, €/kg) by production pathway: gray H2, blue H2, solar PV, wind, renewables, gasification, imports
LCOH (€/kg) of hydrogen for different production pathways

Innovations and synergies

Ammonia (NH3) is emerging as a particularly interesting alternative in the Italian context. This compound, obtained by combining green hydrogen and atmospheric nitrogen through the Haber-Bosch process, offers significant advantages over pure hydrogen, both in terms of energy density and logistics. Indeed, ammonia:

  • Is easier to store and transport: it liquefies at higher temperatures (−33 °C compared with −253 °C for liquid hydrogen), reducing energy consumption during these phases, and it has established transport infrastructure (such as ammonia tankers).
  • Is chemically stable: difficult to ignite and easier to store than pure hydrogen.
  • Avoids the boil-off problem: while liquid hydrogen tends to evaporate over time, ammonia maintains greater stability.
  • Has direct industrial applications: besides serving as an energy carrier, it is used without further transformation to produce fertilizers.

Tools and outlook

Italy has deployed a varied portfolio of tools, funded through the PNRR, to support the development of the hydrogen supply chain. These include:

  • Projects for Hydrogen Valleys, pilot areas for the local development of hydrogen.
  • Initiatives in rail and road transport, aimed at introducing alternative fuels.
  • Production of electrolyzers, essential for green hydrogen.
  • Support for research and development to accelerate innovation.

In addition, emphasis is placed on the synergy between hydrogen and CCS technologies, which could broaden decarbonization opportunities, including through low-carbon hydrogen.

The future of hydrogen in Italy

Among the strategy’s flagship projects, the Southern Hydrogen Corridor stands out: an international infrastructure project that will position Italy as a European hub for hydrogen. This project will facilitate import flows, strengthening energy cooperation in the Mediterranean and beyond.

In a world increasingly oriented toward sustainability, the vision outlined by Italy fits into a framework of international cooperation and technological innovation. It remains to be seen how these ambitions will take shape in the coming years, turning hydrogen from a promise into a pillar of the energy transition.

How to boot Radxa Rock 5B from an NVMe SSD

By

On 2024-04-04

In Guides

Radxa ROCK 5 Model B spec infographic: Rockchip RK3588, up to 16GB RAM, PCIe 3.0 x4 NVMe slot, 8K video, WiFi 6E, 2.5GbE

The tech community has seen a surge of single-board computers (SBCs) over the past few years, offering tech enthusiasts a plethora of options. However, few come as power-packed and future-ready as the Radxa ROCK 5 Model B. This potent Raspberry Pi alternative brings to the table a set of features that puts it a notch above many of its competitors.

Historically, the default choices for booting operating systems on such devices have been either through a microSD card (microSD) or embedded MultiMediaCard (eMMC) memory. While both methods have served their purpose, they come with their own sets of limitations, primarily in terms of speed and overall system responsiveness. Enter the NVMe (Non-Volatile Memory Express) drives, a game-changer in the world of storage solutions, known for their breathtaking speed and efficiency.

The PCIe 3.0 x4 slot on the ROCK 5B isn’t just a token feature; it represents a paradigm shift. By leveraging the capability to connect NVMe drives directly to this slot, users can bypass the traditional bottlenecks associated with microSD cards and eMMC memory. The potential benefits?

  • Faster boot times,
  • snappier system responses, and
  • a smoother user experience.

For those yearning to unlock this potential and revolutionize their SBC experience, the question isn’t about “why” but “how.” How does one transition from conventional storage methods to booting their operating system straight from an NVMe drive on the ROCK 5B? The upcoming guide promises to shed light on this transformative journey, offering step-by-step insights to supercharge your ROCK 5B experience.

Download the needed files

Let’s start by downloading the needed files: zero.img and the new bootloader.img, needed since we are going to flash it to the SPI NOR flash.

There are 4 different bootloader images:

  • normal bootloader [old], recommended for everything except Armbian, has the U-Boot serial console disabled
  • bootloader for Armbian, if you want to boot Armbian from the M.2 NVMe SSD
  • debugging bootloader [old] with U-Boot serial console enabled, if you need to troubleshoot booting issues over the serial console (for advanced users).
  • EDK2 bootloader for booting UEFI-compatible operating system images (currently experimental)

You can download files by using wget link.to/file.img. In this guide I’m using the first one.

mkdir bootloader
cd bootloader/
wget https://dl.radxa.com/rock5/sw/images/others/zero.img.gz
wget https://dl.radxa.com/rock5/sw/images/loader/rock-5b/release/rock-5b-spi-image-gd1cf491-20240523.img

We are going to decompress the file and check that the MD5 digest is the same as the one published on the Radxa website.

gzip -d zero.img.gz
md5sum zero.img

The result of the above command will be something like this: 2c7ab85a893283e98c931e9511add182 zero.img

md5sum rock-5b-spi-image-gd1cf491-20240523.img

cf53d06b3bfaaf51bbb6f25896da4b3a rock-5b-spi-image-gd1cf491-20240523.img

Here are the checksums of the other possible files:

2c7ab85a893283e98c931e9511add182  zero.img
cf53d06b3bfaaf51bbb6f25896da4b3a  rock-5b-spi-image-gd1cf491-20240523.img
fa14c99718f55b66e82aa1661e43c1ec  rock-5b-spi-image-gd1cf491-20240523-debug.img
bd21a6459ad33b8189782e4c904d99b3  rock-5b-spi-image-gbf47e81-20230607.img
1b83982a5979008b4407552152732156  rkspi_loader.img

If everything is okay, we can move on to checking whether the SPI flash is available:

ls /dev/mtdblock*

It will return the device: /dev/mtdblock0

Let’s flash the bootloader

The first step is to completely clear the SPI flash: (be patient: flashing can take up to 5 mins; in my case it took 3 mins)

sudo dd if=zero.img of=/dev/mtdblock0

Check whether the flash was successfully cleared:

sudo md5sum /dev/mtdblock0 zero.img

2c7ab85a893283e98c931e9511add182 /dev/mtdblock0
2c7ab85a893283e98c931e9511add182 zero.img

Okay! Now you can write the desired bootloader to the SPI flash using the following command:

sudo dd if=rock-5b-spi-image-gd1cf491-20240523.img of=/dev/mtdblock0

Be patient, it will take some time again; as soon as it has finished, you can run

sync

and then check again if everything was successful:

sudo md5sum /dev/mtdblock0 rock-5b-spi-image-gd1cf491-20240523.img

cf53d06b3bfaaf51bbb6f25896da4b3a /dev/mtdblock0
cf53d06b3bfaaf51bbb6f25896da4b3a rock-5b-spi-image-gd1cf491-20240523.img
In my case the two digests are identical, which means that everything went well; otherwise, flash the bootloader again.

Now you can safely reboot your device!

Simone Flavio

I’m the CTO of Rinoova and hold a Bachelor’s degree in Computer Science, cum laude. I’m passionate about Linux, electronics and anything that makes life simpler and more secure. In my spare time I tinker with ffmpeg, re-encoding my movie collection to AV1/HEVC. Squeezing the most out of storage and bandwidth has been a habit since childhood, when all I had was a 2 Mbps connection. That’s why every image on this blog is in AVIF: pages stay light and load fast.