Hacker News Reader

Comment by dijit | Hacker News Reader

A lot of 'anti-rust' sentiment here.

Personally, I think the article is somewhat correct. Well vetted and tested C (or C++) is great, but even the guys who are looking for these things get it wrong sometimes.

Rust isn't perfect, and I think the negative reaction is people thinking that evangelists consider it perfect. But I certainly wouldn't call it perfect, and I'm rather fond of Rust.

That said, I still think it's the "best chance", that doesn't mean it's the only possible thing to make headway into more safe systems, but it means that it has the 'best chance'..

Maybe you can make D memory safe, but when I was getting into D development I couldn't even get a compiler working.

Maybe Ada is your favourite, but I don't know anyone writing Ada and integrating it with a C codebase.

Frankly it comes down to the fact that Rust was designed specifically for replacing components of a large C++ codebase that it will be adopted. If you can write a driver that works with linux that's written in rust and you don't have as many memory safety issues or concurrency problems (and theres no overhead) then that's reasonable.

Even if Rust never gets supported by the kernel's buildsystem officially or if the code can not be upstreamed.

View on HN

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

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

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

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

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

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.

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

The compiler has very limited "proof" capabilities even in principle, especially wrt. unsafe{} code. From a principled POV it would be nice to be able to provide a formal, compiler-checked proof that some block of code that has to rely on "unsafe" operations doesn't actually violate the language safety guarantees and can be wrapped safely. But this will have to depend on a formal model of "unsafe" itself which is still lacking. And it wouldn't even help for things like FFI, which involves calls into outside code for which the semantics are not formally known.

> The whole selling point of Rust is that it's supposed to let you write provably safe code.

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.

> Lots of unsafe code is safe

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.

Sorry if I misunderstood your post then.

`unsafe` the keyword vs unsafe the concept. Lots of `unsafe` code is safe when used through a safe wrapper. Verifying that is the duty of the programmer. The compiler can't prove it, but quite often the programmer can.

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

This is what I was trying to say. Unsafe doesn't imply exploitability, at all.

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.

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.

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

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.

Rust is memory safe, not infallible. Catching more runtime errors is a something rust can improve on. Erlang being one example of a strategy.

IMO crates are the biggest danger to Rust. It may very easily turn into the next NPM.

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.

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.

The Rust teams do maintain some crates outside of the standard library.

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.

Regex is one of those crates.

No, they don’t. If the Rust team maintains a crate officially and they will always do so (for reasonable values of "always"), then it is part of the standard library. Otherwise, it isn’t.

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

... I don’t see how that possibly follows. Not everything the project does is the standard library. The compiler, rustup, all kinds of tools.

I don’t see how that follows. Rust could easily have a (small) standard library that is guaranteed to be present everywhere and any of a number of optional libraries that are maintained by the same team that builds the compiler and the standard library.

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)

Actually, I am looking for more than this because I think Rust actually has a number of libraries that I think function fairly similarly to Boost. What I really want is the language committing to a library that is available without a third-party dependency, basically under a "linking exception" to be extremely close to "use however you want", supported by the people developing the language, designed alongside the language to remain ergonomic, with support that is tied to the language, … Personally, I consider this to be a very valuable feature from a programming language. Having a "pretty good" solution available "for free" is immensely value compared to having to go look online for every little thing, evaluate the landscape, audit it, ensure the licensing matches, consider whether will remain supported, and try to work around its idiosyncrasies.

The saddest example I’ve come across so far is the lack of strftime, or any way to even print a clock time / date time in std. Even JavaScript has that. In a supposedly way past 1.0 language one has to rely on 0.x third party libraries to do even the most basic things.

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

The rand and regex crates are two other examples. I would also prefer to have bindgen in the standard library.

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.

> I would also prefer to have bindgen in the standard library.

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.

> the requirement to ship extra libraries that the Rust toolchain doesn't currently ship.

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

Question: is bindgen std quality yet? It seems there are still largely unsolved problems, e.g. https://github.com/rust-lang/rust-bindgen/issues/1549 which is causing hundreds of warnings in a -sys crate of mine and for which I have no recourse.

I think the issue there is that versions are arbitrary and being able to tell when a library is 1.0 is a non-decidable problem. There are lots of 0.x crates which are stable and feel feature complete, but aren't specifically versioned as 1.0.

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.

Yeah, I agree with this.

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.

> [crates may turn into the next NPM]

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.

It can, yes.

It can, but then so can ruby's Bundler and elixir's Hex. But neither of them have the same issues as npm. I think npm's issues arise from a culture of making lots and lots of tiny dependencies, probably spawned by JS's anemic standard library.

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.

I think NPM obsession with small libraries comes from the lack of an decent optimizing compiler that can remove/not-include unused code, combined with a deployment scenario (frontend) where code size matters.

