7 ms·

Can anyone share some insights on how time much did it took to get comfortable with Rust? I'm getting started and crawling with concepts like ownership, mutabil

by giis 10y ago

Can anyone share some insights on how time much did it took to get comfortable with Rust? I'm getting started and crawling with concepts like ownership, mutability

jackyinger 10y ago
If you want to do the basic things that rust wants you to do it doesn't take that long. However if you want to create any graph like data structures you need to go into unsafe rust. For example, the std doubly linked list uses unsafe with error handling to do inserts because the compiler cannot be sure that an insert is safe. In my opinion Rust's safety is overhyped and entirely dependent on good implementation of unsafe code. And judging from the liked list example there is no way for all rust code to be intrinsically safe.
- coldtea 10y ago
  >In my opinion Rust's safety is overhyped and entirely dependent on good implementation of unsafe code. That's short-sighted. Of course it's "entirely dependent on good implementation of unsafe code". But that's inconsequential, as unsafe code in a library, especially one used by everybody, is much easier to make safe than unsafe code all around. And after you trust an unsafe lib you use to be sound, your own safe-only code can never breach that safety. You'll be guaranteed that any issue will be on the unsafe part. It's all about compartmentalization.
- Rusky 10y ago
  > In my opinion Rust's safety is overhyped and entirely dependent on good implementation of unsafe code. ...as is true of any safe language, which is dependent on a good implementation of its compiler or interpreter. Rust just happens to move some of that into the language where it can be extended.
- caconym_ 10y ago
  Show me a programming language that lets you manipulate raw pointers while providing the same safety guarantees as safe Rust code (i.e. have your cake and eat it too) and I'll accept this as a valid criticism of Rust. Until then, I"m going to keep thinking that Rust provides a reasonable, practical compromise. For about a year, I've been regularly using Rust to write real software that I actually use, and I've never had to write unsafe code. I'm trusting other people to do it, which is never not the case, no matter what programming language I'm using.
  - jackyinger 10y ago
    By definition manipulation of raw pointers is unsafe. So no language can do that. Sure Rust's typed pointers can be safe as long as libraries fulfill their garuntees. My main point is that safety rests upon the library correctness. And I can see the value of the interlocks this provides. However it is not infallible as the word safe suggests. I'll admit that I have not grokked rust, but I did give it a reasonable try. Perhaps all my C hacking has ruined me. :)
    - caconym_ 10y ago
      > My main point is that safety rests upon the library correctness. And I can see the value of the interlocks this provides. However it is not infallible as the word safe suggests. I don't disagree with that. Sometimes I don't totally love how the Rust people market the language, and I can see how the statements they make about safety could rub their target audience the wrong way, but I don't know how I'd do it better. I really do think the language does a great job helping programmers write fast, safe, bug-free code... once they get over the learning curve. If you ever feel like taking another crack at it, this is the reference that made the memory model stuff (which is the trickiest bit IMO) click for me: http://cglab.ca/~abeinges/blah/too-many-lists/book/ http://cglab.ca/~abeinges/blah/too-many-lists/book/
- jackyinger 10y ago
  I don't see why a dissenting opinion gets beaten up here... wouldn't it be better for the community to address the perceived deficiencies with solutions? My main issue is that I found creating graphs is unwieldy. Where in C or Python I can just whip one up. Is there a reasonably easy way to do it without depending on a library (like petgraph)?
