Could you please tell more about borrow checker issues?
Within a couple weeks you will get the hang of what the borrow checker can actually handle and you'll mostly not have problems except when you are actually making a genuine mistake.
I don't know if it helps you or not, but you can specify that a type parameter need not be sized with the ?Sized bound. e.g., The `Path::new` constructor is defined as `fn new<S: AsRef<OsStr> + ?Sized>(s: &S) -> &Path`. This means `S` can, for example, be `str`, which is an unsized type.
BTW - this reaction is why I continue to work with Rust; the community is awesome!
(Dealing with trait objects and generics...less so)
I don't think it's description of an issue.
It is if it drives potential community members away.
Look, it's not an issue for all time, there are plans to improve it, I'm just suggesting it as a point of friction right now. If you seriously don't think it's an issue, what would you say are the issues? You won't do yourself any favours if you try to pretend Rust is perfect.
The learning curve for manual memory management in C is a major issue, but not the principal of manual memory management itself.
The only people who have issues are people who've used Rust for less than a week and still do not understand the basic rules of the borrow checker. I've explained it many times to people already. Once you know the rules, it's easy peasy, and you'll never have another complaint from the borrow checker ever again.
The only improvements that I could see for Rust is landing non-lexical borrows, macros 2.0, and faster compile times, albeit compile times are largely fixed now. A 100K combined LoC project can easily compile a release build using 1 core in 3 minutes or less.
Let's be careful not to overstate Rust's benefits and understate Rust's costs. Of course, I do happen to think the benefits are overwhelming compared to the costs. :-)