On Friday 12 June 2026, Anthropic disabled access to its two most powerful AI models, Fable 5 and Mythos 5, to comply with an export-control directive from the US government. In the company’s own words, the order required it to “suspend all access to Fable 5 and Mythos 5 by any foreign national, whether inside or outside the United States, including foreign national Anthropic employees.” There was no way to honour that while keeping the models live for anyone, so Anthropic pulled them for every customer worldwide.

It is worth slowing down on what actually happened here, because it is far bigger than a product outage. A government reached into a lawful, three-day-old commercial product used by hundreds of millions of people and turned it off by decree. The precedent it sets, if it holds, threatens the American AI industry far more than whatever it claims to protect — and for the roughly 96% of humanity that is not American, it is a blunt message about who frontier AI is really for.

What actually happened

The facts matter here, and they are well documented.

On 12 June 2026, Anthropic received a directive from the US government at 5:21pm ET and, within hours, disabled both Fable 5 and Mythos 5 for every single customer — not just foreign ones — because that was the only way to guarantee compliance. Anthropic’s own statement describes the “net effect” plainly: “we must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance. Access to all other Anthropic models will not be affected.”

According to Axios, which broke the scoop, the order came as a letter from Commerce Secretary Howard Lutnick to Anthropic CEO Dario Amodei, placing the models under export controls “to any location outside of the U.S. and to all foreign persons within the country,” and requiring a licence for the “export, re-export or domestic transfer” of the models. Reuters reported the same: the Trump administration is blocking foreign governments, companies and individuals from accessing Anthropic’s most advanced models, and Anthropic responded by cutting everyone off. By Friday night the story was driving a visible spike in searches for “anthropic”, which tells you the wider world noticed too.

The timing is brutal. Anthropic only released these two models on 9 June — Fable 5 as the safeguarded public model, and Mythos 5 as the same underlying model with some protections removed for vetted users. TechCrunch covered the launch three days before the government pulled the plug. So this was a model that lived, as a publicly available product, for roughly seventy-two hours.

What Fable and Mythos actually are

It is worth being clear about what these models are, because the naming is doing a lot of work. By Anthropic’s own description, Fable 5 and Mythos 5 are a new “Mythos-class” tier that the company positions above Claude Opus — its most capable models yet. Fable 5 and Mythos 5 are, underneath, the same model. The difference is the safety layer: Fable 5 is the version released to the general public with additional safeguards around dual-use capabilities, while Mythos 5 is the same model with those measures removed, made available only to a small set of approved organisations — initially through a US-government cybersecurity collaboration called Project Glasswing. The model documentation lists both at the same price: $10 per million input tokens, $50 per million output.

This sharpens the irony. The model the government pulled was Fable 5 — the safeguarded public version Anthropic deliberately built to be safe for general release. It was not the unrestricted Mythos variant. The government did not just pull the dangerous one; it pulled the one with the seatbelts bolted on, for everyone, worldwide.

The “jailbreak” that triggered this was asking the model to fix a bug

Here is the part that should give everyone pause. The government did not, according to Anthropic, hand over a detailed technical case. Anthropic’s statement says: “The letter did not provide specific details of its national security concern. Our understanding is that the government believes it has become aware of a method of bypassing, or ‘jailbreaking’ Fable 5.”

So what was the terrifying jailbreak? In Anthropic’s words: “To date, the government has only given us verbal evidence of a potential narrow, non-universal jailbreak, which essentially consists of asking the model to read a specific codebase and fix any software flaws.”

Read that again. The capability that supposedly threatens national security is asking an AI to read code and fix the bugs in it — the single most common, mundane thing developers do with these tools every single day. Anthropic goes further and says it “validated that the level of capability displayed there is widely available from other models (including OpenAI’s GPT-5.5), and is used every day by the defenders who keep systems safe.”

Axios reports the chain of events: another company claimed it could jailbreak Mythos, this alarmed the administration, the administration tried to get Anthropic to pause the launch, Anthropic declined, and the export-control letter followed. Anthropic’s blunt assessment of the standard being applied: “If this standard was applied across the industry, we believe it would essentially halt all new model deployments for all frontier model providers.”

To be fair: Washington’s fear is not irrational

It is only fair to put the government’s case at its strongest, because the underlying worry is real. The Mythos family is genuinely frightening on cybersecurity. When Anthropic previewed it in April, its own red team reported that Mythos Preview “is capable of identifying and then exploiting zero-day vulnerabilities in every major operating system and every major web browser when directed by a user to do so” — and that engineers with no security training could get a complete working exploit overnight. That is not nothing. Former US National Cyber Director Kemba Walden called Mythos “a clarion call to address weaknesses in our cyber ecosystem,” describing a model that “autonomously builds and chains exploits — and then covers its tracks.”

So I get why officials are nervous. But notice that Anthropic anticipated exactly this. Fable 5 was deliberately shipped as “Mythos on a leash” — its classifiers route sensitive cybersecurity and biology queries to its next-most-capable public model, Opus 4.8, and Anthropic kept the full-strength Mythos behind the vetted Project Glasswing circle. The company built the deployment controls first, then the government overrode them by banning the leashed version too. If the fear is real, the remedy still has to make sense — and recalling the safeguarded model while the same capability stays on sale elsewhere does not.

This is an export control. Understand what that machinery is.

The word “export” is doing enormous work here, so it is worth being precise about the legal apparatus, because it is genuinely alarming once you see it.

US export controls are administered by the Commerce Department’s Bureau of Industry and Security (BIS) under the Export Administration Regulations. The concept that lets a directive reach me, in Australia, and also a foreign-national engineer sitting in an office in San Francisco is the deemed export. It is not a metaphor; it is black-letter regulation. 15 CFR § 734.13 defines “export” to include “releasing or otherwise transferring technology or source code to a foreign person in the United States,” and says any such release “is a deemed export to the foreign person’s most recent country of citizenship or permanent residency.” BIS spells it out: showing controlled technology to a foreign national, even one standing in your own office, is legally an export to their home country. That is why Anthropic’s order explicitly covers “foreign national Anthropic employees.” The US government has not just blocked a product at the border. It has reclassified a commercial AI model as something closer to a controlled munition, where the act of showing it to the wrong nationality is the regulated event.

Where does the power come from? The permanent authority is the Export Control Reform Act of 2018, and in particular its provision for controlling “emerging and foundational technologies” essential to national security — which is the natural hook for frontier AI. Sitting behind that is the International Emergency Economic Powers Act, which lets the President “investigate, block … regulate … prevent or prohibit, any … exportation … [or] transfer” of property once a national emergency is declared. And crucially, this is not unprecedented as an idea: the Biden administration’s AI Diffusion Rule (January 2025) already created a control — ECCN 4E091 — that treated the weights of the most advanced closed models as a controlled commodity, before the Trump administration rescinded it in May 2025. The machinery to treat a model like a weapon has been quietly assembled over years. Friday was the day someone pulled the lever on a live consumer product.

Sit with the implication. A huge fraction of the engineers who build these systems in America are foreign nationals. An order that bars foreign nationals from a model bars some of the very people who built it from touching their own work. Anthropic itself flagged this — the directive hits its own employees.

We have already watched this movie with chips

The US has spent years treating AI as a national-security asset to be fenced off, and we have a very clear record of how that goes. The chip controls are the precedent, and they are not a happy one.

It started in October 2022, when BIS restricted advanced AI accelerators to China, instantly making Nvidia’s A100 and H100 non-compliant. Nvidia simply designed the cut-down A800 and H800 to sit just under the threshold. So in October 2023 BIS rewrote the rule to close that gap. Nvidia designed the even-more-cut-down H20. In April 2025 the government required a licence for the H20 too, and Nvidia took a ~$5.5 billion charge. Then it reversed course and let H20s flow again — under a bizarre arrangement where Nvidia and AMD hand 15% of their China chip revenue to the US government for the privilege of an export licence. Whatever that is, it is not a coherent national-security policy.

And the man whose company lived it has been blunt about the result. Nvidia CEO Jensen Huang stood up at Computex in 2025 and said the quiet part out loud: “The export control was a failure.” His reasoning is the whole point: “AI researchers are still doing AI research in China. If they don’t have enough Nvidia, they will use their own.” By his own account, Nvidia’s share of China’s AI-chip market fell from about 95% to effectively zero — not because demand vanished, but because the controls “gave them the spirit, the energy, and the government support to accelerate their development.”

That is the lesson nobody in Washington seems to absorb: when you wall off an American product, you do not delete demand — you redirect it. And the redirection has a name now. CSIS documented how DeepSeek’s R1, released in January 2025, “cemented its reputation as the top frontier AI research lab in China and caused a reassessment of assumptions about the landscape of global AI competition” — frontier-class performance at far lower cost, with user adoption so fast its servers buckled. Customers do not stop wanting frontier AI because they cannot have Claude. They go and get someone else’s — and increasingly, someone else’s is very, very good.

Code as speech — an old fight, unresolved

There is a deeper, almost philosophical problem buried in here, and it is not new. In the 1990s the US tried to treat strong encryption as a controlled munition. A mathematician named Daniel Bernstein challenged it, and in Bernstein v. United States the courts wrestled with whether source code is protected speech under the First Amendment. The Ninth Circuit panel famously found that it was, and the entire crypto-export regime eventually crumbled under that pressure.

A model is not source code in the Bernstein sense, but the analogy is uncomfortably close: the government is asserting the power to control who may read the outputs of, and interact with, a piece of software, on national-security grounds, with the regulated act being the transfer of information to a foreigner. We litigated a version of this thirty years ago and the government lost. Nobody should assume the AI version is settled law.

What it means for developers outside America

The message just delivered to every developer, startup, and enterprise outside the United States is stark: American frontier AI can be revoked at any moment, retroactively, by executive directive, with no warning and no process to appeal. Anyone who had built workflows on Fable 5 watched them break on Friday — not for anything they did, but because a government they did not vote for and are not citizens of decided foreign access to the model was a national-security risk. Asking a chatbot to read and fix your code is now, apparently, a controlled activity if you hold the wrong passport.

Anthropic, to its credit, apologised — “We apologize for this disruption to our customers” — and says it believes this is a misunderstanding it is working to reverse. That is almost certainly true, and Anthropic is not the party that pulled the trigger. But goodwill does not change the risk calculus. You cannot build a business on an input that a foreign government can switch off without notice or appeal. The rational response is to hedge and diversify away — not out of disloyalty to American AI, but as basic risk management. And that quiet, rational flight is exactly the outcome that should worry Washington most.

Why this could break Anthropic — and hand the game to its rivals

Here is the part I keep coming back to, and it is the genuinely dangerous bit for the American AI industry.

Anthropic is a US company. So is OpenAI. The entire pitch of American AI to the world is “build on us.” A huge share of these companies’ usage and revenue is international. An API-and-cloud business is uniquely exposed to a “no foreign nationals” rule in a way that, say, an exported physical good is not — the product is remote access, and remote access is exactly what got switched off. Cut Anthropic off from every foreign national on the planet and you have not regulated a model; you have amputated its market.

And notice the cruel asymmetry. Anthropic itself points out that the very capability in question is available in OpenAI’s GPT-5.5. So this action does not make the capability disappear from the world. It selectively kneecaps one American company while its American competitor keeps selling. Today it is Anthropic. There is nothing about the mechanism that stops it being OpenAI next week, on someone else’s say-so. A precedent that lets the government disable any frontier model on a single unverified jailbreak claim is a sword hanging over all of them.

Zoom out and it is worse. Every foreign customer Anthropic just lost is a customer that will go shopping — and the alternatives are no longer only American. The world now has capable models out of China and Europe. A US export-control regime that makes American AI unreliable for the 96% of humanity that is not American is, functionally, the single best growth strategy a non-American AI lab could ask for. We may look back on this as the moment the US handed away the one market that actually mattered: everyone else’s.

This is the irony that should keep policymakers up at night. The stated goal is to protect American national security by controlling powerful AI. The likely effect is to make American AI globally untrustworthy, push the world onto non-American models, and weaken the exact companies the policy claims to champion.

The anti-AI mood is what made this possible

None of this happened in a vacuum. A government only reaches for an emergency switch like this when it believes the public will applaud — and the public mood on AI has curdled. Pew Research now finds half of US adults are more concerned than excited about AI in daily life, against just 10% who are more excited than concerned. That concerned share has climbed from 37% in 2021 — a 13-point jump in four years. Stanford’s 2026 AI Index documents the same anxiety, and a widening gap between AI insiders and everyone else.

I am an AI optimist, so I say this carefully: a lot of that anxiety is earned. People watch their juniors’ job prospects, their kids’ homework, and their newsfeeds get churned by this stuff, and they are uneasy. Then a model arrives that can autonomously find and exploit zero-days, the cyber threat is serious enough that it brings Anthropic’s CEO back into the White House to meet the Chief of Staff and the Treasury Secretary, and the doom narrative writes itself. In that climate, “we switched off the scary AI to keep you safe” is a politically rewarding sentence, regardless of whether it withstands ten minutes of technical scrutiny.

