3 ms·

I'm interested in Rust's future, but not a Rust developer myself. The author's argument is pretty straight-forward: Rust's borrow-checker makes for complex cod

by pfraze 7y ago

I'm interested in Rust's future, but not a Rust developer myself. The author's argument is pretty straight-forward: Rust's borrow-checker makes for complex code, so you should think carefully whether your application is resource-constrained enough to merit using Rust. If not, you should consider using a memory-managed language. He's pointing this out as a contrasting point to projects rewriting in Rust, which is what naturally happens when a new language starts going down the path to becoming a Mainstream Programming Language™️. This sets up the question that I'm waiting to get answered: is Rust actually complex enough that it should be a niche PL rather than a mainstream PL? How do current Rust devs feel about that so far?

jstrong 7y ago
perhaps he should have offered even one example where the borrow checker forced a "more complex" design. over time, I've come to realize the types of design decisions the borrow checker guides you to make are excellent for producing robust, reliable software.
qchris 7y ago
I use Rust both professionally for parsing large datasets and image processing, and on most of my personal projects. I'm probably a little biased, since I both aesthetically like how Rust "feels" and that a lot of how it deals with the complexity of computers fits well with my own mental map of how computers work. Whether that's a chicken or the egg situation is up for debate... That said, I think a counter argument here comes back to they complexity budget. I don't feel like language design and borrow checker are inherently more complex, but rather that they explicitly pull out that complexity, but in a way that feels manageable. I know that that since writing more Rust, my code written in other languages like C++ or even Python have started started having patterns that I picked up from my work in Rust, and that I qualitatively feel like that has raised my code quality in those languages. I'm also definitely more aware of some of the hidden complexity in certain tasks like dealing with system paths. So at least in some degree of summary: no. I like the level of abstraction and complexity Rust has, and the mechanisms in place for dealing with that complexity have largely seemed both well thought-out and implemented such that they are accessible to a mainstream audience.
- pfraze 7y ago
  Thanks for the insight!
steveklabnik 7y ago
Personally, I find the argument too abstract. And many of the points are contrary to my actual experience. To give one concrete example, > Rust’s way of managing memory is unique and clever. Unique and clever are generally seen as good things, but in software development they usually lead to difficulties with long-term maintenance, among other issues The citations he gives are 1. a stack overflow post 2. a blog post (by an author I respect, but still) I don't think that this alone proves his point. Even if we ignore that aspect of things, Rust is by far the easiest programming language I've ever had to do long-term maintenance on. This is specifically due to the guarantees. So when I read the above, I see a very general argument, and my experience contradicts it here, so I don't really agree. I am also, of course, incredibly biased.
- pfraze 7y ago
  We'll s/biased/credible/ on this one. Can you think of any cases where he might be right? How often do you hit, for instance, "This code cleanly fit its original construction, but now I have to add some complexity for new cases, and Rust is making that harder?" Put another way, once you're familiar with the borrow checker, how often do you find yourself or your teams fighting it?
  - steveklabnik 7y ago
    It just depends. It's really hard to talk about this stuff because it's always so variable. I think that Rust tends to expose complexity in places that other languages paper over. This means that it can feel like Rust is adding complexity, but it's not really. It's surfacing the underlying complexity. This makes the end result more robust. It takes some practice, and there is the perennial question of "how long does it take to get to that point, and how much effort is it?" I think this line of questioning is more likely to be a real reason to not choose Rust, and is one of the reasons we've been trying to lower the learning curve. > Put another way, once you're familiar with the borrow checker, how often do you find yourself or your teams fighting it? Extremely rarely, if ever. It yells at you, you go "oh yeah, oops" and fix it, and move on with life. But, I should qualify that's mostly personal experience and what I hear from other folks generally and other teams at work; my team at work doesn't really write Rust, our main codebase is in Typescript and Go. I just saw this thread by the ex-CTO of Chef, it matches my experiences here: https://twitter.com/adamhjk/status/1239989909714173952 https://twitter.com/adamhjk/status/1239989909714173952

by pfraze 7y ago

jstrong 7y ago

perhaps he should have offered even one example where the borrow checker forced a "more complex" design. over time, I've come to realize the types of design decisions the borrow checker guides you to make are excellent for producing robust, reliable software.

qchris 7y ago

I use Rust both professionally for parsing large datasets and image processing, and on most of my personal projects. I'm probably a little biased, since I both aesthetically like how Rust "feels" and that a lot of how it deals with the complexity of computers fits well with my own mental map of how computers work. Whether that's a chicken or the egg situation is up for debate... That said, I think a counter argument here comes back to they complexity budget. I don't feel like language design and borrow checker are inherently more complex, but rather that they explicitly pull out that complexity, but in a way that feels manageable. I know that that since writing more Rust, my code written in other languages like C++ or even Python have started started having patterns that I picked up from my work in Rust, and that I qualitatively feel like that has raised my code quality in those languages. I'm also definitely more aware of some of the hidden complexity in certain tasks like dealing with system paths. So at least in some degree of summary: no. I like the level of abstraction and complexity Rust has, and the mechanisms in place for dealing with that complexity have largely seemed both well thought-out and implemented such that they are accessible to a mainstream audience.

pfraze 7y ago
Thanks for the insight!

steveklabnik 7y ago

Personally, I find the argument too abstract. And many of the points are contrary to my actual experience. To give one concrete example, > Rust’s way of managing memory is unique and clever. Unique and clever are generally seen as good things, but in software development they usually lead to difficulties with long-term maintenance, among other issues The citations he gives are 1. a stack overflow post 2. a blog post (by an author I respect, but still) I don't think that this alone proves his point. Even if we ignore that aspect of things, Rust is by far the easiest programming language I've ever had to do long-term maintenance on. This is specifically due to the guarantees. So when I read the above, I see a very general argument, and my experience contradicts it here, so I don't really agree. I am also, of course, incredibly biased.

pfraze 7y ago
We'll s/biased/credible/ on this one. Can you think of any cases where he might be right? How often do you hit, for instance, "This code cleanly fit its original construction, but now I have to add some complexity for new cases, and Rust is making that harder?" Put another way, once you're familiar with the borrow checker, how often do you find yourself or your teams fighting it?
- steveklabnik 7y ago
  It just depends. It's really hard to talk about this stuff because it's always so variable. I think that Rust tends to expose complexity in places that other languages paper over. This means that it can feel like Rust is adding complexity, but it's not really. It's surfacing the underlying complexity. This makes the end result more robust. It takes some practice, and there is the perennial question of "how long does it take to get to that point, and how much effort is it?" I think this line of questioning is more likely to be a real reason to not choose Rust, and is one of the reasons we've been trying to lower the learning curve. > Put another way, once you're familiar with the borrow checker, how often do you find yourself or your teams fighting it? Extremely rarely, if ever. It yells at you, you go "oh yeah, oops" and fix it, and move on with life. But, I should qualify that's mostly personal experience and what I hear from other folks generally and other teams at work; my team at work doesn't really write Rust, our main codebase is in Typescript and Go. I just saw this thread by the ex-CTO of Chef, it matches my experiences here: https://twitter.com/adamhjk/status/1239989909714173952 https://twitter.com/adamhjk/status/1239989909714173952