Isn't rust too difficult to be widely adopted?

#1

Hi! I don’t want to start a rant here. Just want to share my concerns as new rust user.

My background:
I work as Unity3D game developer, I mostly use C# now. I used to do lots of iOS development with Objective-C and web-development with ruby. I always was interested in computer science, so I tried lots of not widespread languages in past years: haskell, clojure, erlang, ocaml, etc. I am interested in computer graphics and most of low-level computer graphics is done in C++ now.
That’s why one of my goals for this year is to refresh my C++ knowledge and adopt some modern C++. Rust looks like good alternative because it is so much simpler and explicit and has good performance which is a must for game dev/computer graphics.

I did some exercises in rust, wrote some small scripting tasks and it was pleasant experience mostly.

My concern with Rust is that some things in Rust are very difficult to do and current solutions don’t look natural.
Things like storing reference to the part of structure into the same structure (I know about owning_ref) or double-linked list in rust is implemented. I read a book http://cglab.ca/~abeinges/blah/too-many-lists/book/ and it is very well-written and interesting but the provided solution looks REALLY hard.
It reminds me experience with Monads in haskell. Yes, they definitely solve the problem with non-pure functions (state, IO, etc). Still they are very difficult to understand, they don’t compose very well (monadic transformers do suck). Monads.

I remember my experience with haskell where I wanted to do something simple like downloading some data from URL and I got some cabal package and expected it to have a function like getDataFromURL(url) and I looked into its documenation and it was based on some category theory concept like Applicative Functors or something like that and I felt myself very dumb at that moment.

It seems like Rust could be used only by experienced and smart developers. Which seems to be great but when you work on big commercial project, your team consists of developers of different skill level (including junior developers). Do you think if rust could be used in such projects?

Does anyone else has similar concerns of complexity of rust? What do you think about it?

15 Likes
#2

I believe in people.

78 Likes
TWiR quote of the week
#3

I wrote personal projects in Rust for 18 months before I introduced it to my (very small) team of developers . Even though I love Rust I had A LOT of FUD about bringing Rust to our development tools because of the learning curve, the lack of libs, and the lack of community experience with Rust in production.

We’ve been rewriting our main product in Rust, over an FFI to FFMPEG. It’s not a trivial project. In fact, it’s hard. We’ve been at it for 3 months.

With that background out of the way, I can tell you that all of my/your FUD was/is unwarranted as is often the case.

My team has had to deal with the learning curve, especially when it comes to the FFI. We’re definitely not as fast as we are in Scala or C#, YET, but we’re working on harder problems in our Rust project. We have a wide range of development experience on my team and everyone’s fine working in Rust. As any good team does, we help each other get through the rough spots and the surprises.

And the team is what a lot of people don’t consider when experiencing FUD about Rust. Yes, Rust is hard at first. But there’s a great community around it, that’s willing to help new Rust programmers get through the rough spots and surprises. If you don’t have your own team, the community will be your team.

“It seems like Rust could be used only by experienced and smart developers.”

I don’t agree. I wouldn’t recommend Rust as a first language so I think experience in another language would help. And, of course, a little bit of smarts wouldn’t hurt. But learning Rust is not so different from learning any other language. One has to work at it, practice, and read a lot of code. The only difference, as I see it, is that Rust forces you to learn a lot of the corner cases from the beginning whereas other languages (e.g. Ruby, Python) are easier to get started with. In fact, I suggest that some of us had too much experience when we came to Rust and habits from other languages made it difficult to make the leap to the Rust way.

21 Likes
#4

This sounds like the XY problem. There aren’t many cases when you want to store a reference to a part of a structure in the same structure that crop up in Rust. This may be a common pattern in other languages, but it’s not necessarily the way you need to do things in Rust – there may be a different way to achieve what you want. Servo, for example, has zero instances of self-borrowing, and I’ve never felt the need for it there.

As far as linked lists, that’s a very specific example you’ve picked up. Why is the ability to write a linked list being used as a yardstick for Rust’s difficulty? Usually linked lists are used to introduce pointers in systems languages, and are considered an “intro” topic. That doesn’t mean that they are an intro topic in Rust, too. (In fact, try to write a doubly linked list in C or C++ with proper cleanup semantics. It’s hard)

The thing about Rust is that it’s not most systems languages. A lot of the basic pointer manipulations that systems languages make easy require unsafe and sometimes some thought in Rust. Which is why you rarely do those things in Rust, and rely on zero-cost abstractions where someone has already done that thinking for you. A Rust programmer should never have to implement a linkedlist, one exists in the stdlib. For the relatively small cost of a couple of stdlib designers thinking hard about the safety about these abstractions, you never have to think about pointers ever in Rust. That’s … a pretty good tradeoff. And, if anything, it makes Rust easier to pick up – all the hard problems have been solved for you, and there’s a nice safety net. On the other hand, existing systems languages need you to be able to think about pointers constantly to avoid messing up. You may be able to write a linkedlist, but using one in a large codebase requires careful thought.

