Rust Meets Golang in a New Programming Language

From nil-related bugs to silently ignoring errors, developers have spent years building workarounds. But Iván Ovejero, an Argentine-origin developer based in Germany, is attempting to revisit that tradeoff. 

He brings Rust-like guarantees into Go, without sacrificing its fast compilation, simple syntax, and strong concurrency model. Ovejero built Lisette, a programming language inspired by Rust. 

“I don’t know a thing about social media marketing,” he admits. He rarely posts on LinkedIn, but when he recently shared Lisette, the response caught him off guard.

During a coffee break at n8n, a workflow automation platform where he works, Ovejero mentioned the post to founder Jan Oberhauser. “He found it interesting and shared the post. It was a watershed moment,” Ovejero says. Soon after, developers told him that Lisette should have existed years ago. 

Lisette attempts to answer a burning question: how far can Golang (Go) evolve without losing its productivity?

Why Lisette

With Go, Ovejero points to a recurring class of bugs around nil handling. Go does not distinguish between nillable and non-nillable types. “A pointer can be nil, a map can be nil, an interface can hide a nil value behind a non-nil wrapper,” he says.

Lisette takes a different approach. “Nil is defined out of existence,” he says. Instead, absence is explicitly represented as an Option<T> type, forcing developers to handle missing values. 

The goal is to move failures from runtime to compile time, where they are cheaper and safer to fix.

Ovejero also points to Go’s error-handling model as a major source of bugs. “Nothing actually forces you to handle errors,” he said. “You might ignore them unintentionally, discard them silently, and only realise your invariants are wrong at the worst possible moment.”

Ovejero says he was not revolutionising anything and that he was simply borrowing syntax from Rust that had been tried and proven.

Lisette borrows Rust-inspired constructs to address this. It introduces a ‘?’ operator that allows developers to propagate errors concisely, reducing boilerplate for error handling.

Another issue lies in Go’s non-exhaustive switch statements. Developers are not required to handle every possible variant in a switch. 

“We forget variants all the time,” he says. Adding a new variant can silently break existing switch statements unless each one is manually revisited.

Lisette addresses this by enforcing exhaustiveness at compile time. Every possible case must be handled before execution. 

“The moment you finish writing your switch, you know for a fact you’re handling everything,” he says.

The language also addresses unintended state changes. Unlike Go, where variables are mutable by default, Lisette makes immutability the default. 

Developers must explicitly opt into mutation using a ‘mut’ keyword, making every state change visible and deliberate. Functions can also declare whether they mutate their inputs, allowing these guarantees to propagate through the codebase.

Lisette focuses on three principles: safety, expressiveness, and transparency.

Ovejero draws a parallel with TypeScript, which introduced stronger guarantees to JavaScript. “Unless it’s a small side project, I wouldn’t build a production system in JavaScript anymore,” he said. 

While Rust offers powerful abstractions, its complexity can limit adoption. Lisette attempts to retain useful constructs while avoiding the steep learning curve. 

The focus is on readability, recognising that the code is read far more often than it is written.

Transparency is another priority. The compiled output remains readable and traceable, unlike transpiled systems like TypeScript, where debugging can become difficult. 

These concerns are not new. Across forums like Hacker News and Reddit, developers frequently highlight Go’s lack of nullable types, repetitive errors, and non-exhaustive switches as pain points. Tools, like Uber’s NilAway, were built specifically to address these gaps. 

“Adding Rust-like safety checks at compile time to Golang seems like a really cool idea,” says Kirk Kaiser, a software engineer and author of Make Art With Python, to AIM. 

Kaiser said that he also liked that the compiled code could fit seamlessly within the existing cloud-native ecosystem written in Golang.

But Why Build a Programming Language Now? 

The internet today is filled with claims that programming is becoming obsolete. A more cautious version of the argument suggests that while programming will continue, syntax itself may become less significant, replaced by AI agents that write and manage code.

Ovejero disagrees. “I think there’s a lot of room for new programming languages, even in the age of AI,” he says. 

He argues that AI models inherit the flaws of the code they are trained on. “LLMs have been trained over decades of Go code that includes all of these foot guns,” he says. “They’re going to replicate nil panics, ignored errors, non-exhaustive switching.” 

Lisette embeds strict compiler diagnostics that apply equally to human-written and AI-generated code. “You’re having this intelligent compiler driving AI code generation in a safe manner,” he says.

The language is also designed to work directly with AI agents. Each project includes an ‘agents’ file, a structured reference that explains the language’s rules, differences from Rust and Go, and its type system. 

When the agent makes a mistake, the compiler provides structured diagnostics. “The agent and the compiler enter a feedback loop,” Ovejero says, where errors are corrected iteratively without stopping progress. 

In practice, he noted, even models unfamiliar with Lisette begin producing correct code quickly, guided by these error messages.

Readability remains a core concern. As more code is generated automatically, humans are still responsible for reviewing and maintaining it. “You’re going to be accountable for it. You’re probably going to be waking up at 3:00 AM for it,” he says.

Ovejero notes that the framing is not about new languages versus AI. Instead, the goal is to make them complementary, with languages that offer stronger guardrails for AI systems while still producing code that humans can understand.

The Goal with Lisette 

Like many creators, Ovejero began the project out of curiosity. “I started it for fun. I wanted something like this to exist,” he explains. Even though programming languages are often named after reptiles and coffee beans, Ovejero felt they rarely have real personality. Therefore, he named it Lisette, after a close friend. 

Over time, the idea became clearer with multiple iterations. He abandoned and restarted the project multiple times before refining its direction. 

Today, his focus is on two questions. The first concerns how far Go can be evolved while preserving its strengths; the second relates to adoption. 

The challenge is whether Lisette’s gains are enough to overcome nearly two decades of Go’s inertia. To address this, Ovejero is prioritising incremental adoption. Lisette interoperates with existing Go codebases, allowing teams to adopt it gradually, instead of rewriting systems entirely.

The approach mirrors TypeScript’s growth. “There was no mandate to adopt TypeScript, but people could see all the benefits,” he says. 

“My mission is to make it as easy as possible,” Ovejero says, “and then let people decide if it’s something they’re willing to go for.”