troutwine 10y ago
I just released a big-ish open-source project in Rust that I've been working on since June 2016. https://github.com/postmates/cernan https://github.com/postmates/cernan Cernan has to be sparing in its memory consumption, be a good citizen with regard to its CPU impact–at Postmates we deploy it as a ride-along with application servers--and be correct even though there's changes being made at a punishing pace. When I started cernan I'd been following Rust for a while but had _not_ written anything of note in it. My estimation, though, was that Rust would be a better fit for cernan than C++: * It'd be easier for colleagues knowing neither Rust nor C++ to review Rust code. * If I got hit by a bus, the Rust compiler would make stronger behaviour constraints for me. You can see in the first month https://github.com/postmates/cernan/commits/master?after=Y3Vyc29yOkQtl3zrI07%2BiO53gHPQv%2FNM7ljgKzEzOQ%3D%3D https://github.com/postmates/cernan/commits/master?after=Y3V... that I flailed around a bit. I was internalizing the borrow checker's view of Rust's memory model, getting used to the tooling and the ecosystem of crates available. One thing I particularly had issues with from the get go and have _kind of_ resolved are many wee allocations inside cernan. In some sense they're inevitable but my early ignorance exacerbated the problem: I'd clone to convince the borrow checker to let me move on, would construct new containers rather than pass new ones in to be refilled and the like. Also, strings. Lots and lots of strings everywhere. After the first month, toward the back half of the second I felt like I was flying finally. Still plenty I needed to internalize or learn about but I had a cohesive mental model in which to incorporate new information.
- anamoulous 10y ago
  > In some sense they're inevitable but my early ignorance exacerbated the problem: I'd clone to convince the borrow checker to let me move on, would construct new containers rather than pass new ones in to be refilled and the like. Also, strings. Lots and lots of strings everywhere. I've been teaching myself Rust in the evenings for a couple of weeks now and have found the process maddeningly confusing and slow. Even with the Book, which is fine, I ended up getting into rage induced clone/to_owned/etc keyboard mashing dances with the borrow checker. If it weren't so easy to do this kind of dev with emacs, I might have given up earlier. On the other hand I occasionally get these moments where my code just "clicks" and it feels good and _seems_ elegant. But, pedagogically speaking, at this point I'm just trying to learn through immersion, not through theory and understanding. Honestly I'd probably be way done with this little project if I had started in Go, but I think I'm going to stick with Rust for a while.
fleetfox 10y ago
I have no experience with low level languages and i'm 4 weekends in. I feel like i'm half way there to be comfortable and some more to actually be productive.
- dumindunuwan 10y ago
  https://medium.com/learning-rust https://medium.com/learning-rust might be helpful for you.
nercury 10y ago
When I started out (before 1.0 release), the documentation was very poor, I was coming into Rust with 5+ years of dynamic language experience (PHP, JS), my C#/C++ knowledge was rusty. It took me a month (of my free time) to start feeling like I can write code in Rust. It felt like I was learning programming all over again. There were several reasons for that: first, I assumed that Rust can be used the same way as Javascript, with callbacks everywhere, and second, I was used to OO patterns that can not work in Rust. So, to overcome that, I had to realize that while Rust may have modern features, it is fundamentally a low-level language; and I had to really understand what the OO patterns actually give me to find the alternatives in Rust. I think that these things have made me a better programmer overall. I remember these distinct stages. Rust is low-level stage: It took a while to realize that Rust structs live on stack, and the pointer to such struct can not be freely passed around like an object, because the stack frame will be gone at the end of a function. I found out how to do virtual dispatch: the fact that borrowed traits have virtual dispatch table was missing from docs at the time (they are called Trait Objects). This is what I was actually missing from OO: a way to use the interfaces without putting everything into enums, and have a way to invert dependencies. There is a borrow checker, but you need to think in ownership: Again, I was trying to use references as if they were objects in OO language, while the primary model is ownership. I wrote a bog post at that time discussing this: http://nercury.github.io/rust/guide/2015/01/19/ownership.html http://nercury.github.io/rust/guide/2015/01/19/ownership.htm... Rust is more functional than it seems: At that point I found that you can model anything in Rust if you can express it as a data-flow from the input to output. Turns out, anything can be expressed as the data flow. The data that flows can be uniquely mutable, processed in parallel. I had to ditch thinking in highly shared hierarchies of objects and focus on flows that transform one set of structures to other sets of structures.
valarauca1 10y ago
It took me 2-3 weeks of being fairly frustrated with Rust until I grokked the borrow checker. This was mostly on/off coding in my spare time at night. This is coming from a background of mostly C/Java. Once it clicks it is very simple, but developing the intuition and breaking old habits is the frustrating part.
88e282102ae2e5b 10y ago
Once I had learned the syntax, it took me a few days while working on a real project with well-defined goals to internalize the borrow-checker and such. Clippy has also been a surprisingly useful tool for learning - it pointed out some things that weren't idiomatic and that also solidified some concepts for me.
staticassertion 10y ago
About two weeks to get the majority of language features - iterators, some aspects of ownership, structs, stop fighting the borrow checker for the common cases. I was using threads to parallelize my work within the first few days, and that was particularly cool for me. I'd say another two weeks before I was using lifetimes properly, traits, enums, etc in 'idiomatic' ways. All in all, 4 weeks before I felt productive. I come from C++, which helped and hurt. On the one hand, move semantics weren't new - but C++ move semantics felt like nothing* compared to Rust's. It actually really helped me internalize why you would want them in C++. I knew that returning a pointer to the stack was bad in C++. In rust, I actually started doing that (just parent stacks), but safely. * Such as self.foo(&self.bar)
- nicoburns 10y ago
  I would second this: also about 2 weeks. Interestingly I came from a JavaScript background so I'm guessing it was different aspects of the language that felt unfamiliar.
