Rust is again most-loved in Stack Overflow survey

I have two very simple answers to this question:

  1. If you use any programming language long enough you will come to think it sucks. For all kind or reasons. Use many, over many years, they all suck.

We know this to be true because those that do a lot of programming in all kind of languages and have the skill and talent end up inventing and implementing their own new programming language to fix all the pains they have suffered in the past. As you know, new languages sprout like weeds as a result.

Given the above, for sure if you ask programmers what language they love it will not be the one they are using or any they have used in the past.

As almost no programmers have had to use Rust for the long haul so far of course they will say they love Rust.

  1. It turns out that Rust is the only language of the dozen or so I have used professionally for four decades that actually introduces genuinely new features. Namely the whole idea of safety of memory usage in a compiled, real systems programming language with no garbage collection or complicated run-time system.

The first language since Ada with an emphasis on correctness. As opposed to the wobbly foundations of all the others.

The fact that Typescript is high on the list rather supports the idea that people are looking for something solid.

14 Likes

Rust does a lot of my thinking for me, particularly when I'm writing multi-threaded code.

7 Likes

Coming from languages with a substantial runtime or weak typing, I found it was easy to get started on easy problems, but in the long run the same thing making it easy to get started created hard problems to fix. I'm unsure if the low price I paid in the start compared to what I got over time was worth it.

In Rust, I find that a lot of the effort is front loaded. It makes easy problems somewhat harder to get started on, but it doesn't create hard problems later on. If there are problems it's most often the problem domain itself that is harder than I thought, and not related to the tools I use. I find the price I pay up front is definitely worth what I get. I also find the price low once you get to know the language well.

13 Likes

Here's a dump of some possibly relevant reddit discussions:

And personal blogs:

If nothing else, I highly recommend reading the iconic and extensive post, fireflowers - The Rust Programming Language in the words of its pracitioners.


As for my own opinion, I think there are too many things to list, so I'll just say things briefly.


Compile time guarantees: When I think of a "staticly typed language", I think of Java, or C#, or something like TypeScript. They give compile time assurances that your code has the correct types, and move a set of errors from runtime to compile time. Rust goes one magnitude further in this! Compile time checking extends to thread safety, to ownership semantics, to validation.

Enums mean that I can at compile time declare the set of variants my data can exist as, and when accessing that data I'm forced to consider all possibilities. Traits mean that when my code is templated/generic, I have exact capabilities I can require.


As a library author, the complex trait/generic system means I can craft intricate, yet easy to use interfaces. These interfaces cannot be used incorrectly, which means I don't have to perform runtime checks, and my users don't have to even think about problem cases, because they can't write them.

As a library consumer, the rich and extensive crates ecosystem enables me to write code in vast different domains without needing to dig into the specifics of every one. I don't need to know how a JSON parser or writer works to use serde - and my lack of knowledge won't ever be a source of bugs, because I get compile time errors rather than runtime ones.


Last, I really appreciate how rust has been designed for backwards-compatibility. Rust is extremely backwards compatible. I can run code written for Rust 1.0. Equally, I can write code which I know I won't have to update next time I update rust.

And it's not just Rust itself - the language enables libraries to have the same guarantees. Consider two facts:

  • In typechecking, only the signature of functions are considered. There's no relying on the implementation for determining if callers are correct (like you can do in Scala, or Haskell)
  • The extensive type system means incorrect usages of interfaces become type errors, not runtime errors

Because of these two things, libraries can be 100% sure that they maintain backwards compatibility when releasing a new interface. In Python, or Java, or Javascript, or even Scala or Haskell, you need to pay extra attention to implementations of things if you want to ensure you maintain backwards compatibility. In Rust, it's free: if you haven't changed the function signature, it remains the same. It's incredibly hard to have accidental interface breakage.

This means that as a consumer of rust libraries, I have no fear of upgrading. As long as they've kept the major version the same, my code works with the newer version. And Cargo takes advantage of this: cargo update keeps me on the same major version, but otherwise upgrades all of my dependencies for free.


