For example, a codebase that accesses a database through a layer of abstraction will likely have a trait for the overall data connection - say, DataRoot - that could have multiple concrete implementations for different database server protocols. If there was no expectation of being able to select or change the specific implementation of DataRoot at runtime, then code could pass around a &mut impl DataRoot and avoid the need for dynamic trait objects. However, if, say, the application takes a command-line argument that selects between different database backends, and can even load plugins that can register new database backend types, then the application’s codebase cannot rely on the concrete implementation of DataRoot being known at compile-time; instead, all it can know is that the type implements DataRoot and the specifics are only determined at runtime. That is precisely what dyn trait objects are meant for, so ideally, the codebase could pass around a &mut dyn DataRoot.

The problem arises when DataRoot needs to use features that prevent it from being dyn-compatible. dyn-compatibility refers to whether a trait can be represented as a vtable, which is required for using it as a trait object, since dyn references internally hold a vtable pointer used for dispatching method calls. There are various things that can prevent a trait from being dyn-compatible, but in this case, we’ll focus on one particular common reason: a trait is not dyn-compatible if any of its methods have generic type parameters.

Practically speaking, that means we can’t use impl ... for parameters or return types without breaking dyn-compatibility, since such parameters are just syntax sugar for having generic type parameters for the concrete types being passed. Going back to the database example, suppose DataRoot has methods that return data access objects for specific types of resources. For example, say we have a User trait that represents access to a user record, and DataRoot has a get_user method to get a User by ID. If we didn’t need to concern ourselves with dyn-compatibility, that would likely look something like this:

trait User {
    fn id(&self) -> u64;
    // ...
}

trait DataRoot {
    fn get_user(&mut self, id: u64) -> impl User;
    // ...
}

(For those wondering why get_user takes a mutable self - that’s because, if the implementation involves communicating with a backend server, the connection object likely requires mutable access to write to the socket. For now, we’re assuming this method blocks, but realistically, it should be async; I’m saving Futures for a, well… future, installment of this topic.)

This would work if the concrete type implementing DataRoot were known at compile-time, but we can’t create a dyn DataRoot because it has a method that breaks dyn-compatibility: get_user returns a impl ... type, which is just a generic type parameter under the hood. Alternatively, we could make it dyn-compatible by changing the return type to Box<dyn DataRoot>, but that would mean using dynamic trait objects even in code where the concrete implementation could reasonably be known at compile-time. That’s not ideal, since we’d lose optimizations like inlining, making zero-cost abstractions impossible with this setup. The goal is to devise a way for the concrete type to be known at compile-time whenever possible, allowing more optimizations, while also providing a way to use the trait dynamically when the implementation can only be known at runtime. The only apparent way forward is to have a separate version of the trait that is kept dyn-compatible:

trait DataRoot<'l> {
    fn get_user(&mut self, id: u64) -> impl User + 'l;
    // ...
}

trait DataRootDyn<'l> {
    fn get_user_dyn(&mut self, id: u64) -> Box<dyn User + 'l>;
    // ...
}

impl<'l, T: DataRoot<'l>> DataRootDyn<'l> for T {
    fn get_user_dyn(&mut self, id: u64) -> Box<dyn User + 'l> {
        Box::new(self.get_user(id))
    }
}

Here, we give a blanket implementation of DataRootDyn for any type that implements DataRoot, allowing us to simply implement DataRoot for a type and get a corresponding DataRootDyn implementation for free. The second half of this will allow the holder of a dyn DataRootDyn to call its methods as if it were a regular DataRoot, since we don’t want the dynamic separatism to be contagious throughout the codebase and require a second version of everything. We can do this by implementing DataRoot for the dynamic trait objects:

impl<'l> DataRoot<'l> for dyn DataRootDyn<'l> + 'l {
    fn get_user(&mut self, id: u64) -> impl User + 'l {
        self.get_user_dyn(id)
    }
}

impl<'l, T: AsMut<dyn DataRootDyn<'l> + 'l>> DataRoot<'l> for T {
    fn get_user(&mut self, id: u64) -> impl User + 'l {
        self.as_mut().get_user_dyn(id)
    }
}

