3608 stories

WALL·E - Typeset in the future

1 Share

From a trash-filled Earth to the futuristic Axiom and back again, WALL·E is a finely crafted balance between consumerist dystopia and sixties space-race optimism. Please join me, then, for a detailed dive into the uniquely robotic future of a remarkably human film, as seen through the eyes of its eponymous hero, WALL·E.

[This article is from the Typeset in the Future book, which is really very good and you’re probably going to want to buy a copy of. If you’d rather read the article first, don’t worry—I’ll remind you again later on.]

Before we get started, there is an important detail we must clear up. Our hero’s name is not, as you might think, WALL-E. Moreover, it definitely isn’t WALL•E. His name is WALL·E, and that dot is an interpunct, not a hyphen or a bullet.

An interpunct is, of course, a vertically centered dot originally used to separate words in Latin and ancient Greek. (Spaces weren’t invented until several centuries later.) The interpunct is still in use today—it’s the official decimal point in British currency (£9·99), and is used to represent the dot product of two vectors in mathematics (x · y). Most relevantly, it’s used in Japanese to separate titles, names, and positions, as in “課長補佐 · 鈴木” (Assistant Section Head · Suzuki). It is therefore entirely appropriate as the separator in WALL·E, which is short for Waste Allocation Load Lifter · Earth Class.

The bold extended typeface seen on WALL·E’s front plate is Gunship, designed by Dan Zadorozny, one of the unsung heroes of modern sci-fi type design. Dan is an amateur type designer from Texas whose Iconian Fonts website features more than six hundred free hand-crafted typefaces, many of which have been used by sci-fi movies, TV shows, and book designers.

In addition to WALL·E’s front plate, Gunship is seen on Earth and aboard the Axiom, the flagship spacecraft of megacorporation Buy n Large (BnL, for short), most notably for robot-facing wall and door typography. Its upper- and lowercase variants include different combinations of cutouts and curve orientations, giving designers flexibility when crafting robot signage. (Strictly speaking, this means that our hero’s name, correctly capitalized, is “waLL·e,” with the interpunct as a further customization—Gunship’s own interpunct is rectangular.)

The movie begins with an insight into WALL·E’s typical workday, which is spent building gigantic piles of trash by compacting waste into neat, stackable cubes. After a hard day’s crushing, we follow him on his journey home, learning some useful exposition along the way. This includes a bank of electronic ads for BnL, promoting everything from liquid air to quadruple-patty burgers. Common throughout these ads is an insistence on immediate consumption—“DRINK NOW,” “HUNGRY NOW,” “RUN NOW,” “CONSUME.” And if consuming a product once isn’t enough, you can repeat the experience a second time—the signage seen below includes ads for both “100% Reused Food” and “Regurgi-Shake: Twice the Flavor.”


We’ve seen how corporate mergers, such as Alien’s Weylan Yutani and Blade Runner’s Shimata-Dominguez, are an inevitability in sci-fi futures. WALL·E’s Buy n Large is similar, except that this company was formed by a merger between a frozen yogurt manufacturer (Buy Yogurt) and a maker of suits for the larger gentleman (Large Industries). Clearly a marriage made in heaven, this corporate combination led to a rapid expansion, culminating with Buy n Large owning every company and government in the world.

The Buy n Large logo is an over-italicized customization of Futura Extra Bold Oblique, as demonstrated by a super-distinctive capital G in the BUY N LARGE BANK logotype that WALL·E passes early in the movie.

If the red-and-blue logo feels familiar, it shouldn’t be a surprise—it’s because BnL uses the exact same typeface and color scheme as real-world retail giant Costco Wholesale Corporation.

There’s another curious BnL subsidiary to be found among the city’s electronic ads, on a beaten-up billboard advertising “Eggman Movers (Creating More Space).” This company is an Easter-egg reference to WALL·E production designer Ralph “Eggman” Eggleston, and it shares the name of the moving company from 1995’s Toy Story, for which Ralph was art director.

The presence of a Buy n Large–branded bank means Buy n Large–branded banknotes, which are unusual for being strewn across the floor of the deserted city. If you look closely at the notes, you’ll see that some of them have “106” in the corner, and are marked “ten million dollars.” Others look to be marked “996,” suggesting that Buy n Large stores continued the classic $9.99 pricing trick even after adding six zeroes to the end of everything. (Indeed, it says much about the Buy n Large approach to consumerism that it prints notes with the 99s already included, to avoid customers having to receive any change.)

We discover later in the movie that the Axiom left Earth in the year 2105. This suggests that in the preceding years of overconsumption there was a period of severe hyperinflation, making a $10 million note a necessity. This is not without historical precedent—Earth’s most extreme example of hyperinflation occurred in Zimbabwe in November 2008, just a few months after WALL·E’s release, when the inflation rate for the Zimbabwe dollar reached a staggering 79,600,000,000 percent per month. At this point, a single US dollar was equivalent to 2,621,984,228 Zimbabwe dollars. The largest-denomination note printed during this time was the $100 trillion note, which makes Buy n Large’s $10 million bill seem like small change by comparison.

WALL·E leaves the bank behind and continues his journey via the disused tracks of the BnL Transit monorail system. In the absence of working trains, these concrete tracks provide a convenient route through the middle of the deserted city.

Despite their association with aspirational futures, monorails have been failing to become a global mass-transit system for almost two hundred years. The first passenger monorail opened in 1825 in Cheshunt, England, primarily to transport bricks, though it was also utilized for transporting people, mostly for novelty purposes. Unlike the top-of-rail system seen in WALL·E, Cheshunt’s monorail consisted of carriages suspended beneath an overhead track, and was powered by a single horse.

The Cheshunt style of monorail—with suspended carriages hanging beneath a single rail—was also adopted by the Wuppertal Schwebebahn, which began operation along the Wupper River in Wuppertal, Germany, in 1901. The Wuppertal’s suspended system is still in operation today, carrying more than sixty-five thousand passengers on an average weekday.

The monorail seen in WALL·E is of the style popularized by Swedish entrepreneur Axel Wenner-Gren, whose prototype ALWEG (Axel Lennart Wenner-Gren) monorail system came to the attention of Walt Disney after a family visit to Wuppertal gave him monorail fever. Disney saw the potential for a monorail attraction at his new Disneyland theme park in California, and the Disneyland-ALWEG Monorail System opened in June 1959. The system remains in operation today (under the name Disneyland Monorail), and there are similar attractions at Disneyland Tokyo and Walt Disney World in Florida. In total, Disney monorails have transported more than one billion passengers into an aspirational transportational future.

It’s not entirely clear what US city WALL·E lives in, but the presence of a monorail network certainly positions it as a location that was once optimistic about the future. This mid-century futurism is borne out by other architectural features of the city, most notably a curved building seen among the billboards encountered earlier. This building is strongly reminiscent of the Space Needle observation tower in Seattle, Washington, which was built for the city’s 1962 World’s Fair, together with an ALWEG monorail system that is still in operation today.

Near the monorail, WALL·E passes a promotional poster for himself, with the caption “Working to dig you out!” This poster has definite communist propaganda undertones, showing a stylized army of WALL·Es working together to build a brighter future. The implication of this design choice—that communist values are the solution to decades of rampant consumerism—is a pretty bold political statement for what is only the fourth minute of the movie.