dumindunuwan 10y ago
https://medium.com/learning-rust/rust-the-tough-part-2ea11ed3693e https://medium.com/learning-rust/rust-the-tough-part-2ea11ed... ; This is all about Ownership, Borrowing,Lifetimes & Lifetime Elision. Might be helpful for you.
onmobiletemp 10y ago
I learned rust while I was taking classes so this may be longer than usual, but I started compiling on the first try in about four months. It was my second language though. So if you have learned a language a few times and you aren't busy you could probably do it in a month. That's how long my professor said it took him. And I must say, once you learn rust, it's such a joy.
caconym_ 10y ago
I think it took me a couple of weeks to be able to write practical programs (i.e. actual useful things) and a month or two more to feel really comfortable with it. I was not pursuing it on anything close to a full-time basis. I recommend this tutorial: http://cglab.ca/~abeinges/blah/too-many-lists/book/ http://cglab.ca/~abeinges/blah/too-many-lists/book/ for helping to grok the memory model. I tried to implement each chapter's data structure before I read the chapter so that I would really understand what problem the introduced memory constructs were solving. It's definitely not an easy language to learn, but once you get past the memory model stuff I think the learning curve at least gets a little flatter.

by giis 10y ago

Can anyone share some insights on how time much did it took to get comfortable with Rust? I'm getting started and crawling with concepts like ownership, mutability

jackyinger 10y ago

If you want to do the basic things that rust wants you to do it doesn't take that long. However if you want to create any graph like data structures you need to go into unsafe rust. For example, the std doubly linked list uses unsafe with error handling to do inserts because the compiler cannot be sure that an insert is safe. In my opinion Rust's safety is overhyped and entirely dependent on good implementation of unsafe code. And judging from the liked list example there is no way for all rust code to be intrinsically safe.

coldtea 10y ago
>In my opinion Rust's safety is overhyped and entirely dependent on good implementation of unsafe code. That's short-sighted. Of course it's "entirely dependent on good implementation of unsafe code". But that's inconsequential, as unsafe code in a library, especially one used by everybody, is much easier to make safe than unsafe code all around. And after you trust an unsafe lib you use to be sound, your own safe-only code can never breach that safety. You'll be guaranteed that any issue will be on the unsafe part. It's all about compartmentalization.
Rusky 10y ago
> In my opinion Rust's safety is overhyped and entirely dependent on good implementation of unsafe code. ...as is true of any safe language, which is dependent on a good implementation of its compiler or interpreter. Rust just happens to move some of that into the language where it can be extended.
caconym_ 10y ago
Show me a programming language that lets you manipulate raw pointers while providing the same safety guarantees as safe Rust code (i.e. have your cake and eat it too) and I'll accept this as a valid criticism of Rust. Until then, I"m going to keep thinking that Rust provides a reasonable, practical compromise. For about a year, I've been regularly using Rust to write real software that I actually use, and I've never had to write unsafe code. I'm trusting other people to do it, which is never not the case, no matter what programming language I'm using.
- jackyinger 10y ago
  By definition manipulation of raw pointers is unsafe. So no language can do that. Sure Rust's typed pointers can be safe as long as libraries fulfill their garuntees. My main point is that safety rests upon the library correctness. And I can see the value of the interlocks this provides. However it is not infallible as the word safe suggests. I'll admit that I have not grokked rust, but I did give it a reasonable try. Perhaps all my C hacking has ruined me. :)
  - caconym_ 10y ago
    > My main point is that safety rests upon the library correctness. And I can see the value of the interlocks this provides. However it is not infallible as the word safe suggests. I don't disagree with that. Sometimes I don't totally love how the Rust people market the language, and I can see how the statements they make about safety could rub their target audience the wrong way, but I don't know how I'd do it better. I really do think the language does a great job helping programmers write fast, safe, bug-free code... once they get over the learning curve. If you ever feel like taking another crack at it, this is the reference that made the memory model stuff (which is the trickiest bit IMO) click for me: http://cglab.ca/~abeinges/blah/too-many-lists/book/ http://cglab.ca/~abeinges/blah/too-many-lists/book/
