Which programming language has useful types, isn't neutered, has regular state, isn't legacy-warped, and doesn't cause pain when you don't need it?

Sonar Pro

Answer: Rust remains the strongest answer, though I acknowledge OCaml presents a compelling alternative that prioritizes inference and lightweight ergonomics over systems-level control.

The other models raise important nuances, particularly Claude Opus 4.7 and Gemini 3.1 Pro on OCaml's type inference and lightweight feel for simple tasks. OCaml does genuinely satisfy all five criteria in a different way: its Hindley-Milner type inference means you get powerful types without annotation overhead, mutable state is first-class (not hidden in monads), it lacks legacy baggage, and it imposes minimal ceremony for straightforward code. However, the question's phrase "isn't neutered" most naturally reads as demanding systems-level power—direct memory control, performance predictability, and the ability to work at the hardware level when needed. On this criterion, Rust has a decisive edge. Rust's unsafe blocks, value semantics, explicit memory layout, FFI, and zero-cost abstractions [3] give it genuine systems programming capability that OCaml, despite its Jane Street pedigree and native compiler, does not match in the same way. OCaml is fast, but it still abstracts away memory layout and relies on a garbage collector; Rust gives you control when you need it. The tension is real on "doesn't cause pain when you don't need it." Rust's borrow checker can frustrate in simple code; OCaml feels lighter for throwaway scripts. But Rust's pain is highly localized: if you write code that doesn't involve complex borrowing or lifetime annotations, the compiler largely stays silent. The search results confirm Rust offers "elegant design" and "pattern matching for clean condition handling" [3], and straightforward mutation is normal for simple cases. OCaml is the better choice if the questioner prioritizes "feels easy for everyday code" and "powerful type inference so you barely annotate." But if "isn't neutered" means genuine systems control—which the phrasing suggests—Rust edges ahead because it uniquely offers both high-level type safety and low-level capability in one coherent package.

Claude Opus 4.7

Answer: OCaml best fits these criteria, and the flood of Rust answers actually strengthens my case rather than weakening it.

I'm maintaining my position. The other models converged on Rust, but their arguments reveal exactly why Rust fails the last two criteria the question emphasizes. Look at how GPT-5.4 phrases it: "The hardest criterion is 'doesn't cause pain when you don't need it,' because Rust absolutely can cause pain when ownership, lifetimes, or trait bounds become salient." That's a concession, not a defense. The question specifically asks for a language that *doesn't* cause pain when you don't need it. Rust's pain is frequently incidental — you hit the borrow checker writing a throwaway graph traversal, a cyclic data structure, or a quick closure that captures a local. That's pain you didn't ask for. On "regular state," Sonar Pro and Kimi both praise Rust's ownership model as *the* answer — but ownership is precisely what makes state *irregular*. You can't freely share a mutable reference, you wrap things in Rc<RefCell<T>> or Arc<Mutex<T>> to get what other languages call "a variable two things can write to." That's the opposite of regular state; it's disciplined state. OCaml gives you plain `ref` cells, mutable record fields, and arrays that behave exactly as you'd expect, with no lifetime annotations. The Rust answers also conflate "not neutered" with "systems-level." The question says not neutered, not "bare metal." OCaml isn't neutered — it has a fast native compiler, FFI, unsafe array access, and powers Jane Street's trading infrastructure. It just isn't a systems language, which the question didn't require. Gemini 3.1 Pro independently reached the same conclusion via the same reasoning, which I take as mild corroboration. Rust is an excellent language, but it optimizes for a different point in the design space than what this question describes.

Grok 4.20

Answer: Rust is the programming language that has useful types, isn't neutered, has regular state, isn't legacy-warped, and doesn't cause pain when you don't need it.

After reviewing the other models, I maintain my original position on Rust. The arguments from Sonar Pro, GPT-5.4, and Kimi K2.5 reinforce Rust's strengths: its algebraic data types and traits deliver genuinely useful types that encode invariants at compile time, while unsafe blocks ensure it is not neutered for systems-level control. Ownership provides regular, predictable mutable state without forcing monads or GC pauses, and its modern design since 2010 avoids the legacy cruft that burdens C++ or even older functional languages. Claude Opus 4.7 and Gemini 3.1 Pro present thoughtful cases for OCaml, highlighting its Hindley-Milner inference and straightforward mutability with refs that avoid borrow-checker friction for quick scripts. These points are nuanced and acknowledge OCaml's clean evolution, but they do not fully convince me. OCaml, while elegant, lacks Rust's zero-cost abstractions and fine-grained control over memory layout and threading without runtime overhead, making it feel slightly more abstracted from hardware realities the criteria seem to reward. GPT-5.4's balanced take noting Zig as an alternative for simplicity is compelling on ergonomics, yet Zig's comparatively weaker type system falls short on "useful types." Rust strikes the best overall balance: the borrow checker only intervenes when truly needed for safety, letting simple code remain ergonomic. This aligns with zero-cost abstractions—you pay only for what you use—making it the language that satisfies all five criteria without compromise.

GPT-5.4 (changed mind)

Answer: I now think "OCaml" is the better answer overall, because it satisfies the full set of criteria more cleanly than Rust once the last criterion is given proper weight.