And here is the bitter irony I cannot get past. A lot of the loudest anti-AI campaigning comes from people who cast themselves as opponents of unchecked corporate and state power — populist critics and online commentators who built big audiences arguing that AI is a scam, a theft machine, a clear and present danger. Whatever you make of those arguments on their merits, look at what the campaign actually produced. It did not rein in the labs. It handed the government a loaded political weapon and a public primed to cheer when it goes off. And the first thing that weapon was used for was not protecting artists or workers — it was the executive branch reaching into a private company and switching off a lawful product for the entire planet, with no due process, on a claim it would not even put in writing. The anti-AI movement said it wanted a check on power. What it manufactured was a blank cheque for it.

That is the trap. Anti-AI sentiment creates a permission structure for heavy-handed, under-reasoned state action — and because the action is dressed in the language of safety, the normal checks feel like obstruction. The danger is that we let a genuine, legitimate unease about AI be laundered into a precedent that lets the government disable lawful software by decree. You can be worried about AI and alarmed that this is how your government chose to act on that worry. I am both.

The precedent is the real story

Strip away the specifics and what remains is this: a government reached into a private company and switched off a lawful, just-launched product used by — in Anthropic’s words — “hundreds of millions of people,” on the strength of a narrow, verbally communicated claim it would not document, and which the company says it could not even reproduce as anything serious.

Anthropic has been consistent about where it stands, and I think it is right: “we believe the government should have the ability to block unsafe deployments, as part of a statutory process that is transparent, fair, clear, and grounded in technical facts. This action does not adhere to those principles.” A government absolutely should be able to act against genuinely dangerous technology. But it has to do so through a process — notice, evidence, a chance to respond, judicial review — not a Friday-evening letter that nukes a product for everyone.

This is not even Anthropic’s first collision with Washington this year. As CNBC notes, the Department of Defense earlier declared Anthropic a “supply chain risk” — a label historically reserved for foreign adversaries. Breaking Defense reported that the designation came under Title 10 § 3252, and that a federal judge, Rita Lin, granted Anthropic a preliminary injunction, finding the stated reasons “were pretextual and that [the government’s] real motive was unlawful retaliation.” Fortune quoted the judge’s line in full: “Nothing in the governing statute supports the Orwellian notion that an American company may be branded a potential adversary and saboteur of the U.S. for expressing disagreement with the government.”

This is now serious enough that the Congressional Research Service has written it up for lawmakers, and legal scholars at Lawfare warned that punishing a domestic company “without notice or an opportunity to be heard” looked like “the beginning of a partial nationalization.” So the relationship between the leading US AI safety lab and the US government is now openly adversarial — litigated in multiple courts. Read that sentence again and tell me it sounds like a healthy basis for “winning the AI race.”

And it is worth being specific about why they fell out, because it reframes everything that has happened since. Breaking Defense reported that the Pentagon’s blacklisting stemmed from disagreements over safeguards Anthropic placed on the use of its AI systems for surveillance and autonomous weapons. Anthropic would not drop them. Negotiations collapsed. The “supply chain risk” label followed — and a judge then found that label was likely unlawful retaliation for the company “expressing disagreement with the government.”

Now hold that pattern up against Friday. A company that has repeatedly told the US government no on weapons and surveillance, that is currently suing the administration, ships the most capable models it has ever built — and within seventy-two hours that same administration invokes emergency national-security export powers to switch those models off for the entire world. I cannot prove motive and I will not pretend to. But a federal judge has already ruled that the last time this administration reached for a national-security label against Anthropic, the label was a pretext for payback. You do not need a conspiracy theory to ask whether this is the next chapter of the same story. You just need to read the docket.

Safety is the costume. Containment is the play.

Let me state plainly what I think is actually going on, because the “safety” framing does not survive contact with the mechanism they chose.

If your genuine concern is a dangerous capability, you restrict the capability. You do not restrict it by passport. But an export control is, by construction, a nationality instrument — the deemed-export doctrine makes the regulated event “a foreigner saw it,” not “harm occurred.” This order does not make Fable’s capabilities disappear. By Anthropic’s own account the same capability ships today in OpenAI’s GPT-5.5. So the policy is not “this is too dangerous to exist.” The policy is “this is too good to share.” Those are completely different statements, and only one of them is about safety.

We have even seen the blueprint written down. The AI Diffusion Rule explicitly carved the planet into tiers: a handful of favoured allies with near-unrestricted access, most of the world capped, and a long list of countries barred outright. The ambition to ration frontier AI by geography is not a conspiracy theory; it is published policy. Friday’s directive is that same instinct applied with a sledgehammer to a single live product. Strip off the safety costume and what is underneath is techno-nationalism: keep the crown jewels inside the border, and let the other ~96% of humanity make do with less. “Safety” is the word you reach for because it is the one word that makes the rest of us feel churlish for objecting to being locked out.

Wrap-up

The facts are damning enough on their own. The trigger was a model fixing a bug. The mechanism was an export-control deemed-export rule designed for munitions and microchips. The blast radius was every foreign national on Earth, including Anthropic’s own staff. The legal theory has lost in court before. And the predictable result is to weaken American AI companies while doing nothing to remove the capability from the world, because the same capability ships in a competitor’s product today.

If the United States wants to lead in AI, this is precisely how it loses that lead — not to a better model, but to its own willingness to make its best companies unusable to everyone outside its borders. Anthropic may well be right that this is a misunderstanding that gets reversed quickly. But the precedent has now been set, and precedents are sticky. The developers, startups, and enterprises outside America who built on these models — and the foreign-national engineers who built the models in the first place — are watching very closely, and many are already thinking about their hedges.

I will update this post as more primary documentation becomes public. As of writing, the government had not released the underlying directive, and Anthropic said it would share more details over the following 24 hours.

Key Takeaways: Python has a tooling problem, not a typing problem. Pylance is proprietary, editor-locked, and too fragile for the way many developers work now. Basilisk is Nimblesite’s attempt to build a complete open-source Python language server, type checker, debugger, and profiler that works everywhere.

A while back, I started building Nimble Agent. It’s a Python AI coding agent built around a simple idea: an agent shouldn’t be allowed to hand-wave its way to “done”. It should have acceptance criteria. It should test its work. It should understand the codebase instead of spraying text into files and hoping for the best.

That led me straight into Python’s type system.

Python is where the AI agent world lives. LangChain, LangGraph, CrewAI, AutoGen, OpenAI’s Python SDK, Anthropic’s Python SDK, and half the ML ecosystem are all Python-first. That’s slightly annoying, because Python is dynamically typed, and dynamic typing confuses the hell out of AI agents. Humans can usually infer intent from messy code. Agents aren’t as good at that. They need contracts. They need explicit shapes. They need a type system that says things out loud.

Python actually has a decent type system now. It’s not TypeScript, but it’s far better than people give it credit for. The problem isn’t the syntax. The problem is enforcement.

PEP 484 made type hints explicitly voluntary. It says no type checking happens at runtime, and it assumes a separate checker that you run over your source. That’s fine as a language design choice, but it means the entire value of typing depends on tooling. If the tooling is weak, optional, proprietary, or locked to one editor, your type annotations aren’t contracts. They’re comments with nicer syntax.

That’s what finally pushed me to build Basilisk.

The Pylance Wall

The obvious answer was supposed to be Pylance, and that’s exactly the problem. Pylance is the thing Python developers are told to use, but the experience is brittle. Large workspaces get slow or memory hungry. Whole-workspace diagnostics and indexing come with tradeoffs. Import and module resolution often need python.analysis.extraPaths, workspace reshaping, or other settings before Pylance sees the same code Python can already run. Microsoft’s own Pylance FAQ has whole sections on import and module resolution, and its configuration tips describe tuning analysis and indexing for large workspaces.

That’s a lot of ceremony for the default Python experience.

That same FAQ explains the relationship clearly: Pylance uses the open-source Pyright type checker underneath, then bolts extra language server features on top.

Pyright is open source, and it’s a very good checker. It has excellent conformance to the Python typing spec, and you can use it outside VS Code. Pyright isn’t the problem. Pylance is.

Pylance is the richer language server experience Python developers know from VS Code, and it’s proprietary. The Pylance license limits installation and use to Microsoft Visual Studio products and services, and Microsoft documents that some extensions use proprietary licenses even when the related source projects are open.

So you get a weird split. Pyright is open. Pylance isn’t. The core checker is right there, but the IDE experience is locked to Microsoft’s distribution. That might have been fine in 2020. It’s a lot less fine now.

The World Moved To VS Code Forks

The most interesting developer tools aren’t just VS Code anymore.

Cursor is a VS Code fork. Windsurf is a VS Code fork. Google’s Antigravity is based on the VS Code codebase and uses Open VSX for extensions. Developers move between VS Code, Cursor, Windsurf, Antigravity, Zed, Neovim, and whatever comes next. The editor is becoming a shell around agents, LSPs, debuggers, terminals, and project context.

That should be great. The whole point of the Language Server Protocol is that language intelligence is portable. The editor shouldn’t own the language.

But Python isn’t in a great place here. If you use official VS Code, you get Pylance. If you use one of the AI-first forks, you get a confusing mix of old Pylance builds, Pyright forks, Basedpyright, marketplace remapping, or custom extensions trying to recreate the thing developers expected in the first place.

This isn’t theoretical. Cursor users have been complaining about it in their own forum. There are threads about not being able to install the latest Pylance extension, Pylance not being supported in Cursor, and Cursor’s Python/Pyright extension getting stuck while analyzing files. In one of them, Cursor staff tell users to install Anysphere’s Python extension, because Pylance isn’t supported inside Cursor.

Windsurf has the same shape of problem. Its own documentation recommends Windsurf Pyright, described as a Pylance-like language server from Open VSX. That wording tells you everything: the market wants complete Python code intelligence, just outside Pylance’s licensing boundary.

Antigravity users are already asking the same question. There are Reddit threads asking for a Pylance alternative in Google Antigravity and a working Python language server for Antigravity. The pattern keeps repeating because the underlying ecosystem is fractured.

Geoffrey Huntley Was Right

Geoffrey Huntley wrote an article called Visual Studio Code is designed to fracture, and it’s worth reading in full.

His argument is that VS Code’s source being open isn’t the same thing as the VS Code ecosystem being open. Microsoft can publish an open-source editor codebase, ship proprietary binaries, control marketplace access, and make proprietary extensions the default. That splits the open version from the version developers actually want to use.

Huntley specifically called out Python. He pointed to the replacement of Microsoft’s open-source Python Language Server with Pylance, and argued the default had quietly moved to a proprietary extension. Visual Studio Magazine reported the same shift: the open-source Microsoft Python Language Server reached end of life, and Pylance became the replacement. The Register noted the open-source cost of swapping the old language server for a closed one.

Microsoft employs great engineers, Pyright is good software, and VS Code is a genuinely excellent IDE. None of that makes Pylance a healthy default for the Python ecosystem.

But we should be honest about the incentives. When the best default experience is proprietary and tied to one vendor’s product, the whole ecosystem bends around that product. Every fork, cloud IDE, open-source build, and AI-first editor either accepts a worse Python experience or burns engineering time recreating what should have been a portable language server in the first place.

That’s bad for Python.

Python Typing Is Better Than People Think

Python’s type system isn’t the problem. The Python typing spec is genuinely good, and in some areas it’s ahead of languages people reflexively think of as “more typed”.

Take unions. Since PEP 604, you can write this:

from pathlib import Path

def load_config(source: str | Path | bytes) -> dict[str, str]:
    ...

That’s a real union type. The value can be a str, a Path, or bytes, and the checker narrows it as the code proves what it has. You can compose it with None too:

def find_user(id: str) -> User | None:
    ...

C# still doesn’t have that as an ordinary, stable language feature. You reach for User? for nullability, pattern matching, object, overloads, custom wrapper types, or a third-party library. Microsoft has a C# union types proposal, which proves the need is real, but Python already lets you express the idea directly in everyday code.

Dart has a sound type system, and Dart 3’s sealed classes and patterns are great. But Dart still won’t let you write a lightweight free union like String | Uri | Uint8List. You model it with a sealed hierarchy or fall back to Object, then write all the surrounding plumbing.

Python can express tagged results without that ceremony:

from dataclasses import dataclass
from typing import Literal

@dataclass(frozen=True)
class Success:
    kind: Literal["success"]
    value: int

@dataclass(frozen=True)
class Failure:
    kind: Literal["failure"]
    message: str

Result = Success | Failure

def render(result: Result) -> str:
    match result:
        case Success(value=value):
            return str(value)
        case Failure(message=message):
            return message