We implement it for both the plain dynamic type and any types that implement AsMut for the dynamic type, so that we can call DataRoot’s methods on smart pointers like Box<dyn DataRootDyn>. For this to work, though, we also need the returned trait, User, to be implemented for its own dyn reference types, so we’ll do something similar for it:

impl<'l, T: AsRef<dyn User + 'l>> User for T {
    fn id(&self) -> u64 {
        self.as_ref().id()
    }
}

It is now possible to seamlessly pass around a dyn DataRootDyn and use it as if it were a regular DataRoot:

struct FauxUser(u64);

impl User for FauxUser {
    fn id(&self) -> u64 {
        self.0
    }
}

struct FauxDataRoot;

impl<'l> DataRoot<'l> for FauxDataRoot {
    fn get_user(&mut self, id: u64) -> impl User + 'l {
        FauxUser(id)
    }
}

fn use_data_root<'l>(root: &'l mut dyn DataRootDyn<'l>) {
    println!("{}", root.get_user(42).id());
}

fn main() {
    let mut root = FauxDataRoot;
    use_data_root(&mut root);
}

Why async?

Let’s start by thinking about why we have async functions to begin with; what problem do they solve? The gist is that many kinds of operations, especially I/O, involve waiting until an external task has finished. During that time, other code could be running until the result is ready. That is what asynchronous code makes possible: “pausing” the flow of code in one task to allow other tasks to run, by internally breaking functions into separate chunks.

Consider, for example, the following asynchronous JavaScript function:

async function getUsername() {
    const response = await fetch('/api/session')
    const json = await response.json()
    return json.username
}

It is functionally equivalent to this code, which does not use async:

function getUsername() {
    return new Promise((resolve, reject) =>
        fetch('/api/session')
            .then(response =>
                response.json()
                    .then(json => resolve(json.username))
                    .catch(reject)
            )
            .catch(reject)
    )
}

Clearly, the former code is cleaner, and that is why the syntax sugar provided by async exists: to simplify working with tasks that cannot finish in a single flow of execution.

Why Not Synchronous

This is where many people start to lose track of the point; the illusion of continuity created by the async syntax sugar leads some to forget the underlying mechanics and believe that the inability to call an asynchronous function from within a synchronous one is an artificial restriction.

“Why can’t I do this?…”

function getUserProfileURL() {
    const username = getUsername();
    return siteRoot + '/users/' + username
}

This textbook answer is that such code is incorrect because getUsername is an asynchronous function, and therefore cannot be called from getUserProfileURL, which is synchronous. But let’s consider why: getUsername is asynchronous because it relies on an inherently asynchronous operation (a network request, which is in turn asynchronous because it must wait for I/O and a response.) Because of that, getUsername isn’t so much a function that “gets the username” as it is a function that “schedules the task of getting the username.” It has to be this way because there is no way to force the result to arrive immediately; the requester has to wait.

With that in mind, it becomes clear why a synchronous function like getUserProfileURL cannot call getUsername: getUserProfileURL does not “schedule a task,” but rather is expected to do something and return a result immediately. It can’t do that if it first has to wait on a sub-operation to finish externally.

“Green Threads”

Some people point to languages that support green threads, such as Go, Dart, and (some versions of) Java, as evidence that it could be possible to design a language that allows calling an asynchronous operation from within a synchronous context.

Green-threaded languages work by fundamentally changing the way function execution happens; instead of a single program stack, a function’s stack frame exists on one of several “green thread stacks,” which are allocated by the execution environment that manages the green threads. Certain operations (for example, any I/O in Go) internally have an extra step at the end that gives the execution environment a chance to switch the active green thread if needed. A certain routine of the execution environment will be invoked that may determine that it’s a good time to switch to a different green thread, and if it does, it will store the address of program execution into a place associated with the current green thread and then jump to the previously stored program execution address of a different one. This simulates “pausing” the current green thread and “resuming” another. Since the green threads have separate stacks, there is no interference from executing other code while one green thread is paused. This seems oddly familiar, though.

async With Extra Steps