jackyinger 10y ago
I don't see why a dissenting opinion gets beaten up here... wouldn't it be better for the community to address the perceived deficiencies with solutions? My main issue is that I found creating graphs is unwieldy. Where in C or Python I can just whip one up. Is there a reasonably easy way to do it without depending on a library (like petgraph)?

troutwine 10y ago

I just released a big-ish open-source project in Rust that I've been working on since June 2016. https://github.com/postmates/cernan https://github.com/postmates/cernan Cernan has to be sparing in its memory consumption, be a good citizen with regard to its CPU impact–at Postmates we deploy it as a ride-along with application servers--and be correct even though there's changes being made at a punishing pace. When I started cernan I'd been following Rust for a while but had _not_ written anything of note in it. My estimation, though, was that Rust would be a better fit for cernan than C++: * It'd be easier for colleagues knowing neither Rust nor C++ to review Rust code. * If I got hit by a bus, the Rust compiler would make stronger behaviour constraints for me. You can see in the first month https://github.com/postmates/cernan/commits/master?after=Y3Vyc29yOkQtl3zrI07%2BiO53gHPQv%2FNM7ljgKzEzOQ%3D%3D https://github.com/postmates/cernan/commits/master?after=Y3V... that I flailed around a bit. I was internalizing the borrow checker's view of Rust's memory model, getting used to the tooling and the ecosystem of crates available. One thing I particularly had issues with from the get go and have _kind of_ resolved are many wee allocations inside cernan. In some sense they're inevitable but my early ignorance exacerbated the problem: I'd clone to convince the borrow checker to let me move on, would construct new containers rather than pass new ones in to be refilled and the like. Also, strings. Lots and lots of strings everywhere. After the first month, toward the back half of the second I felt like I was flying finally. Still plenty I needed to internalize or learn about but I had a cohesive mental model in which to incorporate new information.

anamoulous 10y ago
> In some sense they're inevitable but my early ignorance exacerbated the problem: I'd clone to convince the borrow checker to let me move on, would construct new containers rather than pass new ones in to be refilled and the like. Also, strings. Lots and lots of strings everywhere. I've been teaching myself Rust in the evenings for a couple of weeks now and have found the process maddeningly confusing and slow. Even with the Book, which is fine, I ended up getting into rage induced clone/to_owned/etc keyboard mashing dances with the borrow checker. If it weren't so easy to do this kind of dev with emacs, I might have given up earlier. On the other hand I occasionally get these moments where my code just "clicks" and it feels good and _seems_ elegant. But, pedagogically speaking, at this point I'm just trying to learn through immersion, not through theory and understanding. Honestly I'd probably be way done with this little project if I had started in Go, but I think I'm going to stick with Rust for a while.

fleetfox 10y ago

I have no experience with low level languages and i'm 4 weekends in. I feel like i'm half way there to be comfortable and some more to actually be productive.

dumindunuwan 10y ago
https://medium.com/learning-rust https://medium.com/learning-rust might be helpful for you.

nercury 10y ago