Except npm has order of magnitude more users.

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.

Even legitimate criticisms get downvoted or countered with dishonest marketing speech like 'borrow checker doesn't matter'.

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

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

> the restrictive rules imposed on the rust community.

Can you be specific?

Not to speak for GP, but perhaps they mean 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.

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.

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.

I don't understand why an autistic person would be incapable of expressing a technical issue in a way that isn't sexist/racist, etc, which is basically 99% of compliance with a CoC.

Downvoting has nothing to do with the CoC.

Autistics are not neurotipical

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

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

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

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.

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.

That is how the Mozilla community works and the kind of people they attract.

This was my opinion too, might be a generalisation, yet it is the impression I and it would seem others have!

Then don't come near the Clojure community either, that's the most cultist one I have encountered.

That has a lot to do with Rich Hickey and Cognitect encouraging cultishness.

Would you care to elaborate? I'm very fond of the language but have found people to be generally pleasant. The only criticism I have is that its a pretty small community so finding fellow Clojurists tends to be hard.

(Not the person you responded to.) My direct interactions with the Clojure community have been very pleasant and helpful, and I have zero complaints there. But when searching around for common questions related to Clojure, I often run into answers along the lines of "Clojure doesn't have X because our language is so superior we don't need it", which does sound cultish.

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

The second was probably me. Sorry about that. My words reflect me as an individual who is sometimes socially challenged, not the wider Clojure community.

Ouch—I didn't link to the thread in my previous comment specifically because I didn't want to point fingers at people who were trying to help back in 2017, even if I disagree with their answers, but here you are anyway! For what it's worth, I'd rather have more people in the Clojure community than fewer, even if I don't always share the same viewpoints.

At least they don't bring politics in it.

I wonder which community you’re talking about. My experience is rather positive. The infamous Rust evangelization task force is just a bunch of fanbois to put in your killfile.

They’re also super weirdly political. As a not-especially-political guy I’m super turned off by all the “activism” I see coming out of the community, even where it’s totally irrelevant. I remember seeing a whole thread about how the rust mascot crab is canonically non-gender-binary or something. Wtf?

Don't think of it as a community being political. It's not like people pick a programming language and then suddenly one day decide to be political, in part due to their programming-language choices.

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.

If discussing the gender of the crab is politics, then surely assuming the crab is one gender or another is also politics. The idea that you can avoid politics in anything is a lie told by people whose beliefs conform to mainstream society. What you're really asking for is everyone to agree with the mainstream view.

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.

If communities want to go down that road, fine, but then they need to get out of this weird limbo where some views are allowed and some aren't. That means that someone must be just as free to say, "I believe the rust crab should have a normal gender because non-gender-binary is not a thing." without getting banned or cancelled. Right now it's reverted to a very don't-ask-don't-tell-like environment where one can either speak in support of such things or not say anything at all, effectively pretending to agree just as in your military example servicemen had to pretend to be straight.

In my experience many people (unfortunately) generally feel free to disparage non-gender-binary concepts on internet communities

Maybe in other places on the internet, sure, but I was referring mostly to the code-of-conduct-gated development communities that pretend not to discuss politics while allowing specific viewpoints above others.

I can see a difference between light-hearted speculation about an imaginary crab's gender and saying that non-gender-binary people don't exist. Can you think of any reason why one of these might be allowed, while the other might not be?

I guess I can't, because they're both political statements. Politics is either allowed or not. I assume, however, you have some reason in mind, by how you phrased the question.

Interesting - well, honestly, not sure how anything wouldn't be political if discussing a crab 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.

Discussing a crab is not politics, but attributing to it a non-existent gender is intentionally contrary to most people's social beliefs (especially outside of the SV bubble) and is thus political. Calling it a normal boy or girl isn't.

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

> If discussing the gender of the crab is politics, then surely assuming the crab is one gender or another is also politics.

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

My first reaction was: why is a non-gender-binary crab mascot considered "political"? I'm assuming this came up incidentally in the context of its name and pronouns?

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

You're right that it's primarily a social issue, but people will always try to use the state to enforce their social beliefs, so they become political. See New York City's ordinance that can cause those who won't use a made-up "pronoun" to be fined [0], undoubtedly a use of force by the state to enforce a certain set of beliefs.

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

It’s one example out of many where rust users bring a political topic (and yes, post-gender queer theory stuff is political) into a discussion where there’s no reason to do so except to leverage the discussion as a platform for boosting your political belief. It’s very unprofessional, very counterproductive, and a huge turn off for people who don’t have the same fringe politics.