The above method of wrangling green threads is functionally equivalent to making every function async. Like the separate stacks, variables in async functions become properties of the internal state objects that get passed between executions of asynchronous tasks. Like the specific operations that trigger a chance to switch green threads, async functions use await as an indicator to yield continuity until the result is ready. And like storing execution addresses, registering callback functions provides a way for the environment to know what to call to resume execution of the task. Green threads aren’t so much “threads” as they are the result of hiding asynchronicity behind another layer of syntax sugar: the language itself. That comes with a cost, too.

Static Analysis, Security, and Platform Support

If you were to try to manually implement the kind of internal coordination done with green threads, you would likely run into a problem: it relies on arbitrary jumps. Of course, many languages support the use of jumps within a function, jumping to an arbitrary address in a different function is usually unsupported for a lot of reasons. One of those reasons is that static analysis algorithms, like those used in optimizers, security software, and even in your CPU itself to maximize the benefit of caching, rely on jump instructions only occurring in certain kinds of well-known patterns. For example, conditional blocks and loops can be detected from the way jump instructions are positioned relative to their target address.

If, however, an arbitrary jump instruction is found, it may become impossible for static analysis algorithms to understand the logic of the code. Even worse, the existence of even one arbitrary jump anywhere in the code can be enough to prevent some kinds of optimization and security guarantees even if there is no logical reason why the jump would interfere, simply because the algorithm can no longer be certain that the jump wouldn’t send the execution flow to a position in the code that it could otherwise guarantee would only be accessed under specific conditions.

This problem also has a more concrete consequence than just disabling some optimizations: certain target architectures, notably WebAssembly, do not allow arbitrary jump instructions at all because they prevent static guarantees about the state of the stack. Since all WebAssembly functions are expressed in terms of values on the stack, while the compiled machine code usually maps these stack values into registers, the layout of the stack must be statically known and guaranteed. If it were possible to arbitrarily jump around in the code, unexpected code paths could unbalance the stack from its expected layout and cause fatal errors. Such code flow could even be used maliciously to break out of the sandbox. Since arbitrary jumps are not an option for these targets, languages that support green threads have to find workarounds. Often, the result is less efficient than using asynchronous functions.

What Standard Library?

Then there’s the issue of ensuring that those task-switching operations are called regularly or at key points. As mentioned, Go ensures that the execution environment gets a chance to switch green threads at every I/O operation, but that first requires a standard library where all I/O operations are provided with a call to that procedure. Which, of course, first requires a standard library. That’s a problem for, say, embedded systems, where code is often compiled with only a minimal core library, and operations like I/O come from elsewhere.

But That’s None of My Business

That said, most of these concerns are related to statically compiled languages. One wouldn’t expect to use static analysis on the JIT-compiled machine instructions of a Java program when the bytecode is already known. Nor would one expect to run their Go code on an embedded chip in their coffee maker. (Well, maybe not.) But it still seems important to consider the caveats to different execution models and how that could affect what environments they may or may not be ideal for.

“Way up way up we go

Been up and down that road

Way up way up, oh no

We gon’ burn the whole house down”

• AJR, Burn the House Down

Last month marks the fifty-sixth anniversary of the Stonewall Riots - the day that Manhattan police raided the Stonewall Inn, one of the few places in New York City where openly queer people were allowed at the time. Subjected to inspections, arrests, and brutality, the crowd of gay patrons finally decided they’d had enough; for six days, they fought back against the raid as others joined from nearby and the mob grew. Once the now-iconic crossfire of bricks ceased and the dust settled, with riot control forces left trapped inside the building, a new era of queer activism began.

Organizations like the Gay Liberation Front formed to take a more public approach to the fight, and a sentiment of uncompromising rebellion spread through gay communities. We have these events and people to thank for modern queer rights, but we must now ask ourselves, have we lost the spirit? In this new age of increased acceptance and inclusion, have we become complacent with the oppression that remains and subdued once more by an attitude of compliance? More importantly, now that we live in a time when we can be openly queer without the imminent risk of police raids, has the fundamental meaning of being queer changed for the worse?

As bad as things still are, at least far fewer of us are at risk of homelessness, violence, and legal issues (for now). The hidden cost of society’s increased acceptence towards queer people, however, is that more and more of the queer community has skipped an important step: losing faith in society’s normative ideas. Don’t get me wrong - the progress we have seen is amazing and worth every bit of the fighting it takes to achieve - but what was once the most basic part of the queer movement is leaving us. Now, many queer people still retain a level of faith in normativity of gender roles and society’s structures, and rather than “cutting out the core” of these ideas, they merely select queer culture as an aspect of societal structure.

Back when being openly queer could lead to exclusion and possibly punishment, the strain between one’s own identity and the way society viewed it forced a choice: either repress oneself or reject normative society - there was no middle ground. Many modern queer people still think this way, but the assimilationist concessions we are now afforded have led many others to sidestep that crucial faith-breaking moment. Two major effects have come from this phenomenon: queer infighting and strengthened conservative arguments.

Within our own communities, there has been an increase in “border wars” between different types of queer identity who latch onto some normative ideas as a way to justify their rejection of other ideas without a need to reject the core concept of normativity. For example, we sometimes see binary trans people reinforcing a binary notion of gender and fighting against non-binary people because those binary trans people have constructed their view of being trans around the binary. We also see gay and lesbian people attempting to exclude bi and pan people because, although they have rejected heteronormativity, they have not yet rejected the idea that orientation need not be strictly tied to one gender. Biphobic arguments often also inadvertently reinforce gender roles. It is also common for even more widely accepting queer communitied to exclude asexual people because they have defined themsevles in terms of their specific labels rather than in terms of being outside of cisheteronormativity.

With this movement of queer culture from being outside of normative society to being a different part of it comes a new argument from conservative opposition: that we are no different from them because we are just yet another culture in the pot. Unfortunately, if we continue this trend of keeping some level of faith in normativity, they are not entirely wrong here; parts of the queer community have become “just another slice of society.” If we want to come back from this and avoid being “no different from them,” we need to return to our outright rejection of the core concept of normativity.

I don’t say any of this to discredit how far we’ve come or the change we have achieved, but rather to warn of where we may end up if we go too far into assimilation. I understand that assimilation can be a useful tool for progress, but we must remember that it is just that: a means to an end, not an idea that we should define ourselves in terms of. Being queer under normativity is a losing game, so let’s remind ourselves not to turn that tool into a weapon against each other.

“What sorcery is this?”

Most operating systems have a backup plan for when your physical RAM supply runs out: swap space. Unlike real RAM, this overflow space cannot be directly accessed by programs that are actively using memory; instead, when more memory is needed than can be allocated, pages of memory that haven’t been used as recently are “swapped” out of physical RAM and stored in the swap space to allow that section of physical memory to be repurposed for the new demand. When a program tries to access the memory that was swapped out, the operating system will swap it back into physical RAM, which might require swapping out a different page. Typically, this extra space is provided by a portion of your hard drive space, since that’s the second most accesible kind of memory your system has access to, but as we’ll see, it doesn’t have to be. Compared to ideal conditions of sufficient physical RAM, all this swapping can severly reduce efficiency, especially if programs need quick access to various pieces of data scattered around the memory address space, but at least it works, and that’s more than can be said about fatal error: runtime: out of memory

Loop the loop

On Linux, swap space is a dedicated type of partition separate from filesystems. For example, you might have a partition /dev/sda3 that’s formatted as a swap partition and configured to be your system’s swap provider. In that case, /dev/sda3 is a block device that the Linux kernel can read and write. You can create block devices out of anything, though - including regular files - using loopback devices. A loopback devices is a block device node that proxies read and write operations to a different path, which can be another device, a regular file, or a file provided by a virtual filesystem. To “download some RAM,” we’ll use the latter to put a swap partition on a file in cloud storage.

Setup

1. Virtual Filesystem for Google Drive

This can be done with any cloud storage provider, but this guide will use Google Drive for the example. I will warn that using cloud storage as swap space risks leaking sensitive data like passwords into the cloud. This is really just a silly guide for the lulz. Only do this at your own risk.

To use Google Drive as a local filesystem, we need a virtual filesystem implementation for that. This guide will use google-drive-ocamlfuse, which has an installation guide here. For this guide, I have mounted my Google Drive into ~/GoogleDrive.