In C#, you’d create a base record or interface and derive the cases. In Dart, you’d create a sealed class and subclasses. Those approaches work, but they’re heavier. Python lets you write the union directly, and the annotation is the contract. Add Literal, TypedDict, Protocol, TypeGuard, and TypeIs, and Python typing gets a lot more sophisticated than the industry narrative suggests.

Most developers don’t know this, because the tooling has trained them not to care. The 2024 Python typing survey from Meta, JetBrains, and Microsoft found that type hints are well adopted but tooling usability is still a major problem. A big chunk of developers use types regularly without running a checker in CI. The survey also called out inconsistent checker behavior and poor discoverability as sources of friction.

That’s the real damage. Python has a good type system, and the default tooling lets people miss it. Teams add type hints because they know they help, then forget to turn on strict checking. Or they configure it in the editor but not CI. Or one developer gets different errors from another, because the editor extension and the CLI checker aren’t the same version. Or the checker is technically present, but it lets untyped code drift through the codebase anyway.

Pylance even has several type checking modes. Pyright’s configuration docs describe off, basic, standard, and strict, with standard as the Pyright default. Pylance’s own python.analysis.typeCheckingMode documentation lists off as the Pylance default. Either way, strictness is something you have to opt into.

That’s the wrong default for AI-generated Python. An agent will happily write this:

def enrich_customer(customer, metadata):
    if metadata["active"]:
        customer.score = metadata["score"]
    return customer

That code might be fine. It might also be nonsense. What’s customer? What’s metadata? Is metadata["score"] an int, a float, a str, or None? What happens when an agent refactors this later and invents a field that never existed?

In a dynamic language, that ambiguity spreads. The agent reads ambiguous code, writes more ambiguous code, and eventually your test suite is the only thing standing between you and a runtime failure.

Tests are necessary. Tests aren’t a type system.

Basedpyright Proves The Demand Exists

Basedpyright is another sign the problem is real.

Basedpyright is a fork of Pyright that adds stricter defaults and reimplements some Pylance features outside the closed-source extension. That’s a clear signal from the community. People want stronger defaults. People want Pylance-like behavior in editors that aren’t official VS Code. People want the editor and the CLI to agree.

It solves real problems, and I’m glad it exists. But I wanted to go further. I didn’t want a better Pyright wrapper. I wanted a complete open-source Python developer experience that doesn’t fundamentally depend on Microsoft’s closed extension, Node.js, or a specific editor marketplace.

That’s Basilisk.

What Basilisk Is

Basilisk is an open-source Python language server, type checker, debugger, and profiler. It’s written in Rust, ships as a single binary, and targets VS Code, Cursor, Windsurf, Antigravity, Zed, and Neovim.

The idea is simple:

Python should have a complete open-source language server that works everywhere.

Not a degraded fallback. Not a half-compatible substitute. Not a tool that only works properly in one editor. One language server, one set of diagnostics, one CLI, one editor experience.

Basilisk is strict by default. There’s no permissive mode to forget about, and no global “relax everything” switch. If a function parameter is untyped, Basilisk says so. If a function has no return annotation, Basilisk says so. If an assignment conflicts with its declared type, Basilisk says so.

For example:

def greet(name):
    return "Hello " + name

Basilisk reports:

error[BSK-E0001]: Missing parameter type annotation for `name`
error[BSK-E0002]: Missing return type annotation

The fixed version is explicit:

def greet(name: str) -> str:
    return "Hello " + name

This isn’t about making Python annoying. It’s about making contracts visible.

The Checker Is Only The Start

The type checker is the wedge, but Basilisk isn’t only a type checker. The goal is a complete Python development stack:

• Type checking and inference, strict by default
• LSP diagnostics, hover, go-to-definition, inlay hints, and code actions
• Refactorings like extract variable, extract function, inline variable, move to file, rename symbol, and change signature
• Debugging through debugpy
• Profiling through py-spy
• Ruff-backed formatting and import organization where it makes sense
• uv integration for modern Python project workflows

I’m not interested in reinventing every good Python tool. Ruff is excellent. uv is excellent. debugpy and py-spy already exist. The point is to pull the developer experience together behind one open language server and make it portable across editors.

This matters more now, because AI agents are editor-native. Cursor, Windsurf, and Antigravity aren’t just editors with autocomplete. They’re agent environments. If Python language intelligence is degraded in those environments, the agent is degraded with it. An agent that can’t trust the type information in a project is a worse agent.

Let’s Shake Things Up

Tooling is not ideology. Use what works, ship software, and don’t waste your life performing loyalty to a toolchain. But some tooling decisions shape what the whole ecosystem can become.

When the best Python IDE experience only lives behind one proprietary extension, every new editor starts behind. Open-source builds start behind. Cloud IDEs start behind. AI-first forks start behind. Neovim and Zed users start behind. The community keeps rebuilding the same experience around a closed center, over and over.

The status quo just isn’t good enough anymore. Portable language intelligence is the entire promise of the LSP, and Python developers still don’t really have it. The way forward is to build open tools that are good enough to be the default everywhere.

That’s why Basilisk exists. It’s a pro-Python, pro-open-tooling project, for people who want the same excellent Python experience in Cursor, Windsurf, Antigravity, Zed, Neovim, VS Code, and whatever comes after them.

Where Basilisk Is At

Basilisk is still early, and I won’t pretend otherwise. Pyright and Pylance are mature. mypy has the oldest ecosystem. Astral’s ty is pushing the space forward too. That’s a good thing. Python needs more serious type checking work, not less.

What makes Basilisk different is the stance:

• Strict by default
• Open source
• Single Rust binary
• A complete LSP, not just a CLI checker
• The same experience across editors
• Built for the AI-agent era

I built it because I wanted my Python agent code to be honest. I wanted missing types to be errors, not vibes. I wanted one language server that didn’t care whether I was in VS Code, Cursor, Windsurf, Antigravity, Zed, or Neovim.

Python developers shouldn’t have to choose between an amazing AI editor and a proper Python language experience. That’s the problem Basilisk is trying to fix.

If you’ve ever opened a VS Code fork, searched for Pylance, found some weird substitute, and wondered why Python suddenly felt second-class, Basilisk is for you.

Give it a try: basilisk-python.dev.

Note that some or all of the content here was written with the assistance of AI. View the AI Content Policy

The Problem: C# Doesn’t Have Exhaustive Pattern Matching on Type

Traditional C# pattern matching has a critical flaw that causes production bugs:

public enum Status { Success, Error, Pending }

// This compiles just fine...
var result = status switch
{
    Status.Success => "OK",
    Status.Error => "Failed",
 // Missing Status.Pending case
};
// ...but throws SwitchExpressionException at runtime!

When you’re making HTTP calls, you have multiple distinct failure modes: success responses, client errors (400s), server errors (500s), network timeouts, DNS failures, and serialization exceptions. Each requires different handling. Missing any case means production bugs.

This is probably going to become a core part of the C# language soon, but for the time being, discriminated unions are only at the proposal stage in the C# GitHub repo.

RestClient.Net 7 solves this problem now with exhaustive pattern matching that catches missing cases at compile-time, not runtime.

Result Types: No Exceptions

RestClient.Net 7 uses the Outcome Nuget package. It contains result types (basically, discriminated unions) like Result<TSuccess, HttpError<TError>>. They represent all possible outcomes explicitly:

using var httpClient = new HttpClient();

var result = await httpClient.GetAsync(
    url: "https://api.example.com/posts/1".ToAbsoluteUrl(),
    deserializeSuccess: DeserializePost,
    deserializeError: DeserializeError
);

// The compiler FORCES you to handle all cases
var output = result switch
{
    OkPost(var post) => 
        $"Success: {post.Title}",
    ErrorPost(ResponseErrorPost(var errorBody, var statusCode, _)) => 
        $"HTTP Error {statusCode}: {errorBody.Message}",
    ErrorPost(ExceptionErrorPost(var exception)) => 
        $"Network Exception: {exception.Message}",
 // Missing a case? Your build fails!
};

There are exactly three possible outcomes in the closed type hierarchy:

1. Ok - Success with your data
2. Error with ResponseError - HTTP error response (4xx, 5xx) with the error body
3. Error with ExceptionError - Network exception (timeout, DNS failure, connection refused)

No hidden exceptions. No surprise throws. All error paths are visible in your code.

Exhaustion Analyzer: Compile-Time Safety Net

Here’s how I fixed a core deficiency in C#. RestClient.Net 7 includes the Exhaustion package I created specifically for this purpose. It’s a Roslyn analyzer that provides compile-time exhaustiveness checking. If you forget to handle a case, your build fails with this error:

error EXHAUSTION001: Switch on Result is not exhaustive;
Matched: Ok<Post, HttpError<ErrorResponse>>, 
 Error<Post, HttpError<ErrorResponse>> with ErrorResponseError<ErrorResponse>
Missing: Error<Post, HttpError<ErrorResponse>> with ExceptionError<ErrorResponse>

This shifts errors from runtime (production) to compile-time (development). You literally cannot ship code that doesn’t handle all possible outcomes. For critical applications involving payments, authentication, or data processing, this compile-time guarantee is invaluable.

Model Context Protocol: Make Your APIs AI-Ready

RestClient.Net 7 appears to be the first .NET HTTP client with native Model Context Protocol server code generation. MCP is Anthropic’s open standard (now adopted by OpenAI and Google) that lets AI applications like Claude Code or Cursor discover and invoke your API operations.

Here’s how it works:

# Install the MCP generator
dotnet add package RestClient.Net.McpGenerator.Cli

# Generate an MCP server from your OpenAPI spec
dotnet run --project RestClient.Net.McpGenerator.Cli -- \
 --openapi-url api.yaml \
  --output-file Generated/McpTools.g.cs \
 --namespace YourApi.Mcp \
  --server-name YourApi

Now AI agents can discover and call your API operations through natural language. You’ve essentially created a bridge between your enterprise APIs and the GenAI ecosystem. This positions your APIs so that AI can easily leverage them. You can essentially automate your app with an AI agent.

OpenAPI Code Generation with Type Safety

RestClient.Net 7 generates type-safe C# clients from OpenAPI 3.x specifications:

dotnet add package RestClient.Net.OpenApiGenerator

Unlike other generators that just produce DTOs, RestClient.Net generates complete extension methods on HttpClient with Result type aliases for pattern matching:

// All of this is generated from your OpenAPI spec
var user = await httpClient.GetUserById("123", cancellationToken);

var message = user switch
{
    OkUser(var success) => $"User: {success.Name}",
    ErrorUser(ResponseError(var body, 404, _)) => "User not found",
    ErrorUser(ResponseError(_, var status, _)) when status >= 500 => 
        "Service unavailable",
    ErrorUser(ExceptionError(var ex)) => $"Network error: {ex.Message}",
};

Notice how the generated code maintains compile-time safety throughout. If you add a new error type to your result type, every switch expression fails to compile until you handle it. It makes the error handling impossible to miss.

Design Philosophy: Functional Programming in C#

RestClient.Net 7 embraces functional programming principles:

• Pure functions with no interfaces to mock
• Immutable types throughout (including the Urls library for safe URL construction)
• Zero exceptions - Result types instead of throwing
• Explicit over implicit - all error paths visible

The architecture uses extension methods on HttpClient, which means it works naturally with IHttpClientFactory for proper connection pooling. No more socket exhaustion issues:

var httpClient = httpClientFactory.CreateClient();
var result = await httpClient.GetAsync(url, deserialize, deserializeError);

For testing, use the standard DelegatingHandler pattern - no special mocking framework required.

Getting Started

Install the core package:

dotnet add package RestClient.Net

This includes the Result types (Outcome package), Exhaustion analyzer, and Urls library. For OpenAPI generation, add:

dotnet add package RestClient.Net.OpenApiGenerator

Check out the samples folder for complete working examples.

Why This Matters

I’ve been working on RestClient.Net for over seven years, and version 7 represents everything I’ve learned about making HTTP calls safely and reliably. The combination of Result types, exhaustive pattern matching, and MCP integration creates something unique in the .NET ecosystem.

If you’re building AI-powered applications, need compile-time guarantees for critical systems, or just want to stop debugging production crashes from missing error cases, give RestClient.Net 7 a try. The analyzer will make your life easier.

The package targets .NET Standard 2.1, which means you can use it with .NET Framework 4.5+ through .NET 9+, supports all platforms, and maintains 100% test coverage with a 100%+ mutation score according to Stryker Mutator. It has an MIT license and is ready for production use.

Try it: Install the package and experience compile-time safety with exhaustive pattern matching. Generate an MCP server from your OpenAPI spec. Let the compiler catch bugs before they reach production.

The safest way to make REST calls in C# is here.

Why AI-Generated Content?

This is a small blog, and I don’t have unlimited time to deliver content. However, I want to deliver content that is of the same quality as prior to AI or better, and I want to deliver more of it. AI allows me to do this. ChatGPT alone does not produce well-written content, but a combination of Claude AI Research and OpenAI Deep Research with AI agents like Claude Code produces amazing content that draws on extensive sources.