In fact, we’ve repeatedly gotten feedback that companies introducing non-systems programmers to Rust found it a much better choice to introduce systems programming.

20 Likes
#5

This x 1000000

The vast majority of development is not being done at the linked list level but a lot of people use that as the canonical example of how hard Rust is.

7 Likes
#6

Thank you.
It is actually almost my case. I don’t have experience with system programming besides university course. I am comfortable with manual memory management using refcounting, because it was the model adopted by Objective-C before introducing automatic ref counting (which is mostly like smart pointers). And now I use Rust as a free teacher on system programming and memory management stuff :slight_smile:

One more thing I actually like about Rust is that it is hard to create global variable in rust. When I tried to create one (some global hashmap to cache computation), I got compilation error (hashmap implement Drop and you can’t safely store it in global variable because order of destructors is not determined if I remember correctly). And then I found big blog post explaining why it is bad and that I need Mutex because global variable can be accessed from different threads and there was a crate which does the right thing. So I learnt a lot and if it is a that hard to create global mutable var with heap storage in rust then junior developers won’t be doing it anyway which is kind a nice :slight_smile:

3 Likes
#7

A good question!

I also find that Rust is difficult for some intuitive definition of difficult (though your linked list example is not a good argument for the case :slight_smile: ). However, I don’t believe that simple languages do really exist. Like, I thought that Python is nice and simple until I’ve learned about descriptors and understood how methods really work (spoiler: (lambda : None).__get__). And a lot of people use Scala and C++ which are at least comparable to Rust in the terms of complexity.

The nice thing about Rust is that it makes (comparatively) difficult to write wrong code :slight_smile: So, all languages are complex, all real world problems are complex, but Rust has tools for creating robust solutions, which is an advantage.

4 Likes
#8

I would probably vote this post down if I could. Optimism is fine, as long as you give some sort of evidence for it. This is just completely empty; it’s a feel-good phrase, and nothing more.

17 Likes
#9

The longer version is: People aren’t dumb, just lazy. They tend to be capable of a lot more than even they themselves believe.

11 Likes
#10

This question seems so bizarre to me. I read all the comments, but none of them really go at the heart of this question, which is really two different questions: “Is Rust’s complexity greater than other languages, and will this hold the language back in terms of greater adoption”.

Rust has taken me a while to get comfortable with, but no more than did moving from C -> C++ -> Java -> Javascript -> Python. Any language you learn has it’s own idiosyncrasies, and Rust is no different. I’m no expert in the language yet, but I’ve already decided this is possibly the greatest language I’ve ever learned, it makes no compromises, and doesn’t come at the cost of pointer management.

So is Rust more complex than, what, C#? Maybe? But how hard is it to figure out why you’ve got a major GC pause (something I had to do in Java all the time)? How long does it take to go through the heap and figure out which set of objects is causing the issues in your system. I don’t need to do that in Rust, I’m sure there are other performance issues that I’ll run into, but definitely won’t be major GC pauses. That’s just one example of where the upfront cost of Rust will save you from the downstream cost that other languages force upon you.

I’d say that C is way more complex than Rust, even if it is simpler, because the bugs that you can accidentally create in terms of improperly allocated, deallocated or shared memory will always be issues you have to deal with. In fact anyone who’s dealt significantly with C starts following the same rules that Rust does in terms of memory management. Has this stopped the adoption of C as one of the most used languages of all time?

I think Rust has some great things going for it: it’s a high level language, and when you learn it’s idiosyncrasies, e.g. Iterators solve a lot of usage issues, you become just as efficient in the language as others. And on the other hand, it’s always got something new to learn, it’s a language that you as a developer can grow into, which means that you never get bored with it.

This is a long way of agreeing with @steveklabnik, “I believe in people,” to make choices that will help them be better engineers; to want to always excel; to make the best thing they can. Rust helps me do that.

22 Likes
#11

I’d say it’s more difficult, but it is for good reason. I just finished my first real rust project, and learning to deal with the borrow checker was a pain. It reminded me a lot of going back to a language without a GC from one with, or one without exceptions or a monad-like structure for error handling after using languages that had those things - suddenly there were new things to worry about.

