9 ms·

Does the "lower learning curve" goal include the lowering of learning curve for people who already know how to program? Because right now, the Book sometimes se

by ainar-g 10y ago

Does the "lower learning curve" goal include the lowering of learning curve for people who already know how to program? Because right now, the Book sometimes seems like it's aimed for people who either didn't program a lot, or didn't program in a language with types. What I actually would like is a few "Books" like "Rust for C++ people", "Rust for Go people", etc. Those would describe in many examples how things that are achieved in language X using A, B, and C can be done with D in Rust. Personally, I would like a "Rust for Gophers" book that would describe things like how does Rust do composing (that is, how to do what Go calls embedding), interfaces in Rust (with dynamic vs static dispatch), HTTP in Rust (this may be waiting for Tokio?), how to model your application's types and not get into who-owns-what traps. Also, what I really want is some kind of a list of Rust "warts" and their explanation. Like the fact that sometimes you can't do a.b().c(), but have to write tmp = a.b(); tmp.c().

steveklabnik 10y ago
You will probably like the O' Reilly book. It's a bit closer to "Rust for C++ people", IMHO. I fully agree that more of this kind of thing would be great.
- ainar-g 10y ago
  What about the warts part? Also, as someone who've tried to get into Rust three times now, I've been thinking, have you or anyone from the rust documentation team ever had sessions where you just - take a random C++/Go/Python developer - ask them to solve a not-too-simple but not-too-hard task, something that'll generally take them less than an hour in their "native" language, in Rust - look and take notes on their struggle with it This might shed some light on why people (like me) have so much trouble getting into Rust.
  - steveklabnik 10y ago
    > What about the warts part? I'm not sure enough time has passed to tell what Rust's warts truly are. I always joke String should have been called StrBuf... I do this, yes. This is one of the reasons I hang out in IRC so often; it's an effective way to collect these kinds of things. More data is always better, and collecting it across multiple venues. I don't think IRC is inherently going to be a representative sample. It's one of the reasons you'll see me pushing for details in Rust threads here, for example.
    - kibwen 10y ago
      > I always joke String should have been called StrBuf Agreed, and Vec should just be Buf! Let's fork the language. :)
      - iopq 10y ago
        And it should be white-space sensitive! 1. Writing a tab character introduces the equivalent of {} for blocks, but not other uses of {}. 2. You can still use {} for blocks if need be 3. Everyone uses elastic tabstops in their editor oh yeah, and parens are optional for function application
        kibwen 10y ago
        > parens are optional for function application I think you've gotten confused somehow... Rust++ is a pure concatenative programming language, function application is wholly unnecessary.
        iopq 10y ago
        Stop, I can only get so hard before an unsafe drop in blood pressure
      - cpeterso 10y ago
        Why not rename Vec to Buf everywhere with a Vec = Buf type alias for backwards compatibility?
    - ainar-g 10y ago
      I see. I hope to see more better docs soon. Thank you for answering and for generally being open.
      - steveklabnik 10y ago
        You're welcome, on both counts. I hope we can help you not get stuck if you give it a fourth try :)
  - gcp 10y ago
    Given the number of Rust developers reading this, it's probably going to be very helpful for them if you can describe what you actually got hung up on.
    - ainar-g 10y ago
      This was a few months ago, so I had to dig up some code: https://is.gd/kQJ7nv https://is.gd/kQJ7nv Basically, I tried to create a very basic HTTP server the way I would in Go, but I kept getting all sorts of lifetime errors and kept adding stuff go get away from them. So the code has issues, lots of them. Arc<Mutex<>> was recommended by a guy at the job, I don't even know why I need an Arc here, for example. The compiler says consider using an explicit lifetime parameter as shown: fn handle<'a, 'b>(&self, req: server::Request<'a, 'b>, mut res: server::Response<'a>) But when I do that I get error: `user_index_handler` does not live long enough And there I'm stuck. The user_index_handler is declared and initialised literally one line above. I don't understand why Rust thinks it can just delete it immediately after I've created it.
      - steveklabnik 10y ago
        This issue is a little bit too much in the weeds (and I'm not sure what version of Hyper you were using, it's had some big releases lately) but if you're curious, I recently implemented a basic HTTP service with a router. I still have some cleaning up to do, but https://github.com/rust-lang-nursery/thanks https://github.com/rust-lang-nursery/thanks is the repo, and the code similar to yours is https://github.com/rust-lang-nursery/thanks/tree/master/http https://github.com/rust-lang-nursery/thanks/tree/master/http is the implementation, https://github.com/rust-lang-nursery/thanks/blob/master/src/main.rs#L39-L63 https://github.com/rust-lang-nursery/thanks/blob/master/src/... is the core of using it. I _think_ the issue here is that Request and Response both have lifetimes. The compiler suggestion you're seeing was recently removed for having too high of a false positive rate, which I believe is what happened here. By doing that, you say that the handler must live as long as the Request and Response, which is not true, since it's created inside the functions but they're passed as arguments.
        10y ago
  - carussell 10y ago
    When I suggested doing this last year[1], it was very well-received. Not sure if the Rust folks ever did it. I'd wager no. 1. https://news.ycombinator.com/item?id=11156266 https://news.ycombinator.com/item?id=11156266
    - deleted 10y ago
      [deleted]