In conclusion, I just feel really taken care of when I'm using rust. There are so many trivial things, from package upgrades, to type errors, to passing in a string which an interface doesn't expect and getting a random runtime error which I'm completely free of in Rust. I can just think about the algorithms! That's why I love rust.


Edit: just to emphasize it, I really, really recommend the fireflowers post. It's the result of a whole bunch of research into why different people like rust - it gathers a few key insights into what Rust offers, contains many user testimonials, and at the end links to a number of other response blog posts which give even more insight into the situation. Disregard my own post, this is the useful thing. https://brson.github.io/fireflowers/

The only downside is that it's from three years ago - though if you're doing research into why Rust has tipped the scales so many years in a row, maybe that's even more relevant?

20 Likes

FWIW I had a similar "grass is always greener" bias toward various languages over the decades. But I think this isn't one of the primary contributing factors to this phenomenon. If it were, we might expect some of the newer languages to come out on top in these surveys, right?

An observation

I can make an observation that I think will hold true for many (if not most) of the people who claim Rust is their most loved language. It's akin to wandering around in complete darkness for an entire career, and suddenly being enlightened to two facts:

  1. You are not perfect. You will make mistakes. Those mistakes will cause you a lot of problems.
  2. It doesn't have to be this way.

Tangentially, I see a common dissent where some proclaim that they are in fact perfect, and that they do write flawless code, and everything is peachy, and they can't understand why everyone else is so interested in Rust. I do not claim to speak for these people, nor am I particularly familiar with their experience, credentials, or accolades. But it's clear to this old goat that these are the people who haven't yet learned that the problem is not strictly themselves; it's everyone else. It's a problem of economy of scale.

The collective noun "you" as used in my list of facts is referencing an entire audience; not just an individual. In other words, I myself could write flawless and bug-free code in isolation if I had the time and energy to pay attention to every minute detail and meticulously hand-craft every beautiful line regardless of the language or implementation details. But that doesn't matter. Once I start depending on code written by other people or new contributors come along and make modifications, all of my so-called guarantees of perfection are now incompatible with reality. "Correctness by convention" does not scale.

An epiphany

No matter how much after-the-fact tooling and process rigidity you have, conventions will have faults and impractical amounts of time and energy will be spent trying to automate a bandaid that should not exist in the first place. It's the second of the two facts that is the truly remarkable part of the discovery process. The "aha!" moment is realizing that one can actually get much stronger guarantees by baking those same conventions directly into the language and compiler.

You can't sacrifice memory safety, type safety, or data race safety. In many languages these are either optional or there is no way to make such guarantees. But they are all required in Rust. To top it off, you can also get performance equivalent to that of finely tuned hand-written assembly, if you so desire. You can have your cake and eat it too! The remaining features of the language are truly the icing on this sweet recipe.

Or to sum it up, Rust is the only language that ticks all the boxes:

  • Memory safe
  • Type safe
  • Data race-free
  • Ahead-of-time compiled
  • Built on and encourages zero-cost abstractions
  • Minimal runtime (no stop-the-world garbage collection, no JIT compiler, no VM)
  • Low memory footprint (programs run in resource constrained-environments like small microcontrollers)
  • Targets bare-metal (e.g. write an OS kernel or device driver; use Rust as a "high level assembler")

Ergonomics

Beyond safety and performance, we have: Generics; Traits; Algebraic types; Functional and imperative paradigms; Perhaps the world's best dependency management and build tool which has practically solved the "dependency hell" problem; Fantastic support for inline documentation, tests, and benchmarks; A large and growing ecosystem of libraries, abstractions, and tools; Procedural macros; FFI interoperability with existing code; Support for dozens of platforms (with more on the way!); And a developer experience that is just wholesome and unquestionably satisfying. All of these contribute to what makes Rust a very appealing language.

20 Likes

I wholeheartedly and very strongly disagree with this assertion.

Rust is currently my favorite language by far, despite the fact that I've been using it for 4 years now (for personal projects, as well as "real" code, out of need for performance). By the time I had this much experience with C and C++, I had already discovered their bundle of serious shortcomings.