The future to which these WALL·Es aspire is apparently just above and behind the viewer—a common trope for communist propaganda, where the aspirational group gaze is almost always in this direction.

Indeed, this gaze is such a common trope that it became the primary styling of the promotional poster for 2014’s banned comedy movie The Interview, in which two Americans travel to North Korea to interview the country’s leader, Kim Jong-un. (The WALL·E poster’s bottom-edge caption, punctuated by an exclamation mark, is a recurring design feature in North Korean propaganda posters.)

This aspirational style is an example of socialist realist design, the officially sanctioned visual aesthetic of the Soviet Union, which positioned broad-shouldered, purposeful workers as the true heroes of the age. As a robot who is literally a rectangle, there is surely no worker more broad-shouldered and purposeful than our movie’s eponymous hero, WALL·E.

WALL·E’s self-promotional poster is also a fine example of Handel Gothic, one of the movie’s supporting typefaces. Originally designed in 1965 by Donald J. Handel, the font has become a mainstay of design futurism. (Indeed, it is quite possibly the originator of one of our rules for futuristic type: Make straight things curved.)

My favorite use of the typeface in WALL·E occurs later in the movie, when we see the distinctly curved E of some Handel Gothic… on a handle. (I refuse to believe this is anything but a deliberate typographic joke.)

Handel Gothic enjoyed a particular resurgence when the type family was expanded in the 1980s, and will be immediately familiar to anyone who visited EPCOT Center at Walt Disney World in Florida, which opened in 1982. (Later in this article, we’ll look in detail at the theme park, which is now named simply Epcot.) The original EPCOT Center logo was Handel Gothic all the way, making particularly good use of a lowercase n in “Center” to bring some extra curviness, and choosing a font variant with a curved leg in its R for consistency. (It also added letter joining and slicing for good futuristic measure.)

Handel Gothic will also be familiar to Star Trek fans, from its appearance in the credits for both Star Trek: Deep Space Nine (1993–99) and Star Trek: Voyager (1995–2001).

The movie that made Handel Gothic synonymous with sci-fi, however, was almost certainly Steven Spielberg’s Close Encounters of the Third Kind, released in 1977. Close Encounters used the typeface for its theatrical poster and for its opening credits, with the very words “Close Encounters” offering not one but three opportunities to recognize Handel Gothic’s trademark E.

But back to WALL·E’s journey. Toward the end of his trek home, he passes many more WALL·E units, all of them rusted and dead. The sole remaining WALL·E happily cannibalizes a Caterpillar track from a nearby broken unit to replace his own damaged part, and motors onward with the new track in place.

It’s an easy detail to miss, but WALL·E’s home is a broken-down “BnL WALL·E Transport” vehicle, which may once have housed all the dead units he just passed. When he reverses himself into a WALL·E-size bin in a rotatable storage rack a few minutes later and rocks himself to sleep, his loneliness as the last robot on Earth is made all the more acute by the uninhabited bins around him, now filled with ordered trash.

Before he climbs into bed, WALL·E retrieves his favorite VHS cassette from a nearby toaster, and pops it into a VCR. It turns out this is a beaten-up copy of Hello, Dolly!—1969’s awkwardly punctuated Jerry Herman musical. Delightfully, the typography of this cassette is taken directly from the movie’s 1991 VHS release, though the identity of its non-futuristic title font—half Century Schoolbook, half Benguiat Caslon—has sadly eluded my detective skills.

WALL·E watches his Hello, Dolly! cassette via a small, portable device that looks almost exactly like an Apple iPod Video. I say “almost,” because the real-world iPod Video had a smaller click wheel than the one seen in WALL·E, had white labels on its buttons, and did not support external playback from a VHS cassette player. Nonetheless, this iPod is just one example of many in WALL·E’s home that evoke nostalgia for gadgets past, reinforcing that WALL·E himself is the discarded, unwanted technology that humanity left behind.

To work around the tiny scale of his iPod’s screen, WALL·E uses a plastic Fresnel lens as a magnifying device to enlarge the image to several times its original size. In doing so, he follows a trend started in Terry Gilliam’s similarly dystopian Brazil, in which employees at the Ministry of Information Retrieval huddle around tiny CRT screens to watch westerns through Fresnel lenses when their boss isn’t looking.

WALL·E awakes from robotic sleep on day two of the movie, low on power and dynamism. The fact that his head is a big pair of binoculars gives a great opportunity for a visual gag, as we see him literally bleary-eyed before activating the zoom lock on first his left eye, then his right, to reveal an eye-test chart in the opposing rack.

WALL·E’s binocular form is mimicked in the shape of his heads-up display (or HUD), which has the classic “two circles” shape used in many movies to indicate that we are looking from a character’s viewpoint through a pair of binoculars. This HUD raises an interesting question, however. Why does WALL·E have a heads-up display, with information overlaid on a video stream? A heads-up display really makes sense only if you are a human who has eyes; for a robot, any video input is combined with additional metadata from environmental sensors (such as direction, zoom, and power), and fed directly into the robot’s processor. Overlaying environmental information on a video stream implies that the robot has cameras that look at the world, and then more cameras that look at the augmented output of those cameras, which doesn’t make sense at all.

The answer, of course, is that WALL·E has a HUD because movie robots have HUDs, and movie robots have HUDs because they enable the viewer to visualize what the robots are thinking, even if it makes zero sense in technical reality. This trope began in 1973’s Westworld, whose final act shows us the world from the vantage point of Yul Brynner’s gun-slinging robot. Although Brynner’s HUD is not augmented with data, it is nonetheless the first use of computer-generated imagery in a feature film. Director Michael Crichton cuts several times from a real-world scene to the robot’s pixelated version of the same, including a thermal image when Brynner chases his prey in the movie’s final act.

Westworld’s “robot viewpoint” trope was codified by 1984’s The Terminator and 1987’s RoboCop, both of which augmented their HUDs with additional data and text. Following these two movies, a heads-up display pretty much became the de facto expectation for any on-screen robot whose motives need to be understood.

Pixar’s robot HUDs tend to include the shape of the robot’s eye(s) within the heads-up display, to help us associate the HUD with the character it represents. The Incredibles’ Omnidroid predates WALL·E’s binoculars in this regard. Other WALL·E robots—M-O, SECUR-T, and EVE—also follow suit.

Pixar’s neatest variation on the robot HUD trope occurs all the way back in 1999’s Toy Story 2, where a plastic toy’s marketing gimmick (plus some clever camera framing) enables us to literally see through the eyes of the movie’s robotic bad guy.

There is one further question raised by WALL·E’s binocular HUD. How does his directional compass—seen at the top center of his HUD—continue to work when he is aboard the Axiom? Lots of planets may have a north, but the same is not true of spacecraft—north, south, east, and west make sense only when you’re on the surface of a sphere.

Day two (and act two) of WALL·E see a Buy n Large scout ship arrive on Earth, disrupting WALL·E’s routine. Most importantly, it introduces us to EVE, who is everything WALL·E is not. EVE’s shiny white design is technologically advanced; she’s the curvy iMac G4 to WALL·E’s boxy Mac 128K. Her design evokes sleek Apple products of the 2000s, with her head, in particular, highly reminiscent of a 2002 iMac G4’s base. Even her reboot sound is a futuristic take on Apple’s famous startup chime, whereas WALL·E’s post-charge chime is the version Apple introduced in 1998 and removed altogether in 2016.