It is important for the root user to have access to the filesystem. This is not the default for FUSE-based filesystems, so you’ll need to uncomment the user_allow_other line in /etc/fuse.conf and add the allow_root option when mounting. For me, the command was:

google-drive-ocamlfuse -o=allow_root ~/GoogleDrive/

2. Create a Swap Space File and Loopback Device

To reserve space for swap, we need to create a file filled with the intended number of bytes. This example will allocate a gigabyte of swap.

dd bs=1024 count=1048576 if=/dev/zero of=~/GoogleDrive/swap

This command won’t necessarily end automatically when the bytes have all been written, so you’ll need to keep an eye on the file size to see when it is done. Use the file size shown by the virtual filesystem, not Google Drive’s online details, since they may not synchronize immediately.

Now we need to create a loopback device that points to this file:

sudo losetup -f --show ~/GoogleDrive/swap

This command will output the path to the new loop device. For me, that was /dev/loop0, but it may be different for you. I’ll store it in a variable and use only the variable to refer to it for now. The next step is formatting the content of the file as a swap partition:

SWAP_LOOP=/dev/loop0
sudo mkswap "$SWAP_LOOP"

And We’re Up!

Finally, we’re ready to tell the Linux kernel to use the loop device as swap space:

sudo swapon "$SWAP_LOOP"

Cleaning Up

When you’re done using your terribly inefficient free downloadable RAM, you can stop using it as swap, remove the loop device, and unmount the virtual filesystem:

sudo swapoff "$SWAP_LOOP"
sudo losetup -d "$SWAP_LOOP"
fusermount -u ~/GoogleDrive

Now Go Forth, and Engage the Trolls

With the knowledge in this guide, you are now ready to drop a link to this as a sarcastic response to all the bait and overused jokes about “downloading more RAM” you encounter during your online wanderings.

A beginner learning their first programming language, on the other hand, is not already familiar with the ways of thinking that we tend to hold in our minds when we set out to add another language to our collection. These newbies are tasked with learning the concepts and the language simultaneously, and, despite the difficulty that adds, that process can also ease learning when the language relies on concepts that differ from those the rest of us have already learned.

Rust, for all the talk of its high-and-mighty enlightenment that mere mortals have too much “skill issue” to comprehend, might be an ideal language for absolute beginners to learn programming concepts in a way that better helps them eventually understand computing and move on to other languages.

“Forget Everything You Know”

Imagine a beginner to programming - let’s call him Kevin. Kevin has just finished learning about structures or classes, depending on which language he is learning, and now wants to try passing an instance to a function. If he was learning, say, Python, he might try something like this:

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age

def increase_age(person):
    person.age += 1
    print(f'{person.name} has aged')

ada = Person('Ada Lovelace', 35)
increase_age(ada)
print(f'new age: {ada.age}')

Kevin has just figured out that objects in Python are passed by reference - when he changes a property of an object that came from a parameter, it changes the same object that was created by the caller. This can be just as much of a pitfall as a feature for a beginner:

olympics_2010_ice_dancing_placed_nations = ['United States', 'Russia', 'Canada']
olympics_2010_ice_dancing_nation_points = [215.74, 207.64, 221.57]

def display_nations(nations):
    nations.sort()
    print('Nations that placed:')

    for nation in nations:
        print(f'* {nation}')

display_nations(olympics_2010_ice_dancing_placed_nations)
canada_index = olympics_2010_ice_dancing_placed_nations.index('Canada')
print(f'Canada scored a total of {olympics_2010_ice_dancing_nation_points[canada_index]} points')

Yes, I know it’s messy, but it’s messy in the way an inexperienced programmer’s code might be. There’s a bigger problem here: according to the output of this program, Canada scored a total of 215.74 points, but that is incorrect - Canada scored 221.57 points as shown in the lists.

The issue is that the .sort() changes the list of nations in-place, which takes it out of alignment with the score list. This could’ve been avoided using .sorted(), but a beginner might not think about how the changes they make to a list from a parameter could affect other code because, the way they might see it, the parameter falls out of scope right after and it doesn’t matter.

Now consider an alternate universe where our hypothermic Kevin is instead learning Rust. That same program might look like this:

