27 ms·

"Anti-rust sentiment"? I'm a Rust user, a fan of the language, and I believe it's a great step forward for systems programming. However, it's kind of ridiculo

by pcstl 6y ago

"Anti-rust sentiment"? I'm a Rust user, a fan of the language, and I believe it's a great step forward for systems programming. However, it's kind of ridiculous how on any thread about Rust, anyone who brings up criticism, no matter how valid, gets downvoted into oblivion. Just look at what happened to the comments critical of Rust on this post. The Rust community really needs to take care not to become an echo chamber.

rvz 6y ago
> The Rust community really needs to take care not to become an echo chamber. Exactly. The language has been proven to be stable, however a valid argument is the unsoundness risks of a project when they begin to depend on lots of third-party crates. The moment one imports a crate or third party dependency into their project, unless the dependency explicitly specifies the lack of unsafe{}, all bets are off on the 'safety guarantees', especially when 'that crate' is used in multiple projects.
- staticassertion 6y ago
  "All bets are off" is an insane way to characterize this. IF a project is 99.99% safe code and has one unsafe dependency that is a massive difference from a project that is 100% unsafe. The surface area of the project that may be vulnerable is going to be relatively tiny. As for an echo chamber, yeah the Rust community downvotes way too much. I find myself upvoting just to counter it. But the downvoted comments here are legitimately bad. Someone being pedantic about the 70%, and being wrong, and another person calling this propaganda.
  - zozbot234 6y ago
    > "All bets are off" is an insane way to characterize this. Well, it depends. If the unsafe{} code is also unsound, then "all bets are off" is quite correct because you can't assume memory safety or lack of UB, even in your own code. In practice, you can use cargo-geiger to warn about crates that internally rely on unsafe code, and cargo-audit will warn about known security issues (including but not limited to unsoundness and memory-unsafety).
    - staticassertion 6y ago
      > then "all bets are off" is quite correct because you can't assume memory safety or lack of UB, even in your own code. The problem with "All bets are off" is it's not meaningful. What does that mean? It's so vague. Lots of unsafe code is safe. Lots of UB is not exploitable. I can link to a vulnerable crate and not be vulnerable. Can there be an exploitable bug in rust code? Yeah, sure. But saying "all bets are off" gives the impression of "why even bother if you link to unsafe code", which is absurd. Yeah, we should strive for more safe code, audit unsafe code, be very cautious about using it, but "all bets are off" come on.
      - saagarjha 6y ago
        Well, there's two interpretations of "all bets are off". One is the runtime one, which is if you have a bug in unsafe code, then it is possible that all the other code in your program is safe but you're still totally out of luck because it can invalidate every guarantee. However, from an auditing perspective, the only code you need to look at for memory safety issues is that particular snippet, so you're in a much better position from that perspective.
      - nilkn 6y ago
        > Lots of unsafe code is safe. This seems like a weird statement to make to me when defending Rust simultaneously. The whole selling point of Rust is that it's supposed to let you write provably safe code. When "unsafe" is used, what you're writing can no longer be proven as safe by the compiler. Maybe you've convinced yourself it's actually safe via some other argument, but people have been convincing themselves that their code is memory safe for decades and they're often wrong. More insidiously, relying on anything in Rust that uses "unsafe" makes it seem like the compiler is proving your own code is safe, but that is no longer true. With that said, I don't really disagree with what I think your main point is. But seeing unsafe code in Rust is similar to seeing unsafePerformIO in Haskell libraries. Both of these are much more common than the languages' respective evangelists would have you believe, and at some point it actually does start to call into question whether the languages are successful at their basic design goals. (Spoiler: I believe that they are successful more than they are not, and even in the face of the proliferation of "unsafe" code in both languages, they're still worth using.)
  - bjourne 6y ago
    Rust doesn't check for numerical over and underflows unless you run in debug mode which almost no one does because it is about two times slower than release mode. I.e. Rust doesn't live up to the safety standards many programmers coming from dynamic languages are used to where over and underflows are checked. Many people in the Rust community appear to be unaware of this. Which is actually a big deal. Many of the bugs with the most catastrophic consequences are caused by over and underflows. Consider for example a gas pedal indicator kept as an unsigned that underflows causing the indicator to reach its maximum value. If safety was my primary concern, I wouldn't choose C++ but I wouldn't choose Rust either.
    - smitop 6y ago
      You can pass "-C overflow-checks=on" to rustc to generate an optimized build with over/underflow checks enabled, even in a release build. Also, note that over/underflow behavior is defined to always be two's compliment wrapping when overflow checks are disabled.
    - staticassertion 6y ago
      > Rust doesn't check for numerical over and underflows unless you run in debug mode which almost no one does because it is about two times slower than release mode. Totally, I wish Rust could express over/underflows better! > Rust doesn't live up to the safety standards many programmers coming from dynamic languages are used to where over and underflows are checked. > Rust doesn't live up to the safety standards many programmers coming from dynamic languages are used to where over and underflows are checked. Yeah, that's possible. Thought it won't lead to unsafety, it is definitely a gotcha. > Many people in the Rust community appear to be unaware of this. Which is actually a big deal. Maybe, not sure. > If safety was my primary concern, I wouldn't choose C++ but I wouldn't choose Rust either. Really depends on the goals and constraints, of course. I'd be really concerned about using rust where an integer overflow could kill someone. I'd be really happy to use rust where a program crashing is totally acceptable, but exploitability isn't.
    - acje 6y ago
      Rust is memory safe, not infallible. Catching more runtime errors is a something rust can improve on. Erlang being one example of a strategy.