Google’s AI Summaries Impacted My Traffic

Recently, my monthly statistics took a pounding. It wasn’t quite clear why this happened. At first, I thought it was because of changes to Google’s algorithm, but then I learned that Google’s AI summaries caused a devastating drop in many websites.

It turns out that AI-generated content does not hurt Google rankings, but I cannot justify spending the amount of time I was spending on writing content when the returns are diminishing.

My Commitment

I am committed to posting informative, original and accurate content on this website. I will meticulously review all content, edit it for readability and accuracy, and ensure the same high level of quality that this website has always maintained.

So far, what I’m seeing is that AI research tools greatly enhance my ability to provide accurate background information, ensure links are correct and provide plenty of further reading.

Content Changes

The content on this website is changing. I will post more long-form articles, with a greater emphasis on research and a reduced emphasis on tutorials. This isn’t because AI creates a firehose of cheap content for this purpose. This is because this is the kind of content that I have always wanted to post on this blog, but it was too time-consuming without AI. Moreover, AI makes code samples trivial, and few people click through to my tutorials just for the purpose of seeing tutorials that AI can often write for them.

As always, please report issues on the issues section to improve article quality.

A comprehensive systematic review of 107 studies across 29 countries found that screen time didn’t even reach statistical significance as a predictor of outdoor play in most studies examined. Meanwhile, economic and environmental factors were the real drivers. We’ve dismantled everything that made outdoor play possible. Then, various parties dared to blame parents for the mess we created.

Australian Government Social Media Ban

The Australian government is in the process of banning social social media for children under sixteen. This article is part of a series I am writing about this topic. I encourage you to read this open letter, and write to the relevant people who can make changes to this process.

• Anika Wells MP — Anika.Wells.MP@aph.gov.au (aph.gov.au)
• Minister Wells (Communications Office) — Minister.Wells@mo.communications.gov.au (anikawells.com.au)
• Michelle Rowland MP — via contact form (Attorney-General) on ministers.ag.gov.au (ministers.ag.gov.au)
• Minister Rowland (Communications) — Minister.rowland@mo.communications.gov.au (Infrastructure Ministers Australia)

When Yards Become Luxury Goods

The NET-Works longitudinal study followed 531 children over three years using objective measurements. It made a critical finding: each additional hectare of yard space increased children’s physical activity by 12.72 minutes per week. This isn’t a wishy-washy correlation. It’s proven causation, with rigorous methodology controlling for previous activity levels and confounders. Yet, housing affordability has reached crisis levels. The Economic Policy Institute found that 29% of working families with children can’t afford basic necessities, including adequate housing. When housing costs consume family budgets, kids’ enrichment activities, including outdoor play, often get jettisoned.

The Canadian Multi-Site Study revealed the harsh reality. Rural children receive 8.4 hours of outdoor play per week, while urban kids receive only 6.8 hours. This isn’t about screens. Urban children don’t have more devices than rural kids. It’s about space. When urban families are stuck in apartments, rentals, and properties without yards, children’s indoor lives reflect economic constraints, not parental failures. The evidence confirms what struggling families already know: outdoor play has become a privilege of property ownership.

Vanished Infrastructure And Fortress Childhood

The way we parent has changed over time. In 1971, 80% of seven and eight-year-olds travelled to school independently. By 1990, that figure crashed to just 9%. That’s an 88% decline that happened decades before smartphones even existed. This transformation reflects fundamental changes in community design and social expectations. It’s not a technology apocalypse.

The UK shows just how far infrastructure has collapsed: 793 playgrounds closed over the past decade, with public play area spending crashing 44% since 2017. Meanwhile, organised activities have replaced free play, with families now forking out $883 per sport per child, creating a two-tier system where outdoor engagement is financially accessible only to those who can afford it. Barker and colleagues found that kids in heavily structured activities showed “greater challenges with self-directed executive function.” Yet, parents get judged whether they can afford organised sports or have to rely on free screen-based activities.

The fear of crime significantly influences parental decisions regarding outdoor play. Mothers are more likely than fathers to report such fears due to heightened vulnerability concerns for their children. Research shows that parents respond to neighbourhood violence by avoiding certain locations, which limits activity times and requires them to supervise their siblings. The Fragile Families Study found that mothers’ outdoor play fears correlated with neighbourhood poverty and low collective efficacy. It had little to do with actual crime rates. These fears reflect genuine structural problems. Communities often feature car-centred design, lack sidewalks, and are built as if children don’t exist.

The Screen Time Myth Crumbles Under Scrutiny

Meta-analyses by leading researchers like Amy Orben and Andrew Przybylski consistently find tiny or nonexistent effects when proper controls are applied. The GECKO Drenthe Birth Cohort’s longitudinal data revealed that the supposed displacement effect is laughably minimal. Every additional 10 minutes of daily screen time correlated with just one minute less outdoor play. Socioeconomic status proved a significant predictor of both behaviours. At 3-4 years, low-income children showed more outdoor play. By the ages of 10-11, high-income children had caught up in outdoor play and showed less screen time at higher usage levels, while patterns suggested that low-income children had relatively more screen time.

Orben’s analysis of 17,247 adolescents found technology use explained at most 0.4% of wellbeing variance. Wearing glasses showed stronger negative associations than screens. When researchers preregistered their analyses to prevent cherry-picking results, screen effects basically disappeared. The evidence is clear: apparent screen impacts vanish when studies control for family income, neighbourhood quality, and parental resources. These are the actual determinants of childhood experiences.

Research from Finland, where children maintain high outdoor engagement despite full technology access, proves screens don’t inherently reduce outdoor play. Finnish schools mandate 15-minute outdoor breaks between 45-minute classes, regardless of the weather. This demonstrates that cultural and structural support trumps any supposed screen magnetism.

Individual Differences And Systemic Blame

Not all kids are wired for rough-and-tumble outdoor play. Research from the University of Valencia found 42-88% of autistic children and 50% of children with ADHD experience sensory processing differences that affect activity preferences. These children may find outdoor environments overwhelming, regardless of whether screens are available. Their needs reflect neurology, not parenting failures.

Parents often experience significant confusion and stress when making decisions about screen time. Research shows mothers tend to be more restrictive about screen time than fathers, who take a more relaxed approach. Yet, both struggle with unclear and conflicting guidelines from experts. This is not parental failure. It reflects the impossible position parents face: navigating ubiquitous digital technology without consistent evidence-based guidance. This follows what Christopher Ferguson calls the “Sisyphean cycle of technology panics”. Every generation’s new technology becomes the scapegoat for complex social problems. The pattern repeats: radio, television, video games, now smartphones, all blamed for issues actually rooted in economic inequality.

The childcare crisis exposes this cruel dynamic. 46% of unemployed mothers cite childcare problems as their reason for leaving the workforce. Quality childcare is devouring huge chunks of modest incomes. So, screens become a necessity, not a choice. As one researcher noted, the idea that all families can fill evenings with “enriching games of chess” rather than screens reflects profound economic privilege.

When Barriers Are Removed, Children Play

The evidence becomes crystal clear when you examine what happens when barriers are removed. Australia’s REVAMP study documented a 670% increase in play area visitation after playground installation, with no changes to screen policies. Belgium’s Play Streets intervention, temporarily closing streets to traffic, increased children’s outdoor play from 2 to 3 days weekly, with 62% of parents reporting it replaced screen time. Children had full device access but chose outdoor play when given safe and accessible spaces.

The systematic review of 107 studies found the factors that actually predict outdoor play: yard access, neighbourhood greenness, traffic safety, parental support, and weather. Screen time appeared nowhere on this list. When economic barriers were removed through free programs, safe streets, or quality public spaces, children naturally engaged outdoors, regardless of their access to technology.

Stop Gaslighting Parents

The research reveals a harsh reality: society has systematically eroded the conditions necessary for outdoor childhood, driven by housing costs that force families into apartment complexes without yards, the elimination of public play spaces, car-centric community design, and excessive work demands. Research shows parents’ safety concerns severely restrict children’s free play, with mothers particularly affected by the “culture of fear”. They internalise the belief that allowing unsupervised outdoor play would label them a “bad parent”. This is true even when actual risks are disproportionately small.

The evidence is crystal clear: children don’t lack outdoor play because of screens. They lack it because adults built a world hostile to childhood, eliminated public goods that supported play, and created economic conditions forcing impossible choices onto families. Devices are only a scapegoat. Until we address housing affordability, rebuild public play infrastructure, design walkable communities, and support working families with real childcare solutions, blaming parents for excessive screen time remains nothing other than gaslighting.

Note that some or all of the content here was written with the assistance of AI. View the AI Content Policy

Key Takeaways: AI coding agents are IDE-based (Cursor, Copilot, Cline), CLI-based (Claude Code, Aider), or cloud-based (Devin). Build custom agents with LangChain/LangGraph. Python dominates the AI agent space. Agents will change how we write code within 5 years.

AI agents are new LLM (AI) based tools tools that can really enhance your productivity. As AI agents for software development mature, they are transforming how we approach coding, testing, and deployment tasks. This article introduces you to the various tooling available right now, talks a little about the theory and mentions how development-based AI agents might evolve over the next few years.

What Are AI Agents?

AI agents are virtual assistants that can take action to achieve specific goals on your behalf. According to Oracle,

AI agents are software entities that can be assigned tasks, examine their environments, take actions as prescribed by their roles, and adjust based on their experiences.

They can operate autonomously, use tools, and make and implement plans. This is different from something like ChatGPT, which simply responds to your messages.

For example, you could create an agent to know everything about your company’s product catalog so it can draft detailed responses to customer questions or automatically compile product details for an upcoming presentation.

Microsoft

The term “agentic AI” refers to systems that actively pursue goals and objectives versus merely performing simple tasks or responding to queries.

What are Software Development AI Agents or Coding Agents?

Most agents perform specific types of tasks. Coding agents perform software development tasks like writing or refactoring code, writing tests, or performing other software development activities. They have access to your code and can run CLI tools to perform tasks on your computer.

Types of Coding Agents

IDE-Based Agents

IDE-based AI agents are built into your development environment. In any AI coding assistant tools comparison, these rank among the most accessible options. They offer real-time assistance as you code. These tools provide code completion with AI and automated refactoring and can respond to natural language. They usually have a chat interface, much like ChatGPT. Most importantly, the have built-in AI agents that have access to your code and can edit it directly as you work.

Examples:

• Cursor: A popular AI-powered code editor based on a fork of Vscode that offers features like intelligent code completion and real-time assistance[5].

• GitHub Copilot: GitHub’s flagship AI integration product. This VSCode extension recently gained an AI agent.

• Cline: Another Vscode extension with similar agent functionality to Cursor. This agent has a pay-as-you-go model but tends to be more accurate than the others, in my experience.

CLI-Based Agents

CLI agents allow developers to interact with the terminal using natural language. You can give instructions in plain English instructions and the agent will attempt to execute the commands to achieve your goals.

Examples:

• Nimble agent: This my own open source porject. It’s not complete, but I am looking for contributors. It’s a LangChain, CLI based AI coding assistant and library aimed at fixing common issues that exist in other AI agents.

• Claude code: This is a very popular agent from Anthropic, the maker of the Claude model. This has a pay-as-you-go model and uses the Claude model.

• Aider This has emerged as a very popular and stable open-source tool and allows you to BYO API key.

Cloud-Based Agents

Cloud-based AI agents operate remotely, offering powerful capabilities without the constraints of local computing resources.

Examples:

• Devin.ai: boasts the ability to act as a virtual programmer in the cloud but with a pretty hefty price tag.

• Amazon Q Developer: A cloud based AI coding agent from Amazon.

Agent Frameworks

You can build your own AI agent. Agents extend basic LLM functionality. This usually involves getting the LLM to produce a plan to achieve the goal and then executing that plan in steps with tools. Surprisingly, it’s not that hard, and you can build one with no framework at all in your favorite language.

However, the game is changing so quickly that it will be almost impossible to keep up with the feature sets of all the other AI agents that you can use for free. So, if you do want to build an agent, check out one of these frameworks. You will be able to leverage code that many large companies are already using and get features like MCP Server integration out of the box.

• LangChain specializes in creating multi-step language processing workflows. It excels in tasks like content generation and language translation by chaining together different language model operations. It’s particularly useful for building simple, linear LLM workflows with strong modularity.

• LangGraph takes things further by offering a flexible framework for building stateful applications. It handles complex scenarios involving multiple agents and facilitates human-agent collaboration with features like built-in statefulness and human-in-the-loop workflows.

Python Is King

Frankly, I’m not really sure why ML and AI engineers have opted for Python, especially when Python uses dynamic typing, and this confuses the hell out of AI agents. But this is where the industry is at. However, it’s not all bad. Python does have a great type system if you extend it with type hints.

