In the dynamic world of software development, speed can be a defining factor in productivity and innovation. Recently, a groundbreaking development emerged that promises to transform how we approach TypeScript compilation. A fully compatible TypeScript compiler written in Rust has arrived, and it’s turning heads by being nearly three times faster than its Go counterpart. This revelation is a testament to the increasing influence of Rust in the tech industry and its potential to enhance performance drastically.

To contextualize this remarkable feat, it’s important to understand what a TypeScript compiler does. Essentially, it handles two primary tasks: type checking and converting TypeScript code into JavaScript. The latter process is typically swift, thanks to tools like ESB build that simply strip out types, but it’s the type checking that can slow things down immensely on large codebases. Enter the new Rust and Go compilers, specifically engineered to expedite the sluggish type-checking process.

Based on content from Better Stack

Our experiments comparing JavaScript, Go, and Rust compilers revealed significant differences in processing times. Utilizing the TypeScript repository with 793 files and approximately 380,000 lines of code, the benchmarks were telling. In scenarios with valid types and various error conditions, JavaScript consistently lagged, while Go showed substantial improvements, taking seconds compared to JavaScript’s seven-second average. However, Rust stole the spotlight, showcasing a staggering speed that overshadowed both Go and JavaScript. On average, Rust proved to be 24 times faster than JavaScript and almost three times faster than Go, delivering type-checking speeds that are crucial for developers working with extensive codebases.

The journey of this Rust compiler is as intriguing as its performance. While Microsoft’s Go compiler took nearly two years to develop, the Rust version emerged in just three weeks, marking a swift entry into the tech arena. This accelerated development was made possible by AI agents and a robust test suite of over 13,000 programs, which ensured the compiler delivered precise error reports analogous to Microsoft’s compiler. Engineers utilized AI-driven tooling to meticulously port functions from Microsoft’s Go implementation to Rust, function by function, crafting a reliable and fast compiler.

But why choose Rust for this task? The answer lies in its design and intended use case. Cloudflare, aiming to integrate developer tools within sandboxes and browsers, needed a robust compilation environment. Rust, unlike Go, doesn’t require a garbage collector, making it an ideal candidate for web assembly packaging — a crucial feature for Cloudflare’s vision. Interestingly, the Rust compiler’s performance benefits might not solely arise from Rust’s language design; some optimization techniques used in the Rust port are already influencing future versions of Microsoft’s Go release.

As for what’s next, the Rust port, currently developed within the OXC toolchain from the creators of Vite, is set to advance further. Though not yet integrated into existing tools, its potential for use in type-aware lint rules is a promising development avenue. For those keen to experience the speed and efficiency of this Rust port firsthand, the project is available for exploration, promising a glimpse into what could be the future of TypeScript compilation.

The advent of this Rust compiler underscores the ever-evolving landscape of programming tools and the growing role of collaboration between traditional engineering and AI capabilities. As we continue to push the bounds of what’s possible with languages like Rust, we stand on the precipice of a new era in software development — one where speed and efficiency go hand in hand with innovation.

For further exploration on this topic, check out the relevant links and learn more about the projects and teams pioneering these advancements:

• Learn more about the TypeScript Rust port: Cloudflare Blog
• Explore the GitHub repository: OXC Project
• Additional resources and tutorials from Better Stack: Better Stack Community
• See the exciting projects Better Stack is working on: BetterStackHQ GitHub

Welcome to F# Weekly,

A roundup of F# content from this past week:

News

• Serde.FS 1.0 is out
• FSharp.CloudEdge

Microsoft News

• Get Ready for .NET Conf 2026!
• Help Shape the Future of .NET: Take the 2026 .NET Developer Survey
• Delivering Skills in NuGet packages
• Modernize your .NET apps for Windows Arm64 with GitHub Copilot
• GitHub Copilot in JetBrains Air: Plugin vs. Agent
• Publish Visual Studio Marketplace extensions securely with Trusted Publishing
• Intelligent Terminal Sidebar Brings New Capabilities

Videos