fn display_nations(mut nations: Vec<&str>) {
    nations.sort();
    println!("Nations that placed:");
    
    for nation in nations {
        println!("* {}", nation);
    }
}

fn main() {
    let olympics_2010_ice_dancing_placed_nations = vec!["United States", "Russia", "Canada"];
    let olympics_2010_ice_dancing_nation_points = [215.74, 207.64, 221.57];
    
    display_nations(olympics_2010_ice_dancing_placed_nations.clone());
    let canada_index = olympics_2010_ice_dancing_placed_nations.iter().position(|&n| n == "Canada").unwrap();
    println!("Canada scored a total of {} points", olympics_2010_ice_dancing_nation_points[canada_index]);
}

Grumbles about using Vec<&str> instead of Vec<impl AsRef<str> + Ord + Display> aside, I can hear the angry readers already: “That’s cheating! You snuck a .clone() in there to fix the issue!” The thing is, though, Rust’s borrow checker made me put that there. Without the .clone(), the compiler would complain about the line that determines canada_index because the array of nations has already been moved by that point. If the beginner had instead fixed that by making display_nations take a reference rather than taking the vector by value, the compiler would’ve complained that the array cannot be borrowed as mutable because it is not declared as mutable, and with that, the programmer would become aware that there is a risk of changing something that needs to stay in the same order.

The point is that Rust’s concepts of reference vs. value passing, ownership, and immutability make the programmer aware of things that would remain in the background in a language like Python, and that’s especially bad for beginners who might not think of those things and shoot themselves in the foot.

This raises the question of whether learning about things like ownership and references makes Rust too hard to learn as a first language - and I think the answer is no. Ownership may trip up programmers with experience in other languages who move on to learning Rust, but a beginner learning Rust first would learn it as a basic concept just like any other. In a way, the idea of value ownership is a very tangible and intuitive part of Rust that I think many beginners will have no issue visualizing. It’s the ones of us who think we already have the concepts we need that become confused.

Too Verbose?

There is a reason Python is a popular first language, and it’s not just because of the machine learning boom. As a dynamic language, Python is semantically simple with its lack of type declarations. Compared to learning, say, Java as a first language, Python keeps that part out of the visual space so that the programmer can focus on the flow of the program. As we’ve seen from complaints about runtime errors, though, a dynamic type system can create pitfalls of its own. A nice middle ground is type inference, which has the simplicity benefits of no explicit type declarations at the same time as compile-time type checking. This can be seen with the likes of C# and Kotlin, and modern Java’s var and C++’s auto, but these basic type inference solutions that were shoehorned into existing languages are only useful in some situations and leave quite a bit of code still requiring explicit types. Rust, however, has powerful type inference. Take for example this simple Rust program:

use std::io::{stdin, stdout, Write};

fn main() {
    let input = stdin();
    let mut output = stdout();
    let mut numbers = vec![];
    
    println!("Enter some numbers, one per line. Leave blank to stop:");
    
    loop {
        print!("-> ");
        output.flush().unwrap();
        let mut line = String::new();
        input.read_line(&mut line).unwrap();
        let value = line.trim();
        
        if value.is_empty() {
            break;
        }
        
        if let Ok(num) = value.parse::<f32>() {
            numbers.push(num);
        } else {
            println!("That's not a valid number.");
        }
    }
    
    println!("Sum of all numbers: {}", numbers.iter().sum::<f32>());
}

Notice how there are only two explicit type annotations in all this - the ones for parse and sum. All of the variables have inferred types. Notably, even the vector has an inferred item type, which Rust detects from the code later on. This larger scope for type inference compared to most languages allows code to look more like the simple, dynamically typed Python despite benefitting from compile-time type checks.

A Solid Foundation

Many of us started learning programming with simpler languages like Python and then worked up to the likes of C++, and many of us remember the difficulties of getting used to lower-level concepts we had never seen before. If a beginner started with Rust and learned the basics of programming while being exposed to concepts like ownership, moving, and references, even if they had no understanding of the underlying memory it would likely be easier for them to learn C++. Learning Rust builds a foundation that may prepare someone to learn a difficult low-level language even if they do not learn those advanced concepts in Rust itself. We as people who learned Rust after other languages are facing the difficulties of a top-down learning order, so let’s prepare the next set of programmers to go from the bottom up.