The thing is - I should have been worrying about the things the borrow checker looks for all along. While it’s conservative, in that it warns me about things I can tell aren’t issues but it can’t, it also warns me about things that are issues that I missed, or didn’t even realize I needed to check. I’ve spent enough time chasing bugs from such things in other languages to appreciate it doing this.

As for needing to hire experience and smart developers, experience you can get, and the experience of learning Rust will make you a better programmer. And do you really want to hire or work with not-smart programmers?

Haskell is a completely different animal than Rust. Rust seems to have borrowed the nifty practical things Haskell has (like algebraic data types, immutable variables and monadic error handling) without generalizing them into category theory. So once you get past those things and the borrow checker, you’re pretty much up to speed with Rust. With Haskell, you’re just barely getting started.

4 Likes
#12

I think the concept of object ownership in Rust is one of the hardest things to accept/work with compared to other languages. And it hits you pretty fast, as soon as you want two pointers to have mutable access to and object. Or if even if you want two references with read only access you run face first into lifetimes. Then if you end up with threads you get a whole new slew of issues right out of the gate.

Rust forces you to think about your architecture up front, not later, which I think is a good thing. This hopefully means less time rewriting/reorganizing your code. The down side is if you want to “play” and just write something quick and dirty coming from another language, you can’t. You have to think in Rust terms, not in C++/Java terms that you translate into Rust terms.

Will this hurt adoption, rage quit and all that? I hope not. I think people coming to rust are those who are tired of debugging memory issues, race conditions, and other common programmer issues. People just need to keep that as the goal, that rust will help them avoid the common problems that programmers spend so much time debugging, and stick through the learning curve with ownership and lifetimes.

Personally I came to rust because I was looking to get back into system programming and away from JAVA. I didn’t want to go back to C++, because after writing in JAVA I didn’t want half my object defined in the header file and half in the source file. I wanted a language that brought modern programming concepts to a system language. Happily Rust fit the bill.

5 Likes
#13

Exactly… this was precisely my reason as well.

3 Likes
#14

Many people have said many awesome things already, but I just wanted to address this:

“Natural” and other descriptions of code syntax like “elegant”, “readable”, etc are often heavily biased by the first programming language that each of us have learned, and that first language is what looks “natural” to us. Because we need to be precise enough for computers to understand, all programming languages are by necessity “unnatural” and not at all how we use human languages.

21 Likes
#15

I want to add another angle to this: Writing Rust makes you appear smart, even if you fail. Because we all know systems programming is hard and there are crazily smart people working in Rust, so if you’re a Rustacean, you’re smart by association. Also the safety guarantees lure us to try and punch above our weight, to our collective surprise and delight often successfully. The downside of everyone here appearing smart is that people may get the impression Rust is only for smart people.

10 Likes
#16

I maintain that Rust’s primary difficulty in adoption is mismatch of expected learning curve and actual learning curve. I think actual learning curve is reasonable and expectation is wrong, but the question is how to correct expectation.

Going with a bit of caricature, consider {Java, C++, Rust} and “X programmer learns Y”. Since there are too few Rust programmers to matter, there are four cases:

Case 1. Java programmers learn C++. People expect this to be hard, and it is actually hard.

Case 2. C++ programmers learn Java. People expect this to be easy, and it is actually easy.

Case 3. Java programmers learn Rust. People expect this to be hard, and it is actually hard.

Case 4. C++ programmers learn Rust. For some reasons, people expect this to be easy, but it is actually hard. In my experience, it is equally hard for C++ programmers to learn Rust as for Java programmers to learn Rust. To me this looks reasonable, but mismatch in expectation causes frustration.

One theory I have is that Java programmers expect Rust to be hard because they think they don’t know “memory management”, and C++ programmers expect Rust to be easy because they think they know “memory management”. The problem is, C++ programmers know “C++ memory management”, not “memory management”. To learn Rust, you need to learn “Rust memory management”, and learning transfer from “C++ memory management” to “Rust memory management” is not as good as people expect.

31 Likes
#17

To add to @sanxiyn’s post: because learning Rust for C++programmers is hard it is widely believed that Rust is harder than C++ which is plain wrong. It is because both languages are usually seen as competitors in the same category and people expect them to be similar. In fact each of them is difficult in different areas. On the other hand Haskell is not closely comparable to C++ therefore only few people try to compare their difficulty.

2 Likes
#18

https://www.reddit.com/r/rust/comments/4o6nd7/problem_in_rust_adoption/ — some very interesting comments on reddit post which is continuing this topic

#19

While there is a certain element of truth to your surmise, I would argue that it’s not all black and white as that. For instance, Python certainly is a very readable language compared to Common Lisp.

1 Like
#20

That sounds much more “black and white” than what Carol said.

2 Likes