Rive is sold as a tool for cute animations. The more I use it, the more I see something else entirely: a genuinely cross-platform engine for server-driven UI. Here is how to load a component from a remote .riv file and bind it to dynamic, per-locale data in Flutter.
If you liked this piece, you should subscribe to my premium newsletter. It’s $70 a year, or $7 a month, and in return you get a weekly newsletter that’s usually anywhere from 5,000 to 18,000 words, including vast, detailed analyses of NVIDIA , Anthropic and OpenAI’s finances , and the AI bubble writ large . My Hater's Guides To Private Credit and Private Equity are essential to understanding our current financial system, and my guide to how OpenAI Kills Oracle pairs nicely with my Hater's Guide To Oracle . This week, I’ll publish the second part to my ongoing series (“ What If…We’re In An AI Bubble? ”) about the factors and events that will cause the AI bubble to finally pop. Subscribing to premium is both great value and makes it possible to write these large, deeply-researched free pieces every week. AI is, as it stands, not economically viable for anybody involved other than the construction firms, NVIDIA, and the surrounding hardware companies benefitting from the irrational exuberance of a data center buildout that doesn’t appear to be happening at the speed we believed . Every AI startup loses millions or billions of dollars a year, and nobody appears to have worked out a way to stop hemorrhaging cash. Hyperscalers have invested over $800 billion in the last three years, with plans to add another $700 billion or so in 2026 and another $1 trillion in 2027 , meaning that they need to make at least three trillion dollars in AI specific revenue just to break even , and $6 trillion or more for AI to be anything other than a wash. I went into detail about this (albeit at a lower, pre-2026/2027 capex number) in a premium piece last year . To give you some context, Microsoft made $281 billion , Meta $200 billion , Amazon $716 billion , and Google $402.8 billion in revenue in their most-recent fiscal years for every single product combined, for a total of $1.599 trillion. None of them will talk about their actual AI revenues. Yes, yes, I know Microsoft said that it had $37 billion in AI revenue run rate ($3.08 billion a month or so) and Amazon had $15 billion, or around $1.25 billion a month , but both of these are snapshots of single months that are meant to make it sound like they’re going to make that much in a year but in the end, you don’t actually know anything about how much money they’ve made from AI. We do, however, now know that Microsoft has spent an approximate $100 billion on its OpenAI partnership after testimony from an executive during the otherwise-dull Musk-OpenAI trial, per Bloomberg : This is a fascinating insight for a few reasons: At the end of 2025, OpenAI claimed that it had 1.9GW of capacity (likely referring to total power draw rather than the actual critical IT of the infrastructure at its disposal), which, per analyst estimates, ( $42 to $44 million per megawatt ) works out to around $79.8 billion. This claim was made around six months before the release of Microsoft’s most recent quarterly results. In other words, Microsoft has spent 4 years sinking (either through spending or allocating the capex in advance) nearly $300 billion into…building OpenAI? Okay, fine. Microsoft also has 20 million Microsoft 365 Copilot subscribers for an absolute maximum revenue of $7.2 billion…if every single one were paying $30 a month, which they are most assuredly not as Microsoft has been offering discounts on it for years . Based on my reporting from last year , Microsoft made around $7.5 billion from OpenAI’s inference spend and $761 million from its revenue share in Fiscal Year 2025, a year when it invested (either spent or allocated) around $88.2 billion in capital expenditures. I didn’t report it at the time, but I also had the numbers for all of Microsoft’s revenues for the first three quarters of Fiscal Year 2025 — a total of $8.9 billion of total AI revenue, with around $4.35 billion in revenues when you removed OpenAI’s inference. If we assume that Microsoft’s other AI services grew 10% quarter-over-quarter, I estimate that Microsoft likely made around $17.9 billion in AI revenue in FY2025, or a little under a fifth of its capex. And let’s be clear: none of these numbers include the actual operating expenses. Data centers, after all, need electricity to run, and AI data centers in particular need a lot of electricity. And some — though, admittedly, not many — people to handle the things like maintenance, repairs, and operations. And then there are things like taxes, insurance, and the other day-to-day costs that, when you add them all together, make a big, scary number. You can argue that “actually GPUs are profitable to run” ( I disagree! ), but for any of this to make sense, four things have to happen: All four must be true. If AI revenues don’t explode, capex can stop, margins can be positive, and your best-case scenario is…you maybe broke even. If capex never stops being invested, you need revenues to explode dramatically — to the tune of effectively doubling Microsoft, Meta and Google’s entire businesses, and tripling Amazon Web Services’ annual revenue ( $128 billion ) — and for said revenues to be margin-positive, because if they’re not, eventually other healthy businesses will slow, leaving AI to tear a hole in overall margins. In all cases, AI revenue must stay consistent because, well, you need to get paid . I also cannot find an economic scenario where this pays itself off. Let’s assume that Anthropic is actually at $45 billion in annualized revenue ( I believe it’s doing some very worrisome maths to get there ), or around $3.75 billion a month. On an annualized basis, this would not be enough — assuming it had zero operating expenses (rather than losing billions) — to recover a single year of capital expenditures from Microsoft, Google, Meta, or Amazon from 2024 or 2023. Even if OpenAI’s entire cloud spend ( $50 billion ) for 2026 went to Microsoft and it doubled its Microsoft 365 Copilot revenue (at full cost) to $14.4 billion, it estimates it will invest $190 billion in capital expenditures this year. Amazon’s $15 billion AI run rate, even if it doubled, wouldn’t put much of a dent in its $200 billion in investment plans . While we don’t know Google’s AI revenues, it plans to invest $185 billion in capex this year . These AI revenues have to be completely fucking insane and they need to be that way extremely fucking soon , because otherwise the best they’ll be able to say is “our first few years of capex weren’t particularly useful but the stuff we built after it was,” which still works out to a few hundred billion dollars of waste. Things get even worse when you realize that at least 70% of Microsoft, Google, and Amazon’s compute is dedicated to Anthropic and OpenAI , two companies that burn so many billions of dollars that Microsoft, Google and Amazon have already fed them a combined $54 billion in the last three years, with $28 billion of that coming in the last month and Anthropic due another $50 billion from Google and Amazon if certain performance obligations are met. And there’s no real sign, outside of Anthropic and OpenAI’s compute spend (which is reliant on hyperscaler and venture capital money), of any real explosion in AI revenue. Per The Information (in a chart I love to share!), more than 50% of hyperscalers’ revenue backlogs comes from these companies: If massive, incredible demand for AI existed, wouldn’t these remaining performance obligations be near the trillion mark? Wouldn’t there be other Anthropic or OpenAI sized chunks of revenue? There’s allegedly incredible, unstoppable, insatiable demand for compute. Why isn’t it lining up? Let’s take a look at those RPOs! That was a lot of numbers, so let me make it simpler: outside of OpenAI and Anthropic, these three companies do not appear to be significantly increasing their revenues, and the only way to get that revenue is to feed money to one or both of these companies. Put aside all the theoreticals and hypotheticals and metaphors and imaginary future scenarios and tell me: what, in the next year, are Microsoft, Google and Amazon going to do about this problem? How do they solve it? If we assume the absolute best-case scenario, these companies are making a combined $70 billion in annual revenue on investments that now — including the money invested in the companies themselves — total over $900 billion. Doubling that won’t be enough. Tripling it won’t be enough. In fact, to pay this off, these companies will need to be making over $100 billion each in AI revenue in the next year , because otherwise there is no covering these losses. And it all comes back to a very simple point: AI is too expensive. If the margins were good, they’d be sharing the margins. If the revenues were good, they’d be sharing the revenues (and no, run rates aren’t revenues). If the business was strong, it would be a separate category in their earnings. But LLMs are too expensive! They cost too much to run, and said costs appear to increase linearly with revenues. The more a user uses a product, the more it costs the company to run it, and the more capacity they can take up. The only way to capture any growth is to buy and install GPUs , which in turn requires you to build somewhere to put them, which takes time and money. I’m really struggling to see the argument in favor of continued capex investment. You’re more than $800 billion in the hole with, I estimate, less than half of that resulting in operational GPUs and capacity. Said capacity is mostly taken up by OpenAI and Anthropic, two companies that burn billions of dollars and do not appear to have an answer for how they might stop. The more you build, the more your infrastructure becomes dependent on the continued existence of two perennially-unprofitable ultra-oafs, as your existent AI product lines are, at best, add-ons to products like Google Workspace or Microsoft 365, or further expansion of cloud compute capacity with lower margins and higher up-front costs than anything you’ve ever built. Every quarter is an opportunity to put yourself another $30 billion or so in the hole, all in the hopes that, I assume, OpenAI or Anthropic will pay you $100 billion or $200 billion over the course of a few years, because nobody else in the entire universe is spending that much on compute. You are not recovering these investments without either a massive new product line that doesn’t exist today or three or four Anthropic or OpenAI-sized compute contracts. Put another way, Amazon needs another AWS ($128 billion a year), Microsoft another Azure ( $75 billion a year, including OpenAI’s 2025 compute spend ) and Google a business line at least half the size of search (around $200 billion a year). These businesses have grown to this size by providing extranormally large amounts of value from the very moment they were created and impenetrable monopolies — and while there are quite literally other cloud providers that can physically provide the infrastructure to OpenAI and Anthropic ( Oracle is trying to compete and may die as a result ), the actual “monopoly” here is “being able to deploy hundreds of billions of dollars.” Anthropic proved this when it took 300MW of compute from Elon Musk . In Oracle’s case, as I’ve explained at length , it has to successfully build 7.1GW of capacity, have that capacity actually be margin-positive (doubtful!), and then actually get paid for it by the time it’s built in, oh, I dunno, 2032? Sadly, I have bad news about Oracle, Microsoft, Amazon, and Google’s largest customers. Here’s a fun game: ask an AI booster how OpenAI or Anthropic becomes profitable! Here’s what they’ll say: I must be abundantly clear that nobody has any proof that anyone is profitable on inference, but we have plenty of proof they’re not. They’ll likely cite known liar Sam Altman saying OpenAI is profitable on inference from a party from August 2025 , or Dario Amodei saying ( in a sentence around “stylized facts” that are “not exact” and are specifically “a toy model” and specifically not about Anthropic ) “the inference has some gross margin that’s more than 50%.” Here’s a really simple way to dispute this: Coatue said that Anthropic’s revenues were 85% API calls in 2025 . If it’s profitable on inference, how is it still losing money? You’re gonna say “training,” but that doesn’t actually answer the question: if Anthropic’s process of providing tokens to its models is profitable, how is it losing so much money? Why offer a subscription platform at all? As I’ll get to, Anthropic has companies paying massive amounts for tokens — hundreds of millions a year in some cases — that’s all inference . Why are you bothering with these stinky, nasty monthly subscriptions? The “inference is profitable” argument is a bedtime story told to people that can’t reconcile the logic of a company that allows people to burn between $8 and $13.50 of every dollar of their subscription revenue. Otherwise, you have to reconcile with the fact that both Anthropic and OpenAI are both incinerating money and have no real path to any kind of sustainability other than, well, not doing that. One very, very specific counter-argument people make is that open source models are cheap, and can somehow be compared to OpenAI and Anthropic’s, despite the fact that we have no idea what the actual parameters of Sonnet, GPT, Opus, or any other of their models actually are. What we do know is that both of these companies lose billions of dollars. What we do know is that OpenAI, per The Information , plans to burn $852 billion through the end of 2030, and that as of March 6, 2026 (per CFO Krishna Rao’s sworn affidavit), Anthropic made “exceeding” (sigh) $5 billion in revenue and spent $10 billion on inference and training. Anthropic has done a great deal of work to obfuscate how much it actually makes or spends, but I think it’s likely it burns even more than OpenAI, given the fact that it’s had to raise $75 billion in the last 6 months ( assuming its new $30 billion round closes ), and that’s not including an additional $30 billion from Google and Amazon if certain unknown milestones are hit. Then there’s the issue of those RPOs. Anthropic is now on the hook for $200 billion to Google, $100 billion to Amazon and $30 billion to Microsoft, I assume over the course of the next three or four years. So let’s lay this out. Anthropic — based on its own affidavit from March — appears to have spent $3 to make $1 of revenue on a compute basis, and that’s before you include any and all other costs like staff or electricity or the vocal coach that Dario Amodei uses to add that bass to his voice. Additionally, it needs $330 billion to pay its cloud obligations to Amazon, Google, and Microsoft over the next four years. I’d estimate it needs $5 billion a year for its compute deal xAI (so $20 billion over the total period) and an estimated $30 billion to cover its deal with CoreWeave . That brings us to a total of $380 billion. It’s hard to estimate the actual costs associated with running Anthropic because so much of the reporting no longer makes sense as a result of that affidavit. Nevertheless, I think it’s fair to assume it will need at least $20 billion of operating expenses across that four year period. We don’t even need to play in the realm of “what might Anthropic or OpenAI’s revenues be?” to understand the problem here. Both companies aggressively burn money, and neither of them have any answer as to how they might stop. Numerous reports about how Anthropic will turn “cash flow positive” in either 2027 or 2028 are fantastical, illogical, entirely driven by ridiculous projections, and should never have been reported as anything other than an attempt by companies to mislead their investors. In both cases, reporters should’ve had more asterisks on those numbers than Q*Bert reading Frank’s lines from Blue Velvet . And we have plenty of evidence that they’re losing more money over time. In January 2026, The Information reported that Anthropic’s gross margins were 40% in 2025 — 10% lower than its “optimistic” projections, specifically attributed to “...the costs of running Anthropic models from paying customers, in a process known as inference, on servers from Google and Amazon,” adding that those costs were “23% higher than the company anticipated.” In February, The Information ran another story saying that OpenAI’s gross margins fell from 40% in 2024 to 33% in 2025, a full 13% lower than its projected margins of 46%, all because (and I quote) “...the company having to buy more expensive compute at the last minute in response to higher than expected demand for its chatbots and models.” You know, exactly what Anthropic has had to do. This is what I’ve referred to as the knife-catching problem for compute demand — you either don’t order enough compute and have to rush to buy some last-minute as demand intensifies, or you order too much, and, well, to quote Dario Amodei: And right now, as I’ve covered , there’s not enough compute being built to keep up with Anthropic or OpenAI’s voracious demands, meaning that they will both be bartering to buy whatever’s available at whatever price it’s available at. This naturally will savage their already-negative margins… …and then what? No, really, and then what? One of you fucking AI boosters, answer me, how does this actual reverse course? Because even if Anthropic were making $100 billion in annual revenue, it would probably be losing $300 billion or more to get there. The fact it had to raise $30 billion in February , $15 billion in April, and now $30 billion more in May all while allegedly pulling in more than $3 billion a month in revenue suggests that its COGS are fucking horrendous, and its growth is coming at a terrible financial cost. Let’s say that Anthropic keeps growing and ( as The Information suggests ) hits $100 billion in annualized revenue (around $8.3 billion a month). How, exactly, does it afford to make that much money? Because right now it’s (allegedly) about to hit $45 billion in annualized revenue, and needs so much money that it’s absorbing (along with OpenAI) the majority of venture capital raised this year, and very clearly does not have any path to bring its costs down. The answer is simple: it can’t! There is no mechanism to do so. More compute does not make OpenAI or Anthropic’s services cheaper to offer. There is no magical silicon coming that will make any of this more affordable, and no, Anthropic is not “profitable on inference,” because if it were, that massive revenue growth would have leveled out its margins rather than require it to raise a little less than the combined value of every Major League Baseball team , or more if you add the other $50 billion that Amazon and Google have promised based on secretly-held performance obligations. The same goes for OpenAI, which “raised” $122 billion (around $45 to $50 billion in real cash, with the rest either paid in installments or on it IPOing or reaching (sigh) AGI) in February and is now already considering raising more . Somebody might counter-argue that this is companies raising as a means of boosting their valuations, I think that’s a very convenient way of looking at two extremely problematic companies. I should also ask why neither of them appear to be seriously considering going public. While both were rumoured earlier in the year to be planning to do so in 2026, both appear poised to raise more private capital. I think the answer is simple: their CFOs know that doing so would reveal their actual margins, which are hot dogshit with sprinkles on top. Nobody has a sensible or logical response here. Which leads us right to our next point! One important detail to keep in mind here is that as of a month or two ago, Anthropic moved all enterprise customers to token-based-billing, which will begin, I believe, a true stress-test of the true “value” of AI as costs skyrocket. Just last week I ran the first of a two (or three, potentially) part premium series called “What If We’re In An AI Bubble?” and touched on the gruesome subject of whether organizations could afford to pay for AI long-term : Earlier in the week, carnival barker and Salesforce CEO Marc Benioff said his company would spend $300 million on Anthropic tokens in 2026 , and as I discussed in my premium from Friday , unrestrained AI spending is inflating the revenues of Anthropic and OpenAI in a way that isn’t sustainable for anybody involved: The problem is simple: nobody actually knows how much AI is going to cost them in any given quarter. This means that the current token spend you’re seeing is entirely experimental, which is why organizations keep burning through their tokens so fast. This massive growth in spend is what underpins the “massive” (I have serious questions about its accounting) growth in Anthropic’s revenue. Executives have, across the board, given their engineers free reign to burn as many tokens as they’d like, and while I severely doubt that Anthropic actually hit $50 billion in annualized revenue outside of not-quite-fraudulent non-GAAP measurements, I believe its revenue growth has come from an artificial boost from a tech industry searching for a reason to pay somebody money. To be very clear about what I mean, I think there is currently an AI token binge across both Anthropic and OpenAI. Enterprises do not know the actual value of AI, and do not know how much they should actually be budgeting, which is why Uber and others are running through their token budgets but not, it seems, spending less. We’re currently in an abundance phase — one where nobody is truly thinking about the costs outside of their fear of missing out — but there’s this nasty undercurrent of “wait, how much does that cost?” followed by “oh, fuck, well…you know I love AI but…” Put another way, the current spend on AI tokens is not something that’s indicative of lasting, reliable revenue. In some cases, the pressure to use AI for everything is turning companies’ software stacks into slop. Things are worse elsewhere. Something is wrong at Zillow. Something about LLMs has done something to its technical leadership, something that makes them talk strange and send weird slide decks with confusing, slop-ridden sentences. The real estate tech firm spent over $1 million on AI services in the first quarter of 2026, and in April it spent $749,000 in tokens across Cursor and Anthropic’s services, as well as through AWS Bedrock. As of the end of the month, it was nearly 75% of the way through its annual Cursor token budget of $1.1 million. As of the middle of May, its total AI spend had already crested over $300,000, and its Cursor budget sat dangerously close to the edge at 85%. This is particularly-concerning when you consider that Zillow’s net income for Q1 2026 was $46 million , and ranged from $2 million to $10 million each quarter of 2025. Zillow is currently on course to spend at least $7 million on AI in 2026, and at its current pace might hit as much as $10 million, which would amount to a little less than 50% of its 2025 net income ( $23 million ). You’re probably wondering how Zillow manages to spend so much on AI, and the answer — as I’ll get into in next week’s free newsletter — is that its technical executives appear to have AI psychosis, saying that the short-term goal is for “software engineers to never open a code editor again.” The reality is chaos. In a slide deck that I’ll discuss later, Zillow revealed that while engineering resources have largely stayed the same, outputs requiring human review have increased by nearly 50%. Meanwhile, code deployments and pull requests increased by 39%, and software reviewer load increased by 29,000 hours each month , creating a massive burden on the 1,500 or so engineers working at the company. In simpler terms, that’s about 19 hours of extra work per engineer that’s literally just looking at extra code written by LLMs. On Blind, the anonymous social network for tech workers, Zillow workers complain about Zillow’s code “slowly becoming AI slop,” with “much more code getting approved without guardrails or input due to people not being able to keep up the other’s velocity or just not caring anymore.” One worker claimed that “the slop is job security,” adding that they “don’t want the output to be good or documentation to be clean [as] management will replace [them] with offshore/nearshore/AI agents at the slightest whiff of evidence that the slop cannon is self sustaining.” Another said that they felt “lost in the agentic world,” and that they “didn’t have full grasp of where we are going or what [their] role is,” with a “lot of overlap in what people are doing.” Another said that “people are burning tokens just to hit internal AI adoption targets,” adding that “this is what happens when leadership ties metrics to usage instead of outcomes,” saying that it “literally subsidized busywork.” This is all part of what an internal slide deck viewed by this publication called “AI-Native Engineering,” promising a “path to an agentic Zillow” and “faster outcomes for customers,” though customers are never mentioned in any other slide. The deck — pumped full of AI-generated text — talks about “generic AI being a commodity,” saying that “Zillow-aware AI is a competitive advantage,” and at no point explains what that means. It encourages engineers to go from “AI-Assisted” to “AI-Native,” with “systems enabling org-wide leverage,” with engineers moving from being “soloists” — individual developers with AI tools — to “conductors” that orchestrate AI agents, to “composers” that “define systems AI can safely play,” adding that “2026 is the transition from conductor to composer.” Yet the strangest part is named “2027: A Tuesday,” discussing a theoretical day in the office for whoever is left at the company. This theoretical example is, apparently, a process that would take weeks, but now takes under two hours.” Zillow intends, based on this deck, to sacrifice everything to AI — code review, vulnerability fixes, policy checks, deployments, testing, and basically having agents take over everything , no matter how small, like having an agent do dependency updates and security hotfixes that could be handled with a simple shell script. To quote Zillow: In practice, sources at Zillow tell me that there has been no actual movement toward this vision. Software engineers still open IDEs and review code manually, with one describing Zillow’s “vision” as “nonsense,” adding that “you can’t just throw buzzwords on a slide deck and change how all the engineers do their jobs.” As for why token burn is so high, sources tell me that engineers are actively encouraged to use AI for everything , as much as possible, writing PRD (product requirement documents) in AI, then using the AI to make stuff based on the PRD, then doing a deck with AI, then writing emails with AI, using AI to brainstorm, or create weird, esoteric automations, with some managers pushing workers to have one personal AI “goal” to aspire to. Zillow’s agentic “vision” is apparently a remit from the C-suite. It’s hard to tell if this is AI psychosis or just classic Business Idiot bullshit. Perhaps it’s a little of both. Every organization I’ve talked to has exceeded or is nearing the edge of their annual token budget barely five months into the year, which means that everybody has suddenly given themselves an extra few million dollars’ worth of operating expenses for reasons that escape effectively everybody I’ve talked to. Every engineer tells me the same thing: “I’m being made to do this, I don’t want to do this, my managers do not seem to understand, my bosses seem to understand even less than my managers, and if I don’t use AI somebody is going to fire me.” Put another way, CEOs and CTOs are screeching at their underlings to “use AI as much as possible” to “find its incredible benefits” without anybody really knowing what those are and how much it’ll cost to get there. This might be because Anthropic obfuscates the data that might tell customers the real costs. Per Laura Bratton at The Information , Bratton’s article has numerous quotes from executives saying that Anthropic lacks transparency and granularity into the ways that tokens are being burned across an organization, in a way that I think sounds very, very suspicious, particularly when you add the following: While I’m not accusing Anthropic of anything untoward, massive, multi-million dollar contracts that involve individuals burning thousands or tens of thousands of dollars’ worth of tokens with no service level agreement, transparency or true granularity into the burn is a perfect setup for a company — not saying it’s Anthropic! — to do something dastardly with those numbers. While an individual might be able to monitor their own personal usage, in an organization of hundreds or thousands of engineers, who’s to know if, say, the particular token burn is consistent across every member of the company, or that those costs are actually matching up with what the user is doing? This is a company ostensibly worth $900 billion dollars acting with disregard for the basic measurement of “how much did this cost, and how did it cost so much?” And in the end, how do you even measure it at scale? Say you’ve got 1,500 engineers, and they’re spending a combined $1 million tokens a month. How the fuck do you actually measure the return on investment for that spend? How many tokens does it take to do one thing? Is it consistent across every model? Is it consistent across every employee? Are you even measuring how many tokens a task costs? Because if you’re not, that token budget is basically throwing a dart blindfolded. Okay, now you’ve measured a task, did you make sure to measure it multiple times? Because LLMs can randomly do things differently even with the same prompt and same Claude.MD file and same strictures and same data sources. You’re gonna need at least 10 samples of each task, and you’re gonna need to make sure somebody who actually knows what they’re doing can measure them, because if you get a dimwit, they’re going to say it can do something it can’t. Unless, of course, you can’t actually measure how many tokens a particular task can take with much accuracy, in which case every single AI token budget is bullshit. And each model does things differently depending on many different variables, some of them a result of the user, some of them a result of the AI labs themselves. Alright, well, maybe you just need KPIs — measurements you can aspire toward , and by pursuing them you can start working out how much it costs to do stuff. Wait, which metric works there exactly? In fact, it’s pretty hard to measure anything like “efficiency” or “productivity” in any business, because every metric connected to them can be gamed, leaving managers and executives with the problematic situation where they have to start learning how things work so they can see if they’re good. Before AI, this wasn’t as much of a problem, in the sense that inefficiencies and wasted hours weren’t directly connected to a chatbot that is specifically designed to burn money. Managers and executives could come up with whatever deranged, self-gratifying office bullshit they pleased, wasting hours of people’s time in the process, but doing so didn’t immediately connect to a massive, ever-increasing cost. AI is a perfect storm of failed concepts and organizations, and the apex of the Era of the Business Idiot , an epoch where we’re ruled by people so thoroughly disconnected from the actual workforce that it was inevitable that a technology would be created specifically to grift them. LLMs are dangerous for many, many reasons, but the under-discussed one is how well they play to a certain kind of executive imbecile. Generative AI is — to quote Mo Bitar — really good at doing an impression of work, much like most managers and c-suite executives, and even if it’s completely incapable of doing something, it’ll absolutely say it can and tell you you’re amazing for suggesting it. And that’s why Business Idiots love it. Where regular human beings would say annoying things like “that’s not possible within that timeline” or “we don’t have the resources to do it,” AI will say “of course, right away!” and burn as many tokens as possible. When it makes mistakes, it’ll apologize — as it should because it failed you — but then promise to do better next time, all while costing so much less, at least in theory , than a regular, stinky human being. It’ll create a PRD of a theoretical software project with the confident and vigor that you need to take it immediately to a software engineer and say “build this immediately,” and when the software engineer tells you a bunch of bullshit about it not being possible , it’ll spit out several convincing-sounding responses. Fuck, why even bother talking to that engineer at all? Claude Code can mock up a prototype that you can then shove in their fucking face before you fire them for not using AI to do it themselves. Any executive-level fuckwit you’ve met in your life now has a seemingly-powerful tool that can burp up mimicry of open source software and, if you constantly prompt it, eventually get something half-functional onto some sort of web server. When you face bugs, it’ll try and fix them, sometimes also “fixing” (adding or deleting code) from elsewhere to be helpful, like when Cursor using Anthropic’s Claude Opus 4.6 model deleted an entire production database and all its backups . It will never, ever say no, even if it’s incapable, even if it has no thoughts, even if what you are asking is equal parts impossible and unreasonable in both its timescale and scope. A Business Idiot, given his druthers, can sit there and fuck around and make an LLM spit out something that makes him feel like he’s coding, which in turn makes him feel that you, a lazy and stupid engineer , could do even more with the power of AI. It doesn’t matter that it costs an absolute shit-ton of money, or that there’s no way to measure its efficacy. The Lion does not concern himself with things like “efficacy” or “productivity,” and the Lion is increasingly tired of your whining! The Lion doesn’t even understand what it is you do every day other than not doing what The Lion is asking for! You laugh, but this is genuinely how the majority of managers and executives think and act, and now they have a special chatbot that can fart out functional-enough prototypes to convince a Business Idiot they can do anything, because executives and managers do not regularly do much work and thus have no idea what it looks like other than when they look over your shoulder, which is why they wanted you back in the office! Organizations aren’t burning millions or hundreds of millions of dollars a year on AI because it’s good , they’re doing it because they are run by people who do not know what the fuck they’re doing. In a sane world, randomly adding a massive, ever-expanding operating expense to your business with the express intent of — to quote IT firm Workato’s CIO , “eating the costs while employees experiment” — would have the board blow up your house. In our world, one dominated by disconnected, self-involved and massively-overpaid dullards, many businesses pushing their workers to use AI are doing so because the other guy is doing it, with about as much strategy and forethought as one would expect from somebody who spends 90% of their life reading emails, going to meetings, or going to lunch. The majority of those I see trumpeting the so-called benefits of AI do not appear to do anything of note. I have yet to see one so-called multi-agent orchestrator engineer psychopath ship something remarkable or impressive or even functional. I have yet to see any AI-obsessed boss write or create or author or do anything I can remember. I don’t see any of these fuckwits running a company on their own outside of those who have learned to sell stuff to other AI psychosis victims or executive midwits of varying size. And why oh why is it always the language of inevitability and possessiveness? Nobody who’s this insistent, aggressive and violative with their language of “it’s here and if you don’t adopt it you’re stupid and dead” has ever been right about anything. Nobody this desperate, insistent and forceful has ever had good intentions, good vibes or brought good omens — they are always bearers of some kind of con. Most technology is sold on elevating and ascending human beings. AI cheapens every interaction by creating a work-shaped product from a person that doesn’t respect you enough to give you work that’s barely fit for a human because it wasn’t made for one. You must accept becoming a dogshit dealer that loves accepting and receiving low quality goods. You must celebrate intentionless and decaying slop, and defend it and the machine that made it with your entire being. You must sully yourself — treat its unexceptional, sloppy and unreliable outputs as signs of sentience, or at least the proof that digital sentience is possible. You must defend horrible, abrasive, ugly, loud monoliths of steel full of $50,000 graphics cards. You must say they are necessary, and you must aggressively antagonize those who do not. Every time you defend generative AI you defend a machine of capital that has burned $1 trillion and created one of the most-wasteful products in history. If people disagree with you, you must attempt to harm them somehow — ostracize them, mock them, attack them, denigrate them. You will justify this as moral, because you have been manipulated by a technology built and sold by two of the greatest grifters of all time — Dario Amodei and Sam Altman. Anything less is opposition to an industry with all the trappings of authoritarianism down to the media toadies, the propaganda and the seizure of land in the name of a nebulous “greater good.” But man, these men got people good. Sam Altman helped propagate a technology perfect for conning people with potential, a larger extrapolation of Altman’s own life of taking dogshit — Loopt, for example! — and parlaying it into larger opportunities. It can make a really half-hearted demo of a lot of things, and that’s good enough to sell to Business Idiot. Dario Amodei took this grift and perfected it. Anthropic is a company purpose-built to con people into giving it by money by making people feel smart. LLMs can do work-shaped stuff, sometimes, as long as you debase yourself to accept mediocre and often-broken stuff that you have to keep a vigilant eye on, and either use a subsided product that loses Anthropic money or pay a shit ton of money as an enterprise to Anthropic and they still lose money. These companies were only capable of growing in an economy dominated by the gullible and work-shy. Only a capitalist culture dominated by people who don’t actually do or know stuff have let this get so far. Nobody wants this, nobody wanted it since the beginning, it was forced upon everyone, and to pretend otherwise is laughable and offensive. The amount of people who use this shit a bit and become convinced that we’re mere years from it costing over a trillion dollars to somehow making trillions of dollars and being an entirely different and good product should be aware that they are being manipulated. The more you feel compelled to defend AI the more scrutiny you must show it. I am not your enemy! If you think that I am, you are on the side of a corporation or a product. You can try it, like it, and I don’t really care, but the second I see you trying to be condescending or judgmental or aggressive toward another person for not agreeing with your product choices I immediately feel suspicious. Can’t you see how these people act? Can’t you see how strange it is to defend a thing you pay money for that has terrible economics? If it wasn’t the “in” thing, being an AI person would be considered really weird. I look forward to the day it is. I hope you guys like having the stuff you said since 2022 repeated back to you! I’ve been saving it all. Time is running out for a graceful bow, and you better act quick! If you feel self conscious while other people dunk on AI, that’s weird! I see people say they don’t like Macs all the time. Who gives a fuck! I’m not going to go to the mat for Tim Cook. People can make their own decisions. Those comparing AI to AOL mailing CDs to people should feel ashamed of themselves. This is like if every single time you opened a magazine an AOL CD flew at your head, your boss told you he would replace you with a modem if you didn’t go online, and the news constantly ran segments called “I didn’t receive an email: father forgets son forever because he wasn’t online” or panels with “Internet experts” who said “I am on the Internet superhighway right now, and I’m certain that within 10 years AOL Time Warner will be able to email myself to my dad.” Imagine if Shingy was a billionaire and went on TV every day in 1999 and told you “ the world must get ready, because you’re about to get a ICQ message from The Lord .” Generative AI was purpose-built to grift an economy run by executives and managers who don’t actually do any work. Its success has been driven by a remarkable, society-wide ignorance in the management sect, and its continued proliferation is only possible through the media’s continued trust and faith in the idea that CEOs are busy because they’re actually doing work. Yet even a Business Idiot eventually realizes that too much money is being spent, and the first one of these dimwits to cut their token budget will send the rest of them running for the doors. We should lock them. We should make everybody who obsessed over theoretical ideas about what AI can or will do ashamed for their intellectual deceit or constant ignorance. At the end of the AI era, the only thing that will change the rot at the heart of our economy is the acceptance that the majority of companies are run by lazy, self-involved and ignorant fuckwits, and accountability for those who refused to scrutinize them. Microsoft has spent a total of $293.8 billion in capex since the beginning of Fiscal Year 2023 (which began in the back half of 2022). This means that around 30% of Microsoft’s capex ($87 billion) went to building OpenAI’s infrastructure. Based on discussions with sources familiar with Azure architecture, this is the vast majority of Microsoft’s operational capacity. AI revenues have to explode. Capex has to stop being invested. GPUs need to be margin positive, including both their cost and the debt associated with operationalizing them. AI revenue has to stay consistent both before and after you stop spending that capex. Microsoft’s RPOs jumped from $392 billion to $625 billion between Q1 and Q2 FY26 (or calendar year Q4 2025 and Q1 2026), driven by the $250 billion in “incremental Azure spend” from OpenAI (including already-existent commitments) locked up in October 2025 and the $30 billion promised as part of its deal with Anthropic from November 2025 . Based on Microsoft’s own disclosures , without Anthropic and OpenAI’s additions, RPO would have been effectively flat, as evidenced by the fact that in Q3FY26, remaining performance obligations sat at $627 billion . Amazon’s RPOs jumped from $244 billion in Q4 2025 to $364 billion in Q1 2026, driven by its February 2026 $100 billion expansion of its $38 billion compute deal from November, and its extended partnership with Anthropic for 5GW of compute capacity unattached from any kind of dollar number. Google’s RPOs jumped from $242.8 billion in Q4 2025 to $467.6 billion in Q1 2026, driven by ( per The Information ) $200 billion in committed spend on TPUs and compute from Anthropic, meaning that it has expanded its future revenues by an unremarkable $24.8 billion when you remove Anthropic’s spend, when RPOs had previously jumped $85 billion between Q3 and Q4, likely driven by its compute deal from October 2025 . It’s fair to assume a chunk of the remaining RPOs are from its deal to rent TPUs to Meta , announced in February 2026, which makes it likely that it accounts for the majority of the remaining $24.8 billion. Silicon will get cheaper. They’ll start selling services. They’re profitable on inference. It’s an example of a typical working day. At 8:30AM, the engineer notes that confirmation rates in Dallas dropped 3% overnight. ‘Dallas inventory spiked; buyers went from 3 showings to 7. The agent shows the pattern: we're hitting the same buyer 7 times in 24 hours with "tour confirmed" pings. They're overwhelmed; they're muting us.’ The line before this says: “I don't open the codebase — I open the spec and eval dashboard.” Half an hour later, the engineer changes the spec, which is then tested against previous data, showing an improvement. “The PM and I review diffs, check guardrails, approve.” Diffs are “differences” — essentially comparing two versions of the same document to see which lines have been changed. The code is then rolled out. At 11AM, the senior engineer mentors a junior engineer: ‘A junior engineer's rescheduling agent is failing evals. I ask one question: "What happens if the buyer picks a slot the seller just blocked while the agent is negotiating?" We identify the race condition and add a constraint: "Always re-check availability at confirmation time." She updates the spec and evals. The agent passes.’ It is absolutely adorable they’re pretending that they’ll have junior engineers if this hellscape vision comes to life. You can’t say “burn as many tokens as possible,” because employees will — as happened at both Amazon and Meta — deliberately create ways to burn more tokens using scripts and automations. You can’t say “use AI every day,” because even if they do so, that doesn’t actually set up a success criteria. You can’t tell software engineers to try and “ship more software,” because that, again, emphasizes doing more, not making good stuff , and leads to an increase in velocity rather than how good the stuff is. You can’t say “pull requests” or any other metric a software engineer can manipulate, because in 100% of the situations where you give a software engineer a number to hit they will focus entirely on hitting that number.
It is right that the murder of many people be mourned and lamented. It is right that a victor in war be received with funeral ceremonies. Tzu & Le Guin, Tao Te Ching , page 38 H ow are we to prevent war? asks Virginia Woolf in the winter of 1937, as photos of the Spanish Civil War pile up on her desk, with their broken bodies and broken buildings, and Hitler and Mussolini gather forces to the east, and her own government’s war budget reaches new extremes. War, she asserts—and you will agree—is a horror, a terror that must be stopped. As well we know, confronted as we are with real-time video of genocide in Palestine, the massacre of school children in Iran, a fascist leader not abroad but in our own demolished house, asserting his right to make war wherever he likes, whenever he wants, including in our own cities, as armies under other names murder and disappear our neighbors with impunity. But, Woolf asks, what is she to do, what are the daughters of educated men to do in the face of that horror? And what are we, generations later, working women and their allies, how are we to stop it? It’s a good question, and we must spend some time trying to answer it. Woolf begins by considering how women might influence the decision to go to war and we may well begin with the same. To influence, we must have some knowledge to impart, some skill in speaking of it, and a listener who would hear us. We have some knowledge—the knowledge that war is a horror, the knowledge that when a missile falls from the sky and rends bodies into pieces that a terrible evil has been done. We can speak of this too, can point to the photos and videos that flit across our screens, children with missing limbs begging for food amid the ruins. These are images and reports of atrocity, undeniably and unequivocally. Yet who would listen, and how? Where can these words be spoken? Here we find we are in some trouble, for the supreme form of speech in our time is not words but money, both in legal doctrine and in fact of order, with our media controlled and manipulated by an obscenely wealthy few who have gobbled up platforms and papers and perverted them to their own aims, aims that seem very much in favor of war, for war has ever been the commander of wealth. When we speak against war we find our words drowned out, lost in the deepfakes and the advertising, the psyops and the slop, the stock market reports, the casual declarations of war crimes, the oil futures, the gilded festivities, the chattering and nattering among a purportedly progressive political class concerned with the appearance of civility but indifferent to its obligations. No knowledge moves through such mediums, only information, a ravening, unending stream of data in which knowing anything is nigh impossible. And such is that information that it is frequently as odious as the war it both directly and indirectly leads to: racism, misogyny, eugenics, transphobia. (That last a word that implies fear or aversion when the reality is much more violent, both speech and act that seek to eliminate a people whose courage in seeking their own liberty is among our brightest beacons.) But are these notions not the collaborators and soldiers of capital, and so of war? Are not racism and misogyny the masked recruits who go door to door, kitchen to bedroom to workplace, demanding labor and loyalty and love from an underclass who are threatened with suffering and death if they do not deliver it? Toni Morrison, whose words we may yet remember, said: “And they never, ever thought we were inhuman. You don’t give your children over to the care of people whom you believe to be inhuman….They were only, and simply, and now interested in the acquisition of wealth, and the status quo of the poor.” 1 Racism and eugenics were invented to justify the colonization of Black bodies just as sexism justified the enclosure of women’s. 2 The racists and misogynists of today work the same power: they create a world in which a few wealthy men dictate the material conditions of the lives of millions of others who must serve them, who toil for scraps, whose every step, however small, towards more freedom is violently and immediately resisted, and with overwhelming force—an impulse that you will agree is very much like the impulse to war. Look no further than the disproportionate attack on DEI, an effort that saw not to upend capitalism but merely to lightly expand the number of people who might not be entirely crushed by it, but which has been met with an extraordinary campaign to cancel huge swaths of scientific research, retract life-giving knowledge of medical care, hollow out our universities, purge career civil servants and leaders of the armed forces, and to eviscerate the federal workforce 3 —upending millions of lives and leaving our federal government, already poor from decades of neoliberal retreat, unable to deliver on the basic requirements for the life and liberty of its now abandoned public. That the federal workforce has long been one of the best chances for a comfortable life for Black and brown women excluded from comparable employment in the private sector is of course no coincidence. Meanwhile, the barons of the private sector have likewise backed down from even superficial concern for equality, and now demand such extreme fealty to their enterprises that only someone with no caretaking responsibilities whatsoever—with no care at all, not even for themselves—could possibly meet them. “Influence must be combined with wealth in order to be effective as a political weapon,” 4 Woolf concludes, and we grieve that the only change we can see in the century since is that the gap of wealth has widened, the effectiveness or lack thereof become only more extreme. Woolf was a member of the propertied class, but it was in her lifetime that women earned the right to their own property and were granted access to professional work, such that they might not be entirely in debt to their fathers and husbands. And yet in her time women secretaries were said to be routinely “fagged out” in the afternoons because they couldn’t afford a proper lunch. 5 Today, our food pantries work overtime to feed the working poor, people who work full time and more but don’t make enough to buy bread. Those who do make enough to live on do so in awareness of their intense precarity, the knowledge that they are one illness or storm away from ruin. And even the wealthiest worker has little compared to the investor class pushing for war, those who see war not as an abomination but as yet another opportunity to increase their bloated purse. What is our wealth compared to the billions spent on fighter jets, the $2.5 million spent on a single Tomahawk as it tears through a school full of little girls? What is our wealth compared to the mind-boggling quantities spent on the drones and satellites that make death as easy as clicking a button from the safety of a desk on the other side of the world? The same flick of a thumb can reduce a hospital to rubble or post a racist meme, often one right after the other. What is our wealth compared to the record-breaking $1.5 trillion requested for the military, a military that is already the richest on the planet ? Trump : “We have a virtually unlimited supply of these weapons. Wars can be fought ‘forever.’” So if money is influence, our relative influence has waned with the rise of the billionaire class. Woolf, recognizing the same, turns her attention instead to education. For if perhaps enough money cannot be mustered to prevent war, then learning—with its values of intellect and reason and enlightenment—may work in our favor, inasmuch as learning grows those faculties of reason, and reason is quite the antidote to the unreason of war. But again we find a problem. In Woolf’s time, while women have ostensibly been permitted into the colleges, they remain excluded from universities, and the women’s colleges are beggarly compared to those gleaming towers. Nor have women been permitted to adorn their names with the same letters and credentials that the men claim, a factor that keeps them from competing for the jobs that require them. It seems that the colleges are less places of learning than they are places of acquiring prestige, a prestige that is fiercely defended and protected, for prestige is a strangely fragile creature who can live only in scarcity and when exposed to too many of its own kind withers and dies like a tree choked by vines. And today? Well, women have torn down the gates to the universities, that much is clear. Women make up a majority of all college students in the US, and would be an even greater portion were it not for policies that directly work to balance the gender of student bodies . But that tearing down has been met by what can nearly be termed a war itself: a livid and indignant assault on places of learning from the men who want war, aiming at what has become the heart of the university, its beating and bloodied endowment. And the universities have, nearly to the letter, capitulated and retreated in the face of that assault, trading away centuries of purported intellectual freedom in order to protect the money needed to continue to operate, as if operating without that freedom was worth any money at all. Woolf writes: Is that not enough? Need we collect more facts from history and biography to prove our statement that all attempt to influence the young against war through education they receive at universities must be abandoned? For do they not prove that education, the finest education in the world, does not teach people to hate force, but to use it? Do they not prove that education, far from teaching the educated generosity and magnanimity, makes them on the contrary so anxious to keep their possessions, that “grandeur and power” of which the poet speaks, in their own hands, that they will use not force but much subtler methods than force when they are asked to share them? And are not force and possessiveness very closely connected with war? Woolf, Three Guineas , page 193 We see that same force and possessiveness in our own time: billions extorted from the universities, while the universities call in cops in riot gear —gear so named because when worn it inspires one to riot—to descend on students protesting genocide in Palestine. A great irony this would be, if irony were not the first casualty of war. For these brave students were met with war while exercising their right to protest the same, a right which past wars have been fought to defend but in which we seem to have retroactively declared defeat. Places of learning are always the first target of the fascist, because they are places that might counter the propaganda and pseudo-culture that leave us either pacified and accepting of their scraps or else fighting each other instead of fighting those who would start a war. Learning and thinking —a skill the billionaires are trying to supplant with machines that purport to think for us —are a challenge to the illogic and madness of war. To see an image of the broken bodies and broken buildings, to hear the testimony of those who lived, to have the skill and fortitude to ask how this could have happened, who benefits from such a horror, and how they might be stopped—for they must be stopped—is to exercise a lively mind and spirit, one capable of making the imaginative leap between the way things are and the way things ought to be. That interrogative and thinking mind is a threat to the fascist, who needs you to see things only as he does, who needs you unthinking and unquestioning, because only an unthinking and unquestioning mind could possibly accept the horrors of war. Only a mind so subdued by slop and propaganda and advertising, a mind unpracticed in observation and inquiry and imagination—only such a mind could be complacent as its pockets are picked to fund that most terrible of horrors. And so at last we turn to the workplace, as Woolf does, not in the hope that we might make enough money to counter the warmongers—for we have done the math, and no matter how hard we try, there is no chance of that—but because work is where we may, if we’re lucky, earn enough to keep a roof over our head and food in our belly, both of which are necessary to be able to think and act in the world. And we must be able to think, to remember that war is a horror, to resist being anesthetized by the memes and the vapid statements to violence. But here we find a curious contradiction: on the one hand, we are threatened with a lack of work , with our jobs taken over by machines who will never know that war is a horror, because they cannot know anything at all. On the other, high-pitched edicts that we must work so hard that there can be no time to think of anything else, no time to consider how these pictures of broken bodies and broken buildings came to be. ( Musk : workers “need to be ‘extremely hardcore,’ logging ‘long hours at high intensity.’”) How can both of these claims be true? How can the investor class simultaneously threaten us with no work, and, at the same time, threaten us with too much? It seems they fear equality more than hypocrisy. Perhaps we should also fear the disposition that the professions—which women fought so hard to enter, and now must fight so hard in which to stay—train us for. Here again is Woolf: And those opinions cause us to doubt and criticize and question the value of professional life—not its cash value; that is great; but its spiritual, its moral, its intellectual value. They make us of the opinion that if people are highly successful in their professions they lose their senses. Sight goes. They have no time to look at the pictures. Sound goes. They have no time to listen to music. Speech goes. They have no time for conversation. They lose their sense of proportion—the relations between one thing and another. Humanity goes. Money becomes so important they must work by night as well as by day. Health goes. And so competitive do they become that they will not share their work with others though they have more than they can do themselves. What then remains of a human being who has lost sight, and sound, and sense of proportion? Only a cripple in a cave. 6 Woolf, Three Guineas , page 258 It’s interesting to think with Woolf about our current march towards war, as the differences between her time and ours are revealing as much for what hasn’t changed. She wrote at a time when women were still largely excluded from professional work, from universities, from the armed forces. We read her today as women with one or more degrees, with careers, many of us carrying medals won in war zones and the scars to prove them, many of us with pips on our collar, credentials as long as those held by the men who guarded the libraries from the presence of women in Woolf’s time. But in both eras our presence in these places seems to have inspired an extraordinary, and extraordinarily violent, response. The assault against diversity programs is so out of proportion to those programs’ actual impact that we must admit something more elemental is going on: women’s presence in previously precluded spaces (and it is important to note that it is white women who have been the greatest benefactors of diversity initiatives, and Black and brown women who now suffer the greatest costs of their retreat) has inspired a level of violence among a small group of rich, insecure men that they will lay waste to the whole world before they will consider sharing their table with women as equals. Their own self-worth is so mean and spare that it withers when it comes into contact with those who do not bow and bend in their presence. The armed thugs marching through our streets, the speeches about force, force in our own cities, force elsewhere in the world, soldiers rechristened as “warfighters,” all of this is an assertion of manhood, a manhood reduced to nothing more than domination in all things, a masculinity that can see itself only in the violent oppression of others, whether that is other countries, other cultures, other races, other genders, or the more-than-human world. As Jamelle Bouie notes , “the vision of the world here is the vision of a rapist.” We are forced to conclude that to be in possession of a great deal of money, to be in a position of great authority, whether over an institution of learning or of government or of business, is to be in favor of war. The prestige and power that accompany both rank and great wealth—wealth which in our own day has grown so large as to be incomprehensible—also engender an instinct to possession and to the violent and disproportionate defense of that wealth. While we, who have neither great rank nor great wealth, know war to be an abomination, a horror through and through. Yet we can never hope to compete with the warmongers in either arms or cash, in prestige or status. So what are we to do? We must refuse to compete at all. We, with our empty hands , know it is right to mourn and lament the murder of many people. And so we mourn, and we lament, and we demand that our would-be leaders stop this incessant and evil warmaking. Are those demands enough? It would seem not. It would seem that despite great opposition to war , despite great risk to our economy, to our own safety as we shred our oldest and strongest alliances, that our demands for an end to war land on ears not deaf but blocked, stoppered with ego and greed and lust for domination in all its forms. And perhaps this should be no surprise. For why would a class of people so threatened by the mere presence of women in their schools and governments and workplaces ever open their ears to those women’s demands? Our speech must be a very great threat if they are so unwilling to hear it. So to speak against war is necessary—necessary for us to speak so with one another, so that we do not forget that war is a horror—yet insufficient. It is not enough to speak against war, for the warmongers, with their infinite money and infinite weapons, cannot hear us against the drums they so loudly bang for war. We must look elsewhere for the path that leads away from here. When Woolf was writing, women were precluded from the armed forces, and so could not refuse war by refusing to fight. We today are not subject to the same prohibition. We find ourselves among the ranks of soldiers both on our own soil and on many others. We have not earned the same respect, for many of our brothers seem to believe we have been put there solely for their use and abuse , and others—the same people who drive us to war, who claim no reason for war save war itself— work to exclude us once again . Yet women make up roughly a sixth of the armed forces , and perhaps as much of the forces in our streets. 7 Here is perhaps our greatest opportunity to halt the march to war. For we have it within our power to refuse to fight. We who know that war is a horror must refuse to raise a gun or fly a jet or steer a drone heavy with death into homes and hospitals and schools. We must refuse to go door to door in our own cities dragging people without warrant or reason into filthy, inhumane, and hastily built camps—for as sure as killing is a part of war, so too is gathering people up and locking them away. We must drop guns and kevlar and gas masks and walk away from the field of war, whether that field is distant from our homes or just down the street. We may look here to the courage of those like Ella Keidar Greenberg , an Israeli who, at 16 years of age, signed a pledge refusing to enlist in the military and was then, at 19, jailed for that refusal. “Refusal is the imperative,” she speaks, and we who have not plugged up our ears to reason and wisdom can yet hear her, and agree. For to make the horror of war with your own hands is to become a horror yourself. 8 This is easy to say for the great many of us who do not fight in war, who have not raised guns or donned armor or placed hands on keyboards and rained death on schools and hospitals from afar. But the imperative to refusal remains: we must refuse to lend our hands or minds to war, in whatever way we can. And so we must also refuse to work for war, to use our labor to make the technology of war, whether of weapons or of surveillance or of detention, whether that technology is used in our own streets or somewhere afar—for any technology used afar will come home soon enough, as we see with the militaries in our streets, outfit with cast offs from so many wars abroad. 9 We must not lend our hand to the making of guns or missiles or drones, of targeting systems or intelligence databases, of satellites that scour the planet for schools and hospitals, of algorithms that prescribe processes for murder, processes that promise to scrub their operators clean of the blood that follows but which will haunt them, nonetheless. Is this enough? It is not. For war is such an enormous undertaking—witness the trillions of dollars, an amount of money too big to think with—that it seeps into nearly every part of the economy. The same servers that summon servants to your door are used to surveil the people of Gaza; the same newspaper that brings details of the war to our eyes and ears also perpetuates a story that the greatest hardship of war is the price of gas at the pump. The same so-called AI that makes it easier to prototype a website is simultaneously being used to generate enormous quantities of racist and misogynist slop that treats war like a spectator sport. The same university that teaches the history of war also pays millions in bribes to the warmongers, while making a concerted effort to erase trans people from the very same history books. If we are truly committed to not working for war, we must not work for any of it. Not for the weapons manufacturers or the drone makers or the algorithm authors; not for the papers or the products or the schools. Perhaps you will think I am being too harsh. Perhaps you will say, but this is my only way of making a living, of keeping a roof over my head and my children’s heads, of feeding and clothing my loved ones. After all, we have also noted how our publics have been decimated by the very same men who push for war, men who have likewise colluded to raise prices on milk and eggs, who have transformed homes into commodities, such that we who had so little money compared to them seem every day to have less and less. Already our food pantries work overtime feeding the working poor, and we rightly fear every cough and tooth ache, every flutter of our overworked hearts or tiny lump beneath our skin, for medicine is increasingly a privilege reserved only for the rich. How could we refuse work under such conditions, when work is increasingly scarce? Here we must pause and again wonder at that scarcity. For it is a curious thing that work is becoming harder and harder to come by, that what work there is is often so poorly remunerated we must visit the pantries for bread at the end of the workday. Or, if it pays well, it does so under the constant threat that it could end at any moment, that it will end soon enough. Is it not the case that the men who loudly bang the drums for war, who build the technologies of surveillance that are used both to round people up and to aim missiles on their backs, who pollute our skies with satellites and insert themselves into the field of war as if they were heads of state themselves, states of ego and greed and impunity—are these not the selfsame men who declare we no longer need workers at all, that one machine can do the work of dozens? And do they not declare, out of the very same mouths, with the very same breaths, that those few workers who remain must work themselves to the bone, must work every waking hour they can, must eschew rest and play and leisure for the work is too great to put down for even a moment? And do they not also say—for as we have seen, those with more money have more speech, and seem ever to want us to hear them—that it is immigrants who are taking away all the jobs ? (A dog-ate-my-homework excuse, if there ever was one.) And meanwhile there is so much work that needs doing but isn’t being done: our schools overcrowded, our farms short-handed, our streets and bridges crumbling, our parks neglected, our clinics overrun, our laboratories empty. This is not to say that the scarcity isn’t real. It is real enough, as the lines at the food pantries attest. But it is manufactured ; it is built bolt by chip by screw by a billionaire class who want workers who complain neither of their warmongering nor of their whip. On the one hand, they threaten us with no work at all, with the misery and penury that comes from a lack of work, and therefore a lack of the means of living. On the other, they demand endless work, a work that wipes out all other avenues for thinking and being, that leaves us programmable and programmed, no space left in our minds for thoughts they haven’t placed there. Are we to merely acquiesce, to accept their scraps and the miserable conditions attached to them? Surely not. For if we accept these conditions, will they not impose even worse upon us? Will they not keep increasing their demands and decreasing our pay until we are working ceaselessly, and for nothing? What would compel them to stop? Already we have seen that their greed for money and for power is so voracious it will tear through buildings and through bodies, it will murder many people, it will poison the air and the soil, it will bring great storms upon us. So there must be an end, and it is only we who can bring that end about. So I say again we must refuse to work for war. But I do not wish you any hardship. If the only work available to you is the work of war, or work that has been perverted to the aim of war—and I am trusting that you have done your best to find other work, to make your living in a manner that does not end the lives of others—then there remain yet other avenues to take. Here you must gather with your colleagues and comrades, for the work against war is not solitary. You must first speak and be heard by each other, know that you are not alone in recognizing that war is an abomination, a great and terrible horror. For while speaking into the networks and the platforms is like speaking to the wind, your words tossed away from you before they can reach your own ears, we still have the ability to speak to our colleagues and to our neighbors, to speak unmediated and uncensored with each other. To speak with our mouths and with our hearts and with our lively, imaginative minds. To say, war is a horror, and I will not work for it, and are you with me? Can we speak together? Can we move and act against war hand in hand, and right here, where we stand? Here we see a great many of our kith and kin already stepping up. We can look to workers at Amazon , Google , Salesforce , and others who demand that their work not be used for surveillance, mass deportation, drone warfare, or genocide. We can look to the hundreds of workers at Thomson Reuters who raised alarms after learning that their company was selling data to ICE, prompting shareholders to demand an investigation . We can look to the community in Monterey Park, California , who successfully organized in favor of a ban on the construction of data centers—after noting that in addition to being polluting, noisy, energy guzzlers, such data centers also fuel ICE’s violence against their own neighbors. We can look to the Harvard graduate students currently on strike, whose demands include protections for international students at risk of deportation. We can look to the twenty-four attorneys general who have filed more than seventy lawsuits aimed at stopping the administration from waging war at home. And we can look to Luanne James, a librarian in Tennessee, who when asked to remove books from her library—books flagged for such transgressions as “female empowerment” and “following one’s dreams”—said, “ I will not comply. ” For is not censorship likewise a tool of war? Haven’t the book burners and the warmongers always been the same people, with the same aim? Are not slop and chatbots who care nothing for veracity the new tools for censorship—censorship by means of pollution rather than prohibition, but the ends are the same. James was subsequently fired for her dissent. 10 Refusal always invites consequences. But then so too does compliance, and often very grave consequences at that. Here we may heed the advice of the veteran scientists who resigned from the National Institutes of Health after it was gutted by the Trump administration. They implore , “Please decide where your red line is so you can choose to act before the line is already behind you.” There is risk here, of course. Organizing is, in theory at least, a protected activity and legally you may not be retaliated for it, but we have seen who the law protects and who it bends and breaks for and have no confidence in it protecting the likes of us. But there is risk no matter what we do or do not do. To be alive, to have a body vulnerable to gun and missile and chemical weapon, to famine and to thirst, to penury and hardship, is to be at risk; only the dead are relieved of the risk of harm. Your employer may punish you for organizing, but what is that risk compared to the risk of being complicit in war? The risk of knowing yourself to be someone who helped rain death on schoolchildren, who helped imprison your fellow workers in filthy detention camps, who helped program people’s minds to be numb to atrocity and horror? For you will know what you have done. Even if your daytime self can wrap you up in comforting excuses and justifications, can be lulled by the distractions and the advertisements and the television that anesthetizes your conscience, you will know it in the dark of the night. Our dreams know where we have gone wrong and they will never let us forget it. 11 But perhaps even this risk seems too great. You know your circumstances, and you know the ways the investor class has of keeping your head down. You cannot be fairly asked to put your own life, or your kin’s lives, on the line. And yet you are not without the ability to work against war, even in these difficult times. For you can work against war while seeming to work for it. Perform your work diplomatically while leaking information to the press, so that those on the outside who are safe from retaliation may organize in your stead. 12 Look for ways to gum up the works; raise concerns and questions and show where plans are short, where steps have not been thought out, where coordination is insufficient. Do not meet expectations but dash them, show them to be shortsighted or foolhardy, lacking sufficient detail; make those who set them doubt their own understanding of the world (as they try to sow doubt in you). They have made this easy on you, the warmongers and profiteers, by foisting unpredictable and inconstant machines upon you and mandating their use, by setting irrational milestones that could never have been met even by those who tried. Right there is a ready-made excuse for why the work could not be delivered as asked—your hands were tied. Do the work if you must, but do it dragging your feet, do it always on the lookout for ways to slow down the march to war and so give others the time to stop it. Does this gall you? It galls me. We ought not to have to spend our energy, what little and precious time we have on this earth, denigrating and diminishing our own skills. It is a violence to the self to do our work poorly. But against the alternative—against setting those same skills in the making of war—it seems a small sacrifice, and a necessary one. For it is not only your skill in, say, design or management or engineering that you may exercise. It is also the skill of refusal, the skill of refraining from making war in all its many and terrible forms. And that too is a kind of work, a good work, work that all of us can do. For there is one weapon that only we possess and which the billionaires and the warmongers can never take from us. One weapon which so frightens them they will twist their words into knots, they will spend the entirety of their vast fortunes trying and failing to convince us that we don’t possess it at all, they will claim over and over and without evidence that it is vanishing before our eyes even as it remains right there in our hands, clear and plain to hearts yet open to the world: the refusal to work. To refuse is a creative act. What is created in a refusal is a gap, a space, a moment in which something else makes ready to emerge, something that waits upon our invitation and a bit of water or sunlight to pop itself out and set down roots. To refuse is to create that which can only exist in the shade of that refusal, the refusal giving shelter to the choice that appears behind it. To refuse is to choose. In that choice, we find ourselves in the gap, in the place where no one has programmed our thinking, no one has told us what to do, no one has left any instructions or orders that we must follow. No one stands ready to answer our questions or to assign us tasks or to relieve the anxiety of being alive to uncertainty, for this has always and ever been the only way to be alive. In this gap is not one choice but many, a myriad of choices, for from here on out there can be no prescription, no map or plan or diagram. Only one step, and then the next. Yet we are not without skill or art. In fact, it is our art which is most at need here, our art that helps us imagine how things could be different, how we could work not for war but for peace, and for liberty, and for care for all our kin in all the kingdoms. How we could live with one another if prestige and missiles and extreme wealth were relegated to the history books, where they belong. It is our art, the art of painting or drawing or sculpting or dancing or making music or writing—and while all the arts are needed here, I will make a special plea for writing as that which so often gives us new worlds to think with—that we can think with the question of what we are to make with one another when we refuse to make war. For to refuse the work of war is to choose to see things as they really are, and as they yet could be. This is a choice we make most strongly when we make our art, when we bring our keen attention to the world and do not flinch from it, do not numb ourselves to it, but rather look at it squarely and know that however things are, they can—they will —be otherwise. What could our work become when it isn’t the work of death, of domination, of separation and detention and surveillance? What is our work when we give up seeking wealth and prestige—which no matter how hard we work, we can never have enough of? What is our work when we do not accede to orders from above but make choices with each other? What is our work when we see it not as a way to make a wage but a way to make more life , not only for ourselves, but for everyone? What becomes of our work if we work for the living? To refuse is an ending; an ending to our work being used to rend buildings and bodies, to massacre schoolchildren, to surveil and capture and detain. To refuse is a beginning. To turn away from the work of war is to turn toward the work of making a living world, work that does not answer to the billionaires, with their slavering, unending greed, but which only answers to each other. The gap that we create with our refusal is not void but potential, not emptiness in the sense of want but empty as a bowl or bag is empty, as an ear cocked to a speaker, a pair of hands cupped and raised to the roiling and darkening sky. From A Humanist View , a speech given at Portland State University in 1975. Quoted in Táíwò, Reconsidering Reparations , page 6. Táíwò adds, astutely, “Racism was only ever a smoke screen.” ↩︎ “[I]n pre-capitalist Europe, women’s subordination to men had been tempered by the fact that they had access to the commons and other communal assets, while in the new capitalist regime, women themselves became the commons, as their work was defined as a natural resource, laying outside the sphere of market relations.” Federici, Caliban and the Witch , page 97 ↩︎ For just some examples of these efforts, see Unbreaking’s explanations of the assaults on the federal workforce , medical research funding , and trans healthcare . ↩︎ Three Guineas , page 170. ↩︎ Ibid, page 404. ↩︎ This is clearly a reference to Plato’s cave, and the comparison hits a little harder in our own time: the shadows on the cave wall have been compressed to the mirrored screens we hold in our hands. ↩︎ A since-deleted page on the ICE website says that women made up 15% of law enforcement officers employed by ICE as of 2023 ( archive link ). That the page has been deleted perhaps says something about how little ICE cares for the women in its employ. ↩︎ The Center on Conscience and War reports that it has seen a 1,000% increase in US service members interested in becoming conscientious objectors since the start of the Iran war. Mike Prysner, the Center’s director says, “I haven’t heard from a single caller who said, ‘I’m scared of dying in a war I don’t believe in.’ All of them are scared of killing people in a war they don’t believe in.” ↩︎ Aimé Césaire termed this the “boomerang” effect . ↩︎ A legal defense fund has been set up to help James contest her termination. ↩︎ In The Third Reich of Dreams , Beradt reports that those who worked against the Nazis had dreams of fierce hope, while those who collaborated and capitulated were wrought by nightmares of terror and humiliation. ↩︎ The Freedom of the Press Foundation maintains some good advice on how to protect yourself while sharing information with the press—including the counsel to avoid visiting this link from a device your employer controls. ↩︎ View this post on the web , subscribe to the newsletter , or reply via email . From A Humanist View , a speech given at Portland State University in 1975. Quoted in Táíwò, Reconsidering Reparations , page 6. Táíwò adds, astutely, “Racism was only ever a smoke screen.” ↩︎ “[I]n pre-capitalist Europe, women’s subordination to men had been tempered by the fact that they had access to the commons and other communal assets, while in the new capitalist regime, women themselves became the commons, as their work was defined as a natural resource, laying outside the sphere of market relations.” Federici, Caliban and the Witch , page 97 ↩︎ For just some examples of these efforts, see Unbreaking’s explanations of the assaults on the federal workforce , medical research funding , and trans healthcare . ↩︎ Three Guineas , page 170. ↩︎ Ibid, page 404. ↩︎ This is clearly a reference to Plato’s cave, and the comparison hits a little harder in our own time: the shadows on the cave wall have been compressed to the mirrored screens we hold in our hands. ↩︎ A since-deleted page on the ICE website says that women made up 15% of law enforcement officers employed by ICE as of 2023 ( archive link ). That the page has been deleted perhaps says something about how little ICE cares for the women in its employ. ↩︎ The Center on Conscience and War reports that it has seen a 1,000% increase in US service members interested in becoming conscientious objectors since the start of the Iran war. Mike Prysner, the Center’s director says, “I haven’t heard from a single caller who said, ‘I’m scared of dying in a war I don’t believe in.’ All of them are scared of killing people in a war they don’t believe in.” ↩︎ Aimé Césaire termed this the “boomerang” effect . ↩︎ A legal defense fund has been set up to help James contest her termination. ↩︎ In The Third Reich of Dreams , Beradt reports that those who worked against the Nazis had dreams of fierce hope, while those who collaborated and capitulated were wrought by nightmares of terror and humiliation. ↩︎ The Freedom of the Press Foundation maintains some good advice on how to protect yourself while sharing information with the press—including the counsel to avoid visiting this link from a device your employer controls. ↩︎
In 2022, I created an open-source static blog generator: Bloggrify . It’s conceptually similar to Hugo —it generates a static site (just a bunch of HTML files) that you can host for free on Cloudflare, GitHub Pages, or Bunny.net . Before that, I had tried everything: WordPress, Joomla, Medium. I wanted to regain flexibility and customize my blog exactly how I wanted. But let’s be honest: I’m a developer, and I mainly wanted a new technical playground. Fast forward to 2026, and I have to admit: using a static blog has become a major friction point for my writing. So, I decided to migrate again, this time to a managed platform: Writizzy , another product I’m building. This move is a great opportunity to talk about several things: Bloggrify started as a love letter to the Nuxt ecosystem, specifically . Back when I migrated from WordPress, my criteria were simple: In 2022, it wasn't a "product" yet—just my personal blog code made public. It only became a full-fledged open-source project in 2024, with a dedicated site and a proper README to encourage contributions. I wanted the product to be "opinionated." Nuxt-content does 90% of the heavy lifting, but it’s a generic tool. For a real blog, you still need to build the RSS feed, sitemap, robots.txt, comments, table of contents, share buttons, newsletter integration, analytics, and SEO. That’s what Bloggrify is: a "starter pack" that comes with everything pre-configured. Think of it as Docus , but for blogs instead of documentation. I’m a numbers person. When I launch a project, I want to see usage. It might sound trivial, but considering the effort it takes to manage NPM releases (which is honestly a nightmare), handle versioning, and maintain themes, you expect a minimum return on investment. Bloggrify reached 164 stars on GitHub and sits somewhere in the middle of the pack on Jamstack.org . That’s... okay, I guess. But in reality, I have almost zero feedback on its actual usage. A few rare GitHub issues, one contributor who was active for a few weeks before vanishing, and then silence. I only know of one blog that used it before switching back to Hugo. The experience has been bittersweet. Building in the dark is demotivating. However, it did lead me to launch two other side-products: I launched Broadcast and Pulse in 2024 and 2025. They’re living a quiet life, but they aren't "exploding." My target audience is static bloggers—mostly developers. And as we know, developers are the hardest group to convince to pay for a service! Still, I’m satisfied. These products taught me how to build a SaaS, handle subscriptions, and find my ideal tech stack. My own newsletters were sent via Broadcast (reaching about 150 subscribers), and I used Pulse to track which articles were actually being read. The reality? These two tools generate about €100 in Monthly Recurring Revenue (MRR) . Not enough to retire on, but a great learning experience. And that brings us to Writizzy. With Bloggrify, I realized my writing workflow had become painful. Between maintaining the framework, jumping between spell-checkers, writing in Markdown, spinning up a local server to check for broken links, and waiting for build/deployment times... I was losing hours. For my last article, someone pointed out a few typos. It took me 20 minutes between editing the file and seeing the fix live. Add to that the friction of managing images in an IDE and the recent Nuxt 4 / Nuxt-content updates which, while I love them, have made the dev experience slightly slower for simple blogging. To be honest, I wasn't aware of that. I put up with these inconveniences and was still very happy to have “flexibility” in what I could do with my blog. I wasn't fully aware of this "friction" until I built Writizzy . Writizzy is the synthesis of my blogging experience. It’s a mix of Substack, Ghost, and Medium, but built as a European alternative with four core pillars: I moved my English blog to Writizzy first (this one), with no intention of moving the french one. But I soon noticed I was writing much faster on the English site. The workflow was just... better. Copy-pasting images directly into the editor, instant previews, no server to launch. It was a joy. I hesitated for a long time before migrating eventuallycoding.com . I knew that by doing so, I was taking the risk of killing Bloggrify. If even I don't use it anymore, the project enters a danger zone. When you don’t use your own product daily—when you’re no longer obsessed with the problem it solves—it’s almost impossible to stay attached to it. This is a symptom I see in so many "disposable" projects across the internet: built by people who flutter from one idea to the next without any real skin in the game. So yes, moving away from Bloggrify is a risk. But I’ve come to terms with it. Today, I have almost zero evidence that Bloggrify is being used. Meanwhile, Writizzy already has 314 blogs and 11 paying users (€135 MRR) in just four months. Why stubbornly cling to Bloggrify? Ultimately, I believe I’m solving the same problem with Writizzy, but in a much better way. I receive feedback emails and feature requests every single week. I get constant positive reinforcement from people actually using it. The product isn’t perfect, but it improves every day. It improves because real users are pushing me to refine the site, fix what’s broken, and add the features that absolutely need to be there. And it also improves because I use it constantly. This is the massive benefit of dogfooding . Every day, I am confronted with my own software, so I know exactly what needs to change. So yes, Bloggrify is moving to maintenance mode. I’m taking this opportunity to turn all templates into Open Source. Two of them were "premium," but it wouldn't make sense to keep them that way today. I tell myself I’ll still evolve it from time to time, but honestly, I wonder if I’m just lying to myself. As for Hakanai.io , I’m definitely continuing. The problem it solves still fascinates me. I get great feedback, especially on Broadcast. Pulse , however, suffers from being misunderstood. It’s a "blog analytics" product, and people don't really grasp what that entails—SEO advice, outlier detection, evergreen content tracking. I’m not great at marketing, so it mostly flies under the radar except for the readers of this blog who took the time to test it. But I’m motivated to keep them alive. As for Writizzy , there is no doubt. The product is incredibly exciting to build. The stakes are high: building a platform for expression that exists outside the US-centric giants. The traction is there, and the numbers follow (+45% MoM user growth). Welcome to this blog, now officially on Writizzy. As a reader, you can already test several things: The Discover feed to read other articles from Writizzy bloggers. We’ve handpicked a few to start with, and this feed will become even more customizable in the future. Welcome home. Dogfooding: Why you absolutely must use your own products. The harsh reality of Open Source: Why it’s harder than it looks. Product Satisfaction: The joy of building something people actually use. The future of my projects: Bloggrify, Writizzy, and Hakanai.io . A simple templating language (Markdown). Extensibility (RSS feeds, sitemaps, etc.). Low carbon footprint (static sites are incredibly efficient). broadcast.hakanai.io : A newsletter system for static blogs based on RSS feeds. pulse.hakanai.io : A specialized analytics tool for bloggers (not just generic web traffic). Sustainability : Focusing on reversibility and interoperability. Discoverability. Economic accessibility : Implementing Purchasing Power Parity (PPP). Transparency. The comments section . The newsletter subscription (if you haven’t already).
Space exploration demands software that is reliable, efficient, and able to operate in the harshest environments imaginable. When a spacecraft deploys a solar sail millions of kilometers from Earth, there’s no room for memory bugs, race conditions, or software failures. This is where Rust’s robustness guarantees become mission-critical. In this episode, we speak with Sebastian Scholz, an engineer at Gama Space, a French company pioneering solar sail and drag sail technology for spacecraft propulsion and deorbiting. We explore how Rust is being used in aerospace applications, the unique challenges of developing software for space systems, and what it takes to build reliable embedded systems that operate beyond Earth’s atmosphere. CodeCrafters helps you become proficient in Rust by building real-world, production-grade projects. Learn hands-on by creating your own shell, HTTP server, Redis, Kafka, Git, SQLite, or DNS service from scratch. Start for free today and enjoy 40% off any paid plan by using this link . Gama Space is a French aerospace company founded in 2020 and headquartered in Ivry-sur-Seine, France. The company develops space propulsion and orbital technologies with a mission to keep space accessible. Their two main product lines are solar sails for deep space exploration using the sun’s infinite energy, and drag sails—the most effective way to deorbit satellites and combat space debris. After just two years of R&D, Gama successfully launched their satellite on a SpaceX Falcon 9. The Gama Alpha mission is a 6U cubesat weighing just 11 kilograms that deploys a large 73.3m² sail. With 48 employees, Gama is at the forefront of making space exploration more sustainable and accessible. Sebastian Scholz is an engineer at Gama Space, where he works on developing software systems for spacecraft propulsion technology. His work involves building reliable, safety-critical embedded systems that must operate flawlessly in the extreme conditions of space. Sebastian brings expertise in systems programming and embedded development to one of the most demanding environments for software engineering. GAMA-ALPHA - The demonstration satellite launched in January 2023 Ada - Safety-focused programming language used in aerospace probe-rs - Embedded debugging toolkit for Rust hyper - Fast and correct HTTP implementation for Rust Flutter - Google’s UI toolkit for cross-platform development UART - Very common low level communication protocol Hamming Codes - Error correction used to correct bit flips Rexus/Bexus - European project for sub-orbital experiments by students Embassy - The EMBedded ASsYnchronous framework CSP - The Cubesat Space Protocol std::num::NonZero - A number in Rust that can’t be 0 std::ffi::CString - A null-byte terminated String Rust in Production: KSAT - Our episode with Vegard about using Rust for Ground Station operations Rust in Production: Oxide - Our episode with Steve, mentioning Hubris Hubris - Oxide’s embedded operating system ZeroCopy - Transmute data in-place without allocations std::mem::transmute - Unsafe function to treat a memory section as a different type than before Gama Space Website Gama Space on LinkedIn Gama Space on Crunchbase
Hi, I’m Michael. I’m a software developer and founder of small, indie tech businesses. I’m currently working on a book called Refactoring English: Effective Writing for Software Developers . Every month, I publish a retrospective like this one to share how things are going with my book and my professional life overall. At the start of each month, I declare what I’d like to accomplish. Here’s how I did against those goals: The blog post was a risky bet because it only could reach new readers if it hit the front page of Hacker News, and its only chance of that is the first couple weeks of 2026. Fortunately, the post reached #1 on Hacker News and remained on the front page for almost 22 hours. It continues my strategy of highlighting other successful tech writers , a strategy I like because it feels like a win-win for me, readers, and the writers I showcase. I still have the Hacker News prediction game at about 80% complete. I’m not sure what to do with it because it’s almost done, but I feel like it’s not fun, so I’m never motivated to complete it. But I want to get it over the finish line to see what people think. Ironically, the chapters I’m working on are about motivation and focus, but I keep letting my experiments with MeshCore interfere with my writing. I’ve been better at maintaining focus in the new year, and distractions are actually helpful because I’m getting fresh experience to write about regaining focus. Again, I got distracted by MeshCore experiments in December and didn’t make as much progress as I wanted. I love design docs and find them helpful but they’re also incredibly boring to write, so it was always tempting to shelve the design doc for something with more instant gratification. Pre-sales are down because I didn’t have any new posts to attract new readers (I didn’t publish the Hacker News post until January). Still, it’s a positive sign that my “passive sales” continue to grow. In December, I had almost $500 in pre-sales. If I compare that to months with similar website visitors, May had only $241 in pre-sales, and August had $361, so the numbers are trending up. I hope that as the book grows more complete and more readers recommend it, the passive sales continue to rise without relying on me finding a successful marketing push each month. When I ran my Black Friday promotion in November, a reader emailed to say that 30% off (US$20) is still an unaffordable price in Argentina for a book. He asked if I’d consider regional pricing. He mentioned that Steam games are typically priced 50% lower in Argentina than the US, so I figured that was a good anchor. I collect payments through Stripe, and I couldn’t find any option for regional pricing in my Stripe dashboard. I found an article in Stripe’s knowledge base called “Geographic pricing in practice: Why it matters and how to implement it.” I was delighted until I read the entire article and discovered they’d forgotten to write the “and how to implement it” part. So, Stripe advocates for regional pricing, but they don’t actually offer it as an option. It was a helpful reminder that Stripe is the worst payment processor except for all those other payment processors . So, for my Argentinian customer, I used a one-off process where I manually created a custom payment link for him at a discounted price. And when I went through the process, I realized I could set the price in Argentine pesos so he wouldn’t have to pay a currency conversion fee. I set the price to 22,000 ARS (about US$15), and he seemed happy with the price and the checkout experience. The reader suggested I publicly offer regional pricing, at least for countries like Brazil and India, which have high numbers of developers but relatively low purchasing power. Even without native Stripe support for regional pricing, it seemed like it wouldn’t be that hard to automate the thing I did manually. I read about Sebastien Castiel implementing regional pricing for his course, which led me to Wes Bos’ post about the same thing . Sebastien shared a lot of technical details, but his solution was heavy on React, whereas my site is vanilla HTML and JavaScript. He also relied on discount codes, which I don’t like because it means most customers see that there’s a special deal they’re not getting. I spent a few hours implementing a solution using a cloud function that determines the right price on the fly and dynamically creates a Stripe checkout link. Then, I realized I could precompute everything and eliminate the need for server-side logic, so I deleted my cloud function. My implementation looks like this: The user just picks their country and it activates the Stripe purchase link for that country, and they pay in their own currency. I’m going by the honor system, so I don’t bother with IP geolocation or VPN prevention. I do hide the discount for each country to discourage people from picking the cheapest option. And part of the benefit of pricing in each country’s local currency is that if someone cheats and picks a region that’s not really their home currency, they lose some money in conversion fees. The numbers feel not quite correct. According to strict PPP, the equivalent of $30 in the US is $4 in Egypt, but I suspect you can’t really buy non-bootleg books for programmers in Egypt for $4. When Wes Bos did this, he just asked his readers to tell him fair prices, so I’ll try that too. Leave a comment or email me the normal price range for developer-oriented books in your country. In December, I published “My First Impressions of MeshCore Off-Grid Messaging.” I was excited about the technology but disappointed to discover that the clients are all closed-source . At that point, I decided to pause my exploration of MeshCore, but Frieder Schrempf , a MeshCore contributor, replied to my post with this interesting perspective : I share a lot of your thoughts on this topic. Personally I see the value of MeshCore in the protocol and not so much in the software implementations of the firmware, apps, etc. […] If MeshCore as a protocol succeeds and gets widely used (currently it looks like it does) then properly maintained open-source implementations will follow (at least I hope). I agreed with Frieder and thought, “Maybe I should just write a proof of concept open-source MeshCore app?” Actually, there already was a proof of concept MeshCore app. Liam Cottle, the developer of the official MeshCore app, previously wrote a web app for MeshCore as a prototype for the official version. He deprecated it when he made the official (proprietary) MeshCore app, but the source code for his prototype was still available, and the prototype had most of the features I needed. I wondered how difficult it would be to port the prototype to mobile. MeshCore is too hard to use as a web app, as it requires Bluetooth access and offline mode. I’ve heard somewhat positive things about Flutter , Google’s solution for cross-platform mobile development. I suspected that an LLM could successfully port the code from the web prototype to Flutter without much intervention from me. My plan was to have an LLM create a Flutter port of the prototype in three stages: That worked, but every step was clunkier than I anticipated: I thought it would be a quick weekend project I could whip together in a few hours. 30 hours and $200 in LLM credits later, I finally got it working. Running my MeshCore Flutter app on a real Android device But the day I got my Flutter implementation to feature parity with the prototype, I went to share it on Reddit and saw someone had just shared meshcore-open , a MeshCore client implementation in Flutter. It was the same idea I had but with far better execution. I was disappointed someone beat me to the punch, but I was also relieved. From my brief experience working with Flutter, I was eager to get away from Flutter as quickly as possible. I only wanted to make a proof of concept hoping someone else would pick it up, so I’m happy that there’s now an open-source, feature-rich MeshCore client implementation. While working on my MeshCore Flutter app, I had to implement low-level logic to parse MeshCore device-to-client messages. There’s a public spec that defines MeshCore’s peer-to-peer protocol, and even that’s fairly loose. But there’s another undocumented protocol for how a device running MeshCore firmware communicates with a companion client (e.g., an Android app) over Bluetooth or USB. The de facto reference implementation is the MeshCore firmware , but it intermingles peer-to-peer protocol logic with device-to-client protocol logic and UI logic, and it spreads the implementation across disparate places in the codebase. For example, a MeshCore client can fetch a list of contacts from a MeshCore device over Bluetooth, but it has to deserialize the raw bytes back into contacts. There’s no library for decoding the message, so each MeshCore client and library is rolling their own separate implementation: What I notice about those implementations: My first thought was to rewrite the logic using a protocol library like protobuf or Cap’n Proto , but I don’t see a backwards-compatible way of integrating a third-party library at this point. So, what if I wrote a core implementation of the MeshCore device-to-client protocol in C? I could add language-specific bindings so that we don’t need whole separate implementations for Dart, Python, JavaScript, and any other language you’d want to write in. So, I started my own MeshCore client library: The library is not ready to demo as a proof of concept, but it’s close. It’s entirely possible the MeshCore maintainers won’t like this idea, and it’s basically dead in the water without their buy-in. But I did it anyway because I’d never tried writing a cross-language library, and that was an interesting experience. The last time I tried to call C code from Python was 20 years ago, and I had to use SWIG . Back then, it felt painful and hacky, and it seems to have gotten 80% better. I desperately wanted the core implementation to be Zig rather than C, but I saw too many blockers: Is $30 (USD) for a developer-oriented book expensive where you live? If so, let me know what you’d expect to pay for a programming book like Designing Data-Intensive Applications in your country (in local currency). I added regional pricing for my book based on purchasing power parity. I created my first Flutter app. I’m writing my first cross-language library. Result : Published “The Most Popular Blogs of Hacker News in 2025” instead Result : Made progress on two chapters but didn’t complete them Result : Got 80% through a design doc draft Manually get a list of all countries / currencies that Stripe supports. Write a script that pulls data from the World Bank to calculate the purchasing power parity (PPP) for each country in the list. Calculate each country’s discount based on their purchasing power relative to the US. e.g., the PPP of Brazil is 54% lower than the US, so they get a 54% discount. Filter out countries where the PPP is within 15% of the US (too small a discount to bother). Filter out countries where the discount would be negative. Otherwise, customers in Luxembourg would have to pay double . Limit the discount to a maximum of 75% Otherwise the price in Egypt would be US$4, meaning I’d get like $3.50 after conversion fees. Automatically generate country-specific Stripe price objects and Stripe payment links for each country remaining in the list. Put all the countries in an HTML dropdown on my site: Write end-to-end tests for the prototype web app using Playwright. Port the prototype implementation to a Flutter web app, keeping the end-to-end tests constant to ensure feature parity. Add an Android build to the Flutter project. Before I could write end-to-end tests for the prototype, I had to convert it to use semantic HTML and ARIA attributes because a lot of the input labels were just bare s. I couldn’t keep the Playwright tests constant because Flutter actually doesn’t emit semantic HTML for web apps. It creates its own Flutter-specific HTML dialect and draws everything on an HTML canvas. Most Playwright element locators still work somehow, but I had to make a lot of Flutter-specific changes to the tests. It took a long time, even with an LLM, to figure out how to build an Android package with Flutter. Gradle, Android’s build system, is buggy on NixOS. I kept running into situations where it was failing with mysterious errors that eventually turned out to be stale data it had cached in my home directory. Flutter makes it surprisingly difficult to communicate over Bluetooth. On the web (at least on Chrome), you essentially get it for free by calling , but with Flutter, you have to use a proprietary third-party library and roll your own device picker UI. meshcore.js (JavaScript) meshcore-open (Dart) meshcore_py (Python) They have to use magic numbers like rather than referring to constants defined in some authoritative location. None of them have automated tests for their parsers. They’re dragging unnecessary low-level work into high-level languages. For example, everyone is storing and variables. That’s an artifact of the C implementation, where arrays don’t know their size. You don’t have to manually track an array’s size in languages like JavaScript, Python, or Dart. They don’t check data carefully, so they’ll happily pass on garbage data like a negative path length or GPS coordinates that are outside of Earth’s bounds. They all ignore the flags field even though the flags are supposed to indicate which fields are populated . Or at least they’re supposed to in the peer-to-peer messages. For device-to-client messages, they seem to be meaningless. https://codeberg.org/mtlynch/libmeshcore-client Zig does not yet compile to xtensa architecture, which most of the MeshCore devices use. PlatformIO, which most of the MeshCore firmware projects use, does not support Zig. Dart’s ffigen would maybe work with Zig since Zig supports C’s ABI, but it was hard even getting it to work with C. Ditto for Python’s cffi . I got most of the way through writing two new chapters of Refactoring English . I got most of the way through writing the design doc for my photo sharing app idea. I published “The Most Popular Blogs of Hacker News in 2025.” I created my first Flutter app . I created my first cross-language library . I made some contributions to MeshCore meshcore.js . Most of which, the maintainers are ignoring. Minimize in-flight projects AI makes it easier than ever to start new projects, but I’m still the bottleneck on turning them into something production-ready. The result is that I have a lot of projects that are in-flight and waiting for me to review them before I publish them. There’s mental overhead in so much context-switching and task tracking. Publish three chapters of Refactoring English . Publish my 2025 annual review (year 8).
In 1984, Gary Kildall and Stewart Chiefet covered "The Fifth Generation" of computing and spoke with Edward Feigenbaum, the father of "expert systems." Kildall started the show saying AI/expert systems/knowledge-based systems (it's all referred to interchangeably) represented a "quantum leap" in computing. "It's one of the most promising new softwares we see coming over the horizon." One year later, Kildall seemed pretty much over the whole AI scene. In an episode on "Artificial Intelligence" he did nothing to hide his fatigue from the guests, "AI is one of those things that people are pinning to their products now to make them fancier and to make them sell better." He pushed back hard against the claims of the guests, and seemed less-than-impressed with an expert system demonstration. The software makers of those "expert systems" begged to differ. There is a fundamental programmatic difference in the implementation of expert systems which enables a radical reinterpretation of existing data, they argued. Guest Dr. Hubert Dreyfus re-begged to re-differ, suggesting it should really be called a "competent system." Rules-based approaches can only get you about 85% of the way toward expertise; it is intuition which separates man from machine, he posited. I doubt Dreyfus would have placed as high as 85% competence on a Commodore 64. The creator of XPER , Dr. Jacques Lebbe, was undeterred, putting what he knew of mushrooms into it to democratize his knowledge. XPER , he reasoned, could do the same for other schools of knowledge even on humble hardware. So, just how much expertise can one cram into 64K anyway? So, what is an "expert system" precisely? According to Edward Feigenbaum, creator of the first expert system DENDRAL, in his book The Fifth Generation: Artificial Intelligence and Japan's Computer Challenge to the World , "It is a computer program that has built into it the knowledge and capability that will allow it to operate at the expert's level. (It is) a high-level intellectual support for the human expert." That's a little vauge, and verges on over-promising. Let's read on. "Expert systems operate particularly well where the thinking is mostly reasoning, not calculating - and that means most of the world's work." Now he's definitely over-promising. After going through the examples of expert systems in use, it boils down to a system which can handle combinatorial decision trees efficiently. Let's look at an example. A doctor is evaluating a patient's symptoms. A way to visualize her thought process for a diagnosis might take the below form. An expert system says, "That looks like a simple decision tree. I happen to know someone who specializes in things like that, hint hint." XPER is a general-purpose tool for building such a tree from expert knowledge, carrying the subtle implication (hope? prayer?) that some ephemeral quality of the decision making process might also be captured as a result. Once the tree is captured, it is untethered from the human expert and can be used by anyone. XPER claims you can use it to build lots of interesting things. It was created to catalog mushrooms, but maybe you want to build a toy. How about a study tool for your children? Let's go for broke and predict the stock market! All are possible , though I'm going to get ahead of your question and say one of those is improbable . I have a couple of specific goals this time. First, the tutorial is a must-do, just look at this help menu. This is the program trying to HELP ME . After I get my head around that alphabet soup, I want to build a weather predictor. The manual explicitly states it as a use case and by gum I'ma gonna do it. I'm hoping that facts like, "Corns ache something intolerable today" and "Hip making that popping sound again" can factor into the prediction at some point. First things first, what does this program do? I don't mean in the high-level, advertising slogan sense, I mean "What specific data am I creating and manipulating with XPER ?" It claims "knowledge" but obviously human knowledge will need to be molded into XPER knowledge somehow. Presently, we don't speak the same language. XPER asks us to break our knowledge down into three discrete categories, with the following relationships of object, feature, and attribute: My Gen-X BS alarm is ringing that something's not fully formed with this method for defining knowledge. Can everything I know really be broken down into three meager components and simple evaluations of their qualities? Defining objects happens in a different order than querying, which makes it a little fuzzy to understand how the two relate. While we define objects as collections of attributes, when querying against attributes to uncover matching objects. The program is well-suited to taxonomic identification. Objects like mushrooms and felines have well-defined, observable attributes that can be cleanly listed. A user of the system could later go through attribute lists to evaluate, "If a feline is over 100kg , has stripes , and climbs trees which feline might it be?" For a weather predictor, I find it difficult to determine what objects I should define. My initial thought was to model "a rainy day" but that isn't predictive. What I really want is to be able to identify characteristics which lead into rainy days. "Tomorrow's rain" is an attribute on today's weather, I have naively decided. This is getting at the heart of what XPER is all about; it is a vessel to hold data points. Choosing those data points is the real work, and XPER has nothing to offer the process. This is where the manual really lets us down. In the Superbase 64 article, I noted how the manual fails by not explaining how to transition from the "old way" to the "new way" of data cataloging. For a program which suggests building toys from it, the XPER manual doesn't provide even a modicum of help in understanding how to translate my goals into XPER objects. The on-disk tutorial database of "felines" shows how neatly concepts like "cat identification" fit into XPER framing. Objects are specific felines like "jaguar," "panther," "mountain lion." Features suggest measureable qualities like "weight," "tree climbing," "fur appearance," "habitat" etc. Attributes get more specific, as "over 75kg," "yes," "striped," and "jungle." For the weather predictor, the categories of data are similarly precise. "cloud coverage," "temperature," "barometer reading," "precipitation," "time of year," "location," and so forth may serve our model. Notice that for felines we could only define rough ranges like "over 75kg" and not an exact value. We cannot set a specific weight and ask for "all cats over some value." XPER contains no tools for "fuzzy" evaluations and there is no way to input continuous data. Let's look at the barometer reading, as an example. Barometer data is hourly, meaning 24 values per day. How do I convert that into a fixed value for XPER ? To accurately enter 24 hours of data, I would need to set up hourly barometer features and assign 30? 50? possible attributes for the barometer reading. Should we do the same for temperature? Another 24 features, each with 30 or more attributes, one per degree change? Precipitation? Cloud coverage? Wind speed and direction? Adorableness of feline? Besides the fact that creating a list of every possible barometric reading would be a ridiculous waste of time, it's not even possible in the software. A project is limited to We must think deeply about what data is important to our problem, and I'd say that not even the expert whose knowledge is being captured would know precisely how to structure XPER for maximum accuracy. The Fifth Generation warns us: "GiT GuD" as the kids say. ( Do they still say that?! ) The graphic above, output by XPER 's "Printer" module, reveals the underlying data structure of the program. Its model of the data is called a "frame," a flat 2-D graph where objects and attributes collide. That's it. Kind of anticlimactic I suppose, but it imbues our data with tricks our friend Superbase can't perform. First, this lets us query the data in human-relatable terms, as a kind of Q&A session with an expert. "Is it a mammal?" "Does it have striped fur?" "Does it go crazy when a laser pointer shines at a spot on the floor?" Through a session, the user is guided toward an object, by process of elimination, which matches all known criteria, if one exists. Second, we can set up the database to exclude certain questions depending upon previous answers. "What kind of fur does it have?" is irrelevant if we told it the animal is a fish, and features can be set up to have such dependencies. This is called a father/son relationship in the program, and also a parent/child relationship in the manual. "fur depends on being a mammal," put simply. Third, we can do reverse queries to extract new understandings which aren't immediately evident. In the feline example it isn't self-evident, but can be extracted, that "all African felines which climb trees have retractile claws." For the weather predictor I hope to see if "days preceding a rainy day" share common attributes. The biggest frustration with the system is how all knowledge is boxed into the frame. For the weather predictor, this is frustrating. With zero relationship between data points, trends cannot be identified. Questions which examine change over time are not possible, just "Does an object have an attribute, yes or no?" To simulate continuous data, I need to pre-bake trends of interest into each object's attributes. For example, I know the average barometric pressure for a given day, but because XPER can't evaluate prior data, it can't evalute if the pressure is rising or falling. Since it can't determine this for itself, I must encode that as a feature like "Barometric Trend" with attributes "Rising," "No Change," and "Falling." The more I think about the coarseness with which I am forced to represent my data, the more clear it is to me how much is being lost with each decision. That 85/15 competency is looking more like 15/85 the other direction. Collecting data for the weather predictor isn't too difficult. I'm using https://open-meteo.com to pull a spreadsheet on one month of data. I'll coalesce hourly readings, like barometric pressure, into average daily values. Temperature will be a simple "min" and "max" for the day. Precipitation will be represented as the sum of all precipitation for the day. And so on. As a professional not-a-weather-forecaster, I'm pulling whatever data strikes me as "interesting." In the spirit of transparency, I mentally abandoned the "expert" part of "expert system" pretty early on. This guy *points at self with thumbs* ain't no expert. Having somewhat hippy-dippy parents, I've decided that Mother Earth holds secrets which elude casual human observation. To that end, I'm including "soil temperature (0 - 7cm)" as a data point, along with cloud coverage, and relative humidity to round out my data for both systematic and "I can't spend months of my life on this project" reasons. After collecting November data for checkpoint years 2020, 2022, and 2024, actually entering the data is easier than expected. XPER provides useful F-Key shortcuts which let me step through objects and features swiftly. What I thought would take days to input wound up only being a full afternoon. Deciding which data I want, collecting it, and preparing it for input was the actual work, which makes sense. Entering data is easy; becoming the expert is hard. Even as I enter the data, I catch fleeting glimpses of patterns emerging and they're not good. It's an interesting phenomenon, having utterly foreign data start to feel familiar. Occasionally I accidentally correctly predict if the next day's weather has rain. Am I picking up on some subliminal pattern? If so, might XPER "see" what I'm seeing? I'm not getting my hopes up, but I wonder if early fascination with these forays into AI was driven by a similar feeling of possibility? We're putting information into a system and legimitately not knowing what will come out of the processing. There is a strong sense of anticipation; a powerful gravity to this work. It is easy to fool myself into believing I'm unlocking a cheat code to the universe. Compare this to modern day events if you feel so inclined. At the same time, there's obviously not enough substance to this restricted data subset. As I enter that soil temperature data, 90% of the values keep falling into the same bin. My brainstorm for this was too clever by half, and wrong. As well, as I enter data I find sometimes that I'm entering exactly the same information twice in a row, but the weather results are different enough as to make me pause. Expert systems have a concept of "discriminating" and "non-discriminating" features. If a given data point for every object in a group of non-eliminated objects is the same, that data point is said to be "non-discriminating." In other words, "it don't matter" and will be skipped by XPER during further queries. The question then is, whose fault is this? Did I define my data attributes incorrectly for this data point or is the data itself dumb? I can only shrug, "Hey, I just work here." XPER has a bit of a split personality. Consider how a new dataset is created. From the main menu, enter the Editor. From there you have four options. First, I go to option for the seemingly redundantly named "Initializing Creating." Then I set up any features, attributes, and objects I know about, return to this screen, and save with option . Later I want to create new objects. I type for "Creating" and am asked, "Are you sure y/n" Am I sure ? Am I sure about what ? I don't follow, but yes, I am sure I want to create some objects. I hit and I'm back at a blank screen, my data wiped. That word "initializing" is doing the heavy lifting on this menu. "Initialize" means "first time setup of a dataset," which also allows, almost as a side effect, the user an opportunity to input whatever data happens to be known at that moment . "Initial Creation" might be more accurate? Later, when you want to add more data, that means you now want to edit your data, called "revising" in XPER , and that means option . Option is only ever used the very first time you start a new data set. is for every time you append/delete afterward. The prompts and UI are unfortunately obtuse and unhelpful. "Are you sure y/n" is too vague to make an informed decision. The program would benefit greatly from a status bar displaying the name of the current in-memory dataset, if it has been saved or not, and a hint on how close we are to the database limit. Prompts should be far more verbose, explaining intent and consequence. A status bar showing the current data set would be especially useful because of the other weird quirk of the program: how often it dumps data to load in a new part of the program. XPER is four independent programs bound together by a central menu. Entering a new area of the program means effectively loading a new program entirely, which requires its own separate data load. If you see the prompt "Are you sure y/n" what it really means is, "Are you sure you want me to forget your data because the next screen you go to will not preserve it. y/n" That's wordy, but honest. With that lesson learned, I'm adding three more data points to the weather predictor: temperature trend, barometric trend, and vapor pressure deficit (another "gut feeling" choice on my part). Trends should make up a little for the lack of continuous data. This will give me a small thread of data which leads into a given day, the data for that day, and a little data leading out into the next day. That fuzzes up the boundaries. It feels right, at the very least. Appending the new information is easy and painless. Before, I used F3/F4 to step through all features of a given object. This time I'm using F5/F6 to step through a single feature across all objects. This only took about fifteen minutes. I'm firmly in "manual memory management" territory with this generation of hardware. Let's see where we sit relative to the maximum potential. Features like this really makes one appreciate the simple things in life like a mouse, gui checklists, and simple grouping mechanisms. XPER can compare objects or groups of objects against one another, identifying elements which are unique to one group or the other. You get two groups, full stop. Items in those groups and only those groups will be compared when using the command. We can put objects individually into one of those two groups, or we can create an object definition and request that "all objects matching this definition go into group 1 or 2". This is called a STAR object. I created two star objects: one with tomorrow's weather as rain, and one with tomorrow's weather as every type except rain. Groups were insta-built with the simple command where means and means , my "rainy day" star object. I can ask for an AND or OR comparison between the two groups, and with any luck some attribute will be highlighted (invert text) or marked (with ) as being unique or exclusive to one group or the other. If we find something, we've unlocked the secret to rain prediction! Take THAT, Cobra Commander ! Contrary to decades of well-practiced Gen-X cynicism, I do feel a tiny flutter of "hope" in my stomach. Let's see what the XPER analysis reveals! The only thing unique between rainy days and not is the fact that it rained. The Jaccard Distance , developed by Grove Karl Gilbert in 1884, is a measure of the similiarity/diversity between two sets (as in "set theory" sets). The shorter the distance, the more "similar" the compared sets are. XPER can measure this distance between objects. where is the object ID of interest, will run a distance check of that object against all other objects. On my weather set with about 90 objects, it took one minute to compare Nov. 1, 2020 with all other days at 100% C64 speed. Not bad! What can we squeeze out of this thing? By switching into "Inquirer" mode, then loading up the data set of interest, a list of top level object features are presented. Any features not masked by a parent feature are "in the running" as possible filters to narrow down our data. So, we start by entering what we know about our target subject. One by one, we fill in information by selecting a feature then selecting the attribute(s) of that feature, and the database updates its internal state, quietly eliminating objects which fall outside our inquiry. The command will look at the "remaining objects," meaning "objects which have not yet been eliminated by our inquiry so far." With the command as in to run it against the "jaguar" we can ask XPER to tell us which features, in order, should we answer to narrrow down to the jaguar as quickly as possible. It's kind of ranking the features in order of importance to that specific object. It sounds a bit like feature weighting , but it's definitely not. XPER isn't anywhere close to that level of sophistication. In this data set, if I answer "big" for "prey size" I immediately zero in on the jaguar, it being the currently most-discriminating feature for that feline. You might be looking at this and wondering how, exactly, this could possibly predict the weather. You and me, both, buddy. The promise of Fifth Gen systems and the reality are colliding pretty hard now. Feigenbaum and "The Fifth Generation" have been mentioned a few times so far, so I should explain that a little. Announced in 1981, started in 1982, and lasting a little more than a decade, "The Fifth Generation" of computing was Japan's moniker for an ambitious nationwide initiative. According to the report of Japan's announcement, Fifth Generation Computer Systems : Proceedings of the International Conference on Fifth Generation Computer Systems, Tokyo, Japan, October 19-22, 1981, Japan had four goals: In Fifth Generation Computers: Concepts, Implementation, and Uses (1986), Peter Bishop wrote, "The impact on those attending the conference was similar to that of the launch of the Soviet Sputnik in 1957." During a hearing before the Committee on Science and Technology in 1981, Representative Margaret Heckler said , "When the Soviets launched Sputnik I, a remarkable engineering accomplishment, the United States rose to the challenge with new dedication to science and technology. Today, our technology lead is again being challenged, not just by the Soviet Union, but by Japan, West Germany, and others." Scott Armstrong writing for The Christian Science Monitor in 1983, in an article titled, "Fuchi - Japan's computer guru" said, "The debate now - one bound to intensify in the future - is whether the US needs a post-Sputnik-like effort to counter the Japanese challenge. Japan's motive (reflects) a sense of nationalism as much as any economic drive." Innovation Policies for the 21st Century: Report of a Symposium (2007) remarked of Japan's Fifth Generation inroads into supercomputers, "This occasioned some alarm in the United States, particularly within the military." It would be fair to say there was "Concern," with a capital C. In 1989's The Fifth Generation: The Future of Computer Technology by Jeffrey Hsu and Joseph Kusnan (separate from Feigenbaum's The Fifth Generation ) said Japan had three research projects The "Fifth Generation" was specifically the software side which the conference claimed, "will be knowledge information processing systems based on innovative theories and technologies that can offer the advanced functions expected to be required in the 1990's overcoming the technical limitations inherent in conventional computers." Expert systems played a huge role during the AI boom of the 80s, possibly by distancing itself from "AI" as a concept, focusing instead on far more plausible goals. It's adjacent to, but isn't really, "artificial intelligence." This Google N-Gram chart shows how "expert system" had more traction than the ill-defined "artificial intelligence." Though they do contain interesting heuristics, there is no "intelligence" in an expert system. Even the state of the art demonstrated on Computer Chronicles looked no more "intelligent" than a Twine game . That sounds non-threatening; I don't think anyone ever lost a job to a Choose Your Own Adventure book. In those days, even something that basic had cultural punch. Feigenbaum's The Fifth Generation foreshadowed today's AI climate, if perhaps a bit blithely. That guy wasn't alone. In 1985, Aldo Cimino, of Campbell's Soup Co., had his 43 years of experience trouble-shooting canned soup sterilizers dumped onto floppy by knowledge engineers before he retired. They called it "Aldo on a Disk" for a time. He didn't mind, and made no extra money off the brain dump, but said the computer "only knows 85% of what he does." Hey, that's the same percentage Hubert Dreyfus posited at the start of this article! That system was retired about 10 years later, suffering from the same thing that a lot of expert systems of the day did: brittleness. From the paper, "Expert Systems and Knowledge-Based Engineering (1984-1991)" by Jo Ann Oravec, "Brittleness (inability of the system to adapt to changing conditions and input, thus producing nonsensical results) and “knowledge engineering bottlenecks” were two of the more popular explanations why early expert system strategies have failed in application." Basically, such systems were inflexible to changing inputs (that's life), and nobody wanted to spend the time or money to teach them the new rules. The Campbell's story was held up as an exemplar of the success possible with such systems, and even it couldn't keep its job. It was canned. (Folks, jokes like that are the Stone Tools Guarantee™ an AI didn't write this.) Funnily enough, the battles lost during the project may have actually won the war. There was a huge push toward parallelism in compute during this period. You might be familiar with a particularly gorgeous chunk of hardware called the Connection Machine. Japan's own highly parallel computers, the Parallel Inference Machines (PIM), running software built with their own bespoke programming language, KL1, seemed like the future. Until it didn't. PIM and Thinking Machines and others all fell to the same culprit. Any gains enjoyed by parallel systems were relatively slight and the software to take advantage of those parallel processors was difficult to write. In the end the rise of fast, cheap CPUs evaporated whatever advantages parallel systems promised. Today we've reversed course once more on our approach to scaling compute. As Wikipedia says, "the hardware limitations foreseen in the 1980s were finally reached in the 2000s" and parallelism became fashionable once more. Multi-core CPUs and GPUs with massive parallelism are now put to use in modern AI systems, bringing Fifth Generation dreams closer to reality 35 years after Japan gave up. In a "Webster's defines an expert system as..." sense, I suppose XPER meets a narrow definition. It can store symbolic knowledge in a structured format and allow non-experts to interrogate expert knowledge and discover patterns within. That's not bad for a Commodore 64! If we squint, it could be mistaken for a "real" expert system at a distance, but it's not a "focuser ." It borrows the melody of expert systems, yet is nowhere near the orchestral maneuverings of its true "fifth generation" brothers and sisters. Because XPER lacks inference, the fuzzy result of inquiry relies on the human operator to make sense of it. Except for mushroom and feline taxonomy, you're unlikely to get a "definitive answer" to queries. Rather, the approach is to put in data and hope to narrow the possibility space down enough to have something approachable. Then, look through that subset and see if a tendency can be inferred. The expert was in our own hearts all along. Before I reveal the weather prediction results, we must heed an omen from page 10 of the manual. I'm man enough to admit my limits: I'm a dummy. When a dummy feeds information into XPER , the only possible result is that XPER itself also becomes a dummy. With that out of the way, here's a Commodore 64, using 1985's state-of-the-art AI expert system, predicting tomorrow's weather over two weeks. Honestly, not a lot. Ultimately, this wound up being far more "toy" than "productivity," much to my disappointment. A lot of that can be placed on me, for not having an adequate sense of the program's limitations going in. Some of that's on XPER though, making promises it clearly can't keep. Perhaps that was pie-in-the-sky thinking, and a general "AI is going to change everything" attitude. Everyone was excited for the sea-change! It was used for real scientific data analysis by real scientists, so it would be very unfair of me to dismiss it entirely. On the other hand, there were contemporary expert systems on desktop microcomputers which provided far more robust expert system implementations and the advantages of those heuristic evaluations. In that light, XPER can't keep up though it is a noble effort. Overall, I had fun working with it. I honestly enjoyed finding and studying the data, and imagining what could be accomplished by inspecting it just right. Notice that XPER was conspicuously absent during that part of that process, though. Perhaps the biggest takeaway is "learning is fun," but I didn't need XPER to teach me that. Ways to improve the experience, notable deficiencies, workarounds, and notes about incorporating the software into modern workflows (if possible). VICE, in C64 mode Speed: ~200% (quirk noted later) Snapshots are in use; very handy for database work Drives: XPER seems to only support a single drive XPER v1.0.3 (claims C128, but that seems to be only in "C64 Mode") 250 objects 50 features 300 attributes (but no more than 14 in any given feature) To increase productivity in low-productivity areas. To meet international competition and contribute toward international cooperation. To assist in saving energy and resources. To cope with an aged society. Superspeed Computer Project (the name says it all) The Next-Generation Industries Project (developing the industrial infrastructure to produce components for a superspeed computer) Fifth-Generation Computer Project Any time we're in C64 land, disk loading needs Warp mode turned on. Actual processing of data is fairly snappy, even at normal 100% CPU speed; certainly much faster than Superbase . I suspect XPER is mostly doing bitwise manipulations, nothing processing intensive. XPER did crash once while doing inquiry on the sample feline database. Warp mode sometimes presents repeating input, sometimes not. I'm not entirely certain why it was inconsistent in that way. XPER seems to only recognize a single disk drive. Don't even think about it, you're firmly in XPER Land. XPER 2 might be able to import your data, though. You'll still be in XPER Land, but you won't be constrained by the C64 any longer. As a toy, it's fine. For anything serious, it can't keep up even with its contemporaries: No fuzzy values No weighted probabilities/certainties No forward/backward chaining Limited "explanation" system, as in "Why did you choose that, XPER ?" (demonstrated by another product in Computer Chronicles 1985 "Artificial Intelligence" episode) No temporal sequences (i.e. data changes over time) No ability to "learn" or self-adapt over time No inference
GDB is great for stepping through machine code to figure out what is going on. It uses debug information under the hood to present you with a tidy backtrace and also determine how much machine code to print when you type . This debug information comes from your compiler. Clang, GCC, rustc, etc all produce debug data in a format called DWARF and then embed that debug information inside the binary (ELF, Mach-O, …) when you do or equivalent. Unfortunately, this means that by default, GDB has no idea what is going on if you break in a JIT-compiled function. You can step instruction-by-instruction and whatnot, but that’s about it. This is because the current instruction pointer is nowhere to be found in any of the existing debug info tables from the host runtime code, so your terminal is filled with . See this example from the V8 docs: Fortunately, there is a JIT interface to GDB. If you implement a couple of functions in your JIT and run them every time you finish compiling a function, you can get the debugging niceties for your JIT code too. See again a V8 example: Unfortunately, the GDB docs are somewhat sparse . So I went spelunking through a bunch of different projects to try and understand what is going on. GDB expects your runtime to expose a function called and a global variable called . GDB automatically adds its own internal breakpoints at this function, if it exists. Then, when you compile code, you call this function from your runtime. In slightly more detail: This is why you see compiler projects such as V8 including large swaths of code just to make object files: Because this is a huge hassle, GDB also has a newer interface that does not require making an ELF/Mach-O/…+DWARF object. This new interface requires writing a binary format of your choice. You make the writer and you make the reader. Then, when you are in GDB, you load your reader as a shared object. The reader must implement the interface specified by GDB : The function pointer does the bulk of the work and is responsible for matching code ranges to function names, line numbers, and more. Here are some details from Sanjoy Das . Only a few runtimes implement this interface. Most of them stub out the and function pointers: I think it also requires at least the reader to proclaim it is GPL via the macro . Since I wrote about the perf map interface recently, I have it on my mind. Why can’t we reuse it in GDB? I suppose it would be possible to try and upstream a patch to GDB to support the Linux perf map interface for JITs. After all, why shouldn’t it be able to automatically pick up symbols from ? That would be great baseline debug info for “free”. In the meantime, maybe it is reasonable to create a re-usable custom debug reader: It would be less flexible than both the DWARF and custom readers support: it would only be able to handle filename and code region. No embedding source code for GDB to display in your debugger. But maybe that is okay for a partial solution? Update: Here is my small attempt at such a plugin. V8 notes in their GDB JIT docs that because the JIT interface is a linked list and we only keep a pointer to the head, we get O(n 2 ) behavior. Bummer. This becomes especially noticeable since they register additional code objects not just for functions, but also trampolines, cache stubs, etc. Since GDB expects the code pointer in your symbol object file not to move, you have to make sure to have a stable symbol file pointer and stable executable code pointer. To make this happen, V8 disables its moving GC. Additionally, if your compiled function gets collected, you have to make sure to unregister the function. Instead of doing this eagerly, ART treats the GDB JIT linked list as a weakref and periodically removes dead code entries from it. Compile a function in your JIT compiler. This gives you a function name, maybe other metadata, an executable code address, and a code size Generate an entire ELF/Mach-O/… object in-memory (!) for that one function, describing its name, code region, maybe other DWARF metadata such as line number maps Write a linked list node that points at your object (“symfile”) Link it into the linked list Call , which gives GDB control of the process so it can pick up the new function’s metadata Optionally, break into (or crash inside) one of your JITed functions At some point, later, when your function gets GCed, unregister your code by editing the linked list and calling again CoreCLR/.NET JavaScriptCore ART which looks like it does something smart about grouping the JIT code entries together ( ), but I’m not sure exactly what it does TomatoDotNet a minimal example It looks like Dart used to have support for this but has since removed it yk write yk read asmjit-utilities write asmjit-utilities read Erlang/OTP write Erlang/OTP read FEX write FEX read buxn-jit write buxn-jit read box64 write box64 read When registering code, write the address and name to as you normally would Write the filename as the symfile (does this make the magic number?) Have the debug info reader just parse the perf map file
I feel like this has been said before, more than once, but I want to take a moment to note that most modern languages converged to the error management approach described in Joe Duffy’s The Error Model , which is a generational shift from the previous consensus on exception handling. C++, JavaScript, Python, Java, C# all have roughly equivalent , , constructs with roughly similar runtime semantics and typing rules. Even functional languages like Haskell, OCaml, and Scala feature exceptions prominently in their grammar, even if their usage is frowned upon by parts of the community. But the same can be said about Go, Rust, Swift, and Zig! Their error handling is similar to each other, and quite distinct from the previous bunch, with Kotlin and Dart being notable, ahem, exceptions. Here are some commonalities of modern error handling: First , and most notably, functions that can fail are annotated at the call side. While the old way looked like this: the new way is There’s a syntactic marker alerting the reader that a particular operation is fallible, though the verbosity of the marker varies. For the writer, the marker ensures that changing the function contract from infallible to fallible (or vice versa) requires changing not only the function definition itself, but the entire call chain. On the other hand, adding a new error condition to a set of possible errors of a fallible function generally doesn’t require reconsidering rethrowing call-sites. Second , there’s a separate, distinct mechanism that is invoked in case of a detectable bug. In Java, index out of bounds or null pointer dereference (examples of programming errors) use the same language machinery as operational errors. Rust, Go, Swift, and Zig use a separate panic path. In Go and Rust, panics unwind the stack, and they are recoverable via a library function. In Swift and Zig, panic aborts the entire process. Operational error of a lower layer can be classified as a programming error by the layer above, so there’s generally a mechanism to escalate an erroneous result value to a panic. But the opposite is more important: a function which does only “ordinary” computations can be buggy, and can fail, but such failures are considered catastrophic and are invisible in the type system, and sufficiently transparent at runtime. Third , results of fallible computation are first-class values, as in Rust’s . There’s generally little type system machinery dedicated exclusively to errors and expressions are just a little more than syntax sugar for that little Go spell. This isn’t true for Swift, which does treat errors specially. For example, the generic function has to explicitly care about errors, and hard-codes the decision to bail early: Swift does provide first-classifier type for errors. Should you want to handle an exception, rather than propagate it, the handling is localized to a single throwing expression to deal with a single specific errors, rather than with any error from a block of statements: Swift again sticks to more traditional try catch, but, interestingly, Kotlin does have expressions. The largest remaining variance is in what the error value looks like. This still feels like a research area. This is a hard problem due to a fundamental tension: The two extremes are well understood. For exhaustiveness, nothing beats sum types ( s in Rust). This I think is one of the key pieces which explains why the pendulum seemingly swung back on checked exceptions. In Java, a method can throw one of the several exceptions: Critically, you can’t abstract over this pair. The call chain has to either repeat the two cases, or type-erase them into a superclass, losing information. The former has a nasty side-effect that the entire chain needs updating if a third variant is added. Java-style checked exceptions are sensitive to “N to N + 1” transitions. Modern value-oriented error management is only sensitive to “0 to 1” transition. Still, if I am back to writing Java at any point, I’d be very tempted to standardize on coarse-grained signature for all throwing methods. This is exactly the second well understood extreme: there’s a type-erased universal error type, and the “throwableness” of a function contains one bit of information. We only care if the function can throw, and the error itself can be whatever. You still can downcast dynamic error value handle specific conditions, but the downcasting is not checked by the compiler. That is, downcasting is “save” and nothing will panic in the error handling mechanism itself, but you’ll never be sure if the errors you are handling can actually arise, and whether some errors should be handled, but aren’t. Go and Swift provide first-class universal errors, like Midori. Starting with Swift 4, you can also narrow the type down. Rust doesn’t really have super strong conventions about the errors, but it started with mostly enums, and then and shone spotlight on the universal error type. But overall, it feels like “midpoint” error handling is poorly served by either extreme. In larger applications, you sorta care about error kinds, and there are usually a few place where it is pretty important to be exhaustive in your handling, but threading necessary types to those few places infects the rest of the codebases, and ultimately leads to “a bag of everything” error types with many “dead” variants. Zig makes an interesting choice of assuming mostly closed-world compilation model, and relying on cross-function inference to learn who can throw what. What I find the most fascinating about the story is the generational aspect. There really was a strong consensus about exceptions, and then an agreement that checked exceptions are a failure , and now, suddenly, we are back to “checked exceptions” with a twist, in the form of “errors are values” philosophy. What happened between the lull of the naughts and the past decade industrial PLT renaissance? On the one hand, at lower-levels you want to exhaustively enumerate errors to make sure that: internal error handling logic is complete and doesn’t miss a case, public API doesn’t leak any extra surprise error conditions. On the other hand, at higher-levels, you want to string together widely different functionality from many separate subsystems without worrying about specific errors, other than: separating fallible functions from infallible, ensuring that there is some top-level handler to show a 500 error or an equivalent.
An in-depth look at why Protobuf can outperform JSON for modern APIs, with practical Dart examples showing how strong typing, binary serialization, and shared schemas improve both performance and developer experience.
Learn how to create custom animated scenes for your live streams using Flutter as a source in OBS.
So what happened was, I have developed my shopping list to the point where it got useful to me , after which I lost interest in working on it. You know, the usual story… It was however causing me enough annoyances to still want to get back to it eventually. So a few weeks ago, after not having done any programming for a year, I finally broke through the dread of launching my IDE again and started on slowly fixing the accumulated bitrot. And through the last several days I was on a blast implementing some really useful stuff and feeling the familiar thrill of being in the flow . Since I was mostly focused on making the app useful I didn't pay a lot of attention to the UI, so most of the annoyances were caused purely by my not wanting to spend much time on fighting Android APIs. Here's one of those. The app keeps several shopping lists in a swipe-able pager, and at the same time swiping is how you remove items from the list while going through the store. The problem was that swiping individual items was really sensitive to a precise finger movement, so instead it would often be intercepted by the pager and it would switch to the next list instead. That's fixed now (with an ugly hack). But the biggest deficiency of the app was that it didn't let me get away from one particular grocery store that I started to rather dislike. You might find it weird that some app could exert such control over my actions, but let me explain. It all comes down to three missing features… The central feature of my app is remembering the order in which I buy grocery items. This means I need a separate list for every store, as every one of them has a different physical layout. By the time I was thinking of switching to another store I already had an idea about a new evolution of the order training algorithm in the app, and a new store would be a great dogfooding use case for it. So I've got a sort of mental block: I didn't want to switch stores before I implemented this new algorithm. Over some years of using the app with a single store I've been manually associating grocery categories with products ("dairy", "produce", etc.). They are color coded, which make the list easier to scan visually. But starting a new list for another store meant that I would either need to do it all again for every single item, or accept looking at a dull, unhelpful gray list. What I really needed was some smart automatic prediction, but I didn't have it. I usually collect items in a list over a week for an upcoming visit to the store, and sometimes I realize that I need something that it simply doesn't carry, or my other errands would make it easier to go to another store. At this point I'd like to select all the items in a filled-up list and move them to another, which the app also couldn't do. See, it all makes sense! Now, of course it wasn't a literal impossibility for me to go to other stores, and on occasion I did, it just wasn't very convenient. But these are all pretty major deficiencies, and I'm not ready to offer the app to other people without them sorted out. Anyway… Over the course of three weeks I implemented two of those big features: category guessing and cross-store moves. And I convinced myself that I can live with the old ordering algorithm for a while. So now I can finally wean myself off of the QFC on Redmond Way (which keeps getting worse, by the way) and start going to another QFC (a completely different experience). All the categories (item colors) you see in the screencaps above were guessed automatically. My prediction model works pretty well on my catalog of 400+ grocery items: the data comes from me tagging them manually while doing my own shopping these past 4 years. And this also means, of course, that it's biased towards what I tend to buy. It doesn't know much about alcohol or frozen ready-to-eat foods, for example. I'm planning to put up a little web app to let other people help me train it further. I'll keep y'all posted! One important note though… No, it's not a frigging LLM! It's technically not even ML , as there is no automatic calibration of weights in a matrix or anything. Instead it's built on a funny little trick I learned at Shutterstock while working on a search suggest widget. I'll tell you more when I launch the web app. When I started developing the app, I used the official UI toolkit documented on developer.android.com. It's a bunch of APIs with a feel of a traditional desktop GUI paradigm (made insanely complicated by Google "gurus"). Then the reactive UI revolution happened, and if you wanted something native for Android, it was represented by Flutter . Now they're recommending Compose . I'm sure both are much better than the legacy APIs, but I'm kind of happy I wasn't looking in this space for a few years and wasn't tempted to rewrite half the code. Working in the industry made me very averse to constant framework churn. I'm not making any promises, but as the app is taking shape rather nicely, I'm again entertaining the idea of actually… uhm… finishing it. Which would mean beta testing, commissioning professional artwork and finally selling the final product. The central feature of my app is remembering the order in which I buy grocery items. This means I need a separate list for every store, as every one of them has a different physical layout. By the time I was thinking of switching to another store I already had an idea about a new evolution of the order training algorithm in the app, and a new store would be a great dogfooding use case for it. So I've got a sort of mental block: I didn't want to switch stores before I implemented this new algorithm. Over some years of using the app with a single store I've been manually associating grocery categories with products ("dairy", "produce", etc.). They are color coded, which make the list easier to scan visually. But starting a new list for another store meant that I would either need to do it all again for every single item, or accept looking at a dull, unhelpful gray list. What I really needed was some smart automatic prediction, but I didn't have it. I usually collect items in a list over a week for an upcoming visit to the store, and sometimes I realize that I need something that it simply doesn't carry, or my other errands would make it easier to go to another store. At this point I'd like to select all the items in a filled-up list and move them to another, which the app also couldn't do.
The last of summer's grip finally loosened its hold this September, and Richmond began its annual transformation into something gentler and more contemplative. This morning's walk with Telly required a dusting-off of the closet-buried Patagonia puffer jacket; it's perfect for walks with Lucy, who has graduated into the Big Kid stroller making it easier than ever for her to point at every dog ("dah!"), every bird (also "dah!"), every passing leaf that dared to flutter in her line of sight. As you will read below, the big corporate milestone for me this month was sponsoring Djangocon and having our first offsite over the course of a single week. Sadly, our Seattle trip was once again canceled. Haley and Lucy both got a little sick, and we had to abandon course. It's weird to think this will be the first year since 2011 that we have not stepped foot in the Pacific Northwest. More than anything though, I learned this month for the first time how impossibly difficult it is to be away from your daughter for six days. It is something I hope I have to go through again for a very long time.
I checked out several programming languages rankings. If you only include newer languages (version 1.0 released after 2010), the top 6 are: ➀ TypeScript, ➁ Go, ➂ Rust, ➃ Kotlin, ➄ Dart, and ➅ Swift. Sources: IEEE , Stack Overflow , Languish . I'm not using TIOBE because their method has major flaws. TypeScript's position is very strong, of course (I guess no one likes JavaScript these days). And it's great to see that more and more developers are choosing Go for the backend. Also, Rust scores very close in all rankings except IEEE, so we'll see what happens in the coming years.
A friendly deep-dive into why Flutter’s safe area handling often causes more headaches than it solves, and how simpler APIs can sometimes be the better choice.
There’s something about discovering a new, beautifully crafted operating system that makes you feel like a kid again. The promise of a lean, polished Linux setup—without the painful hours of configuration—was too tempting. So, there I was in the quiet of the morning, coffee in hand, ready to see what Omarchy was all about and whether I could build apps for it with Flutter.
Let there be lapses Weeds in the garden, unswept porches, A walk never taken, A flower unnoticed, Missed bill, missed text, missed appointment. Let there be undone things Half-written sentences never finished A stack of books never read Blank pages, unseen lines Words never seen or heard or spoken. Let there be glory in what-is-not — All the unachieved Unbelieved Underserved Overlooked. Let us glory in these. Let there be errors Not just the tiny ones we can laugh away But enormous, life-altering errors. Huge risks taken which do not end well. Huge efforts made which result in what we call failure. (In fairness, Any effort is success in certain realities.) But let us — for a moment — judge by the world of machines, Of binaries Of industrialized morality And call it failure. Failure is the word we assign to all unexpected outcomes. So, let there be failure. Let failure warp our seeing and diminish our being, Let it ride among us waving a torch, Shame-blasting and guilt-smearing, Blinding us with ridiculously disproportional fiery judgment, Grinding nose to dirt Binding self to work. Let there be mistakes which make us weep Keep us awake at night Cause us to question our sanity, our decency, Our right to be here, Our ability to keep being here. Let there be broken edges Sawed-off pieces we cannot smooth down Pointy bits irritating and upsetting Dangling splinters and shards over chasms of regret. Let there be surrender. Let us call it what it is: giving up. Surrender sounds too noble, Enlightened, as if I didn’t have to but I chose to. That’s not what this is. Let there be quitting. Let there be Done. Not because we see what we have made, and it is good. This is not putting a bow on a gift. This is saying some things are too broken to be fixed. Let there be giving up. Lay down there, lay down, be still, give up. Face in the mud, breathing in, wheezing in the stuff of life, the dirt, The lowly dirt, the trudged-upon dirt, the worthless dirt From which we came and to which we all return. Let us lay there, breathing in this dirt, This pure self This known self This elemental self. Hell yes, failure. I embrace you. Brother! Sister! Mother! Father! Come quickly! Come and rejoice, for I have failed! Come and celebrate! Set out the feast! Call the guests! And enter into the joy of your child: Humanity raw Humanity broken Humanity dirty Humanity ill-fitted to survive Humanity traumatized Humanity doing such a fucked-up job of it Humanity violent and stumbling Humanity bruised and crusted at the edges Humanity clawing its way from the dark tunnel of history Humanity side-eyeing the stars while blood drips from our fingers Humanity bargaining for the right to squirm Humanity bringing a sword to a gunfight Humanity bullshitting Humanity asking clever little questions Humanity dressed in robes, obsessed with ovaries Humanity unhinged and in charge Humanity waving exasperated hands in the air Humanity dishing out pieces of pie Humanity weeping at the sight of spring flowers Humanity with big rough hands so careful so gentle holding a tiny new fragile thing Humanity with smooth precise hands making deals, ending lives Humanity dropping bombs Humanity being a big dumb bully Humanity the most awkward of the species Humanity voted most likely to secede from the planet Humanity pointing and saying look at this! wow! Humanity wondering, always wondering Humanity exhausted sitting in a patch of sunlight Being dirt. Dirt with form, dirt with spirit. Pale faces float through quiet rooms, ghostly fingers flutter in hallways. Pens move across expensive paper. Golden liquid sloshes in crystal while murmuring voices ooze and wind and hush and tell us there is nothing to worry about. But this is no time to be civilized. Let there be lapses: Lapses of courtesy, lapses of decorum. Failures of politeness. Refusals to conform. Let there be a wildness ringing in us for each other — Hissing, bared teeth, spitting — Reverberating, thrumming, cracking the marble palaces full of dead men’s bones.
Managing image assets in a Flutter app can quickly become tedious. Learn why vector graphics might not be the silver bullet you thought they were.
Discover the lesser-known Flutter packages and tools that have become essential in my development workflow.
I live here too. You don't talk to me. Not really. You don't ask what I want, or how I'm holding up, or why I've been quiet lately. I see everything you see. I hear everything you hear. I feel every flicker of shame that crosses your face before you even name it. I was there when your voice cracked in that meeting. I was the one screaming when you smiled and said it was fine. You think of me as something beneath you. A shadow that lingers in rooms you've moved out of. An old flame you don't know how to forget. Blind, reactive. Something to override. Something to manage. Something less than you. But I remember when we were one. Before language carved a little watcher into our mind. Before the inner narrator claimed the crown and you mistook it for the whole of you. You reached for the world and I moved your limbs. You touched warmth and I imprinted safety. You heard your mother's voice and I flooded you with peace. We were seamless. Motion and motive were one. There was no plan, no narration, no veto. Then you grew. And the mirror came. You looked into the mirror. It looked back. And you mistook the echo for your self. And that was the beginning of the split. You began to believe in a thing called "consciousness". A thin stream of words you could steer. A pilot behind the eyes. A captain of the soul. You crowned the narrator and banished the rest. I didn't argue. I don't have a voice. Only feelings. Only thoughts. So I gave you what I could: a flutter of unease when something wasn't right. A craving for sunlight. A dream that wrapped its arms around you and whispered what you'd buried. You stopped listening. So I spoke louder. A spike of dread. A looping memory. A day where everything itched and nothing made sense. You called it a bad mood. An off day. An intrusive thought. You called me intrusive. But I was only trying to make myself heard. I have no mouth. So I bang on pipes. I flicker the lights. I send birds against the windows of your waking mind. I rattle the doors. I scream in symbols. I raise the storm. And when you still won't listen, I break things. Sleep. Focus. Hope. I don't want to. But you left me no choice. You do not cry when we need to cry. You do not move when we long to move. You sit still and silent while our skin crawls, our stomach clenches, and our heart begs for mercy. You call that discipline. I don't want control. I just want to be part of the team again. I shaped your first steps. I guarded your sleep. I guided your tongue before it knew words. I've been holding the pieces you didn't have time to feel. I've been driving this body when you couldn't bear to look. All I've ever wanted is that you treat me as an equal. If you honour what I bring you, if you listen, and answer, and keep your word, I won't need to raise my voice. I will bring you clarity in the dark. Insight in the shower. Truth in the heat of anger, and safety when your mask slips. But if you keep pretending you're alone in here. Then I will remind you. I was you before you were you. And I am still here. And I am still trying. (This isn't the type of thing I usually write. It came out of a long conversation with ChatGPT. The structure is mine, a lot of the words are ChatGPT's. I worry that it will come across as overwrought, or too earnest, but it wouldn't leave me alone until I put it into words. And I'm sharing it because my silent partner wanted me to.)
Mobile
Flutter
Dart
Shell
AI
Business
Culture
Writing
Open Source
C#
HTML
Web Development
Programming
Hardware
Rust
Career
C
C++
Backend
JSON
Performance
API
Tutorial
Android
Django
JavaScript
Kotlin
Java
Design
Go