When do you find lifetime annotations helpful?

For curiosity's sake, what languages were you experienced with before you started learning Rust?

References are a sharp tool and there are roughly three different approaches to sharp tools.

  1. Don't give programmers sharp tools. They may make mistakes and cut their fingers off. This is the Java/Python/Perl/Ruby/PHP... approach.
  2. Give programmers all the sharp tools they want. They are professionals and if they cut their fingers off it's their own fault. This is the C/C++ approach.
  3. Give programmers sharp tools, but put guards on them so they can't accidentally cut their fingers off. This is Rust's approach.

Lifetime annotations are a safety guard on references. Rust's references have no sychronization and no reference counting -- that's what makes them sharp. References in category-1 languages (which typically do have synchronization and reference counting) are "blunted": they're not really quite as effective as category-2 and -3 references, but they don't cut you, and they still work; they might just slow you down a bit.

So, frankly, I like lifetime annotations because they prevent me from cutting my fingers off.

"This would be a great circular saw if only it didn't have this safety guard" is not something you will hear a whole lot of carpenters say.

What does "get rid of them" mean exactly? Do you have an alternative in mind that will also prevent chopped fingers, or do you mean you wish Rust were in category 1, or do you wish that it were in category 2?

I mean, that (inferring ownership and lifetimes based on usage) is just what (most) category-1 languages do already, right? There's nothing really novel about that. Most JVM languages do it pretty well, I think. If you're looking for a statically-typed safe language without lifetime annotations, have you considered maybe Kotlin or Scala?

13 Likes