• My F# Server Is #2 Out of 98 in the $12 Server Challenge – YouTube
• F# basics: let bindings, immutability and expressions – YouTube
• Getting Started with SharpLsp | F# & C# in VS Code – YouTube
• F# Programming in VS Code | SharpLsp .NET Language Support – YouTube

Blogs

• Study notes: automatic differentiation (part 3) · Mathias Brandewinder blog
• Kentaro Inomata: Effect handlers in F#, despite no delimited continuations, GADTs, HKTs or row polymorphism. Ported from Koka, Effekt, Unison, OCaml, Polysem

Highlighted projects

• dotnet-websharper/core: WebSharper – Full-stack, functional, reactive web apps and microservices in F# and C#
• serde-fs/Serde.FS: A deterministic, reflection‑free serialization and RPC platform for F#. Powered by Serde‑style source generation for .NET and (soon) Fable.
• cmeeren/BatchIt: Call batched functions as normal functions
• l0ng-ai/openidea: The IDE you know, rebuilt in Rust.

New Releases

• Fable 5.27.0
• WebSharper 10.1.10.687
• SQLProvider 1.5.30
• fsprojects/fantomas v8.1.1
• dotnet-fsharplint 0.27.2
• SageFs 0.6.938
• BatchIt 2.0.0
• Serde.FS 1.0.1

That’s all for now. Have a great week.

I’ve been poking at the OpenFeature website’s list of providers, with Claude doing much of the code-reading and running of experiments. OpenFeature is the vendor-neutral API for feature flags, and its site lists around sixty providers. A provider is the adapter between the OpenFeature SDK in your app and some flag system behind it. The list says which languages each provider supports. It doesn’t say anything about what’s behind it, even if it does give a breakdown between server or client emphasis for the tech. Claude has also helped with the drafting of this blog entry - and attempting to keep my voice.

My former colleague Pete Hodgson is involved in the OpenFeature effort. He wrote its 2022 launch announcement and sits on its governance committee. Pete also wrote the Feature Toggles article for Martin Fowler’s site, which categorizes toggles by purpose (release, experiment, ops, permissioning), and a five-minute intro to OpenFeature.

The taxonomy I’d teach way back was by when a toggle takes effect: build time, boot time, or run time (“hot”). My 2007 Branch by Abstraction article’s case-study had toggles, in XML back then. It was not drilled into blog entry cos that was about non-branching strategy. My 2019 thoughts on toggles goes into the three. Everything below is about the hot kind, and how hot they really are.

Re OpenFeature’s list of alternates, I had two questions. As ever, the first was whether any of them use version control as the backing store for toggles. Consul had git2consul years ago, and I said back in 2019 that the service-discovery and config-distribution tools should leverage source control. The second question came later: once a toggle is flipped, how long until a running app sees it?

Method

Provider SDKs just call an API, so they don’t reveal where flags are stored. We shallow-cloned the open-source servers behind the providers, and then the SDKs and OpenFeature providers, and read the code: docker-compose files, database drivers, storage packages, polling defaults, streaming code. Every figure below is a code default at the start of November 2026, with a file and line behind it. Mostly the Node provider plus one other server language (Java or Go) per system. Closed-source SaaS offerings (LaunchDarkly, Split, ConfigCat, DevCycle, Statsig and so on) are absent, because there was no code to read.

Not everything on the list is a server

Several entries are flag evaluators. You keep the flags somewhere yourself and they read from there:

• GO Feature Flag’s own README says “no backend to run. No database”. It reads a YAML/JSON/TOML file from wherever you put it: a file, HTTP, GitHub/GitLab/Bitbucket, S3, GCS, Azure Blob, a Kubernetes ConfigMap, MongoDB, PostgreSQL, Redis. All of those are read-only to it. It’s an aggregator more than a flag system, and how a level-two support person would flip a toggle is left to you and whatever store you chose. Three days ago they previewed GO Feature Flag Studio, an optional UI aimed at exactly that person. It stores flags in PostgreSQL, not Git, and isn’t released yet.
• Featurevisor is a flag compiler. You keep flag definitions in a Git repo, CI compiles them into JSON “datafiles”, and you publish those to a CDN or static host. There is no server as such, but it fits a bunch of CI/CD ideals.
• flagd is an evaluation daemon (and the OpenFeature project’s own). It reads from files, HTTP, gRPC, Kubernetes custom resources, S3, GCS or Azure Blob.
• Ageris and MongoDB + Rules are libraries inside your app, reading files and a Mongo collection respectively.

