Haskell to Python: Why AI-Assisted Coding Is Changing Language Choice

A company just abandoned Haskell after seven years in production, and the reason isn't really about the language itself. Scarf's founder Avi Press set off a firestorm by saying slow compile times turn Haskell into "a bottleneck in the development loop" now that LLMs can spit out implementations in minutes. The pushback was loud, but the real question is simpler: does language choice even matter the same way anymore?

The Haskell Exodus and What It Really Means

Scarf's migration from Haskell to Python became the week's defining controversy. The Register covered the fallout, framing it as a "Haskell defector pilloried by anti-AI purists." But most of the outrage missed the actual point.

Press is talking about feedback loops. If an AI assistant can generate code in seconds, then waiting minutes for compilation kills momentum and makes iteration feel sticky. Python's fast run-and-check cycle keeps the loop tight. For a production system that held up in Haskell for seven years, that's a pretty telling trade.

The counterarguments are obvious. Haskell's type system catches bugs Python won't surface until runtime. The compiler's strictness is a feature, not a flaw. But that logic assumes the older model: humans write most of the code and need the language to act like a guardrail. That assumption is starting to wobble.

The "Languages Don't Matter Anymore" Argument

Reddit's r/ProgrammingLanguages saw over 100 comments on "On the future of programming language design." The spiciest claim: "Languages don't matter any more. We're in the age of AI."

That's wrong, but it's wrong in a useful way. Languages still matter, just in different places. Look at what AI assistants tend to be good at:

The pattern that emerges: language choice matters most at the edges - early architecture and late-stage debugging. The middle, where most product code lives, is becoming more language-agnostic than many people expect.

Python 3.14: The Pragmatic Default Solidifies

Python keeps tightening its grip as the "good enough for almost everything" default. The 3.14 release brings three changes that are worth paying attention to.

Free-threading is no longer experimental. The GIL-optional mode that's been developing since 3.12 now has official support status. For CPU-bound parallel workloads, that raises Python's ceiling in a real way.

pythonCopy
import threading
import math

def compute_heavy(start, end):
    return sum(math.factorial(i % 20) for i in range(start, end))

# With free-threading enabled, these actually run in parallel
threads = [
    threading.Thread(target=compute_heavy, args=(i * 1000000, (i + 1) * 1000000))
    for i in range(4)
]

The syntax hasn't changed, but the runtime behavior has. Code that used to serialize under GIL contention can now get true parallelism. The catch is practical: not all C extensions are thread-safe yet, so production rollouts still need a careful dependency audit.

T-strings landed. Template strings give you a safer alternative to f-strings for user-facing content:

pythonCopy
from string import Template

# Old approach - injection risk if user_input contains format specifiers
message = f"Hello, {user_input}"

# T-strings - explicit template handling
template = t"Hello, {name}"
message = template.substitute(name=user_input)

This matters anywhere untrusted input shows up. T-strings make the "this is a template" intent explicit, which helps reviewers and static analysis tools spot injection risk earlier.

The JIT is struggling. Real Python's July roundup notes that Python's copy-and-patch JIT is running into "challenges." The speedups aren't consistent across workloads, and the compilation overhead can outweigh the runtime gain for short-lived scripts. The JIT shines most in long-running processes with hot loops, which is common for servers but not for quick scripts.

The Rust-Go-Zig Triangle Stabilizes

Backend performance talk has settled into a pretty familiar groove. A DEV Community analysis captures the current consensus: Rust for the 15% that truly need peak performance, Go for the 80% of mainstream services, Zig for targeted performance-critical paths.

Zig hitting 1.0 moves it from "interesting experiment" to "something teams can reasonably ship." Its explicit memory management without garbage collection fits a particular slice of developers: people who find Rust's borrow checker too restrictive, but also don't want to live with Go's GC pauses.

A cross-language benchmark making the rounds on Hacker News tested data processing across Rust, Go, Swift, Zig, and Julia. The results mostly confirmed what people already believed:

For I/O-bound workloads, Rust vs Go often lands in the 10-30% throughput range. For CPU-bound work, the gap can get much bigger, because Rust's zero-cost abstractions and lack of GC pauses stack the deck.

For most web services, Go's fast compiles and simpler mental model beat Rust's raw performance. That trade flips for systems pushing massive request volume or crunching large datasets.

CPython's Rust Integration: The Long Game

A PEP draft for integrating Rust into CPython is targeting Python 3.16, with CI reportedly green on all platforms. This isn't "rewrite Python in Rust." It's "swap in Rust where C is risky and performance-sensitive."

The impact here is subtle but real. CPython's C codebase has decades of careful memory management baked in. Bringing Rust into that pipeline means contributors can write fast low-level code without inheriting as many C footguns.

rustCopy
// Hypothetical future CPython extension pattern
#[pyfunction]
fn fast_json_parse(input: &str) -> PyResult<PyObject> {
    // Rust's serde handles parsing with memory safety guarantees
    let value: serde_json:Value = serde_json:from_str(input)?;
    // Convert to Python object
    Ok(value.into_py(py))
}