I'm really confused by your comment because the experience that I have had and in surveys of my coworkers in the Rust community has been uniformly amazing: 1) the technical discussions are always respectful, 2) the in-person conferences have clear code of conducts and the speaker panels represent the best of the engineering and human community, and 3) the community actively encourages people asking newbie questions and goes out of its way to be supportive and non-judgemental when replying.

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.

I’d be curious what your exposure to the Rust community has been and where?

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)

I have to say my experience with the community has been really good. Whether it be the reddit channels, discord channels or conversations with people putting rust related stuff on youtube.

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

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.

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.

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

Dynamic linking is quite possible. You have to use the C ABI however when interfacing with code that's not part of the build.

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.

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

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.

Dynamic linking requires a backwards-compatible ABI essentially by definition. If the ABI changes, that involves a bumped SONAME and version number hence binary objects should never end up being linked in incompatible ways.

Few library authors understand that. In recent years libmq, libpcre, and libssh have all introduced ABI breaking changes without bumping the SONAME. Unless you have very detailed knowledge of how dynamic linking works on all supported platforms it is very hard to know what constitutes an ABI break.

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.

It looks like the Windows equivalent is called a "Side by side manifest". It has to be opted-in-to from both the shared object (.DLL for Windows) side and the loading application, though. On Linux, it just works - it is idiomatic to include major version in SONAME.

libc usually does pretty well, FWIW.

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

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

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.

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.

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: 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 agree that rhetorical damping is necessary - I just think that it should be done on how much a given post contributes to a discussion, not by how much it contributes to the majority opinion's side of a discussion.

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

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.

where do you go instead?

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.

If you ever need a penpal, hit me up.

manyverse! https://www.manyver.se/

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

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

Same thing, "Rust Evangelism Strike Force".

I'm fairly certain it's a meme.

I had to Google to find out... Rust Evangelism Strike Force https://twitter.com/rustevangelism

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.

I've seen (and participated in) useful, productive discussions about core aspects of Rust; occasionally such things can even be improved. It takes a lot of care to have a productive discussion on such things, but it can absolutely happen.

Constructive doesn't mean actionable. Not sure where that assumption comes from. It may be that only future languages can reap the rewards of a discussion on core features that are unlikely to change in rust but that's still possibly valid constructive criticism.

> Well vetted and tested C (or C++) is great

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

There is actually lots of Rust supporters in HN (and what other places you'll find people who actually know what Rust is). This extra-hype made people sensitive for possibly two reasons: Too much coverage (re-write everything in Rust) and the other one is the fear of realizing that Rust is going to take over some day.

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

Or we've been around long enough to hear the same bullshit (a technical term) enough times that we are allergic to how different it is this time.

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

I know very little about Ada, but googling it leads me to understand that freeing memory in Ada is considered unsafe. If that's correct, safely freeing memory (generally in a destructor, much like C++) might be one advantage of Rust.

> extra hype made people more sensitive..

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 think a good insight of rust and other static languages is it moves a lot of testing into the language itself. I once saw an extension of the testing pyramid by adding 'static analysis' and I think that's a good way to think about it.

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

If I might ask, when was the last time you have D a shot? Available documentation has improved recently, though I think there's a big need for improved tooling docs.. in my case, it took forever for me to figure out how packages work with `dub`.

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

> Even if Rust never gets supported by the kernel's buildsystem officially or if the code can not be upstreamed.

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

What do you mean? I have the Rust working in Kbuild; I haven't published the patches. At Linux Plumber's conf for later this year, I've submitted a proposal to discuss the barriers to adoption within the kernel proper. Some very senior kernel devs are supportive.

You have it working, but if you're writing drivers and stuff the kernel might change out from under it and you'll have to continuously keep it up-to-date if it's not in-tree, right?

Yes; but what I'm talking about (Kbuild) is in-tree support for Rust. Bindings are regenerated when the kernel is built.

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.

> A lot of 'anti-rust' sentiment here.

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

Rust makes sense for replacing C++ user space programs. I don’t see how it’s relevant to the Linux kernel at this point.

Due to its strong and simple C bindings, there's no reason new kernel modules can't default to being written in Rust, and allow Rust to spread from the "outside in" to the heart of the kernel. I don't advocate wide-scale rewriting of the kernel, but I do think default-to-rust for new kernel components and modules is rational and improves the system.

What about a Rust to C translator? It would produce "safe" C right?

You would also need to comprehensively annotate the Linux C headers in order to provide the information that Rust expects (e.g. for each ptr instance whether it's a "raw" pointer, a shared/exclusive reference or a piece of "owned" data, whether it can be NULL etc. etc.). This might actually get accepted upstream though. Having the kernel-build itself depend on Rust could be far more problematic, given e.g. the variety of hardware that Linux must support.

Not only that, but Rust depends on LLVM.

It doesn't have to, but yes, it currently pretty much requires LLVM.

Last time I looked at this comment it was flagged [dead]; I'm glad someone was able to remedy that as I was unable to upvote.

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.

If a comment is dead that you think is worthwhile, you can follow the permalink to it and vouch for it. I imagine that feature is gated behind some point threshold, but my guess is whatever that threshold is you're past it.

Oh, nice, thanks for that. :)

I would think such a thing would be more like "compiling" rust to C. As in the C code would have no means to maintain most of the safety guarantees, rather they would be verified at compile time, and the produced C would be meant to be used unchanged. So as long as nobody ever edits the C manually, it would still presumably be safe.

That's what I really meant. Write it in Rust but then output C instead of ASM. The parent is right though. A component/driver would need to use the C headers from the Rust side.

The output of the translator would be right, but messy, and someone would have to go back and clean it up. Doing that work would almost certainly introduce bugs. How many, and whether it outweighs is the question.

https://lwn.net/Articles/797828/

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

There is a lot of work being done on a translator now [0]. However, the goal is to translate C to equivalent Rust and then allow developers to intervene to migrate to safe Rust.

[0]: https://c2rust.com

EDIT: Oops, read the parent comment backwards.

That's C to Rust, not Rust to C. (mrustc provides something like the latter, but it doesn't actually support full Rust.)