- phkahler 6y ago
  IMO crates are the biggest danger to Rust. It may very easily turn into the next NPM.
  - entha_saava 6y ago
    Except npm has order of magnitude more users.
  - saagarjha 6y ago
    I think an even more problematic corollary is the desire to put nothing in the standard library, which cause the proliferation of crates that are the "standard" way of doing things but don't really have the guarantees/benefits that come with being part of "the" standard library.
    - zozbot234 6y ago
      It would indeed be nice to have some sort of middle ground, where a selection of outstanding-quality crates can be officially "endorsed" by the Rust development team, but the endorsement can be withdrawn freely if something better comes along. C++ has something like this via Boost, and Haskell has their Haskell Platform, so it's not a new idea.
      - steveklabnik 6y ago
        The Rust teams do maintain some crates outside of the standard library.
        nicoburns 6y ago
        I think the proposal is specifically to bless a set of crates (that may include those developed by Rust teams, but probably also others such as regex). Being in std implies some kind of quality standard, but it also implies no backwards incompatible changes. A set of libraries blessed by a trusted group could give you the quality standard without constraining backwards compatibility.
- chc 6y ago
  This is true, but it's also something the Rust community discusses all the time, along with what they can do about it. It seems like a huge leap to the conclusion that the Rust community is an echo chamber because some middlebrow dismissals got downvoted on Hacker News.
  - entha_saava 6y ago
    Even legitimate criticisms get downvoted or countered with dishonest marketing speech like 'borrow checker doesn't matter'.
- renewiltord 6y ago
  "All bets are off" is not an engineering way to look at the problem imho. You alter your risk tolerance with the benefit gained. It's just trade-offs and the ability to do that is good. I'm not going to argue you should use rust or not use rust but I think the state space is not binary and people reading will benefit from that.
guug 6y ago
> The Rust community really needs to take care not to become an echo chamber. This is a natural consequence of the restrictive rules imposed on the rust community.
- smhmd 6y ago
  > the restrictive rules imposed on the rust community. Can you be specific?
  - Lammy 6y ago
    Not to speak for GP, but perhaps they mean https://www.rust-lang.org/policies/code-of-conduct https://www.rust-lang.org/policies/code-of-conduct ? > Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer. > Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works. I am not "anti-CoC" but I do see how the particular wording of this one could be interpreted to silence pretty much any technical discussion that someone doesn't like.
    - staticassertion 6y ago
      I think many in the rust community would feel the opposite. Technical conversations, especially tough ones, are far easier when you come in with some enforced civility. More people can contribute their differing technical opinions, not fewer.
      - asjw 6y ago
        I work with autistic people. Not as a doctor, but as software engineer, I teach programming to autistic people that work in the field and are hired because they are autistic, not despite it. This particular company looks for them, trains them and put them to work on software projects, just like any other software house would do. One thing they are often bad at is "enforced civility" not because they are uncivil people, but because their though process is different from ours and forcing them to adhere to some rigid form of presenting opinions that has no other use than enforcing a rule just for the sake of it, bores them in the best of cases, makes them angry in others, but makes uncomfortable in general. You shouldn't decide how people in a community interact with the community, you should value their contributions and just that. Civility can be enforced of course, but post-facto, after further investigation. Doing it preemptively in the COC sounds bad to me. But I could be wrong. BTW I have interacted with Rust community and have been downloaded every time I've said something on the line of "maybe it's not the silver bullet" So my experience says less people can contribute.