Backing stores of the actual servers

So one out of nine. PostgreSQL is the default answer for this category of software.

Git as the store: Flipt v2

What I’m interested in is a round trip. The flag system’s own editing app commits and pushes when someone flips a toggle in the UI. And a suitably authorized person can clone the same repo, change a set of flags in their editor, commit and push, and the system picks it up. That second path is how you batch changes to sets of flags, review them, and get history, blame, diffs and reverts for free. S3 has versioning if you turn it on. An HTTP endpoint has none.

Flipt v2 does both directions. Flipt v1 had SQLite (the default), PostgreSQL, MySQL, CockroachDB and LibSQL, plus read-only Git, OCI and object-storage sources. v2 dropped the databases. A UI or API edit becomes a commit that is pushed to the remote. Flipt also polls that remote every 30 seconds by default (poll_interval, down to 1s) to pick up commits pushed from elsewhere. If the remote moved on, a UI save re-fetches and re-applies the edit on top rather than clobbering someone’s push. Flipt reads the whole repo at one commit, so a batch of flag changes in a single commit lands all at once. Branches can be environments too.

Two caveats. Flipt v2’s server is under the Fair Core License (FCL-1.0-MIT), which is source-available and converts to MIT later, not open source today. And some Git conveniences are in the commercially licensed part: proposing pull requests from the UI, and a webhook from the Git host that triggers an immediate fetch rather than waiting for the next poll.

GO Feature Flag and Featurevisor use Git too, but only to read. You’re expected to edit with ordinary Git tools. That’s fine for developers. It may be OK for support people at 3am, too, but it might not be so smooth for business people if they are encouraged to make changes in certain situations. I blogged previously about pretty editor panels for commodity VCS web-UIs: an app-config workflow using SCM (2012), then Perforce as a datastore with client-side MVC (2013), custom JSON editors for GitHub via a Chrome extension (2015), and RhodeCode and Angular as an editor for a config-as-code system (2016). The business-user angle is in Rules Engines Suck Too If They Are Not Backed By Source-Control.

How long does a flip take to land?

There are two hops: from the change to the flag server serving it, and from the server to the running app via the OpenFeature provider. The app gets changes in one of three ways: it asks the server on every evaluation (fresh, but a network call per flag check), it polls for the whole rule set and evaluates locally, or the server pushes changes over a stream. These are defaults, not best-case configurations.

“Never refreshes” for browser providers means until the page reloads, the user identifies, or the evaluation context changes, depending on the product.

What stands out

“Never” is a common default. GrowthBook’s JS and Java OpenFeature providers fetch once at startup and keep that. So does Superposition’s JS provider. Several browser providers don’t refresh either. That’s fine for a release toggle you flip once and then remove. It’s not fine for an ops toggle or kill switch that someone flips during an incident and expects to take effect. You have to opt into polling or streaming, and you should know which you’ve done before you need it.

Push is often the paid feature. Unleash, Flagsmith and Flipt’s Git webhook are commercial. FeatBit, flagtide, flagd and GrowthBook (via its proxy) have it free.

Asking the server every time is the freshest. Bucketeer, Flagsmith and Flipt default to remote evaluation for server-side apps, so a flip is visible on the next evaluation. You pay a network call per flag check.

Client-side evaluation publishes your rules. Anything a browser downloads is public, and products that evaluate in the browser ship the rules, not only the outcomes: segments, attribute conditions, rollout percentages. Featurevisor has tags and per-target builds to trim what each client receives, but nothing is encrypted. Products whose server evaluates and returns results keep the rules private.

And a bug

