Rust, once celebrated as a game-changer in systems programming, has found itself facing a wave of criticism following a string of high-profile setbacks. Known for its focus on safety — particularly in concurrency — Rust supports multiple paradigms, including functional, imperative, and generic programming. Its syntax is reminiscent of C and C++, making it accessible yet powerful.

However, recent events have cast a shadow over Rust's momentum. In late December, Daniel Stenberg, the creator of the renowned open-source project curl, announced the discontinuation of support for the Rust-based Hyper HTTP backend, along with the complete removal of related code. This decision has sparked widespread discussion within the developer community.

"The journey is ending. The experiment is over. We tried, but we failed."

Stenberg began exploring the integration of a Rust-based HTTP backend for curl back in 2020. The goal was to leverage Rust's memory safety to offer a more secure alternative to the native HTTP implementation used by curl/libcurl. This ambitious initiative was supported by ISRG, the organization behind Let's Encrypt, and involved close collaboration with Sean McArthur, the lead developer of the Rust-based Hyper library.

Significant progress was made, with Stenberg managing to implement experimental Hyper support within curl. This experimental feature was designed to encourage user feedback and experimentation. By the end of the project, roughly 95% of the integration work had been completed, with most tests running seamlessly regardless of the chosen backend.

Yet, as Stenberg revealed, the remaining 5% proved insurmountable. Persistent issues and obstacles turned that final fraction into a roadblock too significant to overcome, ultimately leading to the project's abandonment.

Why Did the Hyper Experiment Fail? Two Key Reasons

The failure of the Hyper experiment can be attributed to two main factors:

First, there was minimal demand for it. Curl users showed little interest in adopting the Hyper backend, and existing Hyper users weren't concerned with whether it was compatible with curl.

Second, the integration of the C-based libcurl library with the Rust-based Hyper backend required a C "glue" layer. This posed a significant challenge, as it demanded developers who were proficient in both C and Rust, along with a deep understanding of the underlying architecture and protocols. Unfortunately, such developers were in short supply.

Given the expectation that completing the Hyper integration would take too long, coupled with the high cost of maintaining the code, Stenberg and his team decided to cut their losses. Removing the Hyper code was necessary to maintain flexibility and reduce complexity in the long run.

Though the experiment failed, Stenberg believes valuable lessons were learned. The process led to improvements in curl. In fact, when the Hyper project was initiated in 2020, Rust itself wasn't fully ready for such an ambitious undertaking. Over time, however, Rust has evolved into a more robust language, better suited for projects like Hyper.

In addition, even after abandoning Hyper, curl still supports two experimental Rust-based backends: rustls (for TLS) and uiche (for QUIC and HTTP/3). These backends use cleaner internal APIs and integrate more seamlessly with libcurl, making them easier to maintain and support compared to Hyper.

As of now, the Hyper super-backend code has been removed from curl's Git repository, and it will not be present in curl version 8.12.0, slated for release in February 2025.

Despite the removal of Hyper, Stenberg remains open to the possibility of introducing security backends written in Rust or other languages in the future. With an improved internal architecture, curl is now in a better position to experiment with these ideas using different approaches.

In a similar move, another prominent open-source project, Prisma, also announced in early December that it would be migrating from Rust to TypeScript. This decision was made in pursuit of a better plugin and extension ecosystem.

In their statement, Prisma explained that its architecture had long limited community contributions. Core functionality, such as query parsing, validation, and execution, was managed by the Rust engine, which made it opaque to the TypeScript-focused community. As a result, Prisma decided to migrate its core logic from Rust to TypeScript and redesign its ORM to make customization and extension more accessible for the broader developer community.

In recent years, the Rust programming language has been on a meteoric rise, consistently climbing the ranks in various programming language charts. For instance, in the 2024 IEEE Top Programming Languages ranking, Rust holds a prominent position. There is also a growing call to replace C and C++ with Rust in many software projects, especially for tasks requiring high performance and memory safety.