EVE’s evocation of Apple product design is not entirely coincidental. In a 2008 interview with Fortune magazine, director Andrew Stanton stated: “I wanted EVE to be high-end technology—no expense spared—and I wanted it to be seamless and for the technology to be sort of hidden and subcutaneous. The more I started describing it, the more I realized I was pretty much describing the Apple playbook for design.” This led to a 2005 call to Steve Jobs—at that time, both owner of Pixar and CEO of Apple—which in turn led to Apple design head Jony Ive spending a day at the Pixar headquarters in Emeryville, consulting on the EVE prototype. (It is surely entirely coincidental that EVE’s wireless arms and hands are reminiscent of Apple’s wireless Magic Mouse, released the year after WALL·E.)

During a dust storm, WALL·E takes EVE back to the safety of his home, where he presents her with a small multicolored cube. In the three seconds the camera pans away for WALL·E to retrieve Hello, Dolly!, EVE solves the Rubik’s Cube and returns it to her astonished host.

EVE’s cube-solving time would be impressive for a human; the current world record is 4.22 seconds, set by Feliks Zemdegs in May 2018. Sadly, because of the camera pan, we’ll never know if EVE broke the world record for a robot, which currently stands at a mind-boggling 0.637 seconds. This record was set in November 2016 by Sub1 Reloaded, a cube-solving robot built by German engineer Albert Beer. Six high-performance stepper motors turned the cube twenty-one times to complete the task, averaging just 0.03 seconds per rotation.

Spare a thought, then, for poor WALL·E. His surprise at EVE’s accomplishment is understandable—he lacks color vision and has only three digits on each hand, which means that Rubik’s Cubes are really not his specialty. (There’s a reason Guinness doesn’t have a “fastest dog” Rubik’s Cube category.)

One other point of note: This scene is the only time the color green appears in WALL·E in a scene unrelated to a plant. While this breaks the movie’s careful color scripting, it’s worth it for a good gag.

All seems to be going well with WALL·E and EVE’s introductions, until they are rudely interrupted by EVE’s spotting a plant that WALL·E has excavated from the trash. She subsumes the plant, as per her “directive,” and enters hibernation mode. WALL·E’s attempts to wake her invariably end in comedic pain, though one of them does reveal EVE’s serial number, 051682, set in Handel Gothic. (I can’t help but wonder whether someone in Pixar’s art department was born on May 16, 1982.)

WALL·E gives up on reviving EVE and disconsolately returns to his trash-crushing routine. Shortly afterward, the Axiom’s scout ship returns to Earth and collects EVE to take her home. Desperate not to lose his new friend, WALL·E hitches a ride on the outside of the scout, causing him grief when the ship blasts through Earth’s surrounding satellite trash. As the satellites fall away, we see that WALL·E has a Soviet-era Sputnik 1 satellite on his head. This is impressive, especially given that Sputnik 1—the first man-made object to orbit Earth—burned up on reentry to Earth’s atmosphere in 1958.

We see Sputnik 1 again later in the movie, as a model in Captain McCrea’s display cabinet. This model is accompanied by a NASA space shuttle launch/entry helmet, as worn by space shuttle astronauts between 1982 and 1986 during launch and return from space.

This “retro space tech” theme can also be seen on Earth during EVE’s scan for plant life. After scanning a Toy Story Pizza Planet truck and a portable lavatory, EVE checks a rusting Apollo command module before slamming the door shut in disgust at its absence of plant-based life.

Showing recent space technology as trash or as museum pieces positions our personal experiences of space as archaic and quaint in comparison to the Axiom’s futuristic styling. This further reinforces WALL·E’s own obsolescence as a discarded piece of technology, and sets us up neatly for a transition to the shiny futurism of the Axiom.

The Axiom paints a vision of the future where every menial task, no matter how small, has a dedicated robot created expressly for the purpose. Like 2001: A Space Odyssey’s HAL and Alien’s MU/TH/UR, all these robots have cute acronyms to make them human-friendly.

Of particular note is VN-GO, the painterbot, whose acronym perpetuates a common yet incorrect pronunciation of Dutch painter Vincent van Gogh’s surname. (According to the BBC Pronunciation Unit, it is “van Gokh,” with the kh pronounced like the ch in the Scottish word loch.)

EVE’s acronym, sadly, is even worse. Her denomination as Extraterrestrial Vegetation Evaluator could not be more inaccurate, given that her entire reason for existing is to evaluate vegetation on the planet Terra (as Earth is known in Latin). Presumably, her moniker was chosen for cuteness rather than linguistic accuracy—after all, this movie is about WALL·E and EVE, not WALL·E and TVE.

Also of note is TYP-E, a typingbot who is designed solely to press keys when someone approaches the elevator shaft to the captain’s quarters. TYP-E provides an excuse for one of the movie’s best visual gags—as a robot, he has a keyboard made entirely, of course, from ones and zeroes.

M-O’s cleaning colleagues (VAQ-M, SPR-A, and BUF-4) may bring back memories for fans of 1997’s The Fifth Element. In Luc Besson’s over-the-top vision of the future, evil industrialist Zorg demonstrates his own array of task-specific robots by dropping a glass tumbler on the floor to trigger their “lovely ballet.” As two sentrybots stand guard, a sweeperbot, a spraybot, and a bufferbot clean up his mess before returning to a nearby storage station.

The Axiom’s robots travel around the ship via their own dedicated corridors, separate from the craft’s passenger areas. These passenger areas are split into three classes—economy, coach, and elite—each of which has a distinct architectural style. The classes themselves do not play a functional role in the movie’s plot, but one has to wonder what they mean for the Axiom’s society. Are children born into the classes their ancestors originally purchased, as if into some kind of futuristic caste system? Would the Axiom have its own Titanic moment if a passenger from economy bumped hover chairs with someone from elite? One thing’s certain: The styling of each class is extremely useful for helping viewers orient themselves within the ship’s overall structure as the action moves back and forth along its length.

Our introduction to the passenger area starts with the economy deck, which is compact, angular, and concrete in texture and color. Its palette is deliberately sparse, rarely moving outside the Buy n Large blue, red, and white, and making extensive use of the corporation’s Futura Extra Bold Oblique.

The deck’s design is highly reminiscent of the interior of the Contemporary Tower at Walt Disney World Contemporary Resort, whose A-frame concrete-and-steel structure was so futuristic when it opened in 1971 that it even had a monorail running through the middle. (As anyone who has stayed at the Contemporary can attest, however, its rates can hardly be considered “economy.”)

The coach deck, unlike the economy deck, is curved, eclectic, and spacious, with brightly colored holo-ads scattered everywhere. It mimics Las Vegas’s Strip in gaudiness and style, with artificial neon colors used extensively and every sign encouraging Axiom passengers to spend more money. (How the ship’s financial economy continues to function after a seven-hundred-year flight continues to remain a mystery.)