While reading MongoDB + Rules, Claude noticed that in single-document mode the change-stream filter lists "update " with a trailing space. MongoDB reports "update", and the library’s own client writes flags with $set, so edits made that way would never reach running apps, and nothing errors to trigger the polling fallback. The default all-documents mode is spelled correctly. That’s one for an issue on the repo.

Where this leaves me

For Git (or any VCS) as a first-class, round-trip toggle store, Flipt v2 is the one for now. Well, after reading the licensing it may be. Everything else that manages its own flags uses a database, mostly PostgreSQL.

If you pick differently, check the refresh defaults of the provider in the language/platform you’re using, and test a flip end to end before an incident does it for you.

A digression, sorry!

I saw that Unleash came up on Hacker News again: We’ve built an open-source feature flag server for 11 years. 156 points and 104 comments in a day. Unleash had been posted five times before, between 2020 and this year, as “Unleash – an open source feature toggle service”, “Show HN: Unleash Open-Source feature flag solution” and similar. Those got one to three points each.

Same repo, so why the difference? Luck in the first hour plays a big part on HN, and Ivar (the creator) being in the thread answering helps. But I think the title did a lot. The grammar is slightly off: “built” says finished, “for 11 years” says ongoing. And it sets up a point and never makes it: for 11 years… and? Here’s what we learned? We’re shutting down? Ask us anything? I doubt any of that was intended, but together it’s accidental catnip for HN frequenters. The earlier titles were complete and coherent, and gave nobody anything to resolve. This one left a gap, and readers filled it with their own endings in the comments: you could have used Redis, LLMs make this obsolete, AGPL isn’t really open source, LaunchDarkly is somehow worth $3B. And I should confess I’m not immune: that catnip is how I ended up here this morning, reading the source of a dozen feature flag systems instead of whatever I’d planned to do.

To come back for usefulness from this digression, somebody in there did ask how clients keep their local evaluation up to date. I have a table for that now, above.

BONUS: Breaking the Permission Loop in Agile Teams

In this BONUS episode, we explore why teams often wait for permission even when they already have skill, tools, and good ideas. Tara Scott, executive, product, and culture coach and author of Breaking the Permission Loop, explains how agency starts with noticing our own reactions, building alignment, and practicing small moments of self-trust.

When a Compliment Becomes a Detour

"You don't really feel like you can say no. So I said yes."

Tara starts with a startup story many Scrum Masters and product leaders will recognize. She was building momentum with user research when a CEO redirected her into a data science initiative that sounded urgent, but did not answer the core product question: do people actually use this product? The request was framed as a compliment, and that made it harder to challenge. Tara's point is practical: sometimes the permission loop begins in the small space between our concern and the automatic yes that comes out before we have understood the tradeoff.

Slow Down Before the Yes

"Sometimes no isn't even no. It's just not right now or give me more context."

For Tara, the first move is observation. Before a team can change a pattern, people need to notice what happens inside them when pressure rises: defensiveness, shame, blame, justification, or the urge to please. Tara connects this to The Responsibility Process, a practice for recognizing when we are below the line and bringing attention back to our own behavior. In a team setting, this is not about blaming ourselves for everything. It is about giving ourselves enough room to ask a better question before committing to work we do not believe in.

Permission Loops Are Patterns We Can Interrupt

"For me, a permission loop is there's different opportunities within those loops where we can step in and say, this could be a really good time to break this."

Tara chose the word loop because the pattern repeats until someone interrupts it. Teams say, "it is what it is," decisions wait for a manager, and people move through the same script because it feels familiar. The useful part is that loops also create openings. A meeting, a question, a moment of discomfort, or a request for one more thing can become the cue to pause and run a small experiment. The goal is not dramatic confrontation. It is a calmer, clearer way to step into the moment with evidence, context, and a suggestion.

Healthy Alignment Is Different From Waiting for Permission

"It is validate, communicate, confirm."

