Isn't rust too difficult to be widely adopted?


Hardly. Not everything is subjective. Anyone who’s programmed in both can clearly attest to that observation. Also, one’s first programming language hardly taints readability as much as people like to believe it does. Fine, if you want a more indisputable statement, take Befunge or Brainf**k vs your favourite mainstream language.


Yes, it’s difficult, and many people like simple language(or can be simple used), like C, Lua, PHP, Java, c#, python, ruby. So I think it’s a challenge that Rust to be widely adopted in both low level and high level programing.
If I am a team leader, I won’t agree to write Rust in project, because that’s absolutely not a good news for project deadline.(my job is not relate to system programing, so you can ignore my opinion if you are system programer)
But, I find learn Rust is full of interesting, so I will write Rust codes for myself, just for fun.:slight_smile:


But Brainf**k is my favorite mainstream language!

Then again I’m much more productive using Rust. Having an actual heap is great for setting up data to munge later…

Kidding aside, what @carols10cents and @birkenfeld mean is that there are always tradeoffs and different people learn differently. For example, Rust makes some things explicit that could be inferred, but this allows reasoning locally about state and ownership, which would otherwise lead to a wild search through the code. So we optimize reading Rust at the expense of pessimising writing it. Sooner or later, IDEs will help with the latter and greatly reduce this cost.


I don’t agree with the premise that Rust is unnecessarily hard, coming from a functional background. Give Idris or Haskell a try! Everyone has a different perspective: from my perspective, the functional aspects of Rust come naturally, and I’ve found Rust very intuitive and beautiful in that sense (for example, with the iterator API). Having clear ownership semantics is just good practice, and when you need complex ownership semantics, I think it makes a lot of sense to drop down to reference counting (and sometimes unsafe code). As they say, “make the easy stuff easy and the hard stuff possible.” How often do you actually need complex ownership semantics? Keep it simple, stupid!


Take all the learning challenges you experienced with C++ in 10 years and compress them into a week. That’s Rust for you. It does mean Rust is harder to learn for that first week compared to your first week of C++, but guess what, you just saved yourself from a decade of painful toil.


I understand this sentiment, but I think there’s another way to think about the problem.

If the question is “How fast can I learn how to get a reasonable systems program to compile and run?” then looser languages like C and C++ seem to be better.

But having done a lot of C/C++ and now learning Rust, I think a different question you could ask is: “How fast can I learn to consistently write a 100% safe reasonable systems program?” In my case, I can say that Rust is a much faster way to get there. In fact, I doubt that in my lifetime I’ll ever get there for C/C++, there are just too many edge cases and pitfalls to consider.

In my opinion, Rust has the opportunity to make developing correct (safe) systems programs easier for me, not more difficult.


Yup. Rust simply sets the bar higher on what is an acceptable program compared to languages like C++. That’s where its initial steep learning curve stems from.

Rust: a strict parent you didn’t like when you were a kid but thank him now that you have grown up.
C++: a negligent parent who was fun and easygoing when you were a kid but caused only a lifetime of hurt and failure in your grown-up life.

TWiR quote of the week

I am still struggling with Rust after a couple of months. Personally, I am finding it a hard language to learn. When this comes up, more experienced Rust programmers wave it away but the truth is some of us find learning Rust a hard and frustrating experience.

I come from a C++ background and I originally thought that Rust would be a safer version of C++. Instead it is a mix of Ruby, Haskell and C++. I will stick with learning Rust and can’t offer any insight other than it really is a big deal for some people such as me.

To give an example, on Saturday I tried to read and write from a TcpStream using a buffered reader and buffered writer. Using the examples in the docs this was impossible because once the writer was constructed the reader could no longer use the stream. Luckily I found this solution on Stackoverflow.

The solution is non-obvious to a beginner and really frustrating – I looked at the buffered reader and writer code and could not see how it was possible to use a reference instead of a value. There was also no hint I could find that this kind of thing is possible. And I need this high level of understanding, that goes beyond the API documentation, just to communicate over a socket!

Sorry if this comes across as venting. My feeling is that this thread was being too dismissive of beginners problems. That said, the community is super helpful and I would thank everybody for your help so far.


Sure, learning rust can be hard. I agree that dismissing anyone that claims this is the wrong approach. As an aside, I think people should remember that a phrase like “rust is hard” or “rust is easy” is shorthand for “rust is hard for me” or “rust is easy for me”.

But to your specific experience, do you think that rust was too hard? It sounds like you ran into a problem, were not able to find a solution by yourself, but found a solution online. And hopefully you learned something along the way (since the answer includes a nice explanation), and are now one step closer to being a rust expert. I see this exact same thing happening in all kinds of languages, for all kinds of problems, and it feels very natural to me.

In my opinion, people are only dismissing the idea that rust is too hard. And I think everyone believes rust could have an easier learning curve. That’s in fact one of the core issues on the 2017 roadmap


The company business case of rust is in my opinion compelling when compared with C/C++, so I expect rust will be in time as widely deployed as C/C++ in my opinion. The business case for developers is as compelling as C/C++ in that it is universal and fast. More people use python than C/C++, because it is quicker and easier to develop in python than C/C++. Unfortunately rust is slower to produce products than python, but as I get better in rust I am hoping it will only by half as slow to write code in rust than python for me, while being more universal.

Rust is “different” in its ownership model, and many will think this is hard, and this will slow its adoption compared with go for example. I think how rust is “different” will reduce as future languages will also use this model as it eliminates a large number of bugs. I expect anyone launching a post rust language will have to compare consider rust’s model of ownership.

