5 ms·
Could you please tell more about borrow checker issues?
by EugeneOZ 10y ago
Could you please tell more about borrow checker issues?
- ZenoArrow 10y agohttp://softwaremaniacs.org/blog/2016/02/12/ownership-borrowing-hard/en/ http://softwaremaniacs.org/blog/2016/02/12/ownership-borrowi...
- EugeneOZ 10y agoQuote: "Rust's borrow checker is a wonderful thing that forces you into designing code to be more robust. But as it is so unlike anything you're used to, it takes time to develop a certain knack to work with it efficiently." I don't think it's description of an issue.
- ZenoArrow 10y ago>"I don't think it's description of an issue." It is if it drives potential community members away.
- mmstick 10y agoNo one's being driven away. Only people who had no intention on trying Rust are complaining about it.
- ZenoArrow 10y agoThere's plenty of comments about it in the Rust subreddit, coming from people who have tried it. 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.
- EugeneOZ 10y agoBorrow checker learning curve is an issue, of course. But not checker itself.
- ZenoArrow 10y agoYou do realise you've wasted both my time and your own. If you thought about it from the start, it's obvious that I was referring to the learning curve. All facets of all Turing-complete languages are useful once you've overcome the learning curve. What varies is the length of time needed before you become proficient in using it. For another example... The learning curve for manual memory management in C is a major issue, but not the principal of manual memory management itself.
- mmstick 10y agoI've been writing software exclusively in Rust since the 1.0 release. I have no issues with the borrow checker, personally. I haven't seen the borrow checker mentioned as an issue on the Rust subreddit, which I frequent. 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.
- azdle 10y agoI assume they're talking about the fact that basically everyone that learns Rust goes through a period of "fighting the borrow checker". Part of the way that rust ensures memory safety is by preventing you from doing things that it can't prove are safe to do. For people coming from languages like C or C++ they've been able to get away with doing things that are probably unsafe but that work either through luck or very careful planning. But since the borrow checker can't prove that some of these tricks are safe it will just say "no" and fail to compile. 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.
- allengeorge 10y agoHonestly, I found dealing with generics worse than the borrow checker. Since the compiler wants everything to be sized, code that I think should work (i.e. using generics and traits) will sometimes just not compile. In fact - I'm dead in the water facing an issue like that right now. That is, by far, the most frustrating thing in using Rust.
- steveklabnik 10y agoHave you asked for help on one of the various forums? If something is leaving you dead in the water, I'd like to help you fix that.
- EugeneOZ 10y agoJust ask for help in IRC or your local Rust community and you'll get help. If you want - post here link to gist.github and I'll try to help.
- burntsushi 10y agoCan you describe the issue? Perhaps someone can help. 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.