4 ms·
I don't care that it's hard to learn. What turns me off rust is that if I ever make a change that requires a lifetime annotation, I now have to go back through
by unclad5968 3y ago
I don't care that it's hard to learn. What turns me off rust is that if I ever make a change that requires a lifetime annotation, I now have to go back through all my code potentially adding lifetime annotations to everything it touches.
I was making a little toy compiler in rust and basically gave up when I wanted to make a change that would have amount to string -> string_view in c++ because in rust I now need to tell the compiler that the String to my &String is going to outlive the struct. Now I understand why it's good but Id rather just let c++ blow my feet off. Maybe once I nail down all the data structures I'll rewrite it in rust.
- zozbot234 3y agoIsn't that why Rc<> and Arc<> exist in Rust? So that you can deal with situations where you don't know the object lifecycle at compile time?
- miniupuchaty 3y agoIf you're fine with dropping safety you can just make a wrapper around a raw pointer. I wouldn't do it in public library but if it's fine for your cpp code then it's fine for your rust code. You can always drop to the "blow my feet off" level.
- merb 3y agoThe last few versions made a lot of the lifetimes elided so you can drop them.
- pdimitar 3y agoDo you have a direct link? I'd love to read more.
- merb 3y agoSadly not. But between 1.5x and 1.7x a lit of things changed, especially around traits and there is clippy which actually helps. So our functions barely need lifetimes anymore.
- winrid 3y agoI feel like this has been this way for at least two years, too?
- merb 3y agoWell maybe we started with 1.5x or so and especially impl trait‘s made a lot of things easier. We barely have lifetimes in our rust code.
- pornel 3y agoThis effect of <'a> spreading everywhere is very frequently a novice mistake of putting temporary scope-bound loans (AKA references) in structs that aren't temporary views themselves. People used to C or C++ perspective tend to reflexively (over)use references to avoid copying, but references in Rust are to avoid owning, and not-copying is handled in different ways. BTW, apart from edgiest of edge cases, &String is a useless type in Rust, because String already stores data "by reference" and is never implicitly copied. For loans it's generally better to deref to &str.
- pdimitar 3y ago> and not-copying is handled in different ways Can you give a few examples?
- imetatroll 3y agoI am a novice when it comes to rust but as I recall the instant you put anything that isn't a scalar type you need lifetimes. Is that what the person you are replying to frustrated with? How would not copying be handled? Sorry for the basic questions. Your comment tickles something in my brain that suggests I need to know.
- telios 3y agoVery rarely do you need to pass around a lifetime-bound struct or enum that isn't _also_ meant to be temporary. (One database pool has database connections lifetime bound, for example, but the pool still owns the connection.) When I do, I generally eat the cost and put it behind a Rc/Arc, where cloning is cheap. It is 'borrowing' because you don't own it, not because you don't want to clone/copy it. Sometimes it is cheaper to borrow than it is to clone/copy; sometimes it is not.
- frfl 3y agoI feel like this could be a great in depth blog post...unless such a blog post already exists? It would greatly benefit novices and those who haven't gotten to that stage where this mentality kicks in.
- rightbyte 3y agoThis is more or less the reason I don't like adding "const" to member functions in C++, or setting any method or field to anything but public. Working with the code base gets so annoying if you suddenly want to change something you didn't plan for. Such changes can have a domino effect through the code.