“Those other corporations don’t have the level of commitment we do. While they are only willing to let the full spectrum of colors on their logos burn in their eyes for a month at most, we’ve had the rainbow since 2009.”

Their head of marketing made specific mention of one of their, arguably, rivals: Apple.

“Now, I know we’re not the only tech company to have had a rainbow logo year-round; Apple had one for over a decade, but even they chickened out. It was too much for them, I guess - the cone cells in their eyes just couldn’t take it.”

The attentive reader might notice that the subject of logo changes has recently resurfaced at Google - just this year, the tech giant changed their main app logo from the long-standing letter ‘G’ with banded colors to the same letter with a continuous color spectrum.

“At Google, we’re not only holding out, but upping our game: in an effort to increase inclusion, we’ve changed our logo to include every visible color - not just a few primaries. Well, given enough pixels, that is.”

When asked about what other changes and actions the corporation would be doing in regards to Pride Month, the marketing head paused for a second, stuttered, and then got up and took off down a hallway, leaving our interviewer baffled.

Called the “Necromancy Labor Project,” this initiative would temporarily direct significant funding to certain scientific institutions for the research and development of technology to reanimate and control corpses. Although nothing is confirmed yet and not many details are known, DeSantis says the intention of the program is to aid the restabilization of the Florida economy by filling jobs that are currently unfilled due to the starvation.

Economists have begun analyzing what kind of effects this type of program could have, and whether it would be enough to recover from this dire situation. Since the original statement, the Governor has also briefly mentioned in an interview that it might be worth considering expanding the program after recovery by reanimating the dead to replace the jobs of the living, maximizing efficient revenue and making employment obsolete.

“It could also have the added benefit that, without jobs, many former workers would starve and die, which would increase the corpse supply.” ~ Governor Ron DeSantis

“I remember thinking it was a trick of the light - maybe the way the sun hit some kind of yellow bird egg - but when I held it, it felt heavy.”

Upon realizing that the “egg” was in fact a ovoid-shaped mass of solid gold metal, she spent roughly two weeks tracking down the bird that layed it. Since then, her annual income has skyrocketed even after quitting her job. That is, until recently, now that the increasing value of chicken eggs has threatened to make her investment obsolete.

“At first I didn’t think I needed to worry about it; surely chicken eggs could never be more valuable than my gold… right? But it kept rising.”

In the interview, she described how this situation affected her politics:

“When I saw the campaign ads for Donald Trump promising to make eggs cheaper, I knew what I needed to do. I voted for him and hoped he would save my investment.”

Regardless, the price of eggs has continued to increase, and today it finally surpassed Mrs. Bratcher’s gold revenue. Despite the campaign promises, we have seen no attempts by the President to remedy this changing economy.

That changed today, when the President signed executive order “Protecting Freedom of Movement and Ending Physically Restrictive Systems.” The order will forbid all departments and operations of the Executive branch from “establishing, assisting, enabling, or acknowledging” any “systems which infringe the right of American citizens to their freedom of movement by causing persons or objects to be forced downward without direct intervention.”

Additionally, the order contains a provision forbidding federal agencies from “propagating the notion one’s rights of physical freedom can be restricted by so-called ‘laws of nature’” or from “providing funding or aid to any public or private entities which make such claims.” In theory, this line would remove funding from schools that teach the physics of gravity, as well as from research institutions that publish gravity-related studies.

A statement issued by Texas governor Greg Abbott contained a sentence sending his condolences to Jimmy Carter’s wife, Rosalynn, before it was later removed.

“Cecilia and I send our prayers and deepest condolences to First Lady Rosalynn Carter and the entire Carter family.”

This line had caused public confusion because Rosalynn passed away in November of last year. Rosalynn herself, however, heeded the call from beyond the veil, leaving this message scrawled on a mirror in the Texas Governor’s Mansion:

“I appreciate your kind words during this emotional time. It is not often that those in the world of the living consider those who have ascended, so I thank you for your forethought in addressing me.”

Several spiritualists and paranormal activity investigators are already planning trips to Austin to learn more about this occurrence.