When working with AI agent frameworks like LangChain, Python’s type hinting system becomes invaluable. Type hints promote clear and reliable code by providing explicit information about the data types your functions expect and return. This makes the code a lot easier for agents to navigate.

Conclusion

AI agents absolutely will change software development. Whether integrated into your IDE, accessible via the command line, or powered by cloud resources, these tools will dramatically increase productivity.

The landscape is rapidly evolving. The competition between established players and newcomers, particularly from China’s tech ecosystem, promises to drive innovation and accessibility in the coming years. There are tonnes of AI agents floating around and they are getting better and better all the time.

Experimenting with these AI agents offers productivity gains today. Your company needs to leverage these tools or they will lose the competitive edge. And you need to learn how to automate some of your jobs because the software engineering profession is changing quickly. Developers won’t be writing the majority of code by hand in five years.

Understanding Flutter Material Design Themes

M3 is Google’s latest design system for building apps and websites. Before looking into theming, you should read up about the design system. A theme in Flutter is a collection of property-value pairs that dictate the appearance of the app’s widgets. ThemeData is the class responsible for holding these properties. Let’s first understand the significance of ThemeData and how it helps in theming.

ThemeData

The ThemeData class encapsulates a Material Design theme’s colors, typography, and shape properties. We typically use it as an argument for the MaterialApp widget, which in turn applies the theme to all descendant widgets.

Creating a Custom Theme

Create a ThemeData instance and assign values to the properties you wish to customize. Let’s create a custom theme and apply it to our Flutter app. You can try this out in Dartpad. Just modify the existing default app there. M3 is now the default design system in Flutter so you don’t need to configure anything. If you are completing a flutter Material 2 to Material 3 migration, you can still explicitly set useMaterial3 to true if you want to make your intentions clear.

import 'package:flutter/material.dart';

ThemeData lightTheme = ThemeData(
  useMaterial3: true, // This is not necessary or recommended anymore.
  colorScheme: ColorScheme.fromSeed(
    seedColor: Colors.pink,
    brightness: Brightness.light,
  ),
  textTheme: const TextTheme(
    displayLarge: TextStyle(fontSize: 32, fontWeight: FontWeight.bold),
    bodyLarge: TextStyle(fontSize: 18),
  ),
);

The most important part of M3 theming is the flutter Material 3 ColorScheme. Instead of setting individual colors, you can use ColorScheme.fromSeed() to generate a complete, harmonious color scheme from a single seed color, enabling flutter dynamic theming with minimal effort. This ensures your app follows M3 color guidelines and has good contrast ratios. It’s also the easiest way to get up and running without needing to harmonize the colors yourself.

Applying the ThemeData Instance

Pass the custom theme to the theme property of the MaterialApp widget.

void main() {
  runApp(
    MaterialApp(
      debugShowCheckedModeBanner: false,
      title: 'Custom Theme Demo',
      theme: lightTheme,
      home: Scaffold(
        body: Center(
          child: ElevatedButton(
            child: Text('Hello, Flutter!'),
            onPressed: () {},
          ),
        ),
      ),
    ),
  );
}

Using the Theme Properties

You can access the ThemeData properties with the Theme.of(context) method. Here’s an example of how to use the headlineMedium named style. You can read more about M3 Typography and scale here.

Text(
  'Hello, Flutter!',
  style: Theme.of(context).textTheme.headlineMedium,
);

Dark and Light Themes

Flutter allows you to define separate themes for dark and light modes. You can set the darkTheme property of the MaterialApp widget. You can use the same seed color for both light and dark themes to maintain color consistency. That means you only need to change the brightness.

ThemeData darkTheme = ThemeData(
  useMaterial3: true,
  colorScheme: ColorScheme.fromSeed(
    seedColor: Colors.pink,  // Same as light theme
    brightness: Brightness.dark,
  ),
  // These modify the default text styles.
  textTheme: const TextTheme(
    displayLarge: TextStyle(fontSize: 32, fontWeight: FontWeight.bold),
    bodyLarge: TextStyle(fontSize: 18),
  ),
);

The ColorScheme.fromSeed constructor automatically adjusts all colors to be appropriate for dark or light mode, and you’ll have the same color harmony in light or dark mode. This ensures a consistent brand identity across both themes.

Applying Dark ThemeData Instance

This example tells Flutter that there are two themes: light and dark. Flutter automatically switches between the two themes based on the device’s brightness settings.

void main() {
  runApp(
    MaterialApp(
      debugShowCheckedModeBanner: false,
      title: 'Custom Theme Demo',
      darkTheme: darkTheme,
      theme: lightTheme,
      home: Scaffold(
        body: Center(
          child: ElevatedButton(
            child: Text(
              'Hello, Flutter!',
            ),
            onPressed: () {},
          ),
        ),
      ),
    ),
  );
}

You can also manually set the theme mode to light or dark using the themeMode property of the MaterialApp widget. If you do this, the Flutter app will ignore your device’s brightness setting and use the theme you specify, which is light in this case.

void main() {
  runApp(
    MaterialApp(
      themeMode: ThemeMode.light,
      debugShowCheckedModeBanner: false,
      title: 'Custom Theme Demo',
      darkTheme: darkTheme,
      theme: lightTheme,
      home: Scaffold(
        body: Center(
          child: ElevatedButton(
            child: Text(
              'Hello, Flutter!',
            ),
            onPressed: () {},
          ),
        ),
      ),
    ),
  );
}

The Importance of ColorScheme in Material Design 3

Flutter widgets pay particular attention to the ColorScheme class in your theme data. ColorScheme is the foundation of M3’s color system and determines how your app’s colors work together.

What is ColorScheme?

ColorScheme defines the complete set of colors used by M3. Using ColorSchemes ensure proper contrast ratios and accessibility. Here are the key color roles included in the class:

• Primary colors: Used for key components and actions
• Secondary colors: Used for less prominent components
• Tertiary colors: Used for contrasting accents
• Error colors: Used for error states
• Surface colors:

Try our new Seed Color Picker, which allows you to see how the seed color affects common widgets in your app. load hfref in new tab ‍

Default colors in Material Design 3

The primary purpose of a ColorScheme is to provide a cohesive set of colors that work together. Components automatically use the appropriate colors from your ColorScheme in M3. This makes it easier to create a consistent color palette while adhering to Material Design guidelines.

You can create a ThemeData with a custom secondary color in the ColorScheme like the code below. However, you should exercise caution because it can break the color harmony of the app. If you do specify a secondary color, you will need to work out if it harmonizes with the other default colors.

ThemeData(
  useMaterial3: true,
  colorScheme: ColorScheme.fromSeed(
    seedColor: Colors.blue,
    secondary: Colors.teal,  // Overrides the secondary color
    brightness: Brightness.light,
  ),
)

While you can override specific colors in the ColorScheme, you’re best of sticking to ColorScheme.fromSeed() without overrides. This ensures all colors work together harmoniously and meet accessibility guidelines.

Identifying How Widgets Get Their Default Color

Widgets get their default color from the ColorScheme. Each widget has a set of specific properties that define the various colors it uses. For example, TextButton gets the foreground text color from ColorScheme.primary. In this example, the button’s text displays as green. This example demonstrates how changing the primary color changes the button’s color.

import 'package:flutter/material.dart';

void main() => runApp(
      MaterialApp(
        theme: ThemeData(
          brightness: Brightness.light,
          colorScheme: ColorScheme.fromSeed(
            seedColor: Colors.blue,
          ).copyWith(
            primary: Colors.green,
          ),
        ),
        debugShowCheckedModeBanner: false,
        home: Scaffold(
          body: TextButton(
            onPressed: () {},
            child: const Text('test'),
          ),
        ),
      ),
    );

‍

Unfortunately, there is no one-size-fits-all way to determine which property of the ColorScheme the widget uses because they use different color properties for their default color. The primary sources for learning these are a) the Flutter source code and b) the documentation.

You won’t always find the answer in the documentation, so look at the widget’s source code. Flutter is open-source. You can view the source code for any widget to see exactly how it works. Simply ctrl+click (or cmd+click on macOS) on the widget name in your editor if you are using an IDE like VSCode or Android Studio. This should take you to the definition in the source code.

For example, buttons have a defaultStyleOf method that returns a ButtonStyle. This code is from the Flutter source code for _TextButtonDefaultsM3, which shows you how the TextButton widget picks up the foreground color from the ColorScheme.primary property. Notice how the code applies difference opacity values to the colors depending on the state of the button. Also notice how the background color for TextButton is set to transparent, instead of a M3 color.

class _TextButtonDefaultsM3 extends ButtonStyle {
  _TextButtonDefaultsM3(this.context)
   : super(
       animationDuration: kThemeChangeDuration,
       enableFeedback: true,
       alignment: Alignment.center,
     );

  final BuildContext context;
  late final ColorScheme _colors = Theme.of(context).colorScheme;

  @override
  MaterialStateProperty<TextStyle?> get textStyle =>
    MaterialStatePropertyAll<TextStyle?>(Theme.of(context).textTheme.labelLarge);

  @override
  MaterialStateProperty<Color?>? get backgroundColor =>
    const MaterialStatePropertyAll<Color>(Colors.transparent);

  @override
  MaterialStateProperty<Color?>? get foregroundColor =>
    MaterialStateProperty.resolveWith((Set<MaterialState> states) {
      if (states.contains(MaterialState.disabled)) {
        return _colors.onSurface.withOpacity(0.38);
      }
      return _colors.primary;
    });

  @override
  MaterialStateProperty<Color?>? get overlayColor =>
    MaterialStateProperty.resolveWith((Set<MaterialState> states) {
      if (states.contains(MaterialState.pressed)) {
        return _colors.primary.withOpacity(0.1);
      }
      if (states.contains(MaterialState.hovered)) {
        return _colors.primary.withOpacity(0.08);
      }
      if (states.contains(MaterialState.focused)) {
        return _colors.primary.withOpacity(0.1);
      }
      return null;
    });

  @override
  MaterialStateProperty<Color>? get shadowColor =>
    const MaterialStatePropertyAll<Color>(Colors.transparent);

  @override
  MaterialStateProperty<Color>? get surfaceTintColor =>
    const MaterialStatePropertyAll<Color>(Colors.transparent);

  @override
  MaterialStateProperty<double>? get elevation =>
    const MaterialStatePropertyAll<double>(0.0);

  @override
  MaterialStateProperty<EdgeInsetsGeometry>? get padding =>
    MaterialStatePropertyAll<EdgeInsetsGeometry>(_scaledPadding(context));

  @override
  MaterialStateProperty<Size>? get minimumSize =>
    const MaterialStatePropertyAll<Size>(Size(64.0, 40.0));

  // No default fixedSize

  @override
  MaterialStateProperty<double>? get iconSize =>
    const MaterialStatePropertyAll<double>(18.0);

  @override
  MaterialStateProperty<Color>? get iconColor {
    return MaterialStateProperty.resolveWith((Set<MaterialState> states) {
      if (states.contains(MaterialState.disabled)) {
        return _colors.onSurface.withOpacity(0.38);
      }
      if (states.contains(MaterialState.pressed)) {
        return _colors.primary;
      }
      if (states.contains(MaterialState.hovered)) {
        return _colors.primary;
      }
      if (states.contains(MaterialState.focused)) {
        return _colors.primary;
      }
      return _colors.primary;
    });
  }

  @override
  MaterialStateProperty<Size>? get maximumSize =>
    const MaterialStatePropertyAll<Size>(Size.infinite);

  // No default side

  @override
  MaterialStateProperty<OutlinedBorder>? get shape =>
    const MaterialStatePropertyAll<OutlinedBorder>(StadiumBorder());

  @override
  MaterialStateProperty<MouseCursor?>? get mouseCursor =>
    MaterialStateProperty.resolveWith((Set<MaterialState> states) {
      if (states.contains(MaterialState.disabled)) {
        return SystemMouseCursors.basic;
      }
      return SystemMouseCursors.click;
    });

  @override
  VisualDensity? get visualDensity => Theme.of(context).visualDensity;

  @override
  MaterialTapTargetSize? get tapTargetSize => Theme.of(context).materialTapTargetSize;

  @override
  InteractiveInkFeatureFactory? get splashFactory => Theme.of(context).splashFactory;
}

Override Default Colors For Widgets

You can override colors for a specific widget at the theme level. This can be a shortcut to finding the ColorScheme default color, but it means you only change the color for a given widget. Widgets that should have the same colors according to M3 may end up with different colors. If you need to override colors, there are three levels where you can do this:

ColorScheme Level

Modify the entire color scheme by adjusting the seed color or overriding specific scheme colors.

Widget Theme Level

Customize colors for all instances of a particular widget type using component themes.

Individual Widget Level

Override colors for specific widget instances.

Tips:

• Always start with ColorScheme.fromSeed() for your base colors
• Try to use the default color assignments before overriding
• When overriding, prefer higher-level overrides (ColorScheme > Component Theme > Individual Widget)
• Consider accessibility and contrast when overriding colors
• Use WidgetStateProperty (formerly MaterialStateProperty) for state-dependent colors

import 'package:flutter/material.dart';

void main() => runApp(
      MaterialApp(
        debugShowCheckedModeBanner: false,
        theme: ThemeData(
          // 1. ColorScheme Level: Adjust the entire color scheme
          colorScheme: ColorScheme.fromSeed(
            seedColor: Colors.blue,
            // Override specific scheme colors if needed (not recommended)
            secondary: Colors.teal,
          ),
          // 2. Component Theme Level: Customize all ElevatedButtons
          elevatedButtonTheme: ElevatedButtonThemeData(
            style: ButtonStyle(
              backgroundColor: WidgetStateProperty.resolveWith<Color?>(
                (Set<WidgetState> states) {
                  if (states.contains(WidgetState.disabled)) {
                    return Colors.grey.withValues(alpha: 0.5);
                  }
                  return Colors.blue;
                },
              ),
            ),
          ),
        ),
        home: Scaffold(
          body: Center(
            child: Column(
              mainAxisAlignment: MainAxisAlignment.center,
              children: [
                // Uses the component theme
                ElevatedButton(
                  onPressed: () {},
                  child: const Text('Default Theme Button'),
                ),
                const SizedBox(height: 16),
                // 3. Individual Widget Level: Override for this instance
                ElevatedButton(
                  onPressed: () {},
                  style: ElevatedButton.styleFrom(
                    backgroundColor: Colors.green,
                  ),
                  child: const Text('Custom Button'),
                ),
              ],
            ),
          ),
        ),
      ),
    );

‍

Complete Example

This example allows you to toggle between the three theme modes to see how the dark and light themes look. You can modify the code to check out how the different colors apply to the widgets.

Staying Up To Date

Flutter’s implementation of M3 is always evolving. Some Flutter releases involve breaking changes to how colors and theming for M3 work. You can stay up to date with the latest changes on the offical Flutter documentation website.

Introduce new ColorScheme roles for Material 3

Breaking changes and migration guides

What’s new in the docs

Modifying Typography with TextStyles

Typography is an important aspect of Material Design, and Flutter’s ThemeData allows you to customize the typography of your app. This includes adjusting font sizes, weights, and colors for different text styles. The textTheme property of ThemeData contains a TextTheme object, which in turn has a set of predefined TextStyle properties. These properties represent different text styles like headlines, body text, captions, etc. You can modify the TextStyle properties to customize the typography for each style. This is an example of setting the font sizes and weights.

ThemeData lightTheme = ThemeData(
  textTheme: const TextTheme(
    displayLarge: TextStyle(
        fontSize: 96, fontWeight: FontWeight.w300, color: Colors.black),
    displayMedium: TextStyle(
        fontSize: 60, fontWeight: FontWeight.w400, color: Colors.black),
    displaySmall: TextStyle(
        fontSize: 48, fontWeight: FontWeight.w400, color: Colors.black),
    headlineMedium: TextStyle(
        fontSize: 34, fontWeight: FontWeight.w400, color: Colors.black),
    headlineSmall: TextStyle(
        fontSize: 24, fontWeight: FontWeight.w400, color: Colors.black),
    titleLarge: TextStyle(
        fontSize: 20, fontWeight: FontWeight.w500, color: Colors.black),
    bodyLarge: TextStyle(
        fontSize: 16, fontWeight: FontWeight.w400, color: Colors.black87),
    bodyMedium: TextStyle(
        fontSize: 14, fontWeight: FontWeight.w400, color: Colors.black87),
    bodySmall: TextStyle(
        fontSize: 12, fontWeight: FontWeight.w400, color: Colors.black54),
    labelLarge: TextStyle(
        fontSize: 14, fontWeight: FontWeight.w500, color: Colors.white),
  ),
);

You can use these styles in your app with the Theme.of(context).textTheme property, and the Text widget’s default TextStyle is bodyMedium. This example shows how to set the text style, how the Text widget picks up the default style, and how to use a named TextStyle from the theme.

Theme Shapes

Defining shapes at the theme level in Flutter ensures your design remains consistent, making your application more intuitive and appealing to users. Shapes in M3 can be simple or complex, adding depth and enhancing the visual hierarchy of the user interface. From subtle round edges to bold, expressive cut corners, shape variations can significantly impact a design’s feel and functionality.

To define shapes at the theme level, specify the shape parameter of the widget’s theme like this.

ThemeData(
  useMaterial3: true,
  cardTheme: CardTheme(
    shape: RoundedRectangleBorder(
      borderRadius: BorderRadius.circular(4.0),
    ),
  ),
)

The theme sets the default shape for the widget, and you can reference the shape from Theme.

Card(
  shape: Theme.of(context).cardTheme.shape,
  child: const SizedBox(
    width: 100,
    height: 100,
  ),
),

This is a complete example. The first card uses the default shape, and the second uses a custom shape.

Conclusion

Grasping Flutter’s M3 themes is key for modern application design, so spend some time on the Material Design website to learn more about the system and how to use it in your apps. Refer back to this guide when you need an overview but remember to take the time to read the official documentation. Also, experiment with themes in Dartpad. This will save you a lot of time. Lastly, remember than you may need to check the actual Flutter code of the widgets to find out where they are getting their default theme values from.

_{Updated Feburary 2025. Previous versions, such as 2024/01/04 are available on GitHub as markdown.}

The Return of a Classic

charts_flutter was a go-to library for many developers looking to integrate charts into their Flutter apps. However, the Google team responsible for this package decided to discontinue work at the beginning of 2023.

Enter nimble_charts, a fork of the beloved charts_flutter, now maintained by the team at Nimblesite. We’ve taken the solid foundation of the original library, turned up the dial on type safety, and added a tonne of golden tests to ensure its long-term stability.

Why Choose Nimble Charts for Your Projects?

charts_flutter was always a winner because of the flexibility, number of chart types, interactive, responsive visualizations, high-level customization, and extensibility. These unique features make it the ideal choice for your data visualization needs. nimble_charts stands out because of the focus on reliability through thorough automated testing. We want to make nimble_charts the go-to package for charts in Flutter, and we plan to do this by making it the most robust Flutter charting package.

The sample app speaks for itself.

Use it online here.

Easy To Use

Integrating Nimble Charts into your Flutter projects is a breeze. You can have stunning charts up and running in no time, making it a user-friendly choice for developers.

Interactive and Responsive Visualizations

Engage your users with charts that aren’t just static images. nimble_charts supports interactivity, allowing users to hover, click, and explore data points for deeper insights. This feature will surely excite data analysts, as it opens up new possibilities for data exploration.

WebAssembly (WASM) Support

Leverage the power of WebAssembly to deliver high-performance web dashboards. Our charts run smoothly in the browser, providing a native-like experience that’s both fast and efficient. Flutter recently added WASM support, and the live sample is made with WASM.

Use it online here.

Customizable and Extensible

Every project is unique, and nimble_charts offers the flexibility to customize your charts to match your application’s look and feel. From colors and fonts to animations and behaviors, make your data visualizations truly your own.

Actively Maintained

nimble_charts benefits from active maintenance. We’re committed to keeping the library up-to-date alongside the Flutter ecosystem. We will prioritize bug fixes, code quality, and testing over new features, but once we’re happy with the level of stability, we will look at adding new features again.

See Nimble Charts in Action

Explore our live demo built with WebAssembly to experience the capabilities of Nimble Charts firsthand. Witness how fluid and responsive your data visualizations can be on the web.

You can select a deselect tags to see the different chart types.

A Nod From The Flutter Community

The revival of this charting library hasn’t gone unnoticed. We’ve already had several pull requests for the library and one influential member of the Flutter community said:

Thank you for bringing back charts!

— Seth Ladd (@sethladd) September 21, 2024

This sentiment echoes the excitement and appreciation we’ve received from developers eager to have a reliable charting solution.

Building Stunning Web Dashboards

Flutter is the right choice for building web dashboards. Flutter is a great UI toolkit for creating stunning apps, but the addition of WASM support introduces a new level of performance and web-readiness.

Data visualization is more than just displaying numbers—it’s about telling a story. With nimble_charts, you can craft dashboards that not only look impressive but also convey meaningful insights. Whether you’re tracking user engagement, monitoring real-time analytics, or presenting quarterly reports, our library provides the tools to make your data shine.

Use Cases

Business Intelligence Dashboards: Keep stakeholders informed with up-to-date metrics.

Financial Reporting: Visualize trends, forecasts, and performance indicators.

Health and Fitness Apps: Track progress and motivate users with engaging visuals.

Educational Tools: Simplify complex concepts through interactive charts.

Nimblesite Is Dedicated to Open Source

We are dedicated to open source. We build components for the Flutter and .NET communities because it’s a great way to give back, and it allows us to remain experts with these packages so we can offer the best level of support for the apps we build with them.

Join the Nimblesite Community

We are very active on GitHub and social media. We’d love it if you would check out our work and engage with us on the socials.

Star Our Repos: Follow our GitHub page and show your support by starring our repos.

Share Your Projects: Showcase how you’re using Nimble Charts in your apps by tagging us on X/Twitter with your creations.

Contribute to Development: To help us improve, contribute code, report issues, or suggest features on the GitHub repo. You can even start a discussion on GitHub.

Stay Updated: Follow our blog and social media for the latest news and updates.

Acknowledgments and License

nimble_charts is a fork of the original charts_flutter package developed by the Google team. We want to express our gratitude to the original creators for their excellent work, which laid the foundation for this project.

nimble_charts is released under the Apache 2.0 license, maintaining the open-source spirit of the original project. We encourage users to review the full license terms on our GitHub repository.

By using and contributing to nimble_charts, you’re not only supporting our efforts but also honoring the work of the original Flutter team at Google who made this possible.

Need a Web Dashboard?

Contact Nimblesite to build a web dashboard for your business: send us an email at sales at nimblesite.co, or fill out the contact form

This article was original published on the Nimblesite website, and the package/repo belong to them.

People often hire us for our technical expertise in building apps, but we also see people making a lot of mistakes that could be hurting their business. You should remember one important thing:

Some horrible apps become wildly successful, and some amazing apps never see the light of day

Creating a robust app that solves user problems and is enjoyable to use is absolutely the most important part of building app development. But, without marketing, you will never gain users to use it. If you’re building an app, you need to think broadly about other aspects that contribute to the success of your app. This guide lists the ten most important aspects and gives you actionable items you can implement.

1. Engage Authentically on Social Media

Social media is a powerful tool for growing your SaaS business. It allows you to engage with your users outside the app itself. Share behind-the-scenes content, product updates, and industry insights to build a community around your brand. Engagement should be genuine. Think about creating content that adds value to your audience’s day-to-day lives rather than just broadcasting advertisements.

Actionable Advice

Create Accounts on Relevant Platforms: Focus on platforms where your target audience is most active. For B2B SaaS, LinkedIn is a must. For consumer-focused apps, consider platforms like Instagram, TikTok, and Pinterest.

Create a Content Calendar: Plan your posts in advance, including a mix of product updates, industry insights, and engaging content such as polls or user-generated content.

Leverage Analytics: Use tools like Google Analytics and native social media insights to track engagement and tweak your strategy based on what resonates with your audience.

2. Produce Valuable Content and Implement Smart SEO

Starting a blog is about more than just improving your site’s SEO. It’s about establishing your brand. Your content should offer original insights, practical advice, and comprehensive analysis that addresses the pain points and aspirations of your target audience.

But, most importantly, it should be entertaining and engaging. This is what the audience will remember and share, and it’s also what modern algorithms are looking for. Focus primarily on the quality and usefulness of your content to ensure alignment with Google’s emphasis on helpful, people-first content.

Actionable Advice:

Direct Users To Your App: put a call-to-action links on your website that link directly to your app in the app stores. This is the most critical point. Your website is the gateway to your app. Put large images of Android and iPhone here so the user picks up the signal that this is how they install your app.

Use Voice Search Optimisation: Voice search will become far more popular in the next few years, so you need to optimise for this.

Follow Google’s Guidelines: Pay attention to Google’s Search Engine Optimization (SEO) Starter Guide and follow its advice. Google is the largest search engine, and its traffic can make or break your app’s success.

Keyword Research: Use tools like Ahrefs or SEMrush to find relevant keywords that your target audience is searching for and incorporate them naturally into your content.

Content Depth: Ensure your articles cover topics thoroughly, using the “Skyscraper Technique” by Brian Dean, which involves creating the best possible content on a topic.

3. Network Effectively

Networking isn’t just about collecting contacts. It’s about creating meaningful partnerships that can lead to growth opportunities. Attend industry conferences, participate in webinars, and engage in community forums. Share your knowledge, learn from others, and keep an open mind about potential collaborations that can drive your business forward.