nilkn 6y ago
Rust as a language is great and at this point I'd much prefer to use it over C or C++ any day of the week if the application and context permit. However, I don't think I'd ever want to participate in the Rust community or really even have any contact with it. Everything I've seen of Rust's community has been deeply toxic and hostile to anyone who falls short of worshipping the language and aggressively promoting and defending it at every chance.
- jeffdavis 6y ago
  I think this is a combination of two things, and is true of many new programming platforms (languages, etc.). 1. If the tech hasn't made full contact with reality yet. For instance, there aren't a diverse set of large projects written in rust yet, so it's a little easier to imagine that it's perfect. 2. We should acknowledge that technology choices have a big impact on one's career. Sure, we are all software engineers that could work in a lot of environments; but we are simply more productive in the ones where we have some experience/depth. If someone is learning rust today, in many respects that's a bet, and they (subconsciously or consciously) have a vested interest in rust's success. More experienced people will usually have a more balanced risk portfolio, spread between proven tech and a few up-and-coming technologies. But for people earlier in their career, it might be a pretty major bet for them.
- techntoke 6y ago
  That is how the Mozilla community works and the kind of people they attract.
  - meh2frdf 6y ago
    This was my opinion too, might be a generalisation, yet it is the impression I and it would seem others have!
- Scarbutt 6y ago
  Then don't come near the Clojure community either, that's the most cultist one I have encountered.
uluyol 6y ago
I think this will get better as Rust becomes more mainstream. At the moment, I would guess that most developers who use rust do so by choice. By contrast, many developers who use C++, Java, JS, or even Go (see docker/kubernetes ecosystem) have little say in the matter. It's not that people don't like these languages, it's that they've been successful enough that some people, who aren't crazy about them, are writing code using them.
- entha_saava 6y ago
  It seems to me some people are genuinely excited too much about it and some people are trying to show off that a 'hard' language is easy for them.
dijit 6y ago
> anyone who brings up criticism, no matter how valid, gets downvoted into oblivion. When I made this comment there was nothing I could call "valid" criticism. There are valid criticisms though; Lack of dynamic linking and immaturity (and most crates only building in the nightly channel, and not easily knowing if there was a version buildable on stable) are things I can think of as large weaknesses. I know these and I'm not a full time rust programmer.
- zozbot234 6y ago
  Dynamic linking is quite possible. You have to use the C ABI however when interfacing with code that's not part of the build.
  - im_down_w_otp 6y ago
    We do this _all the time_ as we write almost all of our software in Rust, but lots of it is for use with/in embedded systems developed in C. It's true that you can mate up to C by exporting the C ABI everywhere. This isn't a free lunch though. There are annoying and/or weird side-effects you sometimes have to deal with when leaning heavily into doing this.
    - andrekandre 6y ago
      > This isn't a free lunch though. There are annoying and/or weird side-effects you sometimes have to deal with when leaning heavily into doing this. as a person not super-experienced in rust, im curious what kind of side-effects? binary size bloat?
  - bjourne 6y ago
    That works in theory but often not in practice. The problem is that many C libraries keep their API backwards compatible but not their ABI. For example, a function might become a macro or the size of a struct might change. It is possible to keep the ABI backwards compatible by practicing good C hygiene, but many library authors doesn't know how. Especially when it comes to Windows which is a platform most C library authors are not intimately familiar with.
