Comment by fizzbatter | Hacker News Reader

Comment by fizzbatter | Hacker News Reader

Parent Full thread

I'm not trying to bash Rust, i love it, so for random viewers looking to pick a fight.. please don't bother. I'm only citing what my experience thus far is.

It's confusing, as hell.

Let me try to explain a little bit. I'm a average dev, and have been for ~7 years or so. My languages have typically been dynamic, but the past 2 years has been heavily Go.

I picked up the majority of Rust, as well as basic borrow checker usage, in a matter of hours. But that's where the fun stopped. Generic syntax beat me up (mostly related to Static dispatch and Type Assertions). Lifetime syntaxes are currently kicking my ass as well. The problem as i see it, seems to be that i am a more.. "dig in" developer. And frankly, that does not seem to fly here. I've read a lot of the rust docs, but rather than start to finish, it's been in response to questions i have. This seems to be problematic for rust, as important concepts can be left in the dust.

A good example of this is Static vs Dynamic Dispatch is rust. Heavy trait usage combined with using Static Dispatch incorrectly resulted in code not designed for what i wanted, and lots of seemingly random bugs. Ie, `foo = Foo::new()` would fail, but `foo = Foo::new(); foo.bad(baz);` would succeed.

Currently i'm trying to figure out how to either move a variable out of a block, or, more importantly define a lifetime on `Ok(r) => r,` so that the result can escape the block.

Anyway. None of this is the fault of rust exactly, and again, i love this language. I'm switching because Go hasn't offered the full safety i want. But man, it has been quite the hellish experience to get started.

Have you dropped by IRC? Always happy to help answer questions in real-time.

  > how to to either move a variable out of a block,

Blocks evaluate to a value, so if it's a movable type, it will move.

    let x = {
        let s = String::new();
        // stuff happens with s

        s
    };

Here, s will move out of the block, and into x.

    > more importantly define a lifetime on `Ok(r) => r,` so that the result can escape the block.

Lifetimes cannot extend the life of something, they are descriptive, not prescriptive. So I think you might be trying something that's impossible...

I hop into Rust beginners from time to time, but it's usually pretty empty so a bit hard to get an answer. I'm very likely explaining the problem incorrectly, so let me give you an example: https://gist.github.com/anonymous/3d72907031ce18d002364e756f...

As you can expect, line 13 is trying to borrow a value that does not live long enough for `req`. Unfortunately, hyper::client::Client's req.body() requires a &str it seems. Somehow i need to pass it a &str (which i would normally do via &String).

Do i need to move s:String out of the block? Do i need to specify a lifetime? These are the sort of "What do i even search for!?" moments i run into heh. Granted, less so these days.. thankfully.

Note that `&mut Some(ref c)` looks pretty terrible, i'm experimenting with an API i'm writing.

I try to idle in there during NYC 9-5ish at least, but depending on your time zone, it can be tough.

Without compiling myself, it can be a bit tricky, but...

Yes, so the issue here is, your String will go out of scope at the end if the if let, on 14. But you're trying to store a reference to it in something that lives longer: the req will continue to live afterwards. So yes, you need to move s outside of the block somehow; there are a few different ways of doing this. What I'd try first is something like this: https://gist.github.com/steveklabnik/54cf7a4a522cd1a7c6e0130...

Now that the binding lives in the outer scope, it will live longer than the `if let`, you're basically moving it out. I'm trusting the compiler's control flow analysis here; it should let you do this, given that you only use s after you've assigned to it.

Indeed, that worked! So, it's good to know i had the right idea (moving the data out of the block), but i didn't think to store it above the request body.

I was trying to be clever, and use explicitly say that `s` should live for the lifetime of the parent function. Any idea if that is possible in this case?

edit: Sidenote, i appreciate that you hang in Rust Beginners, i didn't mean to imply that people weren't being helpful. Just that, it can be difficult to find a solution at times.

On the plus side, i managed to help (i hope haha) a guy in #rust-beginners today, so hopefully i've paid it forward a bit. Appreciate your help!

Yeah no worries :)

  > Any idea if that is possible in this case?

This is what I meant by liftimes being descriptive, not prescriptive: you can't add an annotation and make something live longer. Moving the binding itself is the only way.

OK, I see what the problem is. This is the type signature for the body method:

fn body<B: Into<Body<'a>>>(self, body: B) -> RequestBuilder<'a>

The RequestBuilder struct tries to be clever: it just keeps a pointer to what you want the body to be rather than taking ownership of it or copying it. So when you say that "req = req.body(&s)" you've given the request a pointer to your string, but that string is freed inside that if-block. I don't see an obvious fix right now, but I'll update this is I see something.

Yea, that's another thing about rust. At times, things like what Hyper's Body method is doing can be quite puzzling. And while Rust's attempt to help is noble, it can end up even more confusing. At times it is awesome, but it can be a lot of visual noise for beginners.

Fwiw, https://news.ycombinator.com/item?id=11780196 has the answer to my example problem. I'm also inquiring about using lifetimes to solve the problem.

Reply on news.ycombinator.com