The ceiling of the coach deck is a gigantic animated screen that can switch between day and night, complete with a BnL-branded sun or moon. The ceiling’s relationship to actual time is somewhat tenuous, as we see when Captain McCrea winds the sky back from 12:30 p.m. to 9:30 a.m. in order to make his morning announcements. In this regard, the ceiling is essentially an amalgam of two Las Vegas landmarks: the painted cloud ceilings of the Forum indoor arcade at Caesars Palace, whose lighting ebbs and changes without ever making it nighttime enough for you to want to stop buying things, and the four-block-long overhead screen of the Fremont Street Experience—the world’s largest video screen—whose 12.5 million LEDs illuminate Vegas partygoers every night. The result is an entirely fake sky for the Axiom’s population, allowing finely tuned control over their artificial environment.

The coach deck leads to the elite deck, whose styling resembles that of a high-class lido or spa. Despite their very different palettes, the coach and elite decks share a curved, futuristic environmental styling that unifies their overall architecture. According to production designer Ralph Eggleston, the architecture of this shared area is inspired by the work of architect Santiago Calatrava, whose signature curved supports and arches can be seen throughout both decks’ central concourse.

The other main influence for the Axiom’s architecture is the design of the Tomorrowland area of Disneyland, in California. According to production designer Ralph Eggleston, during the movie’s production WALL·E’s design team visited an exhibition of Tomorrowland concept art and took inspiration from the designs therein. Perhaps the most obvious of these influences is the presence of a PeopleMover transportation system running through the middle of the club and elite decks, in a style very similar to the PeopleMover at Tomorrowland. (Do check out DaveLandWeb’s fantastic PeopleMover photo page for some great examples of the original in action.)

The evolution of Disney’s PeopleMover concept began with the 1964–65 New York World’s Fair, for which the Ford Motor Company asked Disney to design an attraction to compete with General Motors’ Futurama II exhibit. The resulting Magic Skyway gave fairgoers an opportunity to ride in a driverless Ford convertible—including the just-launched Ford Mustang—through a diorama that transported them from prehistoric times to a futuristic space city.

Following its success at the World’s Fair, the traction system behind Magic Skyway was adapted into a new feature for Tomorrowland’s 1967 relaunch. The new attraction, known as the WEDway PeopleMover, enabled Walter Elias Disney to follow Axel Lennart Wenner-Gren (of ALWEG monorail fame) in naming a futuristic transportation mechanism with his initials. It also provided an ideal inspiration for the Axiom’s central transport system.

The Axiom’s PeopleMover has much in common with its WEDway counterpart. Both are focused on a main circular loading area in the heart of a central plaza, with a long, straight stretch of track extending away from the loading deck. Both give passengers a tantalizing view of surrounding attractions as they are transported from one area to another. Indeed, I am sure Walt Disney would have been delighted to see his dream of future transportation integrated into the Axiom’s space-age environment, especially given that Disneyland’s PeopleMover was a prototype for Walt’s grander vision of futuristic living. Walt planned to build a larger PeopleMover installation as part of his Experimental Prototype Community of Tomorrow, or EPCOT—a new and futuristic city to be created from scratch at his planned Disney World Resort in Florida.

In October 1966, Walt recorded a short film pitching his “Florida Project” to industrialists and legislators, including a detailed description of EPCOT’s transportation system. In this new city, cars and trucks were to be pushed underground, with the community’s twenty thousand residents instead traveling by WEDway and monorail to work, play, and socialize. The concept images below from Walt’s EPCOT film give an idea of just how much imagination the creative brains at WED Enterprises applied, under Walt’s careful guidance, to everyday living challenges.

Tragically, Walt Disney died less than two months after his EPCOT introduction was filmed, passing away before the pitch was screened and before New Tomorrowland opened to the public. His ambitious vision of a prototype community did not become a reality, but its name lives on in the Epcot theme park (formerly “EPCOT Center”) at Walt Disney World in Florida—although the eventual EPCOT park became more of a permanent World’s Fair than a real-life city of the future. The WEDway PeopleMover did not realize its potential, either: The Disneyland attraction closed in 1995, to be replaced by the faster (but short-lived) Rocket Rods ride, which itself closed in 2001.

Disneyland park-goers can still see the PeopleMover’s abandoned tracks snaking through Tomorrowland, displaying curved, arched supports that Santiago Calatrava would surely approve of. (Thankfully, a PeopleMover can still be experienced at the Magic Kingdom park at the Walt Disney World Resort in Florida, where the Tomorrowland Transit Authority PeopleMover continues to provide a leisurely tour of nearby attractions.)

Of course, the PeopleMover also lives on via the Axiom, whose reimagining of the concept is almost a microcosm of Walt’s vision for EPCOT. Aboard the Axiom, it’s a PeopleMover (not a monorail) that fulfills the role of high-speed arterial transport, with individual BnL hover chairs completing the “final mile” of the journey via preset illuminated paths (blue for humans, white for robots, red for stewardbots). It may not match the scale of Disney’s EPCOT dream, but it’s nonetheless fitting that Walt’s vision of a transportational future made the trip into space.

During WALL·E’s tour of the passenger decks, we discover that the Axiom’s computer is voiced by none other than Alien’s Ellen Ripley. Casting Sigourney Weaver as the disembodied voice of a space-based computer is clearly ironic, especially given her experience with such voices in Alien and Aliens. WALL·E ups the irony by having Weaver narrate not one but two scenes that would feel all too familiar to her xenomorph-hunting counterpart, triggering bonus space-peril associations for Alien fans. (Weaver also plays a disembodied voice in Andrew Stanton’s Finding Dory, aping her narration of nature documentaries.)

Alien and Aliens are not the only sci-fi movies to get a nod from WALL·E. On the Axiom bridge, we meet AUTO, the ship’s autopilot robot. It might be hard to believe just by looking at him, but AUTO is actually an Evil Space-Based Computer. His design is clearly influenced by a certain other ESBC—that central red eye is a direct reference to 2001: A Space Odyssey’s HAL, giving an immediate signal that this robot is not to be trusted.

AUTO’s physical similarity to HAL gives him a practical similarity, too. On the rare occasions we see the world from AUTO’s vantage point, we get an extreme fish-eye view of the surrounding area, just as we did for HAL in 2001. WALL·E combines HAL’s fish-eye view with The Terminator’s red HUD hue, making AUTO’s evil intent doubly clear to any discerning fan of sci-fi.

AUTO and HAL belong to a long-standing tradition of sci-fi automata whose glowing red eye(s) give away their evil nature. They really are everywhere in sci-fi movies—from the Model 101 in The Terminator, via the replicants in Blade Runner, to the evil wriggly thing inserted into Neo’s belly button in The Matrix.

That red glow has its benefits, however. You can always tell when an evil robot has been finally defeated from the fact that its red eye(s) slowly fade to black. The Terminator’s T-800, The Matrix’s wriggly thing, and WALL·E’s AUTO all follow this trope when deactivated.

AUTO may look like the movie’s bad guy, but his actions are simply an example of artificial intelligence following its programming too literally. To understand his motives, we must remember that BnL’s original plan was for its star liners to return to Earth as soon as an EVE probe found proof that life was once more sustainable. Five years after their departure, however, BnL autopilots were sent a directive by CEO Shelby Forthright telling them to keep their craft in space indefinitely, because the cleanup process on Earth was not going to succeed. Six hundred and ninety-five years later, with no subsequent instructions to the contrary, AUTO is simply following this command to the letter, blocking any and all attempts to return to Earth.

