I've been searching for the perfect programming language for years and my conclusion thus far is that it's missing.

There is no programming language that has it all:

• Expressive types
• Good Community
• Good ecosystem
• Good perf
• Good devx

Several get close, but they're all missing something.

For the past couple years, my languages of choice have been F#, TypeScript, and C#. They are all solid languages but I always felt like I was settling in some dimension.

• F# - Has great types and bones but I think the syntax is too minimal to be readable, the ecosystem is tiny with many abandoned packages or you build wrappers to interop with C#, and AIs aren't very good at idiomatic F# because there's so little training data and is overshadowed by OO C#.

• TypeScript - Is ubiquitious with the biggest ecosystem in the world but the types are lies and the ecosystem is constantly undergoing largescale thrash
• C# - Is a solid OO language but it's full of boilerplate and has yet to get native unions and exhaustive pattern matching (maybe this year?).

Related: 7 Reasons F# Sucks

So I found myself bouncing back and forth year after year and bending each language further towards what I wanted:

• Writing some verbose F#
• Adding results to TypeScript
• Using immutable records and Results in C#

They all got closer but just weren't quite there.

Rust is perfect, except for the productivity

I've known about Rust for a long time but have only seriously considered it a few times and never really built anything with it - largely because I didn't think the learning curve was worth the gains. After all I'm not a systems-level programmer, so why use a systems-level language?

But it's popular at Recurse Center where I've spent the last several weeks building stuff and someone mentioned that Rust was a good language even if you just chose it for the types. That was interesting to me because I often do choose the language for its types (its one of the biggest differentiators) and then hope that there's an ecosystem to support it.

So I went and researched / reported on the missing language and sure enough Rust is a strong contender - except for its devx.

But I got to thinking - with AI so good at writing standard code, is this learning curve now much lower? Can we move about as fast with Rust as we would another language? And if we could do that, what would we gain?

The Pros and Cons of Rust

The pros and cons of Rust basically shake out to:

Pros:

• Fast - Approaching C which is about as fast as you can get in a readable language
• Great types - truly expressive (see: my definition of expressive types)
• Runs ~anywhere - Is so low level it can plug into most things
• Large and growing ecosystem - ~10th in size w ~15% of devs using it and growing at ~30% per year according to Stack Overflow Dev survey 2025
• Super stable - Goes to great lengths to have solid crates that don't break over time (though the lang has had its share of thrash like with async runtimes)

Cons:

• Learning curve - ownership, borrowing, lifetimes, async runtimes and gotchas
• Lower velocity - vs high level languages

So the pros are really really good. In fact, if you could remove the cons Rust looks a lot like the type of language I've been searching for.

High Level Rust

So I had this idea - what if you could just write Rust as a high-level language? If you can just get that devx to approach that of C#, F#, TS then you get basically all upside.

So I started doing research and reading the Rust book and building little prototypes.

What I came up with was an approach that gets us ~80% of benefits of Rust for only ~20% of the pain. And in most cases the only drawbacks are a 10-20% hit on perf which isn't that bad when we consider how fast Rust is out of the box and how it compares to other languages we'd build in the same way.

The approach is:

• Type-first domain modeling - Use enums and structs to model your domain. Make invalid states unrepresentable.
• Functionalish logic - This means immutable by default, pure functions, ImPureIm sandwiches, generous cloning instead of mutations. Rust's type system already pushes you towards this so we're working with the system but if you also allow yourself to take the perf hit on clones you can avoid most painful borrow checker / lifetime / async edge cases. Note: there be dragons in cloning perf since this is not a Garbage Collected language, you likely need to use Arc on non primitives and structs and immutable collection crates to keep clone cost down.
• Domain Driven Design - Domains encapsulated behind services. Use traits as interfaces to help with DI, testing. Create these services at the app root and use Arc<dyn TRAIT> to allow for shared references.

We do lose some perf from this approach but it's in the ballpark of 10-30% depending on how frequently you're doing these clones. If you do have a hot path / perf critical area, you can typically optimize those away by switching them over to mutations.

I'll note that this approach adds in some extra mental overhead in terms of remembering to use immutable structures / primitives / Arc everywhere you can to allow for less expensive clones. That's a real cost you don't typically pay in GC languages (other than limit data / clones in frequency / size) and not something Rust's type system is currently helping with (both expensive and cheap clones are just .clone()). And expensive clones are very bad in Rust because they're all deep clones so some inefficient ones in hot paths can easily tank your perf down below that of other compiled languages like F# / C#. (I see there are some alias proposals to help with this and I'm putting together a package to allow the type system to point these out to prevent myself from repeatedly making this mistake).

So this approach works for most general high level computing tasks but is not universally effective.

When High Level Rust Makes Sense

I think this is a good fit when you care more about logic than performance. But if performance is a concern / you have logic in a hot path then mutations likely makes more sense as it's much faster.

Good fit:

• Web APIs, CRUD services
• Business logic heavy applications
• Projects where correctness > raw performance
• Teams coming from functional languages

Not a fit:

• Hot paths, game engines, OS kernels
• Complex concurrent systems with shared mutable state
• When you need every bit of performance
• When you have time to learn / use "proper" Rust - I'm sure experienced Rustaceans will see this proposal as overly restrictive and ineffective for leveraging the language for what it's capable of

Next

Rust really feels like an excellent language on paper but it has some scary edge cases that make it hard to onboard onto. I think this approach can help soften those edges and make it an excellent high level language that happens to be able to produce near-metal performance if and when you need it.

But we'll see - I just started this journey a few weeks ago and am actively exploring this approach through demo web services, games, and CLIs so maybe my view will change.

I'm actively working on LightClone - the package to enforce cheap clones. If you're interested in this / want to see it happen please star it on GitHub and shoot me any feedback you might have. This would let me know it's smth people want, is worth investing in, and help me make it more generally useful!

If you liked this post you might also like:

• The Missing Programming Language - Why There's No S-Tier Language (Yet)
• How I think about writing quality code fast with AI
• 5 AI Coding Best Practices from a Google AI Director (That Actually Work)