While Rust is undeniably powerful and stands out for its emphasis on safety, it comes with a relatively steep learning curve. In a survey titled "What's preventing you from learning Rust in 2025?", one participant made a compelling point: the C/C++ libraries they frequently use are among the best in their field, backed by decades of development experience. For Rust, they would either have to invest significant effort to learn it or resort to using obscure, lesser-known packages with no pedigree. Others simply found Rust's syntax unattractive.

In fact, earlier in 2024, an article on Medium recounted the experience of Austin Starks, who spent 18 months rewriting his algorithmic trading platform in Rust. Despite the extensive effort, he ultimately regretted the decision. Let's dive into Austin's journey and explore what went wrong.

At the beginning of his article, Austin openly admitted that he was once a passionate advocate for Rust. The language seemed to be one of the fastest and safest programming options available. It wasn't just his personal opinion — he realized he wasn't alone in this belief. If you spend time reading articles about Rust online, you're likely to encounter overwhelming praise. Every guide on Medium, every post on Reddit, and every answer on Stack Overflow seemed to sing Rust's praises.

This was the beginning of Austin's story — or perhaps more fittingly, the start of his "nightmare." Eager to dive into the language, Austin made the bold decision to abandon TypeScript and rewrite his entire open-source algorithmic trading system in Rust.

The warning signs of an unpleasant experience had already appeared earlier. Before diving into the full rewrite, Austin had written another piece about his initial foray into Rust. While he appreciated the speed and some of the design decisions, he wasn't entirely in love with the language itself. His article, however, was met with fierce backlash. One of the most popular comments even accused Austin of having used ChatGPT to write the article — perhaps the highest form of criticism in the AI era.

Austin's Disillusionment with Rust: A Developer's Frustration After 18 Months of Struggles

After some reflection, Austin wondered if he had perhaps not given Rust enough of a chance. Determined to make the most of his experience, he decided to continue using Rust for a while longer. After spending more time with the language, he was finally able to confidently draw a conclusion:

"Rust is awful!"

So, where exactly does Rust fall short?

Austin used several words to sum up his growing frustration: awful, verbose, and difficult-to-understand syntax and semantics.

He vented that anyone claiming Rust's semantics weren't problematic was lying. Without an exceptionally powerful language model, many tasks simply couldn't be accomplished while writing functions. For example, he didn't want to spend 90 minutes deciphering the where clause in the run_transaction function. Eventually, he gave up trying to use helper functions altogether because it seemed impossible to get the code to compile. The very feature touted as Rust's greatest strength—the strict compiler designed to eliminate errors—was, for Austin, its biggest weakness.

He even offered an example: if he were to write the same function in Go, it would look something like the following. While the core structure of the function would remain largely unchanged, the Go code would simply work as expected without the need for complex adjustments, tricks, or endless trial and error.

Austin did concede that Rust might have some advantages in error handling. As long as you avoid using the unsafe unwrap (which could lead to runtime errors like null pointer exceptions), you can be fairly certain that your code will run and continue running. But is that really the case? Austin's answer: No!

He pointed out that when something goes wrong with the data or unexpected errors occur, developers often struggle to quickly diagnose the issue, as the error messages are typically not very helpful. The root cause of the error can be elusive. He joked that perhaps he hadn't found the correct method to enable stack traces, which only made debugging more challenging.

In contrast, languages like Python provide stack traces that clearly tell you exactly what happened, even down to the line number. Austin mentioned that even Go, with its errors.Wrap(...) feature, offers a way to view the entire error stack. Clearly, this was a design flaw in Rust.

Beyond Rust's design shortcomings, Austin also had issues with the community atmosphere. He noted that the Rust community was quick to dismiss any criticism of the language. Voicing concerns would often result in being attacked, and asking questions might invite snarky or condescending responses.

Have you used Rust? Feel free to share your experiences in the comments below.