4 ms·
> 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
by 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 agoI 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> I've seen enough people try to suggest changes to the homepage and flounder that I just have zero interest in trying. I'm guessing most of those people don't have the same level of respect within the Rust community that you do. I could be wrong, though. > It's hard to balance pithiness and precision. IMO Rust itself favors precision, so the website should as well. On the one hand, I think Rust's momentum, including adoption by big industry players, is now strong enough that the website team could afford to avoid even the slightest appearance of over-aggressive marketing. There have been successful programming languages without marketing campaigns, after all; perhaps the best example is C (unless there's some aspect of its history I don't know). On the other hand, maybe discussions on message boards like this one make this problem look more important than it is, and the website is doing the right thing. I don't know. Good points about testimonials being misunderstood and distorted. Thanks for taking time to write a thoughtful response.
- benreesman 4y agoPaul Graham has thoughts on people who “market” programming languages: http://www.paulgraham.com/javacover.html http://www.paulgraham.com/javacover.html I’m the spirit of Postel’s Law I decided to actually learn Rust well before becoming truly dedicated to clowning on super fans. I’m into basically anything if we go all out, as long as Rust is sponsored by a KPop group and a league team fuck hating: let’s make an NFT!