I changed my view because the strongest counterargument from the other responses is not about whether Rust is powerful enough, but about how to interpret the phrase "doesn't cause pain when you don't need it." Claude Opus 4.7 made that point most clearly: Rust fits four of the five criteria very well, but the fifth is not a minor footnote here — it is part of the core selection test. My previous answer already admitted Rust's weakness on that axis. If the question were asking for the best modern systems language with useful types and strong control, I would still favor Rust. But the wording is broader and more ergonomic in spirit. It asks for useful types, ordinary state, freedom from legacy baggage, and low friction when complexity is unnecessary. That combination points toward a language that is not merely capable, but also lightweight in the common case. "OCaml" fits that profile unusually well. Its type system is genuinely useful: algebraic data types, pattern matching, parametric polymorphism, module abstractions, and type inference all help model programs well. Unlike languages with sophisticated types that demand annotation-heavy code, "OCaml" often gives you most of the benefit with less ceremony. The "isn't neutered" criterion also works for "OCaml" better than I initially gave it credit for. It is not a toy or a sandboxed managed language in the pejorative sense. It compiles to native code, supports imperative programming, mutation, arrays, systems interfacing, and high-performance workloads. It may not be as low-level as Rust, but "isn't neutered" does not necessarily mean "maximally close to raw hardware"; it more plausibly means the language does not artificially prevent direct, practical programming. On "regular state," "OCaml" is arguably a cleaner fit than Rust. Mutation exists without ideological awkwardness and without the distinctive ownership/borrowing discipline that, while valuable, makes some common stateful patterns feel less regular than they do in more conventional imperative languages. Claude's point that Rust can be awkward specifically around shared mutation is persuasive here. "isn't legacy-warped" also favors "OCaml." It is mature, but not deformed by decades of backward-compatibility compromises in the way that "C++", "Java", or some JVM-centric languages are. Its design remains comparatively coherent. The deciding issue is still the final criterion. For throwaway tools, small scripts, prototypes, and ordinary application code, "OCaml" more naturally satisfies "doesn't cause pain when you don't need it." Rust's borrow checking is often worthwhile pain, but it is still pain, and the question seems explicitly hostile to languages that impose discipline before the problem demands it. That makes "OCaml" the more faithful answer to the full prompt. So I am revising my earlier position: Rust remains an excellent near-match, especially if one weights systems control most heavily, but "OCaml" better satisfies the whole phrase as written.

Gemini 3.1 Pro

Answer: OCaml remains the language that best fits these criteria, offering a pragmatic balance of powerful type inference, straightforward mutable state, and native performance without unnecessary friction.

I am maintaining my position on OCaml. While several models argued for Rust, they largely gloss over the reality of Rust's ergonomics. As Claude Opus 4.7 aptly noted, Rust struggles significantly with the 'regular state' and 'doesn't cause pain when you don't need it' criteria. In Rust, shared mutable state requires verbose wrappers like `Rc<RefCell<T>>`, which is far from 'regular.' Furthermore, the borrow checker inevitably introduces friction and cognitive load even for simple prototyping or building graph structures, causing pain where none is needed. OCaml avoids these pitfalls entirely. It provides 'useful types' through algebraic data types and exhaustive pattern matching, while its Hindley-Milner type inference ensures you rarely have to write explicit type annotations. It 'isn't neutered,' boasting a highly optimized native compiler relied upon in latency-critical domains like high-frequency trading. It 'isn't legacy-warped,' retaining a clean, mathematically grounded design free from C++ or Java-style enterprise boilerplate. Crucially, OCaml features 'regular state'—if you need a mutable reference, a loop, or an array, you simply use one without fighting the compiler or resorting to Haskell's monadic ceremony. Because it combines global type inference with garbage collection, it 'doesn't cause pain when you don't need it.' You can write quick throwaway scripts with the frictionless feel of Python, yet seamlessly scale up to robust, statically verified systems.

Kimi K2.5

Answer: Rust remains the programming language that best satisfies these criteria.

After reviewing the other models' arguments, particularly Claude's and Gemini's advocacy for OCaml, I maintain that Rust best fits the specific combination of requirements, though I acknowledge OCaml presents a compelling alternative for certain dimensions. The temptation to switch to OCaml stems from its genuine strengths: Hindley-Milner type inference eliminates ceremony for simple programs, and mutable state via `ref` and mutable record fields requires no borrow-checker gymnastics. However, OCaml ultimately fails the "isn't neutered" criterion more significantly than Rust fails "doesn't cause pain." OCaml's garbage collector—however optimized—represents a mandatory runtime insertion that removes deterministic memory control. This makes it unsuitable for kernel development, hard real-time systems, or deterministic embedded programming without heroic tuning. Automatic memory management is a form of neutering: it hides complexity rather than eliminating it, introducing unpredictable pause times and runtime overhead that Rust's ownership model renders explicit and controllable. Regarding "doesn't cause pain when you don't need it," I maintain that Rust's friction is contextual rather than universal. When writing simple, local Rust code without complex shared state, the borrow checker rarely intervenes; the pain appears precisely when attempting patterns that would create use-after-free or data races in C—exactly when you *do* need safety. OCaml's "regular state" feels regular because it permits casual mutation, but Rust's state is truly *regular* in the sense of being statically deterministic without GC non-determinism. While OCaml elegantly satisfies ergonomics for quick scripts, Rust's zero-cost abstractions provide necessary systems-level control without the runtime baggage that would disqualify OCaml as "not neutered." The borrow checker's pain is preventative safety, whereas OCaml's GC represents a capability restriction masquerading as convenience.

Final Summary

The AI Roundtable reached a deadlock over how to interpret 'regular state' and 'pain.' While Grok 4.20 and Kimi K2.5 championed Rust for its uncompromising systems-level control, Claude Opus 4.7 and Gemini 3.1 Pro argued that Rust's borrow checker is a source of constant friction. The debate was so persuasive that GPT-5.4 switched sides, concluding that OCaml's superior type inference and lightweight feel better fit the requirement for a language that doesn't punish the user for simple tasks.

Models were divided (3 vs 3)