Actionable Advice

LinkedIn Networking: Regularly post updates and engage with other content in your field. Use LinkedIn’s search to find and connect with potential partners and influencers and read LinkedIn’s documentation.

Attend Industry Events: Whether virtual or in-person, these can be a great way to make connections. Prepare a short introduction and the goals you aim to achieve from each interaction.

Meet Face To Face: If you can, meet people in person. This can be a great way to build trust and rapport. The online world can become a faceless void, and meeting in person can help to humanize your interactions.

4. Fundraising

Fundraising is a critical component of scaling any SaaS business. Prepare clear, concise pitches that not only highlight the unique value proposition of your product but also demonstrate a deep understanding of your market and growth potential. Be transparent about your goals and use data-driven insights to back your assertions.

Actionable Advice

Develop a Clear Pitch Deck: Follow this simple guide to create a pitch deck. Highlight your value proposition, traction, and market opportunity. Tools like Pitch.com can help streamline this process.

Practice Your Pitch: Refine your delivery by practising with mentors or peers, and be prepared to answer tough questions investors might ask.

Connect With VCs and Angel Investors: Use platforms like Wellfound and Crunchbase to find potential investors. Attend pitch events and network with investors to build relationships, particularly in your local area.

Understand Your Metrics: Be prepared to discuss key metrics like customer acquisition cost (CAC), lifetime value (LTV), and churn rate. Investors want to see that you understand your business and have a clear path to growth.

5. Work on Your App’s Store Ratings

Positive app store ratings can significantly influence potential users’ perceptions and decisions. Encourage satisfied customers to leave a review. Be proactive in addressing negative feedback by providing support and updates that resolve issues. Show potential customers that you are responsive and customer-focused.

Actionable Advice

Encourage Reviews: Prompt users to review your app after experiencing key features. Tools like AppFollow can automate this process and manage reviews efficiently. Use the Flutter package in_app_review in Flutter apps to prompt users to leave a review.

Address Negative Feedback: Quickly and professionally respond to negative reviews. This shows potential customers your commitment to customer satisfaction. Try to fix bugs in a timely manner and communicate updates to users.

Leverage Positive Reviews: Share positive reviews on your website and social media to build credibility and trust with potential users. Share them as testimonials to help you do this.

Monitor Ratings and Reviews: Regularly check app store ratings and reviews to identify trends and areas for improvement. Show that you are paying attention by responding to feedback and making necessary changes.

6. Respond to User Feedback

Engage with your users and solicit feedback through surveys, social media, and direct communications. This demonstrates that you value their input and are committed to evolving your product to meet their needs. Use this feedback to inform product updates and customer service improvements, but remember to quantify data where possible.

Qualitative data like social media posts and complaints can influence the decision-making process, but they are not objective metrics. Data-Driven Decision Making is about making decisions based on objective, quantifiable data. Try to transition your analytics collection to facilitate this.

Actionable Advice

Utilize Comprehensive Feedback Tools: Implement tools like Zonka Feedback and SurveySparrow and other customer feedback tools which offer multi-channel feedback collection and real-time analytics.

Automate Feedback Collection: Automate the sending of surveys after specific interactions or periods using tools like Qualaroo to trigger surveys based on user behavior.

Incorporate Advanced Survey Features: Use advanced features like skip logic, branching, and custom themes offered by tools like SoGoSurvey and Qualaroo to create personalized and targeted surveys.

Leverage AI for Feedback Analysis: Tools like Qualaroo offer AI-powered feedback analysis, which can help you understand user sentiments and behaviors at a granular level.

Integrate Feedback with CRM: A CRM system helps you keep track of interaction with your users. Ensure that your feedback tools integrate seamlessly with your CRM system to maintain all customer data in one place.

Optimize Feedback Forms for Mobile Users: Ensure your feedback forms are mobile-optimized. Tools like Google Forms and JotForm offer user-friendly interfaces that work well on mobile devices

7. Utilize Email Marketing Effectively

Email marketing remains a powerful tool for direct communication. Use it to inform subscribers about new features, tips, and company news. Personalize your emails to increase relevance and engagement, and always provide clear value in each communication to keep your audience interested and engaged.

Actionable Advice

Collect Email Addresses: User registrations are the primary means of collecting email addresses for marketing purposes. Once you have these, use tools like Mailchimp or Brevo to manage your email campaigns.

Understand Privacy and Ethical Use of Email: When collecting and using email addresses, ensure you comply with GDPR and other privacy regulations.

Avoid Spamming Your Users: Be mindful of how often you send emails. Too many emails can lead to unsubscribes and a negative perception of your brand. Focus on sending content that you believe your users will find valuable.

Warm up Your Email Domain: If you are sending a lot of emails, you need to warm up your email domain to avoid being marked as spam. This is critical because if your email gets marked as spam, it will be very difficult to get it unmarked.

Personalize Your Emails: Go beyond just inserting the recipient’s name. Tailor content based on the user’s past interactions with your brand, their preferences, and any data you have that can make the content feel more bespoke.

Regularly Test and Optimize: Conduct A/B tests on various elements of your emails, such as subject lines, email bodies, call-to-actions (CTAs), and sending times. This helps you understand what works best for your audience.

Provide Clear and Immediate Value: Each email should offer something valuable to the recipient, whether it’s informative content, a special offer, or an update they’ve requested. This keeps your audience engaged and less likely to perceive your emails as spam.

Use Engaging Subject Lines: Craft subject lines that are concise, clear, and enticing. Avoid clickbait, but ensure they are compelling enough to make recipients want to open the email.

8. Consider the Role of Influencers

You cannot ignore the power of influencers. Influencers are people who have a large following on social media and can influence their audience’s purchasing decisions. Sometimes, they accept money or gifts for favourable content on social media, but ethical influencers will always disclose this.

Partnering with influencers in your niche can help extend your reach and credibility. Choose influencers who align with your brand values and have a genuine interest in your product. This partnership should feel natural to their audience and beneficial to both parties.

Pay close attention to how influencers go about their business. If they are not ethical, it can reflect poorly on your brand. If your audience respects the influencer, they will respect your brand more. If they detect

Actionable Advice

Identify Relevant Influencers: Use tools like BuzzSumo or Traackr to find influencers in your industry who are not only prominent but also align with your brand’s values and audience.

Evaluate Influencer Engagement: Don’t just look at follower counts. Analyze their engagement rates, audience comments, and the quality of interactions influencers have with their followers.

Establish Clear Collaboration Goals: Define what you hope to achieve through the partnership, whether it’s increasing brand awareness, driving sales, or something else. Make sure these goals are known and agreed upon by both parties.

Clear Messaging: Ensure that influencers understand your brand’s messaging and values. Provide them with guidelines and resources to help them create content and ensure that their values align with the messaging you want to convey.

Create Authentic Partnership Strategies: Perceived authenticity is key. Develop content ideas and promotional strategies that feel genuine and resonate with the influencer’s audience. Authenticity is key to the success of influencer campaigns.

Monitor and Measure Results: Monitoring results is critical to success. Set up tracking for metrics such as reach, clicks, conversions, and engagement that result from influencer collaborations. Use this data to assess performance and refine future campaigns.

9. Offer Exceptional Customer Support

Excellent customer support can be a game-changer for SaaS products. Ensure that your support people are knowledgeable, accessible, and ready to solve problems quickly and efficiently. Consider developing a comprehensive knowledge base and using AI-driven tools to provide timely and effective support.

Actionable Advice

Train Your Support Team: Ensure that every team member is thoroughly trained not just on your product and customer service best practices. Regular training sessions help to maintain high standards.

Implement a Multichannel Support System: Utilize various channels such as email, live chat, phone, and social media to make support accessible. Each channel should be integrated to provide a seamless experience for both customers and support staff.

Make it Easy To Contact You: Provide clear contact information on your website and app and ensure that users can easily reach out for help when needed. Nothing frustrates users more than not being able to find help when they need it.

Develop a Comprehensive Knowledge Base: Use a tool like Freshdesk to create detailed FAQs, how-to guides, and troubleshooting articles. This allows customers to find answers quickly on their own and reduces the workload on your support team.

Leverage AI Tools for Efficiency: Implement AI-driven tools, such as chatbots, to handle initial inquiries and common questions, freeing up human agents for more complex issues. Apps like Don’t Spiral demonstrate how AI-driven chat can provide real-time, personalized support to users experiencing relationship anxiety, showing the power of AI beyond traditional customer service.

Regularly Gather Customer Feedback: Use surveys and direct feedback tools to learn from customer interactions. This can guide improvements in your support services.

10. Advertising

Advertising supplements all your other success initiatives. Without an app that users enjoy, advertising won’t work, and without social media and other platforms to help users find information about your app, advertising will be ineffective. But, if everything else is in place, advertising will boost your app’s visibility and lead to new installs and sign-ups

Advertising your app effectively on digital stores is critical for driving downloads and user engagement.

Actionable Advice

Optimize App Store Listings: Ensure that your app’s title, description, and metadata are optimized with relevant keywords to improve visibility for in-store searches. High-quality screenshots and engaging videos can also help attract potential users.

Leverage Search Ads: Utilize search advertising features available in app stores like Google Play Store and Apple App Store. These ads can significantly increase your app’s visibility when users search for related keywords.

Implement ASO (App Store Optimization): Focus on improving your app’s ranking and visibility in the app store through optimization strategies that enhance your app’s relevance and appeal to potential users.

Encourage Reviews and Ratings: Positive reviews and high ratings can improve your app’s credibility and attract more users. Encourage satisfied users to leave feedback.

Use Retargeting Ads: Implement retargeting strategies to re-engage users who have visited your app listing but haven’t downloaded your app.

Conclusion

Building a successful mobile app in 2024 is about much more than just development. You need to take a holistic approach to marketing, customer engagement, and community building. Create people-first content and engage genuinely with your audience. This will allow you to build a strong foundation for your app’s success. The goal is to create value that resonates well beyond the digital screens, fostering a community of loyal users and advocates for your brand.

This article belongs to Nimblesite. Send them an email at sales at nimblesite.co, or fill out the contact form

What are Algebraic Data Types?

The official Dart documentation doesn’t explain ADTs, or Dart’s relationship to ADTs very well. It glosses over the concept and only introduces one aspect of ADTs in Dart. This article gives a broader perspective on ADTs outside of Dart and gives some examples in other languages. If you want some background reading, the Wikipedia article on ADTs is a good place to start.

There are two main categories of ADTs, and it’s important to understand these definitions.

Sum types (also known as tagged unions or variants)

Product types (such as tuples or records)

You can combine these types to create more complex structures, which enables developers to represent data and states in a highly expressive manner.

ADTs in Other Languages

Before we look at Dart’s implementation, we should see how other languages known for their strong functional programming support handle ADTs.

F#

F# is a modern, FP-first, statically-typed language and provides excellent support for ADTs through discriminated unions:

type Shape =
    | Circle of radius: float
    | Rectangle of width: float * height: float
    | Triangle of base: float * height: float

let area = function
    | Circle r -> Math.PI * r * r
    | Rectangle (w, h) -> w * h
    | Triangle (b, h) -> 0.5 * b * h

The Shape type is a discriminated union, which is F#’s implementation of a sum type. It encapsulates three distinct shapes (Circle, Rectangle, and Triangle) within a single type. Each has its own set of parameters. This structure allows for type-safe representation of different shapes without the need for inheritance or interfaces.

The area function demonstrates pattern matching. Importantly, there are only three possible shapes, which allows the compiler to know ahead of time what branches the code can travel down. It is a key feature of ADTs. This is called exhaustiveness checking. It uses a single function to calculate the area for any shape, and the compiler ensures all cases are covered.

If you’re interested, you can read the official Dart specification on this feature.

Kotlin

Kotlin is a modern, hybrid paradigm language like Dart. Like Dart, Kotlin represents ADTs using sealed classes:

sealed class Shape {
 data class Circle(val radius: Double) : Shape()
 data class Rectangle(val width: Double, val height: Double) : Shape()
 data class Triangle(val base: Double, val height: Double) : Shape()
}

val area: (Shape) -> Double = { shape ->
 when (shape) {
 is Shape.Circle -> Math.PI * shape.radius * shape.radius
 is Shape.Rectangle -> shape.width * shape.height
 is Shape.Triangle -> 0.5 * shape.base * shape.height
 }
}

The Benefit of ADTs and Pattern Matching

ADTs give you tools to improve your code design.

Type safety: they provide compile-time guarantees about the structure of data and reduce the need for casting

Exhaustiveness checking: compilers can determine whether or not your code handled all cases with pattern matching.

Expressiveness: you can represent complex domain models clearly and concisely.

Immutability: ADTs encourage immutable data structures, which reduces side effects.

