5 ms·

> As the author points out, if you’re used to writing C or C++, it’s going to take a while before responding to the borrow checker is second nature I see these

by epage 8y ago

> As the author points out, if you’re used to writing C or C++, it’s going to take a while before responding to the borrow checker is second nature I see these comments and it feels so foreign to my experience. The borrow checker was second nature to me because of my C++ experience. These were things I already had to juggle mentally. On rare occasions, it complained about something that I could prove was valid but I understood why it couldn't tell. Usually, when I hit it, it is because I forgot a case and am grateful for it. I know of at least one optimization I've made that I would never have bothered with without the borrow checker. It would have been too much bother for me to reason about everything. Even if I did, it would have been even worse to maintain.

rcxdude 8y ago
I think it depends on your level of C++ experience. Very experienced and effective C++ developers often will have internalized a lot of the rules of the borrow checker, possibly without consciously realising it. Less experienced developers will not have run into the problems caused by not following these rules because a lot of the time you can get away with it, and/or they haven't associated these habits with the bugs they tend to cause. It's a fairly common theme for people who have learnt rust to report that it has made them a better C++ developer.
ilovecaching 8y ago
Personally, I had the same experience as you did, except the borrow checker also helped me unlearn a few bad habits and gave me a deeper understanding of references. Now it is second nature, and I rarely every fight the borrow checker. I think part of it is planning ahead.
pjmlp 8y ago
Were you trying to write GUI code? Because of my experience it was also plain sailing, while doing the tutorials and exercises from the books I bought. Then I tried to make a GUI application in Gtk-rs and had lots of fun with event handler callbacks, which are the main reason why Relm was created.
- epage 8y ago
  No, I have not written a GUI in Rust yet. I've been doing libraries and CLIs so far. But I find the standard approaches to GUI broken: inheritance and shared mutable state. i think Rust does a service by highlighting the brittleness of this pattern via syntax / libraries. I've not dealt with elm-like GUIs. Probably my natural inclination would be to use an actor framework. And to be clear, I am speaking from having written non-trivial GUIs with both GTK and Qt (I miss the Maemo days).

by epage 8y ago

rcxdude 8y ago

I think it depends on your level of C++ experience. Very experienced and effective C++ developers often will have internalized a lot of the rules of the borrow checker, possibly without consciously realising it. Less experienced developers will not have run into the problems caused by not following these rules because a lot of the time you can get away with it, and/or they haven't associated these habits with the bugs they tend to cause. It's a fairly common theme for people who have learnt rust to report that it has made them a better C++ developer.

ilovecaching 8y ago

Personally, I had the same experience as you did, except the borrow checker also helped me unlearn a few bad habits and gave me a deeper understanding of references. Now it is second nature, and I rarely every fight the borrow checker. I think part of it is planning ahead.

pjmlp 8y ago

Were you trying to write GUI code? Because of my experience it was also plain sailing, while doing the tutorials and exercises from the books I bought. Then I tried to make a GUI application in Gtk-rs and had lots of fun with event handler callbacks, which are the main reason why Relm was created.

epage 8y ago
No, I have not written a GUI in Rust yet. I've been doing libraries and CLIs so far. But I find the standard approaches to GUI broken: inheritance and shared mutable state. i think Rust does a service by highlighting the brittleness of this pattern via syntax / libraries. I've not dealt with elm-like GUIs. Probably my natural inclination would be to use an actor framework. And to be clear, I am speaking from having written non-trivial GUIs with both GTK and Qt (I miss the Maemo days).