> Interesting, I remember having to adapt some idioms around caching and storing iterators in particular, but very quickly I felt like there wasn't that many hoops and they weren't that weird.
I generally didn't feel that way. I didn't need to change much of my use because O barely ran into the borrow checker. The time I did, was recursively accessing different parts of a pretty central struct but the borrow checker concidered the entire struct a borrowed object. Effectively I couldn't access multiple different fields of the struct if I have the larger struct already as a mutable borrow even though I only access one part of it. It was pretty trivial to confirm that the different functions in fact do not touch the same parts of the struct however the borrow checker simply could not do that. Maybe it's changed recently but I required an actual significant change to the code with several abstractions added when it really wasn't necessary.
I did actually agree with you regarding reviewing code to get rid of UB, I was just a little too verbose maybe. Regarding false positives and negatives with santizers and static analysis, I feel it's worth the pain for a language which I find more expressive for my use case, I'm not against usig rust, I'm against saying it's the universal solution to every problem needing to be solved when in my experience I haven't been able to reproduce that view. There are problems it solves well, I don't run into those often.
I'm also happy more data is coming out on productivity, I feel like it can only help light a fire under people on the standards committee who are indifferent to the issues of C++ to actually push to fix some of the issues which are currently solveable.
Ironically I see with your last point regarding golang that we are very different people ans thats fine. For me I would much rather lean back towards C if I can guarantee safety than the more abstract and high level rust. Honestly I am extremely intrigued by zig but until it's stable I'm not going near it.
We want different things from languages and that is fine.
> Ironically I see with your last point regarding golang that we are very different people ans thats fine. For me I would much rather lean back towards C if I can guarantee safety than the more abstract and high level rust. Honestly I am extremely intrigued by zig but until it's stable I'm not going near it.
>
> We want different things from languages and that is fine.
I just wanted to tell you that I agree. A lot of what makes people like or dislike a language seems to be down to aesthetics in its nobler meaning.
> The time I did, was recursively accessing different parts of a pretty central struct but the borrow checker concidered the entire struct a borrowed object.
Ah OK. It helps to model a borrow of a struct as a capability. If your struct is made of multiple "capabilities" that can be borrowed separately, then you better express that with a function that borrows the struct and return "view objects" representing the capabilities.
For instance, if you can `foo` and `bar` your struct at the same time, you can have a method:
I generally didn't feel that way. I didn't need to change much of my use because O barely ran into the borrow checker. The time I did, was recursively accessing different parts of a pretty central struct but the borrow checker concidered the entire struct a borrowed object. Effectively I couldn't access multiple different fields of the struct if I have the larger struct already as a mutable borrow even though I only access one part of it. It was pretty trivial to confirm that the different functions in fact do not touch the same parts of the struct however the borrow checker simply could not do that. Maybe it's changed recently but I required an actual significant change to the code with several abstractions added when it really wasn't necessary.
I did actually agree with you regarding reviewing code to get rid of UB, I was just a little too verbose maybe. Regarding false positives and negatives with santizers and static analysis, I feel it's worth the pain for a language which I find more expressive for my use case, I'm not against usig rust, I'm against saying it's the universal solution to every problem needing to be solved when in my experience I haven't been able to reproduce that view. There are problems it solves well, I don't run into those often.
I'm also happy more data is coming out on productivity, I feel like it can only help light a fire under people on the standards committee who are indifferent to the issues of C++ to actually push to fix some of the issues which are currently solveable.
Ironically I see with your last point regarding golang that we are very different people ans thats fine. For me I would much rather lean back towards C if I can guarantee safety than the more abstract and high level rust. Honestly I am extremely intrigued by zig but until it's stable I'm not going near it.
We want different things from languages and that is fine.