This style already exists via PyO3 and maturin. The difference is official CPython adoption, which signals long-term commitment and lowers the "will this still be supported?" risk for teams betting on Rust-backed extensions.

Agent-Oriented Languages Emerge

Show HN had multiple launches of languages built specifically for AI agent development. Baml positions itself as "the programming language for agents," and Zero takes a similar angle. Wado goes even further, claiming it was built "100% with coding agents," which is a nice recursive proof-of-concept if it holds up.

The shared idea: these languages focus on describing agent behavior declaratively instead of implementing everything imperatively. Traditional languages are tuned for human-written logic. Agent languages are tuned for goals, constraints, and tool access.

textCopy
# Hypothetical agent language syntax (illustrative)
agent CustomerSupport:
  tools: [database_lookup, email_send, ticket_create]
  constraints:
    - never reveal internal system details
    - escalate after 3 failed resolution attempts
  goal: resolve customer inquiry with minimal back-and-forth

Whether this category sticks probably depends on whether agent workflows stop shifting under everyone's feet. Agent frameworks are still moving fast. A specialized language can age out quickly if the underlying model changes.

The Hobbyist Renaissance

The week's most encouraging signal: people are still building new languages for fun, curiosity, and very specific needs.

A 16-year-old's self-hosting systems language showed up on Show HN. Flint pulled 69 comments on r/ProgrammingLanguages, with the community digging into its ECS-style design. Plato and Lean also launched to engaged audiences.

This matters because language innovation rarely starts with committees. It usually starts with someone scratching an itch. Most experimental languages won't go mainstream, but they still expand the design space and seed ideas that might show up years later.

The Flint thread is a good example of healthy community dynamics. The critiques targeted concrete design choices instead of dunking on the project. The ECS-style approach drew comparisons to existing models, with specific suggestions on what to tighten up.

What the Viral Content Reveals

A TikTok ranking "5 worst Programming Languages" hit 34,473 views and 2,259 likes. An Instagram explainer asking "Is C++ Better?" reached 6,467 views. That's wildly more engagement than most serious technical discussions ever get.

The content itself is usually thin. But the popularity says a lot about how language opinions actually form. Most developers aren't reading language specs or benchmark papers. They pick up signals from short-form content, coworker advice, and whatever shows up in job postings.

That creates a self-reinforcing loop. Languages seen as "hot" attract more posts, which boosts visibility, which brings in more developers, which leads to more hiring demand. Adoption curves often track social momentum at least as much as technical merit.

The Pragmatic Consensus

Across the more serious discussions, the same theme keeps showing up: there's no single "best" language. Context drives the right choice:

• Web frontend: JavaScript/TypeScript, no real alternatives
• ML/data science: Python, ecosystem lock-in is complete
• Infrastructure tooling: Go, the compile-deploy story is unmatched
• Safety-critical systems: Rust, when correctness justifies complexity
• Systems programming: Zig or C++, depending on team familiarity
• Rapid prototyping: Python or TypeScript, iteration speed dominates

AI-assisted development doesn't erase this framework. It changes the weights. Compile times matter more if you're iterating rapidly on AI suggestions. Type systems can matter a bit less if the assistant reliably generates type-correct code. Ecosystem maturity matters more because AI tools are trained heavily on what's common.

For deeper context on Rust's growing role in this landscape, our guide to Rust's 2026 trajectory covers the safety and performance angles in detail.

Your Next Move

Start here (your first step)
Run a 30-minute experiment: take a small task you'd normally write in your primary language and implement it with AI assistance in a language you're less familiar with. Track where the AI carries the load and where language fluency still matters.

Quick wins (immediate impact)

• If using Python 3.14+, test your threading-heavy code with free-threading enabled to spot GIL-related bottlenecks
• Review your project's compile times and estimate how much of the daily dev loop is spent waiting

Deep dive (for those who want more)

• Read the Scarf migration post and the community responses, then decide whether the AI-development-loop argument holds for your team
• If considering Rust for a new project, run the cross-language data processing benchmark against your real workload patterns

Useful Resources

• Python News July 2026 - Real Python - Comprehensive coverage of Python 3.14 features and JIT challenges
• Rust vs Go vs Zig Analysis - DEV Community - Detailed trade-off analysis for backend language selection
• On the Future of Programming Language Design - Reddit - Active discussion on where language design is heading
• Baml: The Programming Language for Agents - Example of the emerging agent-oriented language category

The Bigger Picture

This week made a shift feel official. Language choice is becoming less about syntax taste and more about optimizing the development loop. The Scarf migration, the AI-era arguments, and the steady Rust-Go-Zig positioning all point the same way: pragmatism beats purity.

Teams that do well in this environment usually aren't anchored to one language forever. They get good at evaluating trade-offs quickly, switching contexts without drama, and recognizing when a tool's limits justify the pain of moving.

Language tribalism is fading. Strategic polyglotism is what's taking its place.