7 ms·

One thing I've found with rust is that you struggle struggle struggle trying to do a simple task, and then finally someone says "Oh, all you need to do is this"

One thing I've found with rust is that you struggle struggle struggle trying to do a simple task, and then finally someone says "Oh, all you need to do is this". Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it, and getting into rust gets harder and harder as time goes on. Yes, there's some awesome documentation, and the error messaging has gotten a lot better. But the power and flexibility of Rust comes at the cost of it becoming harder and harder to figure out how all the thousands of little pieces are supposed to fit together. What's really needed is a kind of "cookbook" documentation that has things like "How to read a text file with proper error handling" and "what is the proper way to pass certain kinds of data around and why". Right now there's a lot of "what" documentation going around, but little that discusses the "how to and why".

steveklabnik 10y ago
There is an active (but just started) project to write a cookbook: https://blog.rust-lang.org/2017/05/05/libz-blitz.html https://blog.rust-lang.org/2017/05/05/libz-blitz.html
burntsushi 10y ago
> but little that discusses the "how to and why" Have you read the book's chapter on error handling?[1] It's being replaced in the second version of the book, but I still plan on maintaining it as a blog post[2]. Any advice you might have to add more of what you want would be helpful. (And I ask this because I tried to attack the "how to and why" angle, so I'm wondering if I got that wrong.) [1] - https://doc.rust-lang.org/stable/book/error-handling.html https://doc.rust-lang.org/stable/book/error-handling.html [2] - http://blog.burntsushi.net/rust-error-handling/ http://blog.burntsushi.net/rust-error-handling/
std_throwaway 10y ago
How is this problem solved for C++?
- hellofunk 10y ago
  The nice thing about C++ is that it is so widely used that for just about any task you can find examples of how to do it (usually many different ways to do something), especially for tasks like this article. You will also find plenty of C example, which you could also use in C++.
  - arcticbull 10y ago
    Unfortunately 90% of them will be outdated/wrong/unsafe. Being backward compatible with 30 years of code means you're unlikely to find the right answer for the present. And worse, you won't know it.
    - lossolo 10y ago
      You base your 90% claim based on what? I have entirely different experience and I am using C++14 and C. K&R "C programming language" is from 1978 and it's still one of the best books about C still used in 2017. I see many stackoverflow answers updated from C++98 to C++11/14 and some even to C++17.
      - kibwen 10y ago
        As someone whose first introduction to C was through K&R, and still has that torn and tattered copy on his bookshelf, the idea that we're still recommending K&R as "one of the best books about C" only validates arcticbull's (sadly-downvoted) point.
        lossolo 10y ago
        I don't share your opinion and most people I know that do C do not share it also. It's good base to get familiar with language, no one say you can't expand your knowledge further after reading this book. I've read some other "modern" books about C like "21st century C" but they are not for people that do not know C and they are not so good for people that know it. Can you provide any arguments to support what you wrote? What alternative you would propose for learning C? https://www.amazon.com/Programming-Language-Brian-W-Kernighan/dp/0131103628 https://www.amazon.com/Programming-Language-Brian-W-Kernigha... Read what majority of opinions say. It's really easy to criticize without giving better alternative.
cupcakestand 10y ago
> Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it This was my feeling when I got into Ruby on Rails (years too late).
- photojosh 10y ago
  I got into Python/Django seriously in 2013, which is a fair way along in their history, and have loved it ever since. Now even doing async & websockets stuff using django-channels after thinking that would never be possible. Wonder why the difference?
Manishearth 10y ago
(someone recently told me that they were working on just that -- a cookbook -- for common rust tasks. Let's see!)
allengeorge 10y ago
I don't know if that's quite true. While Rust is very deep, I've found that you can get quite far with a few crucial pieces of info (note that I don't speak about generics or macros; haven't worked a lot with them): * All variables are expected to be sized. So, learn what's sized and what isn't. * Understand traits and how they add functionality to types. Have a small dictionary of common ones (From, Into, Debug, etc.) * Learn how to write blanket implementations for traits. This can make your code lighter-weight. You also learn to start looking for blanket implementations. * Encapsulate ownership details when possible. I'm not sure about the best way to explain this, but...at a high level it means "structure your types so that you avoid sharing ownership".
- JasonSage 10y ago
  Any links or ideas on how to get started with some of these? Understanding traits and knowing common ones is as trivial as reading the Rust Book, but ideas like "write blanket implementations" and "encapsulate ownership details" are less easy to find.
  - allengeorge 10y ago
    I really started looking into blanket implementations after I saw this example [1] in Tokio. Basically it says "implement the `AsyncRead` trait for any boxed type that implements `AsyncRead` or any `AsyncRead` trait object. The Error trait contains more examples [2]. As for "encapsulate ownership details". Hard to describe, but...let me point to Tokio [3] again. In Java if you wanted to share an IO reader/writer with two different objects you'd use the same type and pass the same reference to both owners. In Rust, the same idiom would require the wordy use of `Arc<Mutex<Type>>` or `Rc<RefCell<Type>>`. I hope we can both agree that that's frustrating. An alternative (as demonstrated by Tokio's `split` method) is to separate your base type into two other types - reader and writer - that can be owned independently. No more externally-visible ref counting. Of course, this isn't possible in all scenarios: there absolutely are times when you don't have a clean separation of types and have to ref count; but, avoid it if you can. I learned all of this by poking into libs, asking a ton on the IRC channels (everyone is super friendly) and failing a lot. Any errors are my own. Hope that helps! [1] https://github.com/tokio-rs/tokio-io/blob/master/src/lib.rs#L192 https://github.com/tokio-rs/tokio-io/blob/master/src/lib.rs#... [2] https://doc.rust-lang.org/src/std/error.rs.html#281 https://doc.rust-lang.org/src/std/error.rs.html#281 [3] https://github.com/tokio-rs/tokio-io/blob/master/src/lib.rs#L186 https://github.com/tokio-rs/tokio-io/blob/master/src/lib.rs#...
geofft 10y ago
I think it is 100% the case that the best way to learn Rust is to be on the IRC channel (#rust or #rust-beginners, either is fine for beginners but the latter is unlogged and more focused if you prefer) and ask lots of questions and also lurk. I'm not sure if that's good in absolute terms for the language, but it's very helpful. (Which probably means your first project should be something open-source so you can share your code easily)
- bluejekyll 10y ago
  Personally, I learned Rust with "The Book" and "Rust by example", I'm still learning it! My time never really allows me to be on IRC regularly. Point being that if you can't get on IRC, I don't think it's necessary. And honestly, error handling was the most difficult thing to understand, until you start groking why sized types are required as return types from functions and that every function call up the stack requires its callees to compensate for all it's error possibilities. error_chain! has made this all so much better.
onmobiletemp 10y ago
Check out the rust libz blitz, a documentatuon overhaul initiaitive by the rust devs. It addresses all of these issues.
jpfr 10y ago
These are the exact same complaints of students learning to program for the first time. Have you tried functional programmng? Lisp? Ocaml? The complaints of newbie functional programmers are also nearly the same. The "struggle" is necessary. If there is no struggle, there is no learning of fundamentally new approaches you are not yet comfortable with. See it as part of the training regimen that lets people emerge as stronger programmers on the other side.
- throwaway7645 10y ago
  No, the training material for something like Python is orders of magnitude easier to get into than things like OCaml, Haskell, and Lisp. Python has doc and many many books taking you from A through Z. Many of these other languages have "A" and then pick back up at "S", but skip over "B"-"R". You basically get a feel for syntax, control flow, and a few other topics, but don't get the meat of why that language is different. Not everyone wants to learn by digging into open source projects.
  - jpfr 10y ago
    If it is something that OCaml, Haskell and Lisp are not lacking, it is books written about them. We can argue on technical points. But the existence of documentation is a non-issue for all of these languages. https://ocaml.org/learn/books.html https://ocaml.org/learn/books.html https://wiki.haskell.org/Books https://wiki.haskell.org/Books http://lisp-lang.org/books/ http://lisp-lang.org/books/ It could well be, that these books are written for experienced programmers who don't need basic concepts (control flow, object orientation, etc.) explained. But that was not the point. The absence of an easy road for these langauges is because they need to teach some powerful abstractions first that have no equivalence in Python, Java or C.
    - throwaway7645 10y ago
      There are books yes and I've read some of them mostly cover to cover (1 Haskell, 1 F# and 3 common lisp) and still can't proficiently use any of those. Yes there are some things you have to learn like macros, currying, monads. I fully agree with you on that, but feel the task could be much simpler with better intro material. Perhaps the shear amount of material failing to work for so many people is a 100% indication that you're correct and the hurdle can't be made easier to overcome...I don't know. Slightly off-topic, if you're correct...do you ever think FP will take off with the masses?

steveklabnik 10y ago

There is an active (but just started) project to write a cookbook: https://blog.rust-lang.org/2017/05/05/libz-blitz.html https://blog.rust-lang.org/2017/05/05/libz-blitz.html

burntsushi 10y ago

> but little that discusses the "how to and why" Have you read the book's chapter on error handling?[1] It's being replaced in the second version of the book, but I still plan on maintaining it as a blog post[2]. Any advice you might have to add more of what you want would be helpful. (And I ask this because I tried to attack the "how to and why" angle, so I'm wondering if I got that wrong.) [1] - https://doc.rust-lang.org/stable/book/error-handling.html https://doc.rust-lang.org/stable/book/error-handling.html [2] - http://blog.burntsushi.net/rust-error-handling/ http://blog.burntsushi.net/rust-error-handling/

std_throwaway 10y ago

How is this problem solved for C++?

hellofunk 10y ago
The nice thing about C++ is that it is so widely used that for just about any task you can find examples of how to do it (usually many different ways to do something), especially for tasks like this article. You will also find plenty of C example, which you could also use in C++.
- arcticbull 10y ago
  Unfortunately 90% of them will be outdated/wrong/unsafe. Being backward compatible with 30 years of code means you're unlikely to find the right answer for the present. And worse, you won't know it.
  - lossolo 10y ago
    You base your 90% claim based on what? I have entirely different experience and I am using C++14 and C. K&R "C programming language" is from 1978 and it's still one of the best books about C still used in 2017. I see many stackoverflow answers updated from C++98 to C++11/14 and some even to C++17.
    - kibwen 10y ago
      As someone whose first introduction to C was through K&R, and still has that torn and tattered copy on his bookshelf, the idea that we're still recommending K&R as "one of the best books about C" only validates arcticbull's (sadly-downvoted) point.
      - lossolo 10y ago
        I don't share your opinion and most people I know that do C do not share it also. It's good base to get familiar with language, no one say you can't expand your knowledge further after reading this book. I've read some other "modern" books about C like "21st century C" but they are not for people that do not know C and they are not so good for people that know it. Can you provide any arguments to support what you wrote? What alternative you would propose for learning C? https://www.amazon.com/Programming-Language-Brian-W-Kernighan/dp/0131103628 https://www.amazon.com/Programming-Language-Brian-W-Kernigha... Read what majority of opinions say. It's really easy to criticize without giving better alternative.

cupcakestand 10y ago

> Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it This was my feeling when I got into Ruby on Rails (years too late).

photojosh 10y ago
I got into Python/Django seriously in 2013, which is a fair way along in their history, and have loved it ever since. Now even doing async & websockets stuff using django-channels after thinking that would never be possible. Wonder why the difference?

Manishearth 10y ago

(someone recently told me that they were working on just that -- a cookbook -- for common rust tasks. Let's see!)

allengeorge 10y ago

I don't know if that's quite true. While Rust is very deep, I've found that you can get quite far with a few crucial pieces of info (note that I don't speak about generics or macros; haven't worked a lot with them): * All variables are expected to be sized. So, learn what's sized and what isn't. * Understand traits and how they add functionality to types. Have a small dictionary of common ones (From, Into, Debug, etc.) * Learn how to write blanket implementations for traits. This can make your code lighter-weight. You also learn to start looking for blanket implementations. * Encapsulate ownership details when possible. I'm not sure about the best way to explain this, but...at a high level it means "structure your types so that you avoid sharing ownership".

JasonSage 10y ago
Any links or ideas on how to get started with some of these? Understanding traits and knowing common ones is as trivial as reading the Rust Book, but ideas like "write blanket implementations" and "encapsulate ownership details" are less easy to find.
- allengeorge 10y ago
  I really started looking into blanket implementations after I saw this example [1] in Tokio. Basically it says "implement the `AsyncRead` trait for any boxed type that implements `AsyncRead` or any `AsyncRead` trait object. The Error trait contains more examples [2]. As for "encapsulate ownership details". Hard to describe, but...let me point to Tokio [3] again. In Java if you wanted to share an IO reader/writer with two different objects you'd use the same type and pass the same reference to both owners. In Rust, the same idiom would require the wordy use of `Arc<Mutex<Type>>` or `Rc<RefCell<Type>>`. I hope we can both agree that that's frustrating. An alternative (as demonstrated by Tokio's `split` method) is to separate your base type into two other types - reader and writer - that can be owned independently. No more externally-visible ref counting. Of course, this isn't possible in all scenarios: there absolutely are times when you don't have a clean separation of types and have to ref count; but, avoid it if you can. I learned all of this by poking into libs, asking a ton on the IRC channels (everyone is super friendly) and failing a lot. Any errors are my own. Hope that helps! [1] https://github.com/tokio-rs/tokio-io/blob/master/src/lib.rs#L192 https://github.com/tokio-rs/tokio-io/blob/master/src/lib.rs#... [2] https://doc.rust-lang.org/src/std/error.rs.html#281 https://doc.rust-lang.org/src/std/error.rs.html#281 [3] https://github.com/tokio-rs/tokio-io/blob/master/src/lib.rs#L186 https://github.com/tokio-rs/tokio-io/blob/master/src/lib.rs#...

geofft 10y ago

I think it is 100% the case that the best way to learn Rust is to be on the IRC channel (#rust or #rust-beginners, either is fine for beginners but the latter is unlogged and more focused if you prefer) and ask lots of questions and also lurk. I'm not sure if that's good in absolute terms for the language, but it's very helpful. (Which probably means your first project should be something open-source so you can share your code easily)

bluejekyll 10y ago
Personally, I learned Rust with "The Book" and "Rust by example", I'm still learning it! My time never really allows me to be on IRC regularly. Point being that if you can't get on IRC, I don't think it's necessary. And honestly, error handling was the most difficult thing to understand, until you start groking why sized types are required as return types from functions and that every function call up the stack requires its callees to compensate for all it's error possibilities. error_chain! has made this all so much better.

onmobiletemp 10y ago

Check out the rust libz blitz, a documentatuon overhaul initiaitive by the rust devs. It addresses all of these issues.

jpfr 10y ago

These are the exact same complaints of students learning to program for the first time. Have you tried functional programmng? Lisp? Ocaml? The complaints of newbie functional programmers are also nearly the same. The "struggle" is necessary. If there is no struggle, there is no learning of fundamentally new approaches you are not yet comfortable with. See it as part of the training regimen that lets people emerge as stronger programmers on the other side.

throwaway7645 10y ago
No, the training material for something like Python is orders of magnitude easier to get into than things like OCaml, Haskell, and Lisp. Python has doc and many many books taking you from A through Z. Many of these other languages have "A" and then pick back up at "S", but skip over "B"-"R". You basically get a feel for syntax, control flow, and a few other topics, but don't get the meat of why that language is different. Not everyone wants to learn by digging into open source projects.
- jpfr 10y ago
  If it is something that OCaml, Haskell and Lisp are not lacking, it is books written about them. We can argue on technical points. But the existence of documentation is a non-issue for all of these languages. https://ocaml.org/learn/books.html https://ocaml.org/learn/books.html https://wiki.haskell.org/Books https://wiki.haskell.org/Books http://lisp-lang.org/books/ http://lisp-lang.org/books/ It could well be, that these books are written for experienced programmers who don't need basic concepts (control flow, object orientation, etc.) explained. But that was not the point. The absence of an easy road for these langauges is because they need to teach some powerful abstractions first that have no equivalence in Python, Java or C.
  - throwaway7645 10y ago
    There are books yes and I've read some of them mostly cover to cover (1 Haskell, 1 F# and 3 common lisp) and still can't proficiently use any of those. Yes there are some things you have to learn like macros, currying, monads. I fully agree with you on that, but feel the task could be much simpler with better intro material. Perhaps the shear amount of material failing to work for so many people is a 100% indication that you're correct and the hurdle can't be made easier to overcome...I don't know. Slightly off-topic, if you're correct...do you ever think FP will take off with the masses?