If Rust is too hard, quit programming and become a hairdresser

It is a catchy title but a terrible argument. But it provides a teachable moment, for somebody like me who has spent a lot of his career working on usability, communication and teaching. I think my first calling to champion simplicity and ease of use happened when as a child, a friend told me that a PC with MS DOS was more complicated to use than my Amiga Computer, because it was more “sophisticated and advanced”. Ever since they I have noticed that people are very eager to make up excuses for the complexity of the tools they use, and put down those who try to offer simpler solutions.

Any darn fool can make something complex; it takes a genius to make something simple.
— Albert Einstein

It is a good quote, and although it is attributed to Einstein he probably is not the originator of it. Still it is a good quote. Nobody in the world ever complained that our programming languages are not hard enough. Making hard programming languages is not a challenge. If you want to impress me, you create a simple solution to a complex problem.

Imagine working for Steve Jobs making a new revolutionary product. You made an iPhone with 20 buttons and a rotary dial and you are proud of yourself that you can work its complicated interface. Then Steve Jobs comes to you and tells you: “This is too complex, too hard to use. Make it simpler!”

Your response to Steve Jobs is: “If you think my iPhone is too hard to use, maybe you shouldn’t be in hardware development? Perhaps you should be a hairdresser instead Steve Jobs!”

Do you think you would have kept your job? I don’t think so. You impress nobody with complexity, apart from perhaps fellow geeks. Why do you think programming language development has been about all these years if not to reduce complexity and make programming a computer easier?

Using your line of argument I could have told anybody complaining about x86 assembly code programming being hard, that they should be a hairdresser instead. The C programming language was an answer to that complexity. Many people where like you initially, sneering at programmers picking the “easy solution” over programming like a “man,” using assembly.

C++ has in many ways become the new assembly programming language. People take a sick sadomachistic pleasure in handling its complexity and dismiss anyone complaing about its complexity as not being “real programmers.” Rust was after all designed specifically to reduce that kind of complexity.

If you want zero cost abstract, and tight control over memory like C++ does, then Rust is a good alternative. Why? Because it manages to do almost all the things C++ does with less complexity and better safety.

Not Every Solution Require Zero Cost Abstraction

But not every problem requires a C++ style programming language. In fact I frequently use Julia for data science, simulations, text processing, machine learning etc. In this space few people use C++, Rust and languages like that? Why, are they all just wannabe hairdressers? No because this style of programming is naturally interative and iterative. You got large datasets you load and experiment with. You don’t want to reload them every time you make a code change. And people doing science have better things to do than learn about object lifetimes in Rust, or about references to pointers to pointers in C++.

The Purpose of Rust and Zig

Rust was designed to deal with the difficulty of building enormous software like a modern web browser which needs maxium performance and needs to juggle multiple threads. So much critical software today runs on top of web browsers that they really need to be reliable, which is difficult when you got 8 million lines of code juggle. Rust brings complexity as a language, but that complexity can be utilized to manage those 8 million lines of code. In this case it can be worth it.

That is what we deal with in software engineering. We try to find the right tradeoffs for the problems we are working on. I am happy with Julia for most of the work I do. But I also do microcontroller programming as a hobby, or make small game engines. In these cases I am not dealing with millions of lines of code and the complexity Rust adds, does not necesarily give me anything back. There is a significant investment in learning Rust. That is just an observation plenty of people who are proficient in Rust have made. It makes litle sense to make that investment for a hobby project.

In this space even assembly code can work fine. I have done small microcontroller projects that require maybe just 15–50 lines of assembly code. That is small enough that a high level language doesn’t buy you all that much advantage. As things get bigger you benefit from C. As they get even bigger something like Zig would help you. But I will simply not be making microcontroller projects at a scale where Rust will pay off.

What I would use instead of Rust

My primary experience working on large projects have been developing 3D modeling and simulation software for the oil industry. In this case I was using C++, and Rust could have been a nice replacement. However a lot of our work involved creating complex graphical user interfaces for use by geophysicists, geologists and other domain experts. For this task Swift is a much better designed language than Rust. The creator of Rust, Graydon Hoare even works on Swift and is quite positive to the language. I wouldn’t put past you to suggest he should work as a hairdresser instead for caring about another language besides Rust.

Swift has a lot of the same advantages as Rust. It does not have zero cost abstraction, but it trades in some performance for a more user friendly language that a broader set of people can use.

Rust Compilation Times

Not if you structure your code properly. Also, they are necessary if you want 1) your code to run fast 2) your compiler to do semantic analysis.

That sounds like a C programmer telling a Java developer that memory management is not a problem as long as you structure you code properly. Or a Assembly programmer telling an Ada developer that lack of types isn’t a problem as long as you structure your code properly. Sure, in every programming language you can overcome problems with more software engineering disipline. But the whole point of creating new langauges is to reduce the cognitive load. If that doesn’t matter, we might as well program in machine code directly.

Rust complication time is a real problem that many have remarked on. It certainly was a problem in C++. Sure we improved it a lot with better software engineering. But the problem is that the language itself does not help you much in doing things the right way.

Compilation times has real impact on productivity and your ability to deliver quality software. With quick compilation times you get more rapid iterations and can more quickly weed out problems and deliver software quicker. An emphasis over upfront correctness at the expense of rapid iteration leads you to water fall software development, and we all know that that has not been a receipt for success.

Compare SpaceX with the development of SLS. SLS uses the Rust approach of verifying everything upfront. It is the old style of engineering with emphasis on producing reams of specs and documentation. The problem is that the real world is more complicated. There are always unforseen things you need real world experience with.

That is why the SpaceX approach of moving fast and break things have been so much more successful. Yes they do less formalized verification up front, but they do tons of rapid iterations and weed out problems over time. The end result is much quicker development time, lower cost and better product.

If your goal is to compile 400k of generated garbage, go with whatever.

It is a stresstest, I hope you undertand what that means? It is a simple way to compare compilation speeds. You really display a very childish fanboy attitude towards this. When one of the co-founders of Rust and Servo, Brian Andreson even writes long articles about their problem with compilation times in Rust, who are you really to belittle that problem?

If you want to build load bearing software you’ll need the above + generics, hygenic macros, etc.

No, you don’t. Lots of crucial software has been built for decades without your coctail of favorite Rust features. These features can be used to reduce the workload on engineering. As I elaborated on before, it is all about trade-offs which are decided by the kind of software you build. The Linux kernel is perhaps one of the most “load bearing” pieces of software out there and it is written in C, a rather unsafe language.

Critical software like Docker and Kubernetes, used by lots of developers all over the world is written in Go, which pretty much lacks all the buzzwords you list.

Yolo Land

On the other hand, Julia is exceptionally good in the yolo-based programming land, multiple dispatch is probably the final answer for composing software.

As I said, it is about your problem domain. Rust would be a bad choice in most of the areas where Julia excels. Plenty of large projects have successfully been built with dynamic languages. But I know there is a prevalent arrogance within the static typing crowd towards dynamic languages.