
Rust's Complexity Problem – A Warning - jcirclee
https://medium.com/@JoeKreydt/rusts-complexity-problem-a-warning-55c3a6484038
======
mamcx
I think the premise is flawed ("Rust way is clever, ergo, problems").

BTW, I have many troubles with rust, that after more than a year are more
stable ( _starting_ with rust I could have believed what this post say):

[https://www.reddit.com/r/rust/comments/fj824y/whats_your_con...](https://www.reddit.com/r/rust/comments/fj824y/whats_your_controversal_rust_opinion/fkm9cq3/)

I rewrite a huge (for a solo dev like me) codebase from .net/f# to rust, used
in ERP-like app by the small/medium companies on my country. As "normal" and
"boring crud" apps as you can tell.

The complexity of the development wet DOWN, A LOT. Even taking in
consideration the use of F# (that I also pick to reduce the burden of using
C#), the code have MUCH less bugs and troubles. We were on "fire mode" for
some months and after the switch, all is calm as I have not experience in a
lot of time.

And, as I say: I'm a solo developer. Still learning rust.

\---

BTW: I only hit serious blocks working in a relational language on the side.
For "normal" enterprise coding? Rust is a total win.

------
rapsey
> but in order to manage memory the way the borrow checker wants, the
> programmer is at best tempted, and at worst forced, to add complexity to the
> program.

This is a problem for newcomers because they have to adapt their way of
thinking into Rust way of thinking. Once one develops a set of patterns and
principles this is not an issue.

Companies who have large codebases in Rust tend to have praise for it enabling
solutions that are much easier to reason with and work on then if they were
developed in C++.

It is obvious the author has little to no experience in developing production
software in Rust.

~~~
chiefsucker
> It is obvious the author has little to no experience in developing
> production software in Rust.

Statements like these don’t necessarily speak for the user-friendliness of
Rust or Rust itself. Safety? OK, cool. But for what cost?

~~~
jacobr1
I think the cost is roughly: "we force you to reason about, and account for
safety in the code." Then given that this is now explicitly forced upon the
developer, are Rust's constructs overly complex, or reasonably once someone
gets over the learning curve? The alternative is using a managed runtime,
which probably should be the default for most programmers. But for those that
are doing systems programming, we absolutely need something "like Rust." The
memory access patterns need to be explicit.

------
pfraze
I'm interested in Rust's future, but not a Rust developer myself.

The author's argument is pretty straight-forward: Rust's borrow-checker makes
for complex code, so you should think carefully whether your application is
resource-constrained enough to merit using Rust. If not, you should consider
using a memory-managed language.

He's pointing this out as a contrasting point to projects rewriting in Rust,
which is what naturally happens when a new language starts going down the path
to becoming a Mainstream Programming Language™️. This sets up the question
that I'm waiting to get answered: is Rust actually complex enough that it
should be a niche PL rather than a mainstream PL?

How do current Rust devs feel about that so far?

~~~
qchris
I use Rust both professionally for parsing large datasets and image
processing, and on most of my personal projects. I'm probably a little biased,
since I both aesthetically like how Rust "feels" and that a lot of how it
deals with the complexity of computers fits well with my own mental map of how
computers work. Whether that's a chicken or the egg situation is up for
debate...

That said, I think a counter argument here comes back to they complexity
budget. I don't feel like language design and borrow checker are inherently
more complex, but rather that they explicitly pull out that complexity, but in
a way that feels manageable. I know that that since writing more Rust, my code
written in other languages like C++ or even Python have started started having
patterns that I picked up from my work in Rust, and that I qualitatively feel
like that has raised my code quality in those languages. I'm also definitely
more aware of some of the hidden complexity in certain tasks like dealing with
system paths.

So at least in some degree of summary: no. I like the level of abstraction and
complexity Rust has, and the mechanisms in place for dealing with that
complexity have largely seemed both well thought-out and implemented such that
they are accessible to a mainstream audience.

~~~
pfraze
Thanks for the insight!

------
devit
> order to manage memory the way the borrow checker wants, the programmer is
> at best tempted, and at worst forced, to add complexity to the program

Dubious claim; in fact, the opposite seems true, since simpler code passes the
borrow checker more easily

------
DannyB2
Quote 46 from here: [https://www.junauza.com/2010/12/top-50-programming-
quotes-of...](https://www.junauza.com/2010/12/top-50-programming-quotes-of-
all-time.html)

6\. "A programming language is low level when its programs require attention
to the irrelevant." \- Alan J. Perlis.

~~~
adamnemecek
What's irrelevant tho? Like memory layout might seem irrelevant on one hand,
on the other if you care about perf you need to know this.

~~~
Koshkin
but perf is "irrelevant"

~~~
terhechte
In times of climate change, is it? If you can run one machine instead of 60,
that is not just a financial win, it is also a ecology win. Not to mention
that having 60 machines suddenly requires additional complexity in other
parts: Load balancers, memcaches, distributed somethings. Performance also
buys simplicity.

~~~
saagarjha
My guess is that the comment you were responding to was sarcastic.

------
fiedzia
> in applications that don’t require maximum resource efficiency and memory
> safety, adopting Rust in 2020 is irrational at best

which applications don't require memory safety?

~~~
lkschubert8
Just have a cron job restart the service daily to fix all the memory leaks /s

~~~
steveklabnik
(I know this is a sarcastic comment, but memory leaks are memory safe and Rust
does not prevent them (though they do tend to be less common))

------
gautamcgoel
I can't read this without creating a free account, which I refuse to do. Is
there another way?

~~~
ptrik
[http://archive.ph/xg3op](http://archive.ph/xg3op)

------
time0ut
I only have a passing familiarity with Rust. I've worked through some
tutorials just to try it out, but its not even close to one of my daily
drivers. Coming from that perspective, it is really hard to evaluate the
argument this article makes because the author provides no concrete examples
of this extra complexity. Does anyone have a clear example a non-expert can
look at?

------
whateveracct
There is a fair point here that always gets brushed under the rug when
discussing Rust vs X: Not having a GC means Rust forces you to think about
memory allocation throughout your program's logic & structure. That's a cost
and many programs don't benefit from it at all.

I had a Rust vs Haskell debate with a VPE at a company (he wanted to move to
Rust.) He refused to acknowledge that the fact that Haskell has a GC is a big
advantage over Rust for many applications (ours included.) It didn't help that
he (somewhat arrogantly) fashioned himself a "systems engineer" and would've
chosen C++ if he could've.

It wasn't the crux of the argument (there's a lot more to those languages) and
this VPE clearly wanted to move away from Haskell from day 1, but nonetheless
- a very frustrating discussion to have.

I'm not a Rust expert though so please correct me if there's a way to right
large Rust programs without worrying about memory management.

~~~
jonex
You can consistently use reference counting if you want to avoid thinking too
much about memory management.

Haskell vs Rust is probably a question of much more than a GC or not though.

~~~
whateveracct
> Haskell vs Rust is probably a question of much more than a GC or not though.

Oh yes 100%

My issue was that the discussion was disingenuous. GC was used to knock
Haskell, but the cost of Rust's memory management model was not listed at all,
thus painting an unbalanced pro/con picture (the scales were unbalanced!)

------
quantum_state
Would think the architecture & design of software applications are the natural
place to manage complexity, whatever the programming language is. It is simple
an illusion to rely on programming language alone to manage complexity.

------
Koshkin
Ideally (not realistically), every application should be written in its own
language. In any case, trying to be "everything to everyone" inevitably leads
to "problems."

------
MuffinFlavored
I would personally never reach for Rust for a project unless I needed bare-
metal performance. I can make API calls + database calls + interact with USB
devices/filesystems in node.js with much less complexity and a much stronger
ecosystem.

~~~
steveklabnik
I don't know why you're downvoted; this is a decent argument in my opinion.
Node has a fantastic ecosystem, and API + database calls (aka, IO) are its
bread and butter.

We see people switch from Rust to node due to scale and reliability. If you're
not feeling those pains from Node, then you should absolutely keep using it!

~~~
MuffinFlavored
Do you mean to Rust from node?

~~~
steveklabnik
Yes.

------
Koshkin
The intentions are good. (Just like those of C++.) Problem is, as they say, it
is the road to hell that is paved with them.

