The usability of advanced type systems: Rust as a case study

&gt; If we accept that Rust is indeed more difficult to learn than comparable systems programming languages<p>I <i>do</i> accept this, and I try to be honest about it when I&#x27;m shilling Rust :) But at the same time, I think it&#x27;s worth pointing out that what we mean by &quot;learn&quot; can really depend on context. The <i>subjective experience</i> of learning a language looks something like &quot;getting my homework done and turned in for a grade&quot;. And in that sense, for sure, learning Rust is harder than learning C. (I won&#x27;t make a claim about C++.) But what percentage of people who have &quot;learned&quot; C can actually write UB-free C with any reliability? For the folks who really can write UB-free C, how many <i>years</i> did it take you to get to that point?

I’m curious why we see so many papers and discussions about the difficulty in writing Rust relative to other languages. I would like to see more analyses of total cost of ownership.<p>Yes, Rust requires approaching writing code somewhat differently than most popular languages (different isn’t inherently bad), and it’s true borrow checker limitations cause it to reject code that is sound. But that increase in cost at the front end, in my experience, is significantly offset by the decrease in maintenance costs.<p>I’ve spent a non-trivial portion of my career hunting down and fixing memory corruption issues, race conditions, and other undefined behavior in extremely large codebases. Yes, we’ve seen great advances in tooling in Clang+LLVM, but writing that buggy C&#x2F;C++ code is still quite easy (a point I didn’t see in the paper). Using validation tools to their full extent is costly from maintenance, configuration, and compute perspectives, and their correctness assessments are less strong than what an advanced type system provides.<p>Preventing such classes of bugs through an advanced type system seems like a better approach to reducing total cost of ownership because:<p>1. Some classes of (expensive to fix) bugs are eliminated by codifying system behavior into the type system. 2. The need for a variety of CI runs with Address Sanitizer, Thread Sanitizer, Undefined Behavior sanitizer, etc. and their associated corpus of coverage tests is greatly reduced because such issues are defined away by the language. This saves on CI infra costs and requires engineers to spend less time writing&#x2F;maintaining tests to exercise the tools. 3. More engineers will spend more time moving the product forward and less time hunting down hard-to-reproduce bugs.

&gt; [Rust&#x27;s Ownership and Lifetime rules] come with a steep learning curve and have been repeatedly cited as a barrier to adopting Rust<p>Rust Ownership and Lifetime rules aren&#x27;t really that hard to learn. The only trick is that a programmer cannot learn Rust exclusively by trial-and-error (which programmers love to do), trying dozens of syntax combinations to see what works. A programmer is forced to learn Rust by RTFM (which programmers hate to do), in order to understand how Rust works. That&#x27;s all there&#x27;s to it. It&#x27;s like trying to learn to play the guitar without reading a book on guitar cords, pulling guitar strings individually at random - the music just won&#x27;t happen, even if you&#x27;re Mozart.

&quot;The last question I will inspect here is that, if Ownership is difficult to learn and use for so many reasons, why do developers choose to use Rust anyway?&quot;<p>Ownership is not that hard. Borrowing is a bit harder but not that much more so.<p>I use Rust because of the ownership and borrowing systems, not despite them. They help me design systems and write code which has very few bugs once it compiles. (The last code I had with bugs in it I wrote maybe 2 months ago.)<p>I hope some useful pedagogical work comes out of the whole project, but I&#x27;m really doubtful of the premise.

I never understand why people think rust is harder to learn than C. To be able to actually shell out a 100K non trivial C code base, you have to either reinvent or learn all the “patterns” laid out in languages like rust plus more.<p>You can not say you can write a bubble sort in C and you know C, and that’s indeed relatively easy. But you can not actually use it anywhere.<p>Again a good C programmer will be a better rust programmer if he wants to. But sometime the luxury of just work with people with the same technical calibers is a sufficient reason to stay.

Saying other programming languages are easier to learn is practically the same as saying they’re easier to start writing bugs sooner.<p>I forgot who said this but something like “if reading code is ‘debugging’ then writing code is ‘bugging’”

The summary is buried on page 11 in this sentence:<p>&gt; There are almost certainly many other large and small, obvious and subtle reasons for the difficulty of learning and using Rust’s Ownership type system, but these three (Rust’s different paradigm, unhelpful error messages, and the incompleteness of the borrow-checker) are the most apparent from the works surveyed here.

Quote from the paper:<p>Is Ownership difficult to use? “Learning Rust Ownership is like navigating a maze where the walls are made of asbestos and frustration, and the maze has no exit, and every time you hit a dead end you get an aneurysm and die.” — Student participant from [Coblenz et al. 2021]

Is there a well defined class of code, whose expression in Rust, will perform better than what would be emitted by a sufficiently advanced optimizing compiler (say SBCL) ?

What is the role of ARC (automatic reference counting such as in swift) compared to the explicit approaches rust takes?