In this regard, AUTO is eerily similar to 2001’s HAL, whose murderous tendencies aboard the Discovery were similarly driven by an inability to reconcile a contradiction in his programming. In the movie’s sequel, 2010: The Year We Make Contact, we learn that the basic purpose of HAL’s design was “the accurate processing of information without distortion or concealment.” We also discover that HAL was instructed (via Directive NSD 342/23) to lie to Dave and Frank about the real reason for the Discovery’s mission. After lip-reading that they planned to disconnect him, HAL determined that the only logical way for him to both keep processing and avoid lying was for Dave and Frank to die.

AUTO’s own instruction is Directive A113, whose numbering may sound familiar to Pixar fans. “A113” appears in every Pixar film, from a family license plate in Toy Story to an underwater camera model in Finding Nemo. (Indeed, it’s even in Brave, where the roman numerals ACXIII appear carved just above the front door of a witch’s hut.) The reason for its repeated inclusion is that room A1-13 was the classroom for the Character Animation Program at the California Institute of the Arts, where Pixar alumni John Lasseter, Pete Docter, and Andrew Stanton studied. (This explains why it’s also the number on the door of Riley’s classroom in Inside Out, and on the Scaring 101 classroom door in Monsters University.) WALL·E may be its highest-profile outing, but it’s there in every Pixar movie if you keep your eyes peeled.

The majority of WALL·E’s robots are voiced by Ben Burtt, the Academy Award-winning sound designer and creator of R2D2’s bleeps. AUTO’s voice, however, is provided by MacInTalk, a speech synthesis technology first used to announce the Apple Macintosh computer in January 1984. (You may also recognize MacInTalk as the lead vocalist on Radiohead’s “Fitter Happier,” from 1997’s OK Computer album.)

MacInTalk’s inclusion in WALL·E makes it one of only two Apple voice synthesis technologies to star in a feature film; the other is Siri, who provides the voice for ’Puter, Batman’s high-tech assistant in The LEGO Batman Movie.

Despite the technology’s age, I’m happy to report that MacInTalk voices still ship with macOS today. If you’d like to turn your Mac into an Evil Space-Based Computer, simply open the System Preferences application, select Accessibility and then Speech, and enable the “Ralph” system voice.

In addition to AUTO, there are two more nods to 2001: A Space Odyssey in WALL·E, both of which take advantage of preexisting associations for dramatic or comedic effect. The first is WALL·E’s brief escapade in a LifePod, the design of which seems clearly inspired by 2001’s EVA pods. That iconic ball-like shape immediately triggers an association with interstellar peril, which WALL·E soon discovers is entirely justified.

The second 2001 reference is a knowing usage of Richard Strauss’s Also sprach Zarathustra, when Captain McCrea becomes the first human to stand up and walk in possibly hundreds of years. It’s an appropriate enough use of the music—2001’s monoliths oversee (and supposedly trigger) several leaps in mankind’s evolution, so it’s entirely valid to hear those famous chords when the captain makes his first steps (even though this is technically a regression, not an evolution).

Of course, WALL·E is not alone in riffing on Strauss’s classic melody. It is similarly parodied in Charlie and the Chocolate Factory (as a 2001 monolith turns into a bar of chocolate) and Zoolander (as Hansel considers smashing Mugatu’s iMac with a nearby bone). If that’s not enough, it’s also in Pixar’s Toy Story 2 and Cars 3, plus other animated movies including Kung Fu Panda 3, The Pirates! In an Adventure with Scientists!, and The Simpsons Movie. On the live-action front, it’s in Man on the Moon, Catch-22, Night at the Museum: Secret of the Tomb, Clueless, Turner & Hooch, and Harold & Kumar Go to White Castle, to mention just a few.

Despite AUTO’s best efforts, McCrea manages to switch him to MANUAL and sets the Axiom on a hyperjump trajectory back to Earth. The hyperjump looks exactly like you’d expect, which is exactly like the USS Enterprise engaging warp drive in Star Trek: The Motion Picture.

Once again, WALL·E is sneakily using prior sci-fi art as a shortcut, re-creating familiar effects so that the Axiom’s quick journey home can be explained without exposition. (It might also account for why everyone aboard the Axiom experiences a brief stint of The Motion Picture’s wormhole effect during the jump.)

As these homages show, WALL·E is not afraid to borrow from its predecessors to gain some free sci-fi association. Indeed, such references are celebrated and elevated, drawing on the production team’s clear fondness for vintage sci-fi to create a movie that is both a love letter to the classics and a worthy addition to the list. WALL·E capitalizes on our existing associations with the future to communicate complex plot points and motives with minimal dialogue and text. It is, to my mind, Pixar’s most realistic vision of an internally consistent world, despite the polar opposites of its Earth- and space-based environments. It’s political and satirical, representing utopia and dystopia with enough humor to poke fun at the downsides of both. In short, WALL·E envisages a future that could so easily be bleak and pessimistic—but is instead inspired by the naïveté of its inhuman heroes to re-create the optimism that took man into space in the first place.

Wow! That was good, wasn’t it? What an amazing article! So amazing, in fact, that you probably want to impulse-buy the Typeset in the Future book it comes from, right this very second. Here are some convenient links to buy it from Amazon or Barnes and Noble, or you can head down to your local bookstore (which it is much harder for me to link to) when the book is released on December 11 2018.

The book also includes an interview with Pixar designers Ralph Eggleston and Craig Foster about the making of WALL·E, plus six more equally amazing movie studies, alongside interviews with Paul Verhoeven (Total Recall) and Mike Okuda (Star Trek). You can read more about it here if for some reason you’re still not convinced.

Dave Addey

Read the whole story
3 days ago
Hamburg, Germany
Share this story

Motion blur

1 Share

Oooooh here’s something I’ve never thought about when it comes to CSS: motion blur! Adam Argyle wrote this back in 2019 (!) but it still feels new and exciting to me:

Professional polish of motion graphics often includes the application of motion blur. In most cases, it's a boolean toggled at the layer level, that then tells the engine to set a blur amount based on the speed of the pixels. This effect makes animations much closer to real life, among other nice benefits. CSS currently is incapable of such an effect. Instead, a strobing, ghosted type effect is often what we get instead.

I like this proposal, too:

.animated-layer {
  animation: rotate .5s linear infinite;
  motion-rendering: blur;
  motion-shutter-angle: 180deg;

@keyframes rotate {
  to {
    transform: rotate(1turn);

Also, reading the comments on this thread is fun and reveals just how complex the standards process is for adding anything new to CSS.

Read the whole story
3 days ago
Hamburg, Germany
Share this story

Notes for new hires

1 Share

I’m onboarding new engineers at Vori, and finally took some time to write a few ideas I’ve been kicking around and sharing internally. I have personally found these practices helpful over the past few years, and think others might, as well. This isn’t applicable to only junior engineers, or new hires (despite the title). I didn’t learn some of these lessons until I was eight years into my career as a tech lead at edX, or a couple years later at Stripe.

Don’t struggle in silence

If you get stuck, see what you can figure out in 15-30 minutes (up to you to decide if you’re making progress). Ask for help if/when you hit a wall. I’d rather you interrupt me multiple times daily than be blocked for hours for fear of “bothering” me. My goal is to get you ramped up as quickly as possible, so I’ve already planned to spend more time mentoring you and less time on other work.

Ask “why?”

You’re here because we think you’re smart and can help us build a better product and team. You need to understand why decisions were made in the past so you can help us make better decisions in the future. You learn that by asking, “why?”…a lot. Hopefully, we have a good answer and explanation, but that may not always be the case. Sometimes, we simply needed to move quickly so incurred technical/organizational debt. We should be reducing the number of “that’s how we’ve always done it” answers over time.

In addition to helping improve decision making, understanding why some things are as they are will help you avoid falling into the trap of trying to refactor or “improve” something that should simply be left alone. This post on Chesterton’s Fence explains these ideas further.

Maintain a friction log

I learned about friction logs during my time at Stripe, but didn’t truly appreciate them until I joined Vori. The idea is simple: take note of all the things—not just product-related—that are causing you trouble. You focus on internal process, in addition to product run-throughs, because we are still working on these internal processes and scaling them as the team scales. This is all quite subjective and could include anything from a README missing a step to some process simply taking too long. We’ve all been here a while, and have either gotten used to the friction or have not taken time to prioritize reducing it.

I will share mine with you, but your own log doesn’t have to be public. I kept mine semi-private (anyone could find it if they knew what to look for) with a disclaimer that the contents should not be interpreted as criticisms. I fixed some items—migrations used to take 2 minutes to generate!—added some to the backlog, and others have been ignored as we’ve evolved.

This blog post on a “WTF Notebook” offers a similar v iewpoint and deeper example of using what is essentially a friction log.

Keep a brag doc

Brag docs helped me keep track of my accomplishments over the year to prepare for mid-year and full-year reviews at Stripe. Julia Evans, a former Stripe, has an amazing post on brag docs that you should read right now.

We don’t have an annual review process at Vori, but you should still maintain a brag doc to track your own progress and as a source of content for your résumé (not that you’re leaving anytime soon…right!?). Admittedly, I haven’t done a great job of keeping mine up-to-date, but I’ll use commit history and Linear comments to update it soon. My brag doc is also a nice little ego boost when I’m feeling low.

Recommended reading

Here are some items I think are worth the time to read, or at least skim. I have found that the “soft” skills are some of the hardest to master, and the most important. Yes, technical skills matter; however, engineering is about problem solving, which requires communication and relationship building.

These are items have made the greatest impact on me. I consistently reference them. Prioritize reading them if nothing else.

⭐️ What Got You Here Won’t Get You There: How Successful People Become Even More Successful

Kudos to my edX manager, Zach, for recommending this to me. I used to be a terrible teammate. I focused too much on “clean” code at the expense of people. I tried to take on large tasks to meet artificial deadlines, instead of working with my team. This book helped me understand how my bad habits were negatively impacting me, and showed me how to avoid them.

⭐️ Accelerate: Building and Scaling High Performing Technology Organizations

I picked this up at Stripe during a book club led by Will Larson. I recall thinking, “duh,” as I read it because I had practiced many of the “key capabilities” the book recommends. I’m due for a re-read to refresh, especially now that I’m at a startup (and cannot rely on expertise spread across a larger organization).

The Wikipedia page offers a good summary of the key capabilities and metrics.

Designing Data-Intensive Applications

This is recommended by many folks online. It’s meant to serve as more of a reference than to be read cover-to-cover. I’ve read a few chapters, and find it good for getting exposure to concepts I have not necessarily dealt with hands-on.

The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change

Read this if you’re considering becoming a manager, or simply want to better understand what a manager does (or should do).

The 5 Love Languages

We have relationships with the folks we work with. These relationships may not be romantic, but they still need to be maintained. Learn more about what makes people tick to better understand how you can work with them. My love languages are, “acts of service” and “quality time”. My most quality time is at home, away from work, so the best way you can reach me is probably by taking a task off my plate.

Influence: The Psychology of Persuasion

I read this during my Managerial Psychology course at MIT. This is about the only book I recall reading from my time there. The thought of influencing or persuading someone sounds a bit underhanded/two-faced. It doesn’t have to be. You can use the power for good! This has helped me make more-compelling arguments when trying to convince folks to, for example, change a technical architecture.


This series of blog posts/interviews created by Will Larson morphed into a book and podcast. This is great material for learning how staff engineers operate at other organizations, and what is expected at that level. Note that “staff” means different things at different organizations. Make sure you chat with your manager (and maybe their manager) to fully understand (a) what’s expected at that level, and (b) what you can do to get there.


This was a magazine printed by Stripe. Publication has ended but the digital site remains. I suggest you at least skim through each issue to see what sticks out to you. You can (almost) never have too much testing!

Read the whole story
5 days ago
Hamburg, Germany
Share this story

Python has too many package managers

1 Share

Python is a wonderful programming language. I’ve used it to build webapps, deep learning models, games, and numerical computation. However there is one aspect of Python that has been an inexcusable pain-in-the ass over many years. That would be the fragmented Python package and environment management ecosystem, succinctly represented by the following XKCD comic:

Python tooling is complicated

You see, a lot of other programming languages developed standardized ways to setup versioning, dependency resolution, and dev environment setup. C# has NuGet, Javascript has npm, Dart has pub, and most notably Rust has Cargo – quite possibly the most widely loved package manager tool in existence.

The sane way to do things

In a sane world, package management would work like it does with Cargo - the rust package manager. You have a single master configuration TOML file where you simply list your dependencies and config settings. The TOML file goes into a folder encapsulating your entire development environment. For extra reproducibility, whenever you build your environment and resolve all your package dependencies, a *.lock file records all the packages you used along with their versions and hashes.

Finally, because dependency resolution is a directed acylic graph (DAG) resolution problem, the dependency retrieval and resolution should both be engineered to be relatively fast. Dependency information should be freely available from a public API metadata server in a way that is simple to parse, and cached locally once downloaded to avoid redundantly hitting this server. Finally, the dependency resolution algorithm itself should be written in a relative fast programming language like C++ or Rust.

The problem with Python has been that there hasn’t been a single tool that does all of this well although some have come enticingly close. To that end, here is my rundown of more than a dozen Python package managment/virtual environment tools:

Classic Python Package Management

pip and venv

The OG of Python package managers. Dependency resolution? pip up until recently hardly did any dependency resolution at all. Historically it would install packages one by one, conflicts be damned. In version 20.3, introduced in 2020, pipfinally added dependency resolution backtracking, which means if an inconsistent state was detected, it would go back and try to fix the problem. Unlike many of the other tools in this list, and unlike tools like Cargo or NuGet in Rust and C# respectively, pip does not manage environments along with dependencies. A separate tool like venv or virtualenv needs to be used to create “virtual environments” which are in turn be completely decoupled from a specific project or project directory.

One of the key faults of pip is what happens when you decide to remove a dependency. Removing a dependency does not actually remove the sub-dependencies that were brought in by the original dependency, leaving a lot of potential cruft. This actually needs to be done either manually or by using yet another tool like pip-autoremove to remove sub-dependencies that are no longer useful.


One thing to note about python’s venv tool is that it isn’t really setup to create virtual environments for different versions of Python. To actually do this, yet another tool called pyenv exists which allows you to switch between different versions of system Python at will, with options to set Python locally for specific projects. Very often, I’ve seen this tool abused to set Python versions globally, which can lead to some severe reproducibility issues, with folks forgetting which version of Python they were using for different projects.


So pip and venv combined can let you build “virtual environments” and pyenv can let you switch Python versions. The natural thing to do is to have a tool that allows you to specify the python version and dependencies in a single file. pipenv basically sets this up, optionally interoperating with pyenv by letting users specify python version and dependencies in a Pipfile and locked dependencies in a Pipfile.lock.

The downside to pipenv is that it’s dependency resolution is no better than that of pip which it uses under the hood. Furthermore, in 2020, a new “Python Enhancement Proposal” PEP 621 was accepted defining how package metadata should be consolidated in the future for Python projects making Pipfile and Pipfile.lock no longer quite “idiomatic” in the long run…

Consolidating Python config with pyproject.toml and PEP-621

Before PEP-621, there were a large number of config files that could wind up in a given Python project:

  • requirements.txt: The project’s dependencies, which may or may not include package hashes (for security reasons) depending on how its setup.
  • setup.py and setup.cfg: A script and a config file which collectively define dependencies and options.
  • `Pip
  • MANIFEST.in: Tells packaging software (like setuptools) what sort of non-code files to include in the package.
  • tox.ini: Used by the tool tox to configure environment setup, dependencies, and test commands (do you see the redundancy now?)
  • Pipfile and Pipfile.lock: For folks using pipenv.
  • .pylintrc: Used to setup config for linting tools like black and isort
  • environment.yml: Used specifically by conda to define dependencies, some of which are not python packages at all. Interestingly you can specify both pip dependencies and conda dependencies separately, even if a pip package has a corresponding (and possibly better curated) version on a conda channel!
  • .condarc: The config file for Conda.

Naturally the proliferation of all these tools and standards leads to a massive amount of redundancy. There is effectively no standard way to enumerate the dependencies of a given package nor how to setup tools like linters and tests.

The problem with new standards

In 2020 PEP 621 was accepted. This proposal effectively gives a guidance to consolidate everything into a pyproject.toml file, almost identical to Cargo.toml in Rust and similar to the package.json used in npm. Naturally this led to a proliferation of new Python package managers which leverage the new standard. Enter poetry, PDM, Flit, and Hatch.


Poetry right now is the closest tool in the Python ecosystem with widespread traction that actually comes close to approximating the experience of using tools like Cargo and npm. Unlike pip and similar to conda and mamba (See below), Poetry will attempt to resolve the full dependency graph DAG beforehand, and install dependencies in topological order. It mostly respects pyproject.toml and treats it as a first-class citizen. Like conda and venv, poetry can also manage your virtual environments, which can exist within or outside of your project folder. poetry also generates poetry.lock files which can be an immense boon for reproducibility. Notably, these lockfiles are multi-platform lock files meaning they can be extremely large. Finally, poetry is also a build tool, allowing users to build and publish Python packages rather seamlessly.

Poetry is almost the perfect tool for the job, however it has a number of downsides that can be utter deal breakers for production or even basic research and development. First of all dependency resolution can be incredibly slow. A big part of this is no fault of poetry in of itself, but rather in the disparate ways in which Python packages enumerate their dependencies. Unlike other programming ecosystems, not all Python packages declare their metadata in a way that is necessarily served cleanly by public metadata APIs like PyPI. In these cases, exploring every dependency for every possible package in the DAG can involve a staggering amount operations to directly figure out package dependencies by downloading and parsing python wheels. For some folks doing basic R&D, the cost of simply having a few packages excluded from dependency resolution can be a fairer tradeoff than waiting minutes to hours to find a “failure to resolve dependencies”.

Furthermore, as of 2024, the dependency resolver in poetry is actually still written in Python as a depth-first search algorithm. By comparison, tools like mamba have resolvers written in C++ as boolean SAT solvers which are orders of magnitude faster! Dependency resolves for large projects in poetry, combined with the generation of multiplatform lockfiles can take an obscene amount of time… especially when there is an actual conflict in the DAG.

I have actually used poetry at my last job, and one of the number one issues with the tool is in how most folks (even incredibly experienced folks!) used it incorrectly to specify dependency bounds on library code intended to be widely shared. In poetry there is the option to use a caret ^ operator implicitly specify upper and lower bounds. For example, specifying ^0.2.3 is equivalent to specifying >=0.2.3,<0.3.0. This ceiling pinning seems like a good idea on the surface, but can wreck havok when applied across a large RnD organization, with numerous “false positive” unresolvable dependency DAGs when well-intentioned software engineers apply it too liberally. This sort of well intentioned ceiling pinning can have devastating consequences for libraries intended to be used widely.


pdm is incredibly similar to poetry, but has a core difference difference in that it also supports PEP-582. This PEP basically brings pdm in line with other programming language environment setups by jettisoning the idea of virtual environments that are independent of a given project/folder. When you are in your project directory, you are effectively in your virtual environment (which is not necessarily totally isolated from the system environment and any other active virtual environments). This can greatly reduce the futzing around of having to activate and deactivate various virtual environment tools in Python. Furthermore, pdm is much more compliant with PEP standards than poetry, which can be a killer advantage for certain users.


Unlike the other tools on this list, hatch is a full build system for python which support pyproject.toml. I have not actually tried this tool, but it mostly overlaps with poetry in many ways, and has one particular feature that I have yet to see in any other Python tool. You can actually use hatch to run tests in parallel on multiple versions of python.

The Conda ecosystem

It would be impossible to dive into an article on Python tooling without talking about Conda. conda was created by some of the most prominent members of the Python open source community - Travis Oliphant (one of the creators of Numpy, Numba, and SciPy) and Peter Wang who was a developer of Bokeh.


In many ways conda and anaconda solves most of the core problems with Python environment setups for data science work. conda actually can manage non-Python dependencies along with Python packages within its own conda virtual environments. This provided a fairly ergonomic way for scientists to swap around non-python dependencies without resorting to using Docker (which is significantly higher friction to use). This is the tool I use outside of work, and it’s great for experimenting.

Like poetry, conda performs a full dependency resolve when building an environment, but unlike poetry, in recent years the conda dependency resolver has been swapped out for a faster one written in C++ called libmamba. Additionally, unlike poetry, there is no need to go and attempt to parse python packages directly when insufficient metadata was provided by upstream package maintainers. This is because conda has entirely separate metadata api servers which force package uploaders to maintain stricter standards of dependency declarations.

The core tradeoff with conda is that it attempts to do package metadata the “right” way by enforcing the existence of a separate environment.yml which properly declares dependencies and other metadata. It is actually this information which is served by conda’s separate metadata API servers. This can be onerous to adapt in a company that already has many internal python packages. If there is some obscure python package out there that does not have this file, then you won’t be able to install it using conda cleanly. However, pip installs within conda environments are possible leading to a potentially awkward mishmash of relying on two package managers. Another thing to keep in mind with conda is that it neither generates lock files out-of-the-box nor supports pyproject.toml config files.

In 2024, conda is not ideally ergonomic. Users still have to fiddle around with conda virtual environments which are decoupled from specific project folders. Dependencies and config for a project can be difficult to keep track of across conda environment.yml files, pip installs, and other configuration files. Publishing a package is neither particularly simple nor easy.

I have also seen some organizations avoid using conda for production deployments due to the fact conda tends to install a lot of cruft since it manages non-python dependencies as well. Such orgs will lean towards using Docker and *.lock style files to enumerate dependencies.

That being said, conda is probably the best tool for data scientists and experimentalists right now. It is treated as a first-class citizen by a number of third party tools widely used in the Python ecosystem such as Ray and Metaflow.


There are actually multiple implementations of conda. mamba is basically a full rewrite of conda in C++, making it substantially faster. The slowest bits of conda however were actually the solver, and as of 2024, the libmamba solver has been ported over to conda from the mamba project.

In 2024, members of the mamba team switched over to working on pixi – a full mamba and conda replacement written completely in Rust (see below).

Python Package management meets Rust

Some of the most promising developments in the Python package management world have been from the Rust community. No doubt Rustaceans have a clear example of how a package manager setup should work in the from of Cargo, and so several promising solutions have cropped up in the past 2 years, most notable of which has been uv.


Just to illustrate that multiple groups have tried to make a “Cargo for Python”, I wanted to briefly mention huak. The tool is completely experimental as of the writing of this article and not widely used, but attempts to graft the ergonomics of Cargo into a python package manager.


One of the most ambitious Rust projects is pixi which seeks to be a drop-in replacement for conda. Like conda, pixi can manage non-python dependencies. In mid 2024, pixi started to switch from its own backend rip to uv (see below) for better performance. This is an actively evolving tool, and I eagerly await to see where it goes. Unlike conda and mamba, pixi incorporates its own type of *.lock file which immediately puts it ahead of vanilla conda for reproducibility.


One of the first attempts to redo Python package management in Rust by Armin Ronacher. When I first saw this over a year ago, the actual slow part (dependency resolution) was simply calling piptools under the hood, leading to no discernable gain in speed or performance.

However, over time, the project has matured to the point where it now does most if not all of what poetry does only faster. This project was recently taken over by Astral.sh (developers of uv and the ruff linter) and now uses the same dependency resolver as uv on the backend. The tool has also gained a decent amount of traction on some major projects. For example, the OpenAI Python API library uses it. There is a strong possibility that the functionality of rye will eventually be fully replicated by uv alone, leading to a merging of the two projects.


uv is by far the most promising package management tool in the Python ecosystem as of the writing of this post. This project actually aims to be a drop-in replacement for pip on top of being a Cargo for Python. The API is currently in no ways stable (as of 2024), but the benchmarks are incredibly promsing. Most notably, the development is backed by Astral.sh, a company formed by Charlie Marsh and the creators of the ruff linter, a widely beloved tool that virtually supplanted all incumbants overnight when it was released in 2022.

Like poetry, this project supports pyproject.toml, and like pip it uses a backtracking approach for dependency resolution. Unlike pip this algorithm is written in Rust and is very fast! Benchmarks show that uv is at least order of magnitude faster than poetry when it comes to dependency resolution. I fully expect uv to supersede tools like poetry in the future as the project matures and API stabilizes, however as of this writing, it is more of a drop-in replacement for various pip tools than an opinionated build/packaging/versioning tool like poetry or rye,

One promising sign of uv’s performance and adoption is the usage of its libraries in other package managers like pixi and rye.


Hopefully one day there will be a cohesive solution to bring Python package management to the simplicity and ergonomics seen in the Javascript and Rust development ecosystems. Until then, I would simply recommend that most data science/experimentalists stick to using conda, and production oriented folks use pip or poetry (with some mindfulness towards slow dependency resolve for complex projects with poetry).

Fingers crossed, though, I hope uv takes off and the Python community can one day coalesce around a single standardized tool! And there are some promising signs that tools like pixi can improve on conda and its wider scoped dependency management.

Read the whole story
5 days ago
Hamburg, Germany
Share this story

State of Text Rendering 2024

1 Share
Read the whole story
5 days ago
Hamburg, Germany
Share this story

Introduction | Code Review Anxiety Workbook

1 Share

Dear Developer,

Feeling anxious about giving and receiving code reviews is a common, widely-documented experience for software developers. This experience is called code review anxiety. Code review anxiety is characterized by a fear of judgment, criticism, and negative evaluation, and it can lead software developers to engage in a variety of counterproductive behaviors, such as avoiding code reviews, engaging in "rubber stamping", or procrastinating in opening and reviewing pull requests, among other things.

Perhaps unsurprisingly, the avoidance and procrastination that so often accompanies code review anxiety not only makes the anxiety worse in the long-term, but also prevents developers, teams, and organizations from realizing the many documented benefits of code reviews, such as improved code quality and security, learning and knowledge transfer, collaborative and creative problem solving, and trust and community building.

And contrary to industry myths, code review anxiety is not just a “junior developer problem.” This means that any developer can experience code review anxiety, making it relevant to any individual, team or organization. Multiply the negative consequences of this anxiety across developers and development teams in an organization, and the result can be a lot of wasted time, energy, and emotion.

At the Developer Success Lab, we care deeply about the human elements involved in software development, and we believe that attending to code review anxiety matters deeply for both individuals and their software teams. It’s with this caring that we developed a single-session cognitive-behavioral workshop intervention for code review anxiety. In its design, the intervention draws from decades of clinical research on effectively treating anxiety and hinges on addressing both developers’ physical and cognitive experiences of anxiety. Over the course of 90 minutes, participants were taught strategies for managing physiological processes, as well as how to implement cognitive restructuring, a process by which we identify, challenge, and reframe negatively biased thoughts to be more realistic and compassionate. Using a randomized controlled trial, we also scientifically tested if the intervention effectively eased code review anxiety for software developers.

And the findings from this intervention study are quite exciting. Statistical analyses conducted by both Dr. Carol Lee and co-author Dr. Cat Hicks showed that the workshop was highly effective in lessening developers’ code review anxiety. It increased participants’ beliefs that they have the ability to face and manage their feelings of anxiety, and it increased participants’ self-compassion in the face of challenging code review situations.

In the Developer Success Lab, we know our research is only as useful as the number of software practitioners it helps, and it’s with this ethos that we’ve created this Code Review Anxiety Workbook. The workbook is designed to bring the intervention tested in our rigorous, empirical research to the folks who stand to benefit from it most. Its purpose is to equip software practitioners who regularly participate in code reviews with the tools they need to mitigate and manage their code review anxiety so that they can focus their time, energy and emotion on the thing they love best: crafting and shipping code.

In this GitBook, you’ll find a self-guided version of the workshop intervention that we ran with our research participants. Fair warning: There’s a lot of information here! And it’s all meant to help. So tackle it in a single session, if that best suits you (we recommend setting aside around 90 minutes), or go through it in smaller sessions. Work through the workbook on your own, if you so choose (talking about our anxiety is a vulnerable act!), or – if you have friends or colleagues who you think might be interested – maybe start a Code Review Anxiety Workbook Club and benefit from the power of group sharing and learning!

We also created a PDF version, if you prefer that format:

The Code Review Anxiety Workbook.pdf


However you choose to do this work, just know that it’s such worthwhile work to do. You deserve to be able to do your important, creative coding work without the burden of anxiety weighing you down. And we at the Developer Success Lab are cheering for you!


Carol & Kristen

Read the whole story
10 days ago
Hamburg, Germany
Share this story
Next Page of Stories