6 ms·

OK, so I'll respond to what I see are the two "chunks" of your comment. The first chunk I see as "there are too many people zealously advocating for Rust." And

OK, so I'll respond to what I see are the two "chunks" of your comment. The first chunk I see as "there are too many people zealously advocating for Rust." And the second chunk is, "say Rust has worse backward compatibility policy than C++, Python and Haskell instead of linking to an RFC." (I am "quoting" you here with the intent of phrasing my own internal understanding of what you're saying. The benefit of that is that if I misunderstood you, then perhaps you can correct that. It might make the conversation easier.) So to the first chunk: absolutely. I don't really know what to do about it. You can find oodles and oodles of people with persistent misunderstandings about Rust and various aspects on both sides. Lots of people overstate what it can do, and lots of people understate what it can do. The overstatements tend to look like this: * The Rust Project, as a whole, will literally never break your code. * Rust's safety means that "once you compile it, it works." (A funny meme that I remember from my Haskell days. But now people also use it when talking about Rust.) * Rust makes undefined behavior completely impossible. Those are all overstatements. The most persistent understatement I see is, "well if Rust has 'unsafe' and everything boils down to using 'unsafe', then what's the point of Rust at all?" I've spent time correcting all of these misunderstandings in various online forums. I honestly do not know what the root of it is. I do not see people involved in the Rust project trying to push the overstatements. Most of the documentation materials I see maintained in the Rust project are sufficiently nuanced. It is just not obvious to me where "the Rust project is failing at communication" ends and "communication is heavily lossy and the general population is just going to fundamentally misunderstand most things because nuance has been stripped by the time the content filters down to them" begins. I have my own mini-problems with this and ripgrep for example. Just the other day someone was trying to say that ripgrep was a "grep replacement" and so wasn't as suitable to code search as ack or ag. Like... wut? I don't see how it's possible to even skim ripgrep's README for less than 20 seconds and come away with that misunderstanding. Upon further prodding, I discovered: * Their google-fu failed them. * They "just assumed" from the name, because "grep" was in it. * They were still a student and ultimately admitted they should have said they weren't "sure." One of the most important lessons anyone can learn---especially an engineer---is to be clear about their certainty. I think it is just a fact of life that people aren't because they don't want to or maybe more likely, never learned the skill. (And it's even worse outside of engineering.) We could "fix" this by ensuring that everyone commenting online was always labeled with their experience level in a way that was true 100% of the time. Imagine if we could do that, hah. (And if we could, I'm not saying we should, but let's indulge.) I sometimes wonder just how strong the inverse correlation is between "says obviously wrong things with certainty" and "years of experience." Anyway... sorry... Got off on a bit of a ramble there. Bottom line is that I agree it's a problem, but I don't know how it can be fixed. And there are other factors in play here, given that, ultimately, Rust really is trying to unseat some very old and very entrenched technologies. It is a complex sociological and cultural process. OK, as to your second chunk... I want to quote the comment I was originally responding to: > As always when I see this claim, I feel compelled to point out that the Rust team’s claim is simply not true, since they don’t regard adding new functions to existing impls in the standard library as a breaking change, even though it can make working code stop compiling or even do something different. I am pretty sure that the ideal answer to this comment has to include some mention of our API evolution RFC. It is essential context for how we make decisions. What is less clear is that we don't really have (AFAIK) a solid written document describing how we deliberate on things that are permissible under API evolution, but break code in practice. There is a lot of grey area there. If the breakage is super rare, we might go fix that crate or issue a deprecation notice, wait some time and then make the change. That has happened. If the breakage is not so rare, then it's nearly guaranteed that we'll just drop it. Or find a way to smuggle it in over an edition boundary so that there is no breakage at all (you have to opt into it, and new Rust compilers still support the old behavior on the old edition). I also note that in your second chunk, you go from talking about "in C++/Python/Haskell, decades old code still builds and works." But you then go on to talk about semantic stability in Rust. Why not compare apples with apples? Rust doesn't have decades of existence to leverage here. To be quite honest, I would be very interested in analysis of actual decades old code of C++, Python and Haskell. For Python at least, we're talking about pre-2.7. And there were definitely breaking changes introduced in 2.7 when compared to 2.6. And that's just one release. For C++, they break stuff too! For example: https://stackoverflow.com/questions/6399615/what-breaking-changes-are-introduced-in-c11 https://stackoverflow.com/questions/6399615/what-breaking-ch... I really truly believe that Rust is no worse than other programming languages when it comes to backcompat. More than that, I think it's better than most.

mwcampbell 4y ago
> Most of the documentation materials I see maintained in the Rust project are sufficiently nuanced. I appreciate that you likely don't want to name and shame the documentation materials that aren't sufficiently nuanced, but do you think that any appreciable portion of the problem of over-zealous advocacy originates from those materials?
- burntsushi 4y ago
  I honestly don't know. If there were examples I had at the top-of-mind, I would probably cite them. remembers that the rust-lang.org web site changed quite a bit a few years ago and checks it again... Yeah, there are some broad statements on the Rust home page that, if it were fully 100% up to me, would either not be there or be re-phrased. Unfortunately, commentary on the Rust homepage tends to get sucked into a black hole for reasons that I am not going to elaborate on. (And I'm not trying to say I 100% know all of the reasons. Some elude me.) It is definitely a problem. I don't know how to fix it. I've seen enough people try to suggest changes to the homepage and flounder that I just have zero interest in trying. The other problem is that most of the re-phrasings I can come up with would use more words than what is there. It's hard to balance pithiness and precision. Other than that one though, nothing is really coming to mind. The other issue, perhaps, is testimonials. People can write their own lived experience, and sometimes it looks like a broader claim than it is. For example, I'd say this is generally true of my experience: > Writing Rust is a very liberating experience, particularly compared to C, because I never have to worry about undefined behavior. Here, "never" is hyperbole. It would be more precise to say, "99% of the time, I do not have to worry." For many people, it might actually be 99.9% of the time. It is empirically rare for me to need to write `unsafe` in application code, for example. As a similarish example, I use Go at work, and we just never ever use the `unsafe` package. That's not an apples-to-apples comparison, but it's not totally nutso either. The issue here is that there are some people who use Rust who have to worry about UB quite a bit because that's the nature of the work they do in the context of Rust. So my experience is not universal. Even myself, I would guess that I use `unsafe` quite a bit more than the median programmer, because I tend to work on performance critical core libraries. But even then, it's a vast minority of the time. So now let's say someone reads my experience and then goes and tells their friend: > Hey have you seen Rust? It makes it completely impossible to have undefined behavior. Now we've gone from lived experience to a claim about the language. Rust's goal isn't to make undefined behavior literally impossible. Rust's goal is to make it possible to build safe abstractions that are themselves impossible to use in a way that leads to undefined behavior. This is a deeply nuanced thing and it is super easy for it to get dropped from the context when discussing the language. Yet, the two claims are really quite different. And if the wrong claim is repeated in the wrong context, it really looks like over-promising and marketing-speak, which, rightfully, give people a bad taste in their mouths. I'll again invoke ripgrep here, which has its own mini-problem with this too. The silver searcher does too. How many times do you hear people say things like, "grep took 2 hours to search my files, but ripgrep did it in 5 seconds!" Or "ripgrep is sooooo much faster than grep." Like, there are sooooo many problems with saying that! * Which grep? The performance profiles of GNU grep and BSD grep are radically different. * Is this an apples-to-apples performance comparison? * Is the comparison actually about the user experience? (ripgrep might skip that 10GB build artifact in your directory tree where as grep might not. So, if ripgrep isn't doing the same task, is it really fair to say it's faster? Well... yes, it is and no, maybe it isn't. Really depends on the context.) * They might just have a measurement error. Maybe they tried grep first, which ended up measuring mostly disk I/O. Then tried ripgrep while everything was still warm in their file system cache. Oops. Benchmarking greps is hard. What to do? I dunno. I try to fix things like this, but like, I can't respond to every tweet that says, "wow ripgrep was so much faster than grep."

mwcampbell 4y ago

> Most of the documentation materials I see maintained in the Rust project are sufficiently nuanced. I appreciate that you likely don't want to name and shame the documentation materials that aren't sufficiently nuanced, but do you think that any appreciable portion of the problem of over-zealous advocacy originates from those materials?

burntsushi 4y ago
I honestly don't know. If there were examples I had at the top-of-mind, I would probably cite them. remembers that the rust-lang.org web site changed quite a bit a few years ago and checks it again... Yeah, there are some broad statements on the Rust home page that, if it were fully 100% up to me, would either not be there or be re-phrased. Unfortunately, commentary on the Rust homepage tends to get sucked into a black hole for reasons that I am not going to elaborate on. (And I'm not trying to say I 100% know all of the reasons. Some elude me.) It is definitely a problem. I don't know how to fix it. I've seen enough people try to suggest changes to the homepage and flounder that I just have zero interest in trying. The other problem is that most of the re-phrasings I can come up with would use more words than what is there. It's hard to balance pithiness and precision. Other than that one though, nothing is really coming to mind. The other issue, perhaps, is testimonials. People can write their own lived experience, and sometimes it looks like a broader claim than it is. For example, I'd say this is generally true of my experience: > Writing Rust is a very liberating experience, particularly compared to C, because I never have to worry about undefined behavior. Here, "never" is hyperbole. It would be more precise to say, "99% of the time, I do not have to worry." For many people, it might actually be 99.9% of the time. It is empirically rare for me to need to write `unsafe` in application code, for example. As a similarish example, I use Go at work, and we just never ever use the `unsafe` package. That's not an apples-to-apples comparison, but it's not totally nutso either. The issue here is that there are some people who use Rust who have to worry about UB quite a bit because that's the nature of the work they do in the context of Rust. So my experience is not universal. Even myself, I would guess that I use `unsafe` quite a bit more than the median programmer, because I tend to work on performance critical core libraries. But even then, it's a vast minority of the time. So now let's say someone reads my experience and then goes and tells their friend: > Hey have you seen Rust? It makes it completely impossible to have undefined behavior. Now we've gone from lived experience to a claim about the language. Rust's goal isn't to make undefined behavior literally impossible. Rust's goal is to make it possible to build safe abstractions that are themselves impossible to use in a way that leads to undefined behavior. This is a deeply nuanced thing and it is super easy for it to get dropped from the context when discussing the language. Yet, the two claims are really quite different. And if the wrong claim is repeated in the wrong context, it really looks like over-promising and marketing-speak, which, rightfully, give people a bad taste in their mouths. I'll again invoke ripgrep here, which has its own mini-problem with this too. The silver searcher does too. How many times do you hear people say things like, "grep took 2 hours to search my files, but ripgrep did it in 5 seconds!" Or "ripgrep is sooooo much faster than grep." Like, there are sooooo many problems with saying that! * Which grep? The performance profiles of GNU grep and BSD grep are radically different. * Is this an apples-to-apples performance comparison? * Is the comparison actually about the user experience? (ripgrep might skip that 10GB build artifact in your directory tree where as grep might not. So, if ripgrep isn't doing the same task, is it really fair to say it's faster? Well... yes, it is and no, maybe it isn't. Really depends on the context.) * They might just have a measurement error. Maybe they tried grep first, which ended up measuring mostly disk I/O. Then tried ripgrep while everything was still warm in their file system cache. Oops. Benchmarking greps is hard. What to do? I dunno. I try to fix things like this, but like, I can't respond to every tweet that says, "wow ripgrep was so much faster than grep."