iphone_elegance 6y ago
What part of the Rust community are we talking about here the parts I've interacted with (mostly a local meetup and the rust discord) have been great and don't feel like an echo chamber do you just mean reddit and hacker news posters because I find calling that part of the community pretty absurd that's just lowest common denominator internet yelling
deleted 6y ago
[deleted]
IshKebab 6y ago
> on any thread about Rust, anyone who brings up criticism, no matter how valid, gets downvoted into oblivion. Just look at what happened to the comments critical of Rust on this post. That's just not true.
derefr 6y ago
What would you have happen instead? IMHO, on an ideal platform for debate, the audience's experience of the debate should itself resemble the statistical distribution of opinions held by the debaters. I.e., if 80% of people think X while 20% of people think Y, then comments saying Y should not make up 90% of the debate by any metric (number, word-count, above-the-fold representation, etc.) If Y did take a majority share by any metric, that'd be a misrepresentation of the debate, that is likely to cause the audience to come away with a misunderstanding of the issue. I don't know how close we are to an "ideal platform for debate" on HN (probably not very)—but I feel like a certain degree of people reflexively downvoting contrarian opinions (no matter the subject) probably bring us closer, not further, from that point. Contrarian opinions should not be presented as if they were orthodox opinions. They should be given some representation—I'm not advocating for censorship—but they should only be highlighted in any algorithmic way, to the exact degree that they're recognized as something some appreciable group of people really believes.
- pasabagi 6y ago
  I think this is wrongheaded, for the simple reason that whether an idea is contrarian or not is irrelevant to its merit as an idea. Misrepresentation is only possible through sophistry, not through volume, or even placement. Therefore, it makes sense to downvote only things that are 'sophist', in the sense that they contain no kernel of communication, but rather, just obscure or muddy - not things that are contrarian. Indeed, to do so is in itself an attempt to cloud and thwart communication, as you're manipulating placement and representation to make arguments less or more present, independent of their actual content.
  - derefr 6y ago
    This presumes that people have infinite time and motivation both to debate, and to read the ensuing infinite debate. Rhetoric works to win debates because debates are time-limited (and the audience's attention is both time- and attention-limited), and so you can win just by e.g. preventing your opponent from ever getting a word in edge-wise, or forcing them to answer for trivial side-issues and therefore never have time to say what they really want to say; etc. What I'm railing against here is the https://en.wikipedia.org/wiki/False_balance https://en.wikipedia.org/wiki/False_balance: the rhetorical rearrangement of non-equal evidence into a debate presented to the audience as if each side had equal support behind it. And, make no mistake, that sort of rhetorical rearrangement is what discussion forums with comment voting are doing when the community rearranges the comments with upvotes/downvotes: they're curating which comments appear first (and thus which comments appear at all, to those without interest in reading the whole page.) They're changing the impression of aggregate weight-of-evidence someone gets by skimming the debate. But my claim is that this is not a bad thing, when it is done in the goal of presenting the debate accurately. If one side of a debate has little evidence, but more voices, those voices should be rhetorically damped down to compensate, until the force of their combined voice matches the volume of the evidence on their side. That is the proper goal of editorial curation in e.g. news journalism: to let authoritative primary sources speak loudly, secondary sources quietly, and kooks and rumormongers not-at-all. And it should, IMHO, be the proper goal of a community's editorial curation of a comments section, as well.
yepthatsreality 6y ago
I think the downvoting is pretty ubiquitous across HN now-a-days. This will also happen with any criticism of Apple, for example. Most of HN is an echo chamber as evidenced by the often off topic posts and discussion that reach the front page. I still come here for insight but I rarely have in-depth discussions here because HN and the crowd simply no longer cater to that kind of discourse for the most part. This is probably due to its increased popularity.
- ahnick 6y ago
  where do you go instead?
  - yepthatsreality 6y ago
    I just started having the conversations with my peers and colleagues instead. The net benefit of getting upvoted here is minimal and the social/networking aspects as well. In person convos really can be much more rewarding and fruitful because you can focus it rather than post on HN and some person comes along who is offended can derail and kill the conversation. I’m honestly more jaded about online interaction than most though.
    - h0p3 6y ago
      If you ever need a penpal, hit me up.
  - madushan1000 6y ago
    manyverse! https://www.manyver.se/ https://www.manyver.se/
JoshTriplett 6y ago
I'm one of the leads of the Rust language and community, and we absolutely welcome constructive criticism in many different forms. That's part of how we improve the language. I regularly upvote comments that point out things Rust needs to improve, as well as linking them from appropriate github issues or Zulip discussions. The whole "RESF" thing is not in any way welcomed by Rust community and governance folks. It's not funny, it's harmful, and anyone posting it is doing a disservice to the language they purport to support. To anyone reading this: please don't downvote constructive criticism of Rust. Save your downvotes for the comments that wish Rust wasn't as welcoming to everyone. ;)
- blargmaster33 6y ago
  There are only two genders
- afiori 6y ago
  What does RESF stand for? I know of "Rust Evangelism Task Force" and I am trying to match against "Rewrite Everything ..." or similar, but I am lost...
  - Teknoman117 6y ago
    Same thing, "Rust Evangelism Strike Force". I'm fairly certain it's a meme.
  - deleted 6y ago
    [deleted]
  - jonquark 6y ago
    I had to Google to find out... Rust Evangelism Strike Force https://twitter.com/rustevangelism https://twitter.com/rustevangelism
- chongli 6y ago
  constructive criticism in many different forms The thing about constructive criticism, when it comes to something like programming language design, is that its usefulness varies inversely with the importance of its aim. Core features of the language are highly important (obviously) but criticizing them is not very useful since they're highly unlikely to change. Thus, only the most peripheral and superficial parts (as well as new additions) are subject to valid, constructive criticism. People who have criticism for (or are otherwise skeptical of) the core parts of Rust are not being constructive, then, and so these fights can break out.
bt4u2 6y ago
The community is why I, and a lot of people I know, won't touch Rust. It should rarely be about that but Rust is an extreme example

by pcstl 6y ago

rvz 6y ago

> The Rust community really needs to take care not to become an echo chamber. Exactly. The language has been proven to be stable, however a valid argument is the unsoundness risks of a project when they begin to depend on lots of third-party crates. The moment one imports a crate or third party dependency into their project, unless the dependency explicitly specifies the lack of unsafe{}, all bets are off on the 'safety guarantees', especially when 'that crate' is used in multiple projects.

staticassertion 6y ago
"All bets are off" is an insane way to characterize this. IF a project is 99.99% safe code and has one unsafe dependency that is a massive difference from a project that is 100% unsafe. The surface area of the project that may be vulnerable is going to be relatively tiny. As for an echo chamber, yeah the Rust community downvotes way too much. I find myself upvoting just to counter it. But the downvoted comments here are legitimately bad. Someone being pedantic about the 70%, and being wrong, and another person calling this propaganda.
- zozbot234 6y ago
  > "All bets are off" is an insane way to characterize this. Well, it depends. If the unsafe{} code is also unsound, then "all bets are off" is quite correct because you can't assume memory safety or lack of UB, even in your own code. In practice, you can use cargo-geiger to warn about crates that internally rely on unsafe code, and cargo-audit will warn about known security issues (including but not limited to unsoundness and memory-unsafety).
  - staticassertion 6y ago
    > then "all bets are off" is quite correct because you can't assume memory safety or lack of UB, even in your own code. The problem with "All bets are off" is it's not meaningful. What does that mean? It's so vague. Lots of unsafe code is safe. Lots of UB is not exploitable. I can link to a vulnerable crate and not be vulnerable. Can there be an exploitable bug in rust code? Yeah, sure. But saying "all bets are off" gives the impression of "why even bother if you link to unsafe code", which is absurd. Yeah, we should strive for more safe code, audit unsafe code, be very cautious about using it, but "all bets are off" come on.
    - saagarjha 6y ago
      Well, there's two interpretations of "all bets are off". One is the runtime one, which is if you have a bug in unsafe code, then it is possible that all the other code in your program is safe but you're still totally out of luck because it can invalidate every guarantee. However, from an auditing perspective, the only code you need to look at for memory safety issues is that particular snippet, so you're in a much better position from that perspective.
    - nilkn 6y ago
      > Lots of unsafe code is safe. This seems like a weird statement to make to me when defending Rust simultaneously. The whole selling point of Rust is that it's supposed to let you write provably safe code. When "unsafe" is used, what you're writing can no longer be proven as safe by the compiler. Maybe you've convinced yourself it's actually safe via some other argument, but people have been convincing themselves that their code is memory safe for decades and they're often wrong. More insidiously, relying on anything in Rust that uses "unsafe" makes it seem like the compiler is proving your own code is safe, but that is no longer true. With that said, I don't really disagree with what I think your main point is. But seeing unsafe code in Rust is similar to seeing unsafePerformIO in Haskell libraries. Both of these are much more common than the languages' respective evangelists would have you believe, and at some point it actually does start to call into question whether the languages are successful at their basic design goals. (Spoiler: I believe that they are successful more than they are not, and even in the face of the proliferation of "unsafe" code in both languages, they're still worth using.)
- bjourne 6y ago
  Rust doesn't check for numerical over and underflows unless you run in debug mode which almost no one does because it is about two times slower than release mode. I.e. Rust doesn't live up to the safety standards many programmers coming from dynamic languages are used to where over and underflows are checked. Many people in the Rust community appear to be unaware of this. Which is actually a big deal. Many of the bugs with the most catastrophic consequences are caused by over and underflows. Consider for example a gas pedal indicator kept as an unsigned that underflows causing the indicator to reach its maximum value. If safety was my primary concern, I wouldn't choose C++ but I wouldn't choose Rust either.
  - smitop 6y ago
    You can pass "-C overflow-checks=on" to rustc to generate an optimized build with over/underflow checks enabled, even in a release build. Also, note that over/underflow behavior is defined to always be two's compliment wrapping when overflow checks are disabled.
  - staticassertion 6y ago
    > Rust doesn't check for numerical over and underflows unless you run in debug mode which almost no one does because it is about two times slower than release mode. Totally, I wish Rust could express over/underflows better! > Rust doesn't live up to the safety standards many programmers coming from dynamic languages are used to where over and underflows are checked. > Rust doesn't live up to the safety standards many programmers coming from dynamic languages are used to where over and underflows are checked. Yeah, that's possible. Thought it won't lead to unsafety, it is definitely a gotcha. > Many people in the Rust community appear to be unaware of this. Which is actually a big deal. Maybe, not sure. > If safety was my primary concern, I wouldn't choose C++ but I wouldn't choose Rust either. Really depends on the goals and constraints, of course. I'd be really concerned about using rust where an integer overflow could kill someone. I'd be really happy to use rust where a program crashing is totally acceptable, but exploitability isn't.
  - acje 6y ago
    Rust is memory safe, not infallible. Catching more runtime errors is a something rust can improve on. Erlang being one example of a strategy.
phkahler 6y ago
IMO crates are the biggest danger to Rust. It may very easily turn into the next NPM.
- entha_saava 6y ago
  Except npm has order of magnitude more users.
- saagarjha 6y ago
  I think an even more problematic corollary is the desire to put nothing in the standard library, which cause the proliferation of crates that are the "standard" way of doing things but don't really have the guarantees/benefits that come with being part of "the" standard library.
  - zozbot234 6y ago
    It would indeed be nice to have some sort of middle ground, where a selection of outstanding-quality crates can be officially "endorsed" by the Rust development team, but the endorsement can be withdrawn freely if something better comes along. C++ has something like this via Boost, and Haskell has their Haskell Platform, so it's not a new idea.
    - steveklabnik 6y ago
      The Rust teams do maintain some crates outside of the standard library.
      - nicoburns 6y ago
        I think the proposal is specifically to bless a set of crates (that may include those developed by Rust teams, but probably also others such as regex). Being in std implies some kind of quality standard, but it also implies no backwards incompatible changes. A set of libraries blessed by a trusted group could give you the quality standard without constraining backwards compatibility.
chc 6y ago
This is true, but it's also something the Rust community discusses all the time, along with what they can do about it. It seems like a huge leap to the conclusion that the Rust community is an echo chamber because some middlebrow dismissals got downvoted on Hacker News.
- entha_saava 6y ago
  Even legitimate criticisms get downvoted or countered with dishonest marketing speech like 'borrow checker doesn't matter'.
renewiltord 6y ago
"All bets are off" is not an engineering way to look at the problem imho. You alter your risk tolerance with the benefit gained. It's just trade-offs and the ability to do that is good. I'm not going to argue you should use rust or not use rust but I think the state space is not binary and people reading will benefit from that.

guug 6y ago

> The Rust community really needs to take care not to become an echo chamber. This is a natural consequence of the restrictive rules imposed on the rust community.

smhmd 6y ago
> the restrictive rules imposed on the rust community. Can you be specific?
- Lammy 6y ago
  Not to speak for GP, but perhaps they mean https://www.rust-lang.org/policies/code-of-conduct https://www.rust-lang.org/policies/code-of-conduct ? > Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer. > Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works. I am not "anti-CoC" but I do see how the particular wording of this one could be interpreted to silence pretty much any technical discussion that someone doesn't like.
  - staticassertion 6y ago
    I think many in the rust community would feel the opposite. Technical conversations, especially tough ones, are far easier when you come in with some enforced civility. More people can contribute their differing technical opinions, not fewer.
    - asjw 6y ago
      I work with autistic people. Not as a doctor, but as software engineer, I teach programming to autistic people that work in the field and are hired because they are autistic, not despite it. This particular company looks for them, trains them and put them to work on software projects, just like any other software house would do. One thing they are often bad at is "enforced civility" not because they are uncivil people, but because their though process is different from ours and forcing them to adhere to some rigid form of presenting opinions that has no other use than enforcing a rule just for the sake of it, bores them in the best of cases, makes them angry in others, but makes uncomfortable in general. You shouldn't decide how people in a community interact with the community, you should value their contributions and just that. Civility can be enforced of course, but post-facto, after further investigation. Doing it preemptively in the COC sounds bad to me. But I could be wrong. BTW I have interacted with Rust community and have been downloaded every time I've said something on the line of "maybe it's not the silver bullet" So my experience says less people can contribute.

nilkn 6y ago

Rust as a language is great and at this point I'd much prefer to use it over C or C++ any day of the week if the application and context permit. However, I don't think I'd ever want to participate in the Rust community or really even have any contact with it. Everything I've seen of Rust's community has been deeply toxic and hostile to anyone who falls short of worshipping the language and aggressively promoting and defending it at every chance.

jeffdavis 6y ago
I think this is a combination of two things, and is true of many new programming platforms (languages, etc.). 1. If the tech hasn't made full contact with reality yet. For instance, there aren't a diverse set of large projects written in rust yet, so it's a little easier to imagine that it's perfect. 2. We should acknowledge that technology choices have a big impact on one's career. Sure, we are all software engineers that could work in a lot of environments; but we are simply more productive in the ones where we have some experience/depth. If someone is learning rust today, in many respects that's a bet, and they (subconsciously or consciously) have a vested interest in rust's success. More experienced people will usually have a more balanced risk portfolio, spread between proven tech and a few up-and-coming technologies. But for people earlier in their career, it might be a pretty major bet for them.
techntoke 6y ago
That is how the Mozilla community works and the kind of people they attract.
- meh2frdf 6y ago
  This was my opinion too, might be a generalisation, yet it is the impression I and it would seem others have!
Scarbutt 6y ago
Then don't come near the Clojure community either, that's the most cultist one I have encountered.

uluyol 6y ago

I think this will get better as Rust becomes more mainstream. At the moment, I would guess that most developers who use rust do so by choice. By contrast, many developers who use C++, Java, JS, or even Go (see docker/kubernetes ecosystem) have little say in the matter. It's not that people don't like these languages, it's that they've been successful enough that some people, who aren't crazy about them, are writing code using them.

entha_saava 6y ago
It seems to me some people are genuinely excited too much about it and some people are trying to show off that a 'hard' language is easy for them.

dijit 6y ago

> anyone who brings up criticism, no matter how valid, gets downvoted into oblivion. When I made this comment there was nothing I could call "valid" criticism. There are valid criticisms though; Lack of dynamic linking and immaturity (and most crates only building in the nightly channel, and not easily knowing if there was a version buildable on stable) are things I can think of as large weaknesses. I know these and I'm not a full time rust programmer.

zozbot234 6y ago
Dynamic linking is quite possible. You have to use the C ABI however when interfacing with code that's not part of the build.
- im_down_w_otp 6y ago
  We do this _all the time_ as we write almost all of our software in Rust, but lots of it is for use with/in embedded systems developed in C. It's true that you can mate up to C by exporting the C ABI everywhere. This isn't a free lunch though. There are annoying and/or weird side-effects you sometimes have to deal with when leaning heavily into doing this.
  - andrekandre 6y ago
    > This isn't a free lunch though. There are annoying and/or weird side-effects you sometimes have to deal with when leaning heavily into doing this. as a person not super-experienced in rust, im curious what kind of side-effects? binary size bloat?
- bjourne 6y ago
  That works in theory but often not in practice. The problem is that many C libraries keep their API backwards compatible but not their ABI. For example, a function might become a macro or the size of a struct might change. It is possible to keep the ABI backwards compatible by practicing good C hygiene, but many library authors doesn't know how. Especially when it comes to Windows which is a platform most C library authors are not intimately familiar with.

iphone_elegance 6y ago

What part of the Rust community are we talking about here the parts I've interacted with (mostly a local meetup and the rust discord) have been great and don't feel like an echo chamber do you just mean reddit and hacker news posters because I find calling that part of the community pretty absurd that's just lowest common denominator internet yelling

deleted 6y ago

[deleted]

IshKebab 6y ago

> on any thread about Rust, anyone who brings up criticism, no matter how valid, gets downvoted into oblivion. Just look at what happened to the comments critical of Rust on this post. That's just not true.

derefr 6y ago

What would you have happen instead? IMHO, on an ideal platform for debate, the audience's experience of the debate should itself resemble the statistical distribution of opinions held by the debaters. I.e., if 80% of people think X while 20% of people think Y, then comments saying Y should not make up 90% of the debate by any metric (number, word-count, above-the-fold representation, etc.) If Y did take a majority share by any metric, that'd be a misrepresentation of the debate, that is likely to cause the audience to come away with a misunderstanding of the issue. I don't know how close we are to an "ideal platform for debate" on HN (probably not very)—but I feel like a certain degree of people reflexively downvoting contrarian opinions (no matter the subject) probably bring us closer, not further, from that point. Contrarian opinions should not be presented as if they were orthodox opinions. They should be given some representation—I'm not advocating for censorship—but they should only be highlighted in any algorithmic way, to the exact degree that they're recognized as something some appreciable group of people really believes.

pasabagi 6y ago
I think this is wrongheaded, for the simple reason that whether an idea is contrarian or not is irrelevant to its merit as an idea. Misrepresentation is only possible through sophistry, not through volume, or even placement. Therefore, it makes sense to downvote only things that are 'sophist', in the sense that they contain no kernel of communication, but rather, just obscure or muddy - not things that are contrarian. Indeed, to do so is in itself an attempt to cloud and thwart communication, as you're manipulating placement and representation to make arguments less or more present, independent of their actual content.
- derefr 6y ago
  This presumes that people have infinite time and motivation both to debate, and to read the ensuing infinite debate. Rhetoric works to win debates because debates are time-limited (and the audience's attention is both time- and attention-limited), and so you can win just by e.g. preventing your opponent from ever getting a word in edge-wise, or forcing them to answer for trivial side-issues and therefore never have time to say what they really want to say; etc. What I'm railing against here is the https://en.wikipedia.org/wiki/False_balance https://en.wikipedia.org/wiki/False_balance: the rhetorical rearrangement of non-equal evidence into a debate presented to the audience as if each side had equal support behind it. And, make no mistake, that sort of rhetorical rearrangement is what discussion forums with comment voting are doing when the community rearranges the comments with upvotes/downvotes: they're curating which comments appear first (and thus which comments appear at all, to those without interest in reading the whole page.) They're changing the impression of aggregate weight-of-evidence someone gets by skimming the debate. But my claim is that this is not a bad thing, when it is done in the goal of presenting the debate accurately. If one side of a debate has little evidence, but more voices, those voices should be rhetorically damped down to compensate, until the force of their combined voice matches the volume of the evidence on their side. That is the proper goal of editorial curation in e.g. news journalism: to let authoritative primary sources speak loudly, secondary sources quietly, and kooks and rumormongers not-at-all. And it should, IMHO, be the proper goal of a community's editorial curation of a comments section, as well.

yepthatsreality 6y ago

I think the downvoting is pretty ubiquitous across HN now-a-days. This will also happen with any criticism of Apple, for example. Most of HN is an echo chamber as evidenced by the often off topic posts and discussion that reach the front page. I still come here for insight but I rarely have in-depth discussions here because HN and the crowd simply no longer cater to that kind of discourse for the most part. This is probably due to its increased popularity.

ahnick 6y ago
where do you go instead?
- yepthatsreality 6y ago
  I just started having the conversations with my peers and colleagues instead. The net benefit of getting upvoted here is minimal and the social/networking aspects as well. In person convos really can be much more rewarding and fruitful because you can focus it rather than post on HN and some person comes along who is offended can derail and kill the conversation. I’m honestly more jaded about online interaction than most though.
  - h0p3 6y ago
    If you ever need a penpal, hit me up.
- madushan1000 6y ago
  manyverse! https://www.manyver.se/ https://www.manyver.se/

JoshTriplett 6y ago

I'm one of the leads of the Rust language and community, and we absolutely welcome constructive criticism in many different forms. That's part of how we improve the language. I regularly upvote comments that point out things Rust needs to improve, as well as linking them from appropriate github issues or Zulip discussions. The whole "RESF" thing is not in any way welcomed by Rust community and governance folks. It's not funny, it's harmful, and anyone posting it is doing a disservice to the language they purport to support. To anyone reading this: please don't downvote constructive criticism of Rust. Save your downvotes for the comments that wish Rust wasn't as welcoming to everyone. ;)

blargmaster33 6y ago
There are only two genders
afiori 6y ago
What does RESF stand for? I know of "Rust Evangelism Task Force" and I am trying to match against "Rewrite Everything ..." or similar, but I am lost...
- Teknoman117 6y ago
  Same thing, "Rust Evangelism Strike Force". I'm fairly certain it's a meme.
- deleted 6y ago
  [deleted]
- jonquark 6y ago
  I had to Google to find out... Rust Evangelism Strike Force https://twitter.com/rustevangelism https://twitter.com/rustevangelism
chongli 6y ago
constructive criticism in many different forms The thing about constructive criticism, when it comes to something like programming language design, is that its usefulness varies inversely with the importance of its aim. Core features of the language are highly important (obviously) but criticizing them is not very useful since they're highly unlikely to change. Thus, only the most peripheral and superficial parts (as well as new additions) are subject to valid, constructive criticism. People who have criticism for (or are otherwise skeptical of) the core parts of Rust are not being constructive, then, and so these fights can break out.

bt4u2 6y ago

The community is why I, and a lot of people I know, won't touch Rust. It should rarely be about that but Rust is an extreme example