Heck, even Haskell, the most elite of elegant languages, showed its inevitable ugliness after about a year or so, when I had to start fiddling with language extensions and dialects in order to get a somewhat advanced library to compile.

This simply didn't happen in Rust. The bag of footguns and design errors just never emerged from the mist.

10 Likes

Let me ask some simple questions:

  1. Who would stand up for computing systems that are not efficient and maximally performant?

A lot of currently used languages are interpreted. They need orders of magnitude more machine cycles to get a result than the actual machine cycles required. That means they burn more energy. That means higher electric bills. Ultimately that means contributing to global warming.

Some of the above will matter to the likes of Google and their huge data centers. But even for the individual it feels yucky to be so inefficient.

That leaves us with efficient compiled to machine code languages like C and C++. Not to mention long forgotten favorites like ALGOL, Coral, Ada, PL/M etc, etc..

  1. Who wold stand up for computing systems that don't try to ensure correctness of behavior and results?

Given the fallibility of human coders it is desirable that the tools they use help them avoid as many mistakes as possible. Or at least survive the consequences in a predictable manner.

That desire rules out C, C++, Coral, PL/M, etc, etc... Wonderful as they are they do not do anything to help with silly errors in the code that humans write.

As far as I can tell the last bastions of efficiency and correctness were ALGOL and Ada. Both of which fell by the wayside partly because they did sacrifice some run time efficiency for correctness at a time when computers were much slower.

What does that leave us with? Ah yes, only Rust. As far as I know.

Call me crazy for saying all that but at some point physics and logic trump ease of hacking out code.

6 Likes

I want to put a small asterisk on that "Most Loved*" statistic.

SO's most loved metic is derived as the percentage of developers that say they are currently using Rust that also say they would like to continue using Rust.

To be perfectly frank: I think Rust benefits here that very few people are being forced to use Rust. Most people are electively using Rust, still.

This the fact that Rust scores the highest "Most Loved*" score may not be entirely based on the fact that people that like the language, but also on the fact that people who don't like the language just... don't use the language.

