Hacker News Reader

Comment by gameswithgo | Hacker News Reader

I tried to do a small project using Rust and SDL2 and gave up due to having to deal with lifetimes on textures.

> you just implement the [Drop] trait and that's basically it.

Is that what I was missing? could I have done that and not had to deal with lifetimes?

In the transition from 0.29 to 0.30, the sdl2 library added that lifetime parameter to textures. Personally I found that it made the library unuseable, and I switched to an alternative.

I don't think I was the only one, because in 0.31 they added the option to remove that lifetime as long as you are happy disposing of the textures yourself. If you do the following in your Cargo.toml they go away.

    [dependencies.sdl2]
    version = "0.31"
    default-features = false
    features = ["unsafe_textures"]

I think the argument for lifetimes on textures and surfaces was to increase the safety of the library. This is probably true, but in practice I found it unuseable, and I think a system of handles along with error messages when you try to use it would have solved the problem in a workable manner with minimal performance overhead.

So it wasn't just me! One thing that kept bugging me is that in my case the lifetime of every texture was "forever" and it seemed like there ought to be an easy way to indicate that, without lifetime annotations propagating throughout all the code.

Maybe there is!

That's `'static`!

Lifetimes can be a challenge to learn but once you do not having to worry about whether something is actually getting destroyed is a great feeling. The opposite example is I just wrote some GL in Swift and I have no idea if my GL textures are leaking. I’m confident with lifetimes I’d know ^_^ my email is in my profile. Happy to help out if you’re still interested in debugging.

You always have to "deal" with lifetimes. The rules are not that complicated once you understand them. It boils down to:

* An object can only have one owner.

* When giving a reference away from an object, the reference has a lifetime that makes sure the reference doesn't outlive the owner.

* You can either have one mutable reference >>or<< arbitrary read-only references.

* An owned object must be denoted mutable to be mutable, otherwise it is read-only.

Some comments with the caveat that I have used Rust only for a short learning exercise a while ago and I don't fully understand programming in Rust (and found it tough going), but I think the problem is not about being able to understand the ownership models and lifetimes (which seems fairly straightforward conceptually).

The problem is in being able to put together a program that the compiler does not complain about. It always seems like you have to "feel" your way around by trying different things like a jigsaw puzzle rather than having a "canonical" way to do things that fit the lifetime/ownership model. Maybe there are more canonical ways based on people's experiences nowadays and maybe this problem is due to approaching solving things using a C (or other language) mind-set. It seems like learning these ways to avoid the Rust compilers errors related to lifetimes in any complex program takes longer than in other languages.

Yeah, most people who make it over the hump describe it as "once you learn the rules and develop intuition for them, you start designing your code in a way that works well first rather than fighting with the borrow checker all the time."

> It seems like learning these ways to avoid the Rust compilers errors related to lifetimes in any complex program takes longer than in other languages.

Opinion is split here. Some people prefer that C and C++ let you "get it slightly wrong" for a while, so you learn more incrementally. Others prefer that the Rust compiler tells you exactly what you've gotten wrong, so it can help you figure out what to learn about. I suspect which works better for you depends on you.

Rust is for sure not an easy language (but compared with Haskell also not that hard/time consuming to learn). The major stumbling block seems to me is, that the syntax looks some kind of familiar, which tricks you into believing that knowledge-of-other-language applies, but in reality Rust is a completely different beast.

For me there was a gap between reading the Rust book and applying the knowledge. While reading I thought "that's easy" but later on "oh shit, the compiler complains all the time". If you make it past that point – which takes for most non-novice programmers around three weeks – then Rust becomes a very powerful tool to you.

If you have any thought or insight on how to get over that, please let me know. The docs team wants to work on "what comes after the book" next, so any insights into what made it work for you would be very helpful!

> If you have any thought or insight on how to get over that...

It depends with which concepts someone is already familiar. To me the only really new concept was the lifetime and ownership one, all others have just a different syntax plus here and there some extra goodies. As example, when I saw the match keyword I thought "cool, Rust has a keyword for guards".

I learned Rust shortly after 1.0 was released. The real obstacle for me to overcome was to build a mental concept of what Rust is. Something that wasn't really communicated while reading the first pre-release Rust book.

You have to read a lot to get an idea of Rust, it should be the other way around – a common mistake done by almost everyone teaching something. Ideally the first chapter would be a buzzword free, Rust code free chapter about how Rust works superficially and why there is a need for yet another computer language. It should describe what kind of tools and concepts in Rust exist and which problems they solve. This is better than introducing somewhat complicated concepts/tools and trying to explain how they fit into the big picture at the same time.

Ideally there would be an introduction like this:

A program needs a structure, variables, control flow, tools... blablabla... this leads to some common problems [some easy examples] and [this] are some concepts Rust invented/uses to solve them.

In later chapters the abstract ideas would be "converted into Rust". Also don't go too much into detail. I don't think for example that a representation of the memory layout of a vector helps much. At first I just need to know there is a thing where I can put objects of the same type into, how it is implemented is not that important for a beginner. It's better IMHO to know how to do something right, than why something is right. This reduces the mental burden in the beginning of the learning phase. The why is something that you learn over time – or maybe you are not that interested and skip it forever, also a valid thing to do.

Overall the Rust community does a stellar job providing so much help in so many different ways – /r/rust on Reddit is really awesome – thanks for the book and your open mind to ask for feedback.

Thank you! Very helpful.

It has been a while but I was moving along ok until I wanted to put some of them in a map and then I ran out of IQ!

Best practices are "use owned types for the keys and values until you have a reason not to." It makes things much simpler. Of course, this isn't always possible, but most of the time, it is!

Reply on news.ycombinator.com