Tara makes an important distinction between acts of authorization and permission-based behavior. In software teams, some decisions need security, architecture, compliance, or dependency alignment. That is real. The permission loop starts when people ask for approval for things nobody can actually give them, such as self-trust, courage, or the right to raise a concern. Tara's working pattern is simple: validate what needs to happen, communicate it clearly, and confirm that the right people are aligned. That connects closely with intent-based leadership from David Marquet's Turn the Ship Around!: say what you intend to do, check alignment, then move.

Autonomy Without Direction Can Leave Teams Lost

"I was told I have total freedom, but to do what?"

Tara challenges a common agile assumption: autonomy alone will not solve the problem. She describes a team that had been told they had freedom, but no shared goal. Leadership and developers blamed each other, and everyone was using different language for success. Without direction and explicit alignment, autonomy becomes another source of confusion. That is why Tara shifts the focus toward agency: enough trust in yourself to speak, enough confidence to offer a path forward, and enough humility to be wrong and still keep working with others.

Atomic Habits for Breaking the Loop

"We have to start where we start and start small."

Tara connects her six-week practice to James Clear's Atomic Habits: habits continue because the cues and rewards are already wired into us. Breaking a permission loop also needs cues. In Tara's startup example, the cue could have been the CEO asking, "What do you think?" That would have been her window to explain the user research data, name the tradeoff, and propose a better way forward. If the cue does not appear, we may need to create it ourselves. The practice is small, but the shift is significant: prepare for the moment before emotion runs the meeting.

About Tara Scott

Tara Scott is an executive, product, and culture coach with 20+ years in agile, helping organizations build healthier, behavior-driven cultures. Her book, Breaking the Permission Loop, is out now. Tara is a certified Fearless Organization practitioner focused on psychological safety. LinkedIn: Tara Scott.

You can link with Tara Scott on LinkedIn and find more about Tara's work and Breaking the Permission Loop at TaraScott.net.

In my last post I wrote that syntax recall was never the goal.

It’s easy to say though and I wanted to see what it meant in practice.

I extended a small prototype I had centred around a virtual business analyst and virtual project manager. I added a virtual developer agent to the solution then gave them this prompt:

“Create a basic customer order search functionality using a simple HTML form and JavaScript. The form will allow users to input a customer name or order ID, and upon submission, it will display the matching orders from a predefined list. Clicking on a selected order will show the order details below the search results.”

A few minutes later I had user stories, risks and assumptions, 16 tickets with story points, code for the top three tickets and a Visual Studio 2022 solution.

I opened it, hit build, and it ran.

That’s a big chunk of what people in the industry have been paid to do.

So what’s left of these jobs?

~

What I Built

Nothing fancy. Three agents built with Microsoft Agent Framework, each doing the job you’d expect from the title.

• The BA agent takes the requirement and turns it into user stories, functional and non-functional requirements, assumptions and risks.
• The PM agent takes those and creates Jira-style tickets with story points, priorities and acceptance criteria.
• The Developer agent picks up the top three tickets and writes the code.

There’s a button at the end that generates a VS2022 solution.

There’s also a small web front end so you can watch the work move through the pipeline.

It’s a prototype. I recorded a short demo, posted it, and the response was better than I expected. One of the people who liked it was a client.

Here’s the demo:

~

What It Got Right, And What It Didn’t

It worked, but many things jumped out at me straight away. The first thing I noticed was that the BA and PM agents both went well beyond what was asked for.

Here is a breakdown of the main things each agent did.

Business Analyst

• Turned one paragraph into user stories, risks and assumptions
• Added requirements I never asked for: accessibility for keyboard and screen reader users, search handling 5K orders in under 200ms, all text sanitised against XSS
• Flagged its own ambiguity: one input field or two? Would partial name matching match what stakeholders expect?
• Assumed no backend and USD
• Wrote stories with two inputs, name and order ID. The app has one search box

Project Manager

• 16 tickets with story points, across two sprints, for a search page
• Included a cross-browser test matrix and performance tuning
• Marked the sanitisation ticket Critical

Developer

