3 ms·

I admit that I sometimes do this myself, but it's usually a last resort when I deem that a more elegant solution would probably end up being a lot more complica

• ben-schaaf 5y ago
  > I don't find that I write Rust much differently from C++ Same here, though I do find myself deviating sometimes. Specifically there are cases in C++ where I could write code that makes less copies or handles data more efficiently but I don't because the approach would be more error prone. In rust these more risky approaches simply result in having more compiler errors instead of crashes or other runtime bugs.
• stouset 5y ago
  As a Rust proponent I’d agree with this take 100%. There are a lot of programmers who approach new languages by trying to write in the style of their previous language. That’s not really optimal, but it can get you up and running quickly producing passable results for a wide variety of (previous, next) language pairs. Rust is not one of these languages. If you don’t try to “get” Rust and continue working across the grain, you’re going to have a rough time of things. Rust brings along an entirely new concept of explicit ownership that’s implicit in other languages, and if you simply try to push forward without internalizing those restrictions (and understanding their implications on how to structure your programs), the Rust compiler will never stop pushing back against you. While there are legitimate reasons to need Rc<RefCell<_>>, to Box things, and to clone(), the vast majority of Rust code doesn’t need to fall back on them. If you find yourself instinctively and repeatedly reaching for these as a quick workaround for borrow checker complaints, it’s going to be much better in both the long and medium term to try and understand what the compiler is trying to tell you about your overall approach to design. This is, I think, the biggest area where Rust evangelists can make some big strides. There are a lot of program designs that compile just fine in other languages but that Rust rejects (or pushes back against) for Very Good Reasons. And getting new developers over that hurdle where they understand how to internalize enough about ownership upfront that they can come up with approaches that work with the grain is a hard problem, and I’m not sure how to solve it. There’s a moment where something clicks and Rust goes from being a fight against the borrow checker to something where your designs just work out of the gate and I don’t know how to get that click to happen quicker.
• iudqnolq 5y ago
  > IMO Reference counting and cloning should be the exception, not the rule, and I'd go as far as saying that if you find yourself cloning and boxing data all over the place in your Rust application you're either working on a very atypical application or you're doing it somewhat wrong. I strongly disagree. For example, I'm working on a project that shells out to a command line program to get a graph structure, and then computes things based on that structure. I want the code that traverses the graph to be efficient, but a handful of clones is trivial compared to opening a subprocess. In my case the clones are in the constant part of the big O. Sometimes clones can let you have a more efficient algorithm as well. Reference counting is pervasive in async primitives, and (for very specific io-bound usecases) async can sometimes be more efficient. It comes down to knowing your domain, althorighms, data, constraints, etc. and picking the right choice. I don't think you can say Arc is always a sign of a mediocre programmer. I've never programmed embedded, but it makes sense that you've got strong memory constraints. One thing I like about Rust though is that there's a strong culture that just because you have to walk uphill through the snow on a tiny device doesn't mean you get to look down on those of us who get to run our code on a server.