We just seen a news that Firefox is reusing Chromes regex c++ code, so from my point of view Firefox is barley pushing for Rust components but Rust fans expect the kernel to push harder. IMO when Firefox and all it's componetns/dependencies are Rustifed then I think we can ask for the kernel to attempt the same.

If Firefox wrote a new regex module and didn't use Rust that would contradict the poster's advice, but them using an existing mature bit of coded doesn't seem to prove much.

What Firefox done makes sense, but it does not look good to the idea you can just rewrite in Rust function by function. A regex engine seems to me a thing that is easy to TDD, so I would expect if rewriting in Rust is that easy Firefox would rewrite the most dangerous parts in Rust already (I assume regex is used with untrusted input but I am clueless so i could be wrong). IMO the giant army of Rust fans should put their energy working on Firefox or donating to have Firefox rewriten before 2030, because the story that is heavily promoted is that you can rewrite shit in Rust super easy, function by function, etc but the reality is different.

C code can be rewritten function-by-function, even programmatically via c2rust. C++ is a bit messier and even the FFI interoperability story wrt. Rust is not quite complete.

Firefox didn't choose the C++ regex implementation because rewriting pieces of code with well defined interfaces is hard. It was for a few reasons: 1) at the time they made the decision, there was no existing rust regex library that matched the way that JavaScript worked, 2) they didn't want to write their own/rewrite existing code because regex libraries are complicated beasts, 3) the C++ code is mature and well tested, so the primary benefit of a rust implementation would be more speed (because it's easier to safetly reason about shared data) they didn't think that optimizing the regex engine was a priority.

It makes sense, I am still a bit disappointed (so is a subjective thing) hopefully the RIR crowd gets more rational and reads your explanation and see that is not so easy.

>. A regex engine seems to me a thing that is easy to TDD Why go to all that effort when the thing you need is already available? I don't think there are that many people that argue that everything, even the stuff that works fine and doesn't have issues, should be re-written just because rust exists.

One component choosing to use a mature implementation in another browser instead of a rewrite from scratch in rust means very little.

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

Firefox JS engine is in C++ even though rust has been available for years now, they've said more than once that they have no plans on porting Spidermonkey to Rust.

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.

It seems unlikely that there is any great conspiracy at play here to me... they found a good solution to a problem, they implemented it. Spidermonkey is a highly optimized carefully examined code base, it's not easy to replace wholesale or particularly low hanging fruit to be replaced with rust.

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

I personally would also check if the libraries Firefox uses are Rust, I mean the browsers this days are huge, you have image,audio,video,WebGl,pdf and a ton more features so you need all the dependencies to also be memory safe especially the ones that handle untrusted input.

A mixed-language codebase will always be more complex than a single language one. So it's not just a matter of Rust integrating well-enough with the rest of the kernel, but it has to offer enough improvement for the cost to be worthwhile.

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.

The kernel is required to be compilable with very old versions of GCC. So unless all users/companies agree on lifting that restriction, there is not much to do. rustc is not stable nor old enough.

So it's currently GCC 4.6+, with patches queued to bump that to 4.8+. Also, you can use Clang. So I'm not sure how rustc being used for some parts of the kernel has anything to do with developers "restriction?"

Via LWN, looks like the GCC 4.8+ patches got merged into the kernel's 5.8 merge window recently, with a footnote suggesting this be bumped to GCC 4.9+.

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

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

Reply on news.ycombinator.com