I think rust will be widely adopted because it is bringing something new to the table in terms of its model of ownership, while being very competitive with C/C++ (having similar universality and performance), and has static analysis built in to the compile process, which will lead to more bugs being found quicker.


A few people have said things along the lines of “yes it is a bit hard, so I wouldn’t recommend it as a first language” - and I’m curious if anyone has actually tried to learn Rust as a first language, or tried to teach it as a first language?

I haven’t either, but I have some suspicion that it actually might be easier to learn it without any preconceptions of other languages. If all you have ever known about programming is ownership and borrowing, I really don’t think it would confuse you.


I’m also new to Rust and have found the “Programming Rust” book by Blandy & Orendorff to be very helpful. Especially the chapters on ownership and references. It is an expensive book though.

Also the second edition online book is a resource I keep referencing:

I’m excited about some of the working group books announced for best practices for specific areas such as CLI tools and WASM.

If you use these books please ignore me :slight_smile:


To answer the original question: Yes, rust is too difficult to be widely adopted. I came to Rust with 20 years of experience programming in C, C++, PHP, JavaScript and Python and I found Rust to be the hardest language to learn.

For me, the first edition of Rust’s The Book was not very helpful and there was no other reference book available at the time. Reading Blandy & Orendorff’s Programming Rust definitely helped me, but I would still rank Rust as the most difficult language for me.

I expect Rust will grow in usage, but I doubt it will ever become one of the top 10 languages. I don’t think that we will ever have another language like C and C++, that dominates both system and big application programming. Almost every program which I use on a daily basis today (Linux kernel, GNOME, Apache, LibreOffice, MySQL, PHP, Chromium, Acrobat Reader, etc.) was written in C or C++, and I don’t think that Rust will ever grow to that position. I expect that Rust will expand to new areas like robotics, embedded programming, web services, etc, but I don’t think it will ever become the dominant language in any area, because of its steep learning curve. I expect that we will see greater diversity in the future with many languages occupying the current position of C/C++. However, a language with a simpler syntax and easier learning curve like Swift is more likely than Rust to become the next big systems programming language. I don’t know if the next C/C++ will be Swift itself, but it is likely to be a similar language. The growth of Swift depends on whether it can become popular outside of the Apple ecosystem and it will need to be managed as a true open source project with many organizations participating in order for it to spread to Windows, Linux, embedded development, etc.


What in particular do you find difficult in Rust? It’d be helpful to identify those areas.

C++ is at least as difficult as Rust, probably more so since buggy code will compile but then crash or worse, elicit UB at runtime.


In retrospect, was it worth the extra effort? why?


The only thing that makes Rust a harder language to learn than any other is the concept of Borrowing.

I think it’s helpful to learn it in two steps, first learn the syntax staying as far away from lifetimes as possible. Then accept that there’s an additional leap of learning for borrowing. Rust has done a lot to reduce that learning curve and there’s probably more that could be done but fundamentally it’s hard because it’s new and there are no parallels to draw on.

As to whether Rust will succeed long-term, ask yourself whether you think processor speeds will increase or whether more cores will be added? If the latter then Rust’s future is pretty rosey.

(Besides, have you ever met such a nice community?)


Non lexical lifetimes will probably be a major step forward for the learnability of Rust.


For sure! I’ve been patiently awaiting NLL for as long as I’ve been working with Rust. It should make a lot of common/unusual problems go away, which is very promising.

I think to be clear, the concept of borrowing itself is very simple; it’s defined perfectly with just 3 short rules. The real learning curve is not with borrowing (or these rules), the problem is with complex lifetimes. Complex lifetimes come into play anywhere that the lifetimes cannot be elided.

I’ve mentioned this elsewhere, but since it is relevant … I had a really hard time coming to terms with lifetimes as I was learning Rust. In fact, it is still my biggest pain point with the language. But I taught myself to get around it by writing a non-trivial project without using a single lifetime parameter. I also didn’t need Box, Rc, RefCell, or friends. But that’s because most of the code is stateless (which explains why it doesn’t need explicit lifetimes).

IMHO, this is the best way to learn Rust. Doing things that require explicit lifetimes (like global state management or FFI) should come way, way, way later in the book.


because the syntax and hard to learn of rust, i don’t think rust will be popular and widely adopted, rust has value and cool feature, but it’s will can be adopted in other languages. swift will has ownership but no ugly syntax, I think it will be popular than java(if it be friend for linux etc), also make rust more minority. syntax and easy leanning is more important with the time go

many people say rust have a lot advances, it’s true. but nothing,when people leave it


As @vitalyd said, it would be very helpful if you could provide precise feedback, rather than sweeping subjective statements.

For example, “ugly syntax” is a highly subjective statement which depends on one’s habits. For someone who is used to Pascal/Ada syntax, every popular language these days looks ugly. Since you present Swift as a role model for beautiful syntax, I will point out that if you search for “swift ugly syntax” on the web, you will find that this language’s syntax irritates newcomers like that of any other programming language. Unfortunately, it seems that programming language aesthetics is something that one just needs to get used to.

I also think that you highly overestimate the ability of programming languages to evolve in core design decisions. For example, ownership and borrowing permeates many design decisions of Rust, and I am highly skeptical of your opinion that it is something that could be introduced in Swift without breaking compatibility with most existing Swift code (exclusive mutability in particular strongly influences APIs).