general_pizza 10y ago
Interesting. Out of curiosity, what's a case where tmp = a.b(); tmp.c() works but a.b().c() doesn't? I'm still learning rust and the online book's Methods chapter doesn't say anything about such restrictions.
- steveklabnik 10y ago
  It happens if b() returns an owned value that c() returns a reference to. In that case, a.b().c() b here is temporary, and so is freed at the end of the line, making the return of c dangling let temp = a.b(); temp.c(); Now that the return of b() is not temporary, it will last to the end of the scope and so c is fine.

by ainar-g 10y ago

steveklabnik 10y ago

You will probably like the O' Reilly book. It's a bit closer to "Rust for C++ people", IMHO. I fully agree that more of this kind of thing would be great.

ainar-g 10y ago
What about the warts part? Also, as someone who've tried to get into Rust three times now, I've been thinking, have you or anyone from the rust documentation team ever had sessions where you just - take a random C++/Go/Python developer - ask them to solve a not-too-simple but not-too-hard task, something that'll generally take them less than an hour in their "native" language, in Rust - look and take notes on their struggle with it This might shed some light on why people (like me) have so much trouble getting into Rust.
- steveklabnik 10y ago
  > What about the warts part? I'm not sure enough time has passed to tell what Rust's warts truly are. I always joke String should have been called StrBuf... I do this, yes. This is one of the reasons I hang out in IRC so often; it's an effective way to collect these kinds of things. More data is always better, and collecting it across multiple venues. I don't think IRC is inherently going to be a representative sample. It's one of the reasons you'll see me pushing for details in Rust threads here, for example.
  - kibwen 10y ago
    > I always joke String should have been called StrBuf Agreed, and Vec should just be Buf! Let's fork the language. :)
    - iopq 10y ago
      And it should be white-space sensitive! 1. Writing a tab character introduces the equivalent of {} for blocks, but not other uses of {}. 2. You can still use {} for blocks if need be 3. Everyone uses elastic tabstops in their editor oh yeah, and parens are optional for function application
      - kibwen 10y ago
        > parens are optional for function application I think you've gotten confused somehow... Rust++ is a pure concatenative programming language, function application is wholly unnecessary.
        iopq 10y ago
        Stop, I can only get so hard before an unsafe drop in blood pressure
    - cpeterso 10y ago
      Why not rename Vec to Buf everywhere with a Vec = Buf type alias for backwards compatibility?
  - ainar-g 10y ago
    I see. I hope to see more better docs soon. Thank you for answering and for generally being open.
    - steveklabnik 10y ago
      You're welcome, on both counts. I hope we can help you not get stuck if you give it a fourth try :)
- gcp 10y ago
  Given the number of Rust developers reading this, it's probably going to be very helpful for them if you can describe what you actually got hung up on.
  - ainar-g 10y ago
    This was a few months ago, so I had to dig up some code: https://is.gd/kQJ7nv https://is.gd/kQJ7nv Basically, I tried to create a very basic HTTP server the way I would in Go, but I kept getting all sorts of lifetime errors and kept adding stuff go get away from them. So the code has issues, lots of them. Arc<Mutex<>> was recommended by a guy at the job, I don't even know why I need an Arc here, for example. The compiler says consider using an explicit lifetime parameter as shown: fn handle<'a, 'b>(&self, req: server::Request<'a, 'b>, mut res: server::Response<'a>) But when I do that I get error: `user_index_handler` does not live long enough And there I'm stuck. The user_index_handler is declared and initialised literally one line above. I don't understand why Rust thinks it can just delete it immediately after I've created it.
    - steveklabnik 10y ago
      This issue is a little bit too much in the weeds (and I'm not sure what version of Hyper you were using, it's had some big releases lately) but if you're curious, I recently implemented a basic HTTP service with a router. I still have some cleaning up to do, but https://github.com/rust-lang-nursery/thanks https://github.com/rust-lang-nursery/thanks is the repo, and the code similar to yours is https://github.com/rust-lang-nursery/thanks/tree/master/http https://github.com/rust-lang-nursery/thanks/tree/master/http is the implementation, https://github.com/rust-lang-nursery/thanks/blob/master/src/main.rs#L39-L63 https://github.com/rust-lang-nursery/thanks/blob/master/src/... is the core of using it. I _think_ the issue here is that Request and Response both have lifetimes. The compiler suggestion you're seeing was recently removed for having too high of a false positive rate, which I believe is what happened here. By doing that, you say that the handler must live as long as the Request and Response, which is not true, since it's created inside the functions but they're passed as arguments.
      - 10y ago
- carussell 10y ago
  When I suggested doing this last year[1], it was very well-received. Not sure if the Rust folks ever did it. I'd wager no. 1. https://news.ycombinator.com/item?id=11156266 https://news.ycombinator.com/item?id=11156266
  - deleted 10y ago
    [deleted]

general_pizza 10y ago

Interesting. Out of curiosity, what's a case where tmp = a.b(); tmp.c() works but a.b().c() doesn't? I'm still learning rust and the online book's Methods chapter doesn't say anything about such restrictions.

steveklabnik 10y ago
It happens if b() returns an owned value that c() returns a reference to. In that case, a.b().c() b here is temporary, and so is freed at the end of the line, making the return of c dangling let temp = a.b(); temp.c(); Now that the return of b() is not temporary, it will last to the end of the scope and so c is fine.