Feeling down about Rust for serious projects

Some projects are not realistic for one person in a reasonable amount of time. About 40 years ago, I was working for a company making compilers, C, C++, Modula-2, Pascal were no problem, but one team member was tasked with Ada. Of course it is lucky that nobody told Linus Torvalds what he could not do.

First of all, I think its important to distinguish large projects from serious projects. I concede that large projects in any language will have a great deal to think about. One way to compare languages is by the things they allow you to do relatively simply.

In Erlang (or nowadays, Elixir), for instance, you get parallelism and a fault tolerance model for free.
It also has a nice bit syntax and immutable data structures. Together these make writing many types of programs extremely simple, and perfectly reliable. Of course this comes with a lot of complexity built into the runtime, and a loss of control over many types of decisions.

From my perspective, in Rust you pay more in terms of 'time to first working version' of anything you do. I find that if I try to write down the most direct model of an approach to a particular problem, I generally spend most of my time placating the compiler and forget what I was actually trying to do. My workflow these days seems to be to prototype in TypeScript first, to try and work through the core aspects of an idea, before attempting it in Rust. And even having done that, and finding what I consider a minimal impedance mismatch for whatever I'm trying to do, I still find myself fighting with rustc for a long time to get it the way I want. That's not to say the struggle isn't a useful part of the process. In fact, the reason I like Rust is that it allows me to express complex constraints and have the compiler do a lot of work for me, but its also highly opinionated with a lot of rough edges.

My only real point is that I don't consider this a fast process, and I empathize with the OP. I do consider it a great way to produce robust and efficient software. But not all serious projects require the same level of efficiency, and it definitely comes at a cost, in my experience.

3 Likes

Yeah, I think this "extra cost" of Rust does actually exist in a certain way, like how you describe that Erlang's runtime will do a lot for you. I think Rust allows you to do a lot more for yourself than some other languages, and if there isn't already a Rust framework that is really setting the stage for what you want to do, you have to bear more of the burden of doing it yourself.

When somebody makes a great, ergonomic framework for Rust that will really streamline what you are trying to do, and that makes a lot of decisions about how it is done for your, I think you approach the initial cost of other languages and ecosystems, and you get the cool ability to do some things yourself, while being able to re-use an existing framework.

Also, since Rust lets you do stuff yourself, it means that not every Rust project must share the same "framework" for async code and actors and stuff that, for instance, come with Erlang, so even the these different Rust frameworks have more to do themselves, or otherwise decide how to do, than frameworks in other languages.

One of the hardest things in designing new projects is making decisions about how you are going to put it together, and there are sometimes more questions that come up in Rust, or at lest those questions are made into a bigger deal, or made more obvious by the compiler earlier on, which I can imagine making it more difficult for some people to start a project with.

This isn't as much of a cost for people who have internalized a lot of the compiler rules or already have a good idea of what their design should be, though, so it's going to be different for different people and different projects.

I see the fire-n-forget concept very much problematic because TCP is chosen over UDP because of its guarantees of the connection and communication state.

It is a normal and perhaps natural approach to start with synchronous programming but unfortunately todays web development in Rust is almost always asynchronous. The asynchronous approach does not forget about the response but issues a Future to deal with the result when it arrives not blocking for it until it arrives.

Additionally it is noteworthy that there are already very good asynchronous web development libraries in the Rust core that implement low-level parts of the OSI-Model.

For a serious project it is always advisable to build on existing libraries to speed up the productivity rather then re-writing them from scratch.

You might want to checkout libraries like:

Even if you think that those libraries do not match your requirements, studying their code certainly will bring you also forward with your different approach.

Then for web development you might want to use some of those already existing web development frameworks.
I personally like the Axtix Web Framework very much because it produces nice, lean and maintainable code.