I'm not saying Rust doesn't deserve the label (I'm pretty sure it does!), I'm just arguing that Rust is in a very good position to "game" the metric SO is actually measuring here, because it has a large elective adoption from enthusiasts but a low(er) adoption by those who would mandate people to use a language they would rather not continue to use.

16 Likes

I'm not sure which part you are disagreeing with.

Edit: Deleted an unfounded argument here...

1 Like

I believe that Rust is challenging to learn but rewarding to use.

I think it is actually surprising how much people enjoy being challenged as long as the reward is good enough. The reward to me has been confidence. Confidence that my program won't blow up on me. Confidence that I can change the code and refactor without braking something. Confidence that I can write better performing, lower level software.


I am a professional full stack developer. I mostly write software that is actually fairly simple if you think about it. Mostly just querying and updating stuff in a database and displaying it to the user. But it is surprising how slow, inefficient, and error prone that actually ends up being most of the time.

For example, our company has a Ruby on Rails application that uses 1GB of memory, takes 1 second to render even simple pages, and new errors appear all the time. It was easy to write but it has become impossible to maintain. I know that you can write well performing Ruby on Rails servers but I think it takes a talented team of people with a lot experience and knowledge specific to Ruby on Rails to pull it off.

I think a lot of languages have focused on making software easier to write, but I think Rust has focused on making good software easier to write. Not good software in an abstract sense like "Look at the code! It's so simple and elegant!" Sometimes Rust code can be simple and elegant. This is usually because some smart people really know how to use Rust to make great libraries. But I am talking about good software in the concrete sense. More like "Look at how few bug reports we have! Looks how low our latency is! Look how high our throughput is! Look how much money we are saving by running fewer less expensive servers!" You also don't have to be the best programmer in the world to take advantage of it. Rust allows average programmers to make great software too.

I picked Rust up for a personal project after trying to do it in TypeScript. It was a simple Japanese to English dictionary app. I wanted it to work offline in the browser as a PWA so I had to do full text search without my usual go to, ElasticSearch. I tried using a couple of JS libraries but nothing I tried could do even a simple search without taking a minute. So I decided to learn Rust because I could compile it to WASM. I made a simple prototype without a library that could do a simple search in about 100 ms. I then found a full text search library and got it down to less than 1ms without much effort. It was challenging to learn Rust, but it was worth it because it solved a real problem for me.

I found Rust hard to learn but pretty easy to use. I think a lot of people come to Rust from a different language and are surprised how much different (and therefore hard to learn) it is . But they forget how hard it was to learn to program in the first place. In college, we had two courses on Object Oriented Programming in Java. By the end, most people still didn't really get it. Rust is different enough from other languages to be hard to learn. It's hard to learn say Functional Programming if all you know is OOP. It's hard to learn OOP if all you know is Fuctional. It's hard to learn Ownership if all you know is GC or manual memory management. Traits are pretty weird too. But it's worth it for better software.

13 Likes

Your ad hominem attacks are not welcome.

Furthermore, you misunderstood my statement. I clearly stated "By the time I had this much experience with C and C++" — meaning that I've been necessarily using C and C++ for a longer time than 4 years.

I hate to get into comparisons of experience and authority, but here we go then.

I'm now 26. I discovered programming at the age of 9. My first language was QBASIC because that was the language for which I found an old book in the school library. I didn't even have internet at home back then (the family just got hold of our first ever computer), so I downloaded the QBASIC interpreter to a flash drive to take it home.

No wonder I hadn't discovered any more decent or at least more modern/more used languages until years later. I was messing around with Pascal too, but it wasn't until I went to high school that I found out about C and C++. This was in 2007. I haven't stopped using them since, and I picked up Objective-C around 2009, because I got into iOS and jailbreaking. I had my first iOS developer job at the age of 17 in 2012, then in 2018, I secured a senior iOS developer position, having programmed the platform for 9 years by that time.

While iOS apps were a constant motif in my career (and I of course closely followed and used Swift daily from the beginning of its piblic release), I found it increasingly less and less exciting, so I did a couple of other things. That was when I picked up Haskell and Python, and in parallel got into embedded using the AVR family of µCs – of course still in C and C++ at the time.

Haskell made me interested in language design and compilers. I've been musing about various designs for a language, and I was so fascinated with the internals of compilers that I decided to design and implement a small scripting language (compiler and bytecode VM) in C from scratch. This grew into a project that a couple people, including a game developer friend of mine, started using. Soon I didn't have time to keep maintaining it, so that friend took it over and made it the extension language of the game engine he was working on, becuase he liked it more than Lua and Python.

This interest in language design was what ultimately lead me to Rust, too.

I then had to figure out how to get out of university, so I learned a bit of FPGA programming with VHDL as well as high-level synthesis. Based on the idea of my supervisor, which was about accelerating a bioinformatics algorithm (Smith-Waterman sequence alginment) on an FPGA and reusing it for structural comparison, I wrote my thesis and eventually made it into a paper that got accepted into the 2017 European Conference on Circuit Theory and Design.


Just because I don't happen to be physically old, you don't have to instantly and unprofessionally dismiss my claims. I'm not that new kid on the block.

6 Likes

My apologies H2CO3. I did not mean that as any kind of personal attack. I have deleted most of that post as I seen now I phrased it really badly and as you say unprofessionally.

I might try and find a better way to state the case. Or not, it was not much of a case.

9 Likes

Infrastructure

With Rust/cargo I can focus on the actual code rather than the build system. No need to spend whole days reading up on Yet Another Build System.

Cross-compliation with Rust is so incredibly simple and painless that when you read up on how to do it you can't help think "Wait, I must be missing something..".

Code

When you're outside of Rust there are things that sound like empty slogans, but when you start using it you'll become pleasantly surprised to realize there's a lot of truth to:

  • While you spend time fighting to compile your code, you save that time in not having to debug your code.
  • You're no longer afraid of major refactoring. Once your refactored code compiles, it works as intended.
  • It really does force you do to proper multithreading (well, you can still deadlock, but the crashy types of bugs are far more difficult to do).

I find myself doing far less boilerplate code. And what boilerplate code I do need, I can often hide in a different module so it doesn't get in the way of the actual application logic code. (Most common example of this is the Error type conversions).

Community

It's pretty clear that this whole "be respectful" is working very well. There have been a few cases where people have, imho, asked questions in bad faith, but rather than coughing up a giant hairball over the situation, community members reply in good faith, and it defuses the situation.

10 Likes

And I disagree with the assertion that Rust is the "first language since Ada with an emphasis on correctness". You have forgotten about Haskell.

I now have a good deal of experience writing code in both Haskell and Rust and the experience is similar in that when your code finally compiles, the program works, modulo logic errors.

The difference is that Haskell is much easier to learn, in my opinion, because of the GC. There are no battles with the borrow checker and/or lifetime hell. The performance of the resulting code is not as good, but it's not that far off and on today's hardware, it's very often good enough (consider how much useful code is written these days in interpreted languages, like Python; the code that comes out of ghc is much faster than any of them) . I also find Haskell code much more readable than Rust. And the language better documented.

But if ultimate performance is needed, or resources are limited, I don't think there's anything available today that competes with Rust. Zig is an interesting project, with some very good ideas (and some not so good, in my opinion), but at least as of today, memory management is the programmer's problem, so it doesn't begin to offer Rust's very valuable, maybe essential, correctness guarantees.

I also came to Rust from Haskell, and I feel that Haskell is a very elegant and safe language. The biggest differentiator for me (the ultimate reason I prefer Rust to Haskell) is that difference between high-performance code and idiomatic 'clean' code is usually greater in Haskell than it is in Rust. Most Rust code looks like most other Rust code, even when it performs well. Haskell can get very unfamiliar real quick if someone is operating under different libraries and goals from what you are typically doing. Small differences in syntax can result in huge differences in behavior, and Rust has more uniformity on that axis.

2 Likes

Others have already pointed out so many good points why they love Rust ( :kissing_heart:), so I just add these two to the list:

  • Quote from Chris Dickinson, engineer at npm, sums it up perfectly for me, because I have thought the same, without knowing the quote at that time:

My biggest compliment to Rust is that it's boring, and this is an amazing compliment.

  • Rust is a programming language that looks like it has been developed by user experience designers (or rather developer experience designers?). The creators of the language have, what Simon Sinek would call, an infinite mindset. They have a clear vision (a why) of the language and carefully choose what to add to the language and what to rework, while listening to what the community really wants. There are no loose ends, but it's all a coherent whole that perfectly supports a developer's workflow.

That is why I love Rust! :heart:

7 Likes

Not that you're wrong, but I believe @ZiCog was referring to compiled languages without GC here. I.e. the first language which could be a viable option for bare-metal, OS and resource-intensive kind of applications since Ada with an emphasis on correctness.

I have to come clean and say that the real reason I left Haskell out of the conversation was ignorance. Up until about a year ago I had never even heard of Haskell. Despite moving in and out of different industries in different countries over decades I have heard any one speak of it let alone use it. I should have added my usual get out clause "as far as I know".

Even now I have only seen a few dozen lines of Haskell, as the result of a "favorite language benchmark shoot out" a bunch of us had a while back. I immediately decided it was not for me. My Rust entry won by the way! Only the C entrant could get close.

L0uisc has a point. As far as I can tell Haskell is out of the running for much of the work I have ever done if it requires a complex run time and GC. It's not a systems programming language.

3 Likes

Thanks to everyone who responded in this thread, your insights are very helpful. If you want real names, job titles, and a link to your personal site included in the article, please email me at pitches@stackoverflow.com. Cheers!

1 Like

Article published! https://stackoverflow.blog/2020/06/05/why-the-developers-who-use-rust-love-it-so-much/

Thanks to everyone who contributed.

9 Likes