We (@emmatyping, @eclips4) propose introducing the Rust programming language to CPython. Rust will initially only be allowed for writing optional extension modules, but eventually will become a required dependency of CPython and allowed to be used throughout the CPython code base.

As much as I like Rust, Python is a very early dependency in the bootstrap path for most Linux distributions (it’s a build-time dependency of glibc and gcc). With this change Rust becomes necessary to build most Linux distros, and it does not support all the architectures that Linux does. There is of course the Rust-for-Linux project aiming to bring Rust to the Linux kernel, but that is currently optional and is taking a conservative incremental approach for integrating it.

Rust supports all platforms which CPython supports and many more as well. Rust’s tiers are slightly different, and include information on whether host tools (such as rustc and cargo) are provided. Here are all of the PEP 11 platforms and their corresponding tiers for Rust:

In summary, every platform Python supports is supported [by] Rust at tier 2 or higher, and host tools are provided for every platform other than those where Python is already cross-compiled (e.g. WASI and mobile platforms).

I’m surprised how small the officially supported platform list is for Python. It’s certainly used on a much more diverse set of architectures than the official list. For example, there’s not a single musl based distro on the list. Gotta imagine there’s a lot of Alpine containers out there running Python code. Also of the BSDs only FreeBSD is listed.

Making Rust a dependency of CPython would introduce a bootstrapping problem: Rust depends on Python to bootstrap its compiler.

Rust already has a pretty sorry bootstrapping story, unfortunately this only makes it worse. There’s hope that gcc-rs comes to the rescue of bootstrapping quandaries like this as well as architecture support, but it doesn’t look to be getting anywhere near the resources it needs. For the health of the Rust project, and to make it less dramatic to introduce a dependency on Rust to established projects the Foundation could be funding gcc-rs more significantly.

Hans Halverson:

Brimstone is a JavaScript engine written from scratch in Rust, aiming to have full support for the JavaScript language.

Brimstone is a work in progress but already supports almost all of the JavaScript language (>97% of the ECMAScript language in test262). Not ready for use in production.

Brimstone features:

• Bytecode VM, heavily inspired by the design of V8’s Ignition
• Compacting garbage collector, written in very unsafe Rust
• Custom RegExp engine
• Custom parser
• Almost all builtin objects and functions implemented to spec

I love it when a near complete project just appears out of nowhere.

aapoalas on Lobsters:

As a fellow JavaScript engine developer, this was a really humbling project to stumble upon recently: effectively feature complete, double the performance of Boa which is already double the performance of the engine I work on, and done by a single person in the span of quite exactly 3 years (started November 19th of 2022). The engine I work on had its first commit a few months before that, although actual development started only in the summer of 2023.

Brimstone appears to be quite an impressive effort for a solo developer. The other project in the space that I’ve been watching is Boa. Boa had a notable release last month that included a bunch of improvements, and some significant performance gains.

From a quick glance over the API it looks like Boa has a more developed story for Rust⇿JavaScript bindings.

Alexander Petros:

When I advise people on how they should structure a web service, I always start from the same place: make a server that responds to HTTP requests with HTML text. That is the most durable, cost-effective, and user-friendly way to build a web service. Most web services should be built this way absent an excellent reason not to.

Upon hearing this, web developers often reply “oh, you like server-side rendering,” to which I usually wince and answer “more or less.” You have to pick your battles when chipping away at a decade of miseducation. At least people know what I’m talking about.

But “server-side rendering” is a horrible term. It implies that the server is not just doing more work, but doing hard work, work that’s best left to the experts. None of this is true. You, too, can do server-side “rendering,” with essentially no effort, in whatever programming language you prefer.

Once you understand that, you’ll start to see the web the way I do: as the simplest, easiest, and most powerful interface for computation ever created.

I’d not thought about things this way before, since the server often is rendering templates to generate the HTML sent to the client, but it’s a good point.

Just getting a couple letters on the page requires layout math that most web developers have never even considered. All this is learnable (that’s what the book is for), but web rendering is astoundingly complex. Imagine trying to implement kerning; instead, you get it for free.

I chuckled at this bit because I have implemented kerning, but the point remains: getting text onto a computer display is amazingly complex and a testament to how fast computers are.

The AlphaStation 500 is a workstation from Digital, circa 1996. Mine is a 500 MHz model and has an Alpha 21164A processor (aka EV56). And the way it boots is weird.

On your common-or-garden PC, there has always been some kind of ROM chip. It holds a piece of firmware known as the BIOS. This ROM chip is available at a well-known location in the processor’s address space (remembering that any PC processor boots up in 16-bit, 8088 compatible mode, with a 1 MiB address space, just like an IBM PC 5150) and the processor just starts executing code in it after reset.

The Alpha (or at least this AlphaStation 500 - although I think they mostly worked like this) is different.

There is a serial ROM (SROM) on the main board, and after reset, some logic internal to the CPU kicks in to generate a clock pulse. This drives an (external) counter, which provides consecutive addresses into the ROM. The 1-bit output of the ROM is sent into the processor, in sync with the clock pulse. The Alpha processor stores this data in its internal Instruction Cache. Once the code load is complete, the processor then executes the code, from its cache. The code is just enough to get the processor to configure its external memory bus, and find a memory-mapped parallel ROM, which it will then hand-over execution to.

But wait, how do you find a 1-bit wide ROM chip? Aren’t most ROM chips at least 8 bits wide? Yes, they are.

Well that’s certainly an interesting take on booting. The rest of the post is about trying to decipher an SROM dump in order to work out why a system might not be booting. It even includes some DEC Alpha assembly—that’s not something you see everyday.

Mihai Parparita:

Infinite Mac can now run early Mac OS X, with 10.1 and 10.3 being the best supported versions. It’s not particularly snappy, but as someone who lived through that period, I can tell you that it wasn’t much better on real hardware. Infinite HD has also been rebuilt to have some notable indie software from that era.

As Mihai notes they take a while to boot, but are fairly usable one up and running. It was a great blast from the past to poke around these this evening. There’s some familiar apps on the Infinite HD—a good reminder of how many great indie apps were available from really early on.

Mac OS X was what got me back into the Mac after a few years on Windows 98. I started with Public Beta and continued with each new release until 2017.

I was surprised to be reminded of how quickly the UI evolved. I knew that it was iterated upon with every major new version, but even by 10.3 here it’s looking quite clean. Not sure the brushed metal holds up but the refined version of Aqua is pretty great.