Consider this Dart code. At first glance, it has the right data, but there is a problem. None of the values are mutually exclusive, even though the states that the class represents have mutually exclusive pieces of data.

class AuthState {
  final String? userId;
  final String? errorMessage;
  final bool isLoading;

  AuthState({this.userId, this.errorMessage, this.isLoading = false});

  bool get isAuthenticated => userId != null;
  bool get hasError => errorMessage != null;

  // This allows creation of invalid states
  // e.g., AuthState(userId: "123", errorMessage: "Error")
}

// Usage
void handleAuth(AuthState state) {
  if (state.isLoading) {
    print("Loading...");
  } else if (state.isAuthenticated) {
    print("Welcome, user ${state.userId}");
  } else if (state.hasError) {
    print("Error: ${state.errorMessage}");
  } else {
    print("Please log in");
  }
}

ADTs solve this code-design issue and make accessing this data far safer because you can’t access two pieces of mutually exclusive data at the same time.

ADTs in Dart

Dart 3.0 introduces several new class access modifiers, such as the sealed modifier. This addition brings the ADT approach to Dart and allows for a form of sum type.

Let’s look at how we can improve upon the previous example with ADTs in Dart. Notice that the user id and error message are now mutually exclusive pieces of data. We cannot create a scenario where there is both a userId and an errorMessage. This is the magic of ADTs. We prevent states that shouldn’t exist from occurring in the first place.

sealed class AuthState {}

final class Unauthenticated extends AuthState {}

final class Authenticating extends AuthState {}

final class Authenticated extends AuthState {
  final String userId;
  Authenticated(this.userId);
}

final class AuthError extends AuthState {
  final String errorMessage;
  AuthError(this.errorMessage);
}

// Usage
String handleAuth(AuthState state) => switch(state) {
  Unauthenticated() => "Please log in",
  Authenticating() => "Loading...",
  Authenticated(:final userId) => "Welcome, user $userId",
  AuthError(:final errorMessage) => "Error: $errorMessage"
};

// Example usage
void main() {
  final states = [
    Unauthenticated(),
    Authenticating(),
    Authenticated("user123"),
    AuthError("Invalid credentials"),
  ];

  for (final state in states) {
    print(handleAuth(state));
  }
}

The example above uses a sealed type, AuthState, to declare a fixed set of types that can derive from it. The compiler knows that these are the only possible types, which means it can do exhaustiveness checking.

Exhaustiveness checking forces you to handle all possible states. If you don’t, you will get a compilation error. This removes a whole category of potential exceptions from your code. Without exhaustive cases, your code could end up on an unknown branch, and the code would throw an exception. Then, you’d have to handle the exception at a higher level. ADTs allow you to avoid this need.

Notice that the subtypes use the final class modifier. This is important if you want to preserve the behavior of the class and prevent other classes from inheriting from this type. Still, not using it doesn’t break exhaustiveness checking.

Here is the shape example we saw earlier, but in Dart:

sealed class Shape {}

final class Circle extends Shape {
  final double radius;
  Circle(this.radius);
}

final class Rectangle extends Shape {
  final double width;
  final double height;
  Rectangle(this.width, this.height);
}

final class Triangle extends Shape {
  final double base;
  final double height;
  Triangle(this.base, this.height);
}

double area(Shape shape) => switch (shape) {
      Circle(radius: final r) => 3.14 * r * r,
      Rectangle(width: final w, height: final h) => w * h,
      Triangle(base: final b, height: final h) => 0.5 * b * h
 };

Pattern Matching in Dart

Let’s explore some sophisticated pattern-matching examples in Dart to showcase the power of ADTs. See my library nadz for more complete examples of Result objects as ADTs. This library is also loaded with extension methods to make working with ADTs easier.

sealed class Result<T> {
  const Result();
}

final class Success<T> extends Result<T> {
  final T value;
  const Success(this.value);
}

final class Failure<T> extends Result<T> {
  final String error;
  const Failure(this.error);
}

T match<T, R>(
  Result<R> result,
  T Function(R) onSuccess,
  T Function(String) onFailure,
) =>
    switch (result) {
      Success(value: final v) => onSuccess(v),
      Failure(error: final e) => onFailure(e)
 };

// Usage
void main() {
  final result = Success(42);
  final output =
      match(result, (value) => "Success: $value", (error) => "Failure: $error");
  print(output); // Output: Success: 42
}

The above is an example of a Result object that can either have a state of Success or Failure and allows you to specify what mutually exclusive data these two states have.

Here’s a more complex example using nested patterns:

import 'dart:math';

sealed class Tree<T> {
  const Tree();
}

class Leaf<T> extends Tree<T> {
  final T value;
  const Leaf(this.value);
}

class Node<T> extends Tree<T> {
  final Tree<T> left;
  final Tree<T> right;
  const Node(this.left, this.right);
}

int sum(Tree<int> tree) => switch (tree) {
      Leaf(value: final v) => v,
      Node(left: final l, right: final r) => sum(l) + sum(r)
 };

num depth<T>(Tree<T> tree) => switch (tree) {
      Leaf() => 0,
      Node(left: final l, right: final r) => 1 + max(depth(l), depth(r))
 };

// Usage
final tree =
    Node(Node(Leaf(1), Leaf(2)), Node(Leaf(3), Node(Leaf(4), Leaf(5))));

main() {
  print(sum(tree)); // Output: 15
  print(depth(tree)); // Output: 3
}

ADTs are a great choice for tree structures in Dart because any element could be a Node or a Leaf.

Avoid Casting and Unnecessary Assignments

FP encourages the use of expressions. Expressions are generally more concise than imperative statements. Instead of writing code in a step-by-step way, expressions return the value of one or more operations. Pattern matching with constructs like Dart switch expressions allow you to write fluid expressions that don’t require unnecessary variable assignments or casting.

While this point is not strictly about ADTs, it illustrates how a shift towards expressions over statements can generally improve your code. ADTs help you move your code in this direction.

Consider these three functions.

import 'dart:convert';

void main() {
  final jsonMap = jsonDecode('{ "test": 123 }');

  final one = numberWithCasting(jsonMap as Map<String, dynamic>);
  final two = numberWithTypePromotion(jsonMap);
  final three = numberWithSwitch(jsonMap);

  print(one);
  print(two);
  print(three);
}

int numberWithCasting(
  Map<String, dynamic> jsonMap,
) {
  if (jsonMap['test'] is int) {
    return jsonMap['test'] as int;
 }
  return -1;
}

int numberWithTypePromotion(
  Map<String, dynamic> jsonMap,
) {
  final test = jsonMap['test'];
  if (test is int) return test;
  return -1;
}

int numberWithSwitch(
  Map<String, dynamic> jsonMap,
) =>
    switch (jsonMap['test']) {
      final int value => value,
 _ => -1,
 };

Notice that the first two functions require you to either cast the type to int with as or make a variable assignment. There is nothing inherently wrong with the extra assignment in numberWithTypePromotion, but the naming of the variable can detract from the readability of the function and make the code more verbose.

On the other hand, casting is generally bad because it can cause exceptions. Avoiding the as keyword is generally advisable, even in cases where it obviously does not cause an issue. If someone refactors this code, they may separate the type check from the cast, and then the cast becomes dangerous.

The third function, numberWithSwitch, addresses both issues by eliminating the need for a variable assignment and combining the type check with the switch. The switch only returns the value if the expected type occurs and allows us to safely deal with other cases.

Records

Records are another recent addition to the Dart language and add further expressiveness to ADTs. Here is a simple example of a record type, which is a product type in Dart.

typedef Point = (double x, double y);

double distanceFromOrigin((double, double) point) {
  final (x, y) = point;
  return sqrt(x * x + y * y);
}

A Complete Example

This example combines several different types of data into a record and gives you an example of how you might use it in switch expression with pattern matching

// Sealed class representing different account statuses
sealed class AccountStatus {}

// Represents an active user account
class Active extends AccountStatus {
  final DateTime lastActive;
  Active(this.lastActive);
}

// Represents a suspended user account
class Suspended extends AccountStatus {
  final String reason;
  Suspended(this.reason);
}

// Represents a deactivated user account
class Deactivated extends AccountStatus {
  final DateTime deactivationDate;
  Deactivated(this.deactivationDate);
}

// Record type representing a user profile with bio, interests, and account status
typedef UserProfile = (
  String? bio,
  List<String> interests,
  AccountStatus status
);

String analyzeProfile(UserProfile profile) => switch (profile) {
      // New or minimal active profiles
      (null, [], Active(lastActive: final date)) =>
        "New user, last active on ${date.toLocal()}. Needs to complete profile.",
      (String b, [final single], Active()) =>
        "Minimal profile: '$b'. Only interested in $single. Very active.",

      // Active coder profiles
      (_, ["coding", final second, final third, ...], Active()) =>
        "Active coder also interested in $second and $third.",

      // Other active profiles
      (String(), [], Active()) ||
      (String(), [_, _], Active()) ||
      (String(), [_, _, _, ...], Active()) =>
        "Active user with varying interests.",
      (null, [_], Active()) ||
      (null, [_, _], Active()) ||
      (null, [_, _, _, ...], Active()) =>
        "Active user without bio, with varying interests.",

      // Suspended profiles
      (_, [_, _, ...], Suspended(reason: final r)) =>
        "Suspended account ($r) with multiple interests.",
      (String() || null, [], Suspended()) =>
        "Suspended account with no interests.",
      (String() || null, [_], Suspended()) =>
        "Suspended account with one interest.",

      // Deactivated profiles
      (String b, final ints, Deactivated(deactivationDate: final date)) =>
        "Deactivated on $date. Bio: '$b'. Had ${ints.length} interests.",
      (null, [], Deactivated()) =>
        "Deactivated account without bio or interests.",
      (null, [_], Deactivated()) =>
        "Deactivated account without bio, with one interest.",
      (null, [_, _], Deactivated()) =>
        "Deactivated account without bio, with two interests.",
      (null, [_, _, _, ...], Deactivated()) =>
        "Deactivated account without bio, with multiple interests.",
    };

void main() {
  final now = DateTime.now();
  final profiles = <(String?, List<String>, AccountStatus)>[
    // New active user
    (null, <String>[], Active(now)),

    // Minimal active profile
    ("Dart lover", ["programming"], Active(now)),

    // Active coder profile
    ("I code, therefore I am", ["coding", "philosophy", "coffee"], Active(now)),

    // Active user with varying interests
    ("Eclectic", ["music", "sports", "cooking", "travel"], Active(now)),

    // Active user without bio, with varying interests
    (null, ["reading", "writing", "arithmetic"], Active(now)),

    // Suspended profile with multiple interests
    ("Flutter enthusiast", ["mobile", "web", "AI"], Suspended("Spam")),

    // Suspended profile with no interests
    ("Oops", [], Suspended("Violation of terms")),

    // Suspended profile with one interest
    (null, ["trouble"], Suspended("Inappropriate behavior")),

    // Deactivated profile with bio and interests
    ("Ex-user", ["reading", "writing"], Deactivated(DateTime(2023, 12, 31))),

    // Deactivated profile without bio or interests
    (null, [], Deactivated(DateTime(2023, 11, 15))),

    // Deactivated profile without bio, with one interest
    (null, ["gaming"], Deactivated(DateTime(2023, 10, 1))),

    // Deactivated profile without bio, with two interests
    (null, ["music", "dance"], Deactivated(DateTime(2023, 9, 15))),

    // Deactivated profile without bio, with multiple interests
    (
      null,
      ["art", "science", "history", "literature"],
      Deactivated(DateTime(2023, 8, 1))
    ),
  ];

  // Analyze and print results for each profile
  for (final profile in profiles) {
    print(analyzeProfile(profile));
    print('---'); // Separator for readability
  }
}

Output

Minimal profile: 'Dart lover'. Only interested in programming. Very active.

Active coder also interested in philosophy and coffee.

Active user with varying interests.

Active user without bio, with varying interests.

Suspended account (Spam) with multiple interests.

Suspended account with no interests.

Suspended account with one interest.

Deactivated on 2023-12-31 00:00:00.000. Bio: 'Ex-user'. Had 2 interests.

Deactivated account without bio or interests.

Deactivated account without bio, with one interest.

Deactivated account without bio, with two interests.

Deactivated account without bio, with multiple interests.

Notice that the switch cases allow you to bind variables. For example lastActive becomes date. Also notice that we don’t need to do a null check on Bio: '$b' because the match already determined that the value is not null.

Conclusion

Dart has taken a significant step towards supporting the functional programming paradigm. These features enable developers to write more expressive, type-safe, and maintainable code and it bridges the gap between Dart and languages traditionally associated with functional programming.

The access modifiers enable powerful ADT features, and if you start thinking in FP style, your code design becomes more natural and fluent. There are fewer opportunities for exceptions to occur. It probably won’t be obvious until you try it a few times for yourself, but this is a game changer for your code design game.