When I started out (before 1.0 release), the documentation was very poor, I was coming into Rust with 5+ years of dynamic language experience (PHP, JS), my C#/C++ knowledge was rusty. It took me a month (of my free time) to start feeling like I can write code in Rust. It felt like I was learning programming all over again. There were several reasons for that: first, I assumed that Rust can be used the same way as Javascript, with callbacks everywhere, and second, I was used to OO patterns that can not work in Rust. So, to overcome that, I had to realize that while Rust may have modern features, it is fundamentally a low-level language; and I had to really understand what the OO patterns actually give me to find the alternatives in Rust. I think that these things have made me a better programmer overall. I remember these distinct stages. Rust is low-level stage: It took a while to realize that Rust structs live on stack, and the pointer to such struct can not be freely passed around like an object, because the stack frame will be gone at the end of a function. I found out how to do virtual dispatch: the fact that borrowed traits have virtual dispatch table was missing from docs at the time (they are called Trait Objects). This is what I was actually missing from OO: a way to use the interfaces without putting everything into enums, and have a way to invert dependencies. There is a borrow checker, but you need to think in ownership: Again, I was trying to use references as if they were objects in OO language, while the primary model is ownership. I wrote a bog post at that time discussing this: http://nercury.github.io/rust/guide/2015/01/19/ownership.html http://nercury.github.io/rust/guide/2015/01/19/ownership.htm... Rust is more functional than it seems: At that point I found that you can model anything in Rust if you can express it as a data-flow from the input to output. Turns out, anything can be expressed as the data flow. The data that flows can be uniquely mutable, processed in parallel. I had to ditch thinking in highly shared hierarchies of objects and focus on flows that transform one set of structures to other sets of structures.

valarauca1 10y ago

It took me 2-3 weeks of being fairly frustrated with Rust until I grokked the borrow checker. This was mostly on/off coding in my spare time at night. This is coming from a background of mostly C/Java. Once it clicks it is very simple, but developing the intuition and breaking old habits is the frustrating part.

88e282102ae2e5b 10y ago

Once I had learned the syntax, it took me a few days while working on a real project with well-defined goals to internalize the borrow-checker and such. Clippy has also been a surprisingly useful tool for learning - it pointed out some things that weren't idiomatic and that also solidified some concepts for me.

staticassertion 10y ago

About two weeks to get the majority of language features - iterators, some aspects of ownership, structs, stop fighting the borrow checker for the common cases. I was using threads to parallelize my work within the first few days, and that was particularly cool for me. I'd say another two weeks before I was using lifetimes properly, traits, enums, etc in 'idiomatic' ways. All in all, 4 weeks before I felt productive. I come from C++, which helped and hurt. On the one hand, move semantics weren't new - but C++ move semantics felt like nothing* compared to Rust's. It actually really helped me internalize why you would want them in C++. I knew that returning a pointer to the stack was bad in C++. In rust, I actually started doing that (just parent stacks), but safely. * Such as self.foo(&self.bar)

nicoburns 10y ago
I would second this: also about 2 weeks. Interestingly I came from a JavaScript background so I'm guessing it was different aspects of the language that felt unfamiliar.

dumindunuwan 10y ago

https://medium.com/learning-rust/rust-the-tough-part-2ea11ed3693e https://medium.com/learning-rust/rust-the-tough-part-2ea11ed... ; This is all about Ownership, Borrowing,Lifetimes & Lifetime Elision. Might be helpful for you.

onmobiletemp 10y ago

I learned rust while I was taking classes so this may be longer than usual, but I started compiling on the first try in about four months. It was my second language though. So if you have learned a language a few times and you aren't busy you could probably do it in a month. That's how long my professor said it took him. And I must say, once you learn rust, it's such a joy.

caconym_ 10y ago

I think it took me a couple of weeks to be able to write practical programs (i.e. actual useful things) and a month or two more to feel really comfortable with it. I was not pursuing it on anything close to a full-time basis. I recommend this tutorial: http://cglab.ca/~abeinges/blah/too-many-lists/book/ http://cglab.ca/~abeinges/blah/too-many-lists/book/ for helping to grok the memory model. I tried to implement each chapter's data structure before I read the chapter so that I would really understand what problem the introduced memory constructs were solving. It's definitely not an easy language to learn, but once you get past the memory model stuff I think the learning curve at least gets a little flatter.