Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> ...indicated that ownership, borrowing, and lifetimes were primary causes of the challenges that...

I thought this was kinda obvious. Reasoning about borrowing and lifetimes is hard if you've never done it before. But the real question is how long it takes users to learn it and what we can do to improve that. I wonder how close the plain rust users' times would get to bronze users over time as they keep doing similar tasks.



>> I wonder how close the plain rust users' times would get to bronze users over time as they keep doing similar tasks.

This is the real question for me. The rest is just implementation detail. Someone is (usually) paying for the code to be written. Are they getting more value for less spend over time?

When you look at it through this lens though, there tend to be bigger overriding factors a rust compiler (or any other choice of language) can’t really help with - e.g. is the design & architecture of the code heading in the “ball of mud” direction. I.e. is change velocity going to reduce over time?

With a garbage collector, yeah you most likely are getting more productivity out of a developer. You’ve delegated one of the hardest problems (when can i free this thing?) to the computer. Because of the way rust is designed, it doesn’t protect against memory leaks. It protects against use after free but not that i fail to release redundant memory. But unfortunately It’s not guaranteed that just adding a garbage collector will help with this. With a sufficiently good developer though, they should be able to move faster than if you make them Arc<> & lifetime everything themselves. It’s specifically the lifetime bit that consumes time / developer productivity. Using Arc<> isn’t hard or arduous in any way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: