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.

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. ;)

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.

I'm fairly certain it's a meme.

The only counter example that I can think of is the way that the actix unsafe maintainer's behaviour was handled (brigadiering bands of Reddit evangelists flaming him for his own flaming). However, I chock that up to an anomaly caused by Reddit's toxic community and not representative of the Rust community.

Within the Rust reddit or forums, they specifically dissuade blind evangelism and there are often posts critical about the language that get quite a lot of traction.

Outside the main rust community, there are definitely zealots but they are usually not accepted by the larger community, and are usually called out.

I’m not saying it’s perfect, nor that there aren’t zealots who go overboard. However it’s probably one of the least toxic of the programming communities I frequent (swift, c++, Python, c# , go 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.

It's kinda like the old military policy of "don't ask don't tell" - the policy wasn't actually don't ask don't tell - the actual policy was "pretend to be straight". Guys didn't get in trouble for talking about their girlfriend.

Beyond that, as someone that doesn't care about politics, I just skip the thread. There are dozens I don't care to read about. It's just another one. No big deal.

A) sane and professional communities just don’t talk about irrelevances like this at all, which is my point

B) if some fringe political belief rejects some standard bread-and-butter assumption, it’s not really useful to describe running with the default assumption as “political”

“If abolishing private property is politics, then surely locking your door is politics.”

Not that that's necessarily wrong - I'm definitely sympathetic to the argument that the personal is political. But that argument would justify more technical communities taking political stances, not fewer.

If, however, some community members wish to do that, they open to others the option to speak their minds on the topic, including stating that such an action ought not to be taken because no such gender exists. Contrast this with how most "codes of conduct" are written: they would permit community members to speak in favor of such a decision but not against it, as doing so would be "hateful", "bigoted", or "exclusionary".

Think of it instead as "people who are political" looking for a community (not necessarily because of that community's politics, but often for orthogonal reasons, e.g. a language being relatively new and so not yet used by anything they dislike) and then those people being political about their programming wherever they land. If some percentage of programmers are like that, then just statistically, some language is going to end up with a lot of them, whether its maintainers wish to cultivate the community image as being such or not.

By this implied definition of political, more or less any human social interaction is political in the broader view.

[0]: https://www.washingtonpost.com/news/volokh-conspiracy/wp/201...

Maybe you had a particular bad experience after someone mistook your behaviour as trolling - not that you would have been ... I just haven't witnessed any bad behaviour in the community yet - either towards myself or others.

If anything, I have appreciated at how much support the informed members are giving to the relative newbies like myself. Not only in advice but listening without ridiculing if the speaker is not that knowledgeable on the topic of conversation.

@jasondclinton, I agree with you in regards to the bad experience the actix project owner got in regards to unsafe code use. It was sad to see that happen to an open source contributor (or anyone).

For example, I was looking for GraphQL ClojureScript libs a few days ago, and found a thread where the first answers were essentially:

- "If you can’t find a framework that does it, chances are it’s so easy to do in Clojure/ClojureScript that nobody bothers to put an abstraction there"

- "Datomic has been doing what GraphQL offers plus much more since like 2013"

Both answers are a bit cultish. The first suggests a lack of enlightenment. The second suggests that salvation can be found by embracing the cult even further and locking yourself into a proprietary database invented by Clojure's author and used almost exclusively by Clojurists.

(Edit: This thread was from 2017. Such answers may have become more rare since then.)

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.

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.

as a person not super-experienced in rust, im curious what kind of side-effects? binary size bloat?

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.

The reason it mostly works on Linux is because header files are available. For example, if a function in library A that program B depends on is changed to a macro then all that is required is for B to be recompiled. Which B almost always is because most users get their software from package archives that are recompiled when dependencies are updated.

On Windows there is no such thing as an SONAME and Microsoft has essentially given up on ABI compatibility. If you write C or C++ in Visual Studio you must ship with it with the language runtime dlls for that version of Visual Studio. Microsoft doesn't guarantee ABI compatibility with any other version of the runtime.

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.

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.

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.

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.

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).

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.

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.)

I disagree. A significant purpose of rust is to encapsulate unsafe code, and provide safe abstractions. Lots of unsafe code is safe - most of it, even, I'd bet.

I mean this with the greatest possible respect, but you replied by simply restating verbatim the quote that I originally responded to, so I'll just point you to my previous post.

IMO it's good practice to provide a comment with such proof for every `unsafe` block.

So `unsafe` does not imply unsound, but unsound does imply `unsafe`.

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.

I see it kind of like Go's lack of generics, in a strange way. With Go, no one was explicitly "anti-generics", it's just the core team couldn't find a design they liked, and as time went on it became sort of a meme. "Go is opposed to generics." "No, here's that blog post by Russ Cox about finding a way to implement them." Etc, etc.

Similarly, the rust core team was afraid to settle on designs for certain libraries, pointing out things like python's various standard library HTTP modules, and at least "for now" shunting a lot of functionality out into the ecosystem. When you have limited manpower, this makes sense, but I think a lot of people have since rationalized that decision as philosophically the right thing to do, not just a way of prioritizing development work.

In other words, I feel like it's a case of a smart tactical decision growing into an identity.

Disclosure: only dabbled in Rust a bit, currently maintain two crates of some traction.

I’d love to use Rust in the OS I work on, but integrating our build system with Cargo and dealing with external crates is a huge obstacle.

That's a challenging one. I'd like to have native support for C integration as well, but we'll have to balance that with the stability of the corresponding clang interfaces, and the requirement to ship extra libraries that the Rust toolchain doesn't currently ship.

Working on it, though.

> The rand and regex crates are two other examples.

rand I'd agree with, though it would need paring down to not have as many dependencies. For regex, there are multiple tradeoffs to be made; for instance, the most popular regex crate is fast and does most of what people want but doesn't have backreferences or lookahead/lookbehind assertions.

Ah, that's something I did not consider...

I would actually prefer if the Rust std would not include functionality that's not essential, for example sockets don't seem essential and the standard library does not implement them in a particularly complete and well thought out manner either IMHO.

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.

It is as simple as that. When serious, important projects depend on a standard library is because they want those guarantees. Having some members of Rust work on some crates does not give anyone those guarantees.

Which is why all those crates must be in std, or declare that the standard library is a set of crates (including core, std and others).

That’s what java spent years on getting (https://www.oracle.com/corporate/features/understanding-java...), and I think that’s the way to go for any language. It prevents the standard library from bloating, yet provides quality libraries that can be trusted. It also allows some implementations to be standard without providing all the bells and whistles. That can be useful on small platforms, and allows for ‘heavier’ optional libraries (for example a SVG renderer, PDF parser, etc)

Can't cargo refer to arbitrary git repos or even just plain directories? I don't see how it's any different from C or C++ in that case.

At work, we have a number of Phoenix web apps with JS frontends. Looking at one randomly, there's... checking... 48 elixir dependencies and... checking... 911!! JS ones. I have to spend literally hours every week keeping those stupid JS dependencies up to date across our apps. The churn is enormous.

I think the fear is that as long as rust keeps its standard library small, a culture may develop to have more and more in the crate ecosystem, which proves to be a huge maintenance burden, as those are freer to update in breaking ways, and cross-depend on each other.

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

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.

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: 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.

I think Carl Schmitt, for instance, should have been put in prison. His ideas are horrible. I still think they are worth reading.

This is a natural consequence of the restrictive rules imposed on the rust community.

Can you be specific?

> 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.

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.

Downvoting has nothing to do with the CoC.

The Rust COC is so vague that anything can be flagged as "non welcome"

Nobody said racist or sexist and I don't understand were it's coming from

If they don't want sexism or racism, they should write sexism and racism

An autistic person will react differently from neurotipical when confronted about manners, in a way that the COC forbids

Communities should be goal based, tribes are based on rules and enforcing them

> We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.

"Non welcome" doesn't appear in the CoC. The most vague part, I would say, is:

> Please be kind and courteous. There’s no need to be mean or rude.

The bar is extremely low here. No one is saying "you have to say please and thank you or you're banned" it's more like don't personally insult people to an extreme. That could be more explicit, since some people may have a harder time interpreting that - seems like valuable feedback.

> An autistic person will react differently from neurotipical when confronted about manners, in a way that the COC forbids

I am quite sure that many members of the rust community are far from neurotypical and they do fine. Autistic people are capable of technical conversations in which they are not attacking people.

That's just not true.

The review process and standards maintenance must be very strict.

Otherwise, as someone said, "A C compiler is a mechanism to turn coffee into security advisories".

Yes, I'm a Rust moon-boy ;)

Sure, because you people talk about it literally everywhere.

> other one is the fear of realizing that Rust is going to take over some day.

It is not. It is a good systems language, not so much for application domains where other languages get shit done in half the cognitive load. just because rust community likes to promote rust for everything and involves in dishonest marketing that borrow checker is not a problem, rust is not the optimal language for applications domains where high guarantees and low resource usage aren't mandatory.

I've still to hear why Rust is better than Ada and I caught the tail end of that madness.

With more static analysis baked into the language itself although, comes the trade off of more restrictions and longer compile times.

However, if you can get past the startup barrier, D is a real pleasure to work with.

That is not how the (Linux) kernel likes to work…

As far as "how the Linux kernel likes to work" either it's in tree, or it doesn't matter. (Not my opinion per se, IDC, but look at upstream's collective treatment of ZFS and other out of tree drivers in general; they remove APIs they know external modules are using). I do generally find out of tree drivers to be a PITA to build outside of the kernel, and sometimes find curious things in their build scripts. Updating NVIDIA drivers seems to be...not great.

"here" meaning where? Can you point to it, because there's not "a lot" on this thread.

So to evaluate whether it's worth introducing rust, you'd ideally want to find a self-contained part of the kernel that is responsible for many CVEs and you'd want to show a substantial reduction of CVEs with the rewrite of just that component. Not impossible, but also not so easy.

https://lwn.net/Articles/822527/

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

I think this is a good criticism, but might not be true forever and is certainly something to keep in mind.

As I said in the GP, Rust will not be upstreamed into the kernel- this is one of the reasons why.

Perhaps the way to do it is to rewrite common bits that get CVEs, just so it doesn't happen again.

[0]: https://c2rust.com

EDIT: Oops, read the parent comment backwards.

We can look at actually statistics instead of just one random anecdote. For instance, according to [1], there are 2 million lines of rust code in firefox, 6 million lines of C++, and 3 million lines of C. Very roughly speaking that's 20% of the lines of low level language being in Rust.

Firefox only started requiring rust to be built about 3 years ago, this is a pretty breakneck pace of replacing C/C++ with rust.

[1] https://www.openhub.net/p/firefox/analyses/latest/languages_...

The most recent information I've found is from a Spidermonkey Dev here on HN who said they might even port the Regex engine to Rust

That didn't happen either

https://news.ycombinator.com/item?id=18988024

Something tells me that there's more than meets the eye.

Mozilla is working on replacing the wasm compiler, and eventually the compiler for "ion MIR" (an intermediate langauge that js is compiled to), with cranelift, a rust implementation of a compiler backend. See [1] for pretty pictures of this.

It's been possible to use this backend to some extent since 2018 [2]. The best place I was able to find in the last 5 minutes to describe the current state of the integration is the doc comment at the top of this file [3].

In other words it looks like spidermonkey is not not being ported, it's just not being entirely ported yet.

[1] https://github.com/bytecodealliance/wasmtime/blob/master/cra...

[2] https://old.reddit.com/r/rust/comments/9mvnrk/in_firefox_nig...

[3] https://github.com/mozilla/gecko-dev/blob/master/js/src/wasm...

Edit: Another component of spidermonkey that is being rewritten in rust is the JS parser, that project is called smooshmonkey. You can read about it in the spidermonkey news letters [4] [5] [6], and there's an nice comment describing it at the top of this reddit thread [7]

[4] https://mozilla-spidermonkey.github.io/blog/2020/01/10/newsl...

[5] https://mozilla-spidermonkey.github.io/blog/2020/03/12/newsl...

[6] https://mozilla-spidermonkey.github.io/blog/2020/05/11/newsl...

[7] https://old.reddit.com/r/rust/comments/h0ddpi/smooshmonkey_n...