High-Level Rust: Getting 80% of the Benefits with 20% of the Pain

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 becaues I often do choose the language for its types 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
• 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 - Go 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
• Lower velocity vs high level languages

So the pros are really really good. In fact, if you could remove the cons Rust starts looking like the shape of the 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. For perf, likely need to use Arc and im crate on non primitives in structs 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 30% or less unless we're doing some of these clones in super hot paths. If you do have a hot path / perf critical area, you can typically optimize those away by switching them over.

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 and not something the type system is helping with unfortunately. 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 to allow the type system to point these out to prevent myself from repeatedly making this mistake).

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.

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)