• Built the top three tickets, sanitisation first
• One search box, a results list and a details panel
• Sample data included <script>alert('admin')</script> as a customer name. It renders as plain text
• Wrapped everything in a .NET project with a minimal API. I asked for HTML and JavaScript
• Never called that API. The UI reads from a JS data file, so the sample data exists twice
• Picked the currency from the browser locale: pounds for me, dollars for everyone else

The PM agent marking sanitisation as Critical, and the Developer agent building it first, is defensible. I probably wouldn’t have done that as a first task though.

The agents also didn’t always agree with each other. The BA’s two input fields became one search box. The BA assumed no backend, and the Developer built an API that nothing calls.

Then there’s the estimate. Sixteen tickets and two sprints for a basic search page. An experienced PM would challenge the scope before the first stand-up. Left to their own devices, these models don’t seem to worry about over-delivering. Your token bill will confirm it. ;-)

So, the virtual team was good at producing detailed work that looks ok on the surface. They’re not as good at staying consistent with each other, or knowing when to stop.

Human judgement is required.

~

Where The Work Moves

If pushing around syntax and writing docs is becoming cheaper, the value moves to the start and the end.

At the start, someone has to work out what’s actually needed.

One search box or two? Partial match on names or exact? Is this a quick internal tool or the first step of something that will sit on top of a real database?

The BA agent raised some of these questions itself, which is impressive, but raising a question isn’t answering it. Someone still has to go back to the business, get an answer and make sure every agent sticks to it.

At the end, someone has to check what comes out and be accountable for the output. Saying “the AI generated it” doesn’t cut it.

• Does it handle the edge cases?
• Is it secure?
• Does it fit the existing system and the way the team deploys?

When it falls over in production, who gets the call?

~

Who Gets Squeezed And Who Doesn’t

If your role is mainly taking Jira tickets and turning them into code, these roles are going to contract.  That doesn’t mean software development disappears, but it does mean teams may need fewer people to produce the same amount of code.  Highly regulated environments, and organisations that aren’t comfortable with their data being pushed to an overseas frontier firm, will be slower to adopt, but I don’t think they’ll be immune.

The wider industry is starting to grapple with what this means for its workforce. Microsoft recently announced a voluntary exit offer available to around 60,000 employees across participating teams.  About 25% of the workforce, that’s substantial.

That doesn’t mean 60,000 people are being replaced by AI, and Microsoft hasn’t claimed that. But against the backdrop of its substantial AI investment, it raises a question worth asking: as companies spend more on AI and change how work gets done, will they need the same number of people to deliver it?

Equally though, I don’t think AI is all bad news for the industry. Most real systems aren’t greenfield. I spend a lot of my time reverse engineering legacy systems and replacing them with more recent technologies.

Agents can help with that, but you still need someone who understands what the old code is doing and why it was written that way in the first place. Someone also has to design how it all fits together, decide what not to build, and keep it running in production.

Also, someone has to run the agents. Set them up, keep them on track, check what they produce and take responsibility for it.

That still leaves the question from my last post. If AI writes the code, how do people starting out build their judgement?

I don’t have a perfect answer for that.

My advice would be to use the agents, but understand the output. Trace the code, run the tests, investigate the decisions and understand why the solution works. Don’t accept an answer just because it builds. Call the model out when your experience or wider context tells you there’s more to consider.

~

Where I Am Now

I started out as a .NET developer over 20 years ago. I was the guy on client sites, some with the internet disabled for security reasons, building CRUD apps from memory.

These days, I still type code, but a little less than I used to. The bulk of the time is on engaging stakeholders, figuring out the problems, working out what should be built, how it fits together, and whether what’s been built is any good.

The prototype is done, but it’s not a massive leap to take it to the next logical step and implement a Tester agent that turns the acceptance criteria into tests and keeps looping until they pass.

~

Closing Thought

A short paragraph of requirements to a working Visual Studio solution in a few minutes. A couple of years ago I wouldn’t have believed it.

But the agents didn’t decide what was worth building. They didn’t settle the questions they raised. And they won’t be the ones answering for it if it breaks.

That part is still on us.

Generating code is getting cheaper but good judgement is not. And that comes with experience and being in the trenches.

What do you think?

Drop your comments below.

~