[CartwheelLinux]

The language is tough love, and I think it's important despite what the first respondent has said.

Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage.

I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe languages and defensiveness against adopting modern tooling/languages

[uecker]

I think the spin that Rust is necessarily the way forward is what is wrong. IMHO Rust has severe problems and what is considered "modern" is mostly taste. We have seen the same thing in the past with a push towards C++, Java, managed languages. What is new is that the free software movement is now controlled so much by corporate interests that some of these changes are pushed through aggressively against the interests of other parts of the community. In the past, if you wanted something changed and there was no agreement, you created a fork and if it was truly better it was eventually adopted by the majority. Nowadays, the companies which fund most of the development aggressively pursue their interests and the part of the community that disagrees is forced out. This justified by with suitable propaganda "not willing to adapt", etc. The whole point of free software should be that I do not have to adapt to some companies's idea of what is modern, if I do not want to. This is why I fled from Microsoft.

[tialaramex]

> I think the spin that Rust is necessarily the way forward is what is wrong.

I haven't seen this from Rust. Obviously lots of us think that Rust is the way forward for us but I think the problem you're talking about is that nobody offered any alternatives you liked better and that's not on Rust.

If Bob is ordering pizza for everybody who wants one, it is not the case that "Pizza is necessarily the way forward", and it's not Bob's fault that you can't have sliders, I think if you want sliders you're going to need to order them yourself and "Pizza is the way forward" is merely the default when you don't and people are hungry.

Dave Abraham's Hylo is an example of somebody offering to order sushi in this analogy. It's not yet clear whether Dave knows a Sushi place that delivers here, or how much Sushi would be but that's what having another way forward could look like.

In C++ they've got profiles, which is, generously, "Concepts of a plan" for a way forward and in C... I mean, it's not your focus, but nobody is looking at this right? Maybe Fil-C is your future? I note that Fil-C doesn't work on these obsolete targets either.

[mirashii]

This whole it used to be different thing is looking back with rose tinted glasses. It’s always been the case that project maintainers were able to make choices that the community didn’t necessarily agree with, corporate backed contributors or not, and it’s still a possibility to fork and try to prove out that the other stance is better.

Nobody is being forced out of the community, you can fork and not adopt the changes if you want. Thats the real point of free software, that you have the freedom to make that choice. The whole point of free software was never that the direction of the software should be free from corporate control in some way, the maintainers of a project have always had the authority to make decisions about their own project, whether individual or corporate or a mix.

[uecker]

The point of freedom in software is certainly that I can create my own fork. And individual projects a maintainer can certainly do what he wants. But it is still worrying if in community projects such as Debian when decisions that come with a cost to some part of the community are pushed through without full consensus. It would be certainly not the first time. systemd was similar and for similar reasons (commercial interests by some key stakeholders), and I would argue that Debian did suffer a lot from how badly this was handled. I do not think the community ever got as healthy and vibrant as it was before this. So it t would be sad if this continues.

[solidsnack9000]

...it is still worrying if in community projects such as Debian when decisions that come with a cost to some part of the community are pushed through without full consensus.

What are some concrete cases you can point to where a decision was made with full consensus? Literally everyone agreed? All the users?

I'm not sure many projects have ever been run that way. I'm sure we've all heard of the Benevolent Dictator for Life (BDfL). I'm sure Linus has made an executive decision once in a while.

[kelnos]

> pushed through without full consensus

Requiring full consensus for decisions is a great way to make no decisions.

[Klonoar]

> are pushed through without full consensus

You describe it that way, but that's not how the world in general works in practice. You do things based on majority.

[uecker]

No, this is not how you do things in a functioning community. You do things based on societal contracts that also protect the interests of minorities.

[Klonoar]

I cannot fathom using the rest of my Saturday attempting to break down the level of spin you’re trying to play at here.

[throwaway7356]

> systemd was similar and for similar reasons (commercial interests by some key stakeholders)

False claims don't really make the claims about the evils of Rust more believable.

[mrkeen]

> if you wanted something changed and there was no agreement, you created a fork and if it was truly better it was eventually adopted by the majority.

This assumes there wasn't agreement.

And if so, what would 'eventually adopted by the majority' mean. Is this announcement not that?

[throwingrocks]

> The whole point of free software should be that I do not have to adapt to some companies's idea of what is modern, if I do not want to.

This hasn’t changed.

[crote]

> I think the spin that Rust is necessarily the way forward is what is wrong.

Well, what's the alternative? The memory safety problem is real, I don't think there is any doubt about that.

C/C++ is a dead end: the community has thoroughly rejected technical solutions like the Circle compiler, and "profiles" are nothing more than a mirage. They are yet again trying to make a magical compiler which rejects all the bad code and accepts all the good code without making any code changes, which of course isn't going to happen.

Garbage collection is a huge dealbreaker for the people still on C/C++. This immediately rules out the vast majority of memory-safe languages. What is left is pretty much only Zig and Rust. Both have their pros and cons, but Rust seems to be more mature and has better community adoption.

The way I see it, the pro-memory-safety crowd is saying "There's a giant hole in our ship, let's use Rust to patch it", and the anti-Rust crowd yells back "I don't like the color of it, we shouldn't repair the hole until someone invents the perfect solution". Meanwhile, the ship is sinking. Do we let the few vocal Rust haters sink the ship, or do we tell them to shut up or show up with a better alternative?

[zozbot234]

Basically correct, but Zig is not a memory safe language. It may be an improvement wrt. syntax over C, and its standard library facilities may be genuinely better than Rust's wrt. writing unsafe code, but it's simply not interesting from a safety perspective. I'm sure that even the most rabid Zig advocates would readily acknowledge this point.

> Garbage collection is a huge dealbreaker for the people still on C/C++.

The problem is not so much GC itself, but more like pervasive garbage collection as the only memory management strategy throughout the program. Tracing GC is a legit memory management strategy for some programs or parts of a program.

[pron]

> it's simply not interesting from a safety perspective

The reason memory safety is interesting in the first place (for practical, not theoretical reasons) is that it is a common cause of security vulnerabilities. But spatial memory safety is a bigger problem than temporal memory safety, and Zig does offer spatial memory safety. So if Rust's memory safety is interesting, then so is the memory safety Zig offers.

I'm a rabid software correctness advocate, and I think that people should acknowledge that correctness, safety (and the reasons behind it) are much more complex than the binary question of what behaviours are soundly disallowed by a language (or ATS advocates would say that from that their vantage point, Rust is just about as unsafe as C, and so is completely uninteresting from that perspective).

The complexity doesn't end with spatial vs temporal safety. For example, code review has been found to be one of the most effective correctness measures, so if a language made code reviews easier, it would be very interesting from a correctness/security perspective.

[Measter]

Zig only does bounds checking by default in Debug and ReleaseSafe builds. If you build with ReleaseFast or ReleaseSmall it will happily do an out of bounds read: https://godbolt.org/z/733PxPEPY

[pron]

That's a matter of how policy is set. You can set it to on or off for a particular function, too. The point is that language offers sound spatial safety just as much as Rust does (and both allow you to turn it on or off in particular pieces of code).

[throwaway17_17]

I am very much inclined to agree with you, but do you have any sourcing for a claim that spatial is a bigger problem with regards to security vulnerabilities? Every time I feel like posting similar sentiments I just know that a reply linking to an article about how Microsoft and/or Google claim 70% of bugs are memory safety issues will be posted. Both of the ‘studies’ (code surveys) seem to claim use-after-free make up the majority of those bugs.

[pron]

Mitre place spatial memory safety higher on the list: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html (also >3x KEV)

[davemp]

Rust technically isn’t a memory safe language the second you use “unsafe”. Rust advocates tend to pretend the can have their cake and eat it too when comparing it to other low level languages. No, just because you have the word unsafe next to the scary parts doesn’t make it okay.

I’ve written a good chunk of low level/bare metal rust—unsafe was everywhere and extremely unergonomic. The safety guarantees of Rust are also much weaker in such situations so that’s why I find Zig very interesting.

No oob access, no wacky type coercion, no nullptrs solves such a huge portion of my issues with C. All I have to do is prove my code doesn’t have UAF (or not if the program isn’t critical) and I’m basically on par with Rust with much less complexity.

[dvtkrlbs]

The point of unsafe is you have small bubbles of unsafe which you can verify rigorously or use tools like Miri to make sure they upheld and you build safe abstraction on top of that unergonomic part. Looking at embedded-hal and even to extreme embassy you can see the value of it. If you don't do any abstraction I definitely agree Rust is not fun to write at all.

[zozbot234]

The safety guarantees of Rust the language around unsafe are just as good as C or Zig if you use the appropriate facilities (raw pointers, MaybeUninit, UnsafeCell/Cell, Option for nullability, Pin<> etc). Sometimes this is made unnecessarily difficult by standard library code that expects all the guarantees of ordinary Safe Rust instead of accepting more lenient input (e.g. freely aliasable &Cell<T>'s), but such cases can be addressed as they're found.

[davemp]

My point is that it’s easier to write correct Zig code than correct unsafe Rust. Raw pointers can be null in rust so you should use NonNull<T> but there’s aliasing rules that are easy to mess up. And difficultly with the stdlib as you mentioned.

I don’t actually mind Rust when I was able to write in safe user land, but for embedded projects I’ve had a much better time with Zig.

[cardanome]

> Meanwhile, the ship is sinking.

No it is not. We have a lot of amazing and rock solid software written in C and C++. Stuff mostly works great.

Sure, things could be better but there is no reason why we need to act right now. This is a long term decisions that doesn't need to be rushed.

> What is left is pretty much only Zig and Rust.

We had Ada long before Rust and it is a pretty amazing language. Turns out security isn't that important for many people and C++ is good enough for many projects apparently.

There is also D, Nim, Odin and so on.

> Garbage collection is a huge dealbreaker

It isn't. We had Lisp Machines in the 80s and automatic garbage collection has vastly improved these days. So I wouldn't rule those out either.

In short, no the ship is not sinking. There are many options to improve things. The problems is once you depend on rust it will be hard to remove so it is better to think things through because rushing to adopt it.

[uecker]

While memory safety is important, I do not believe it is now suddenly so important that it needs now needs to be solved quickly at all cost. There are far more pressing issues. I also do not think at all that C/C++ are dead end. In fact, I think it would be far more cost effective to continue to improve safety of C and C++ code via gradual improvement than adding another language into the mix. The reason is that complexity and the burden of long-term maintenance is the main issue we have in free software, and Rust makes this worse rather than better. Case in point, the fact that I have limited security updates because of some Rust video codec in the dependency chain hurts my security far far more than the fact that it might prevent some memory safety issue: https://www.debian.org/releases/trixie/release-notes/issues.... I think this is what people are missing. They over-exaggerate the important of memory safety over rather mundane issues which are actually far more important. I have never known anybody who was directly affected by a security issues caused by memory safety, I know plenty who were affected because their software was not up-to-date.

[mkl]

English link: https://www.debian.org/releases/trixie/release-notes/issues....

> The Debian infrastructure currently has problems with rebuilding packages of types that systematically use static linking. With the growth of the Go and Rust ecosystems it means that these packages will be covered by limited security support until the infrastructure is improved to deal with them maintainably.

[solidsnack9000]

What are realistic options for "gradual improvement" of memory safety in C and C++?

My first thought is that it is kind of like talking about gradually improving manual memory allocation in Java. C and C++ are fundamentally memory unsafe; it's part of their design, to offer complete control over memory in a straightforward, direct way.

[Mond_]

> IMHO Rust has severe problems and what is considered "modern" is mostly taste.

Really? As opposed to e.g. C or C++ (as the most important languages which Rust is competing with)? Sure, taste plays into everything, but I think a lot of people work with Rust since it's genuinely a better tool.

I hear you on free software being controlled by corporate interests, but that's imo a separate discussion from how good Rust is as a language.

[Antibabelic]

Ada and SPARK fulfilled the promise of a safe systems language decades ago without making most of the mistakes Rust does. Rust has its strong sides, sure, but it's far from the only shop in town. The GCC happens to include an Ada compiler as well.

[dvtkrlbs]

The problem is they forgot about making the language approachable so it lives in its bubble for safety criticial usage (which Rust kinda starting to eat its lunch from with the certified Rust fork)

[Xylakant]

If you’re referring to Ferrocene with the certified Rust fork, then I’d like to make the minor correction that we don’t consider Ferrocene a true fork, but rather a downstream distribution of the Rust projects compiler. There are very little changes to the compiler itself. Most relevant changes are documentation, build process and different test coverage - we do test architectures that upstream does not.

[dvtkrlbs]

Yeah fork is a bad word for it. Sorry about that.

[Antibabelic]

What do you find unapproachable about Ada?

[dvtkrlbs]

For starter it looks completely alien my real introduction to Ada was with this article comparing it to Rust on solving advent of code [1] but it gives me that feeling when I try to read Haskell code (not that extreme). I did not actually give it a real chance though but its user base even more niche than Rust so idk. It has really cool properties (being able to define n bit datatypes is nice) but it is also leans to more on the imperative side so that also does not interest me.

[1] https://github.com/johnperry-math/AoC2023/blob/master/More_D...

[solidsnack9000]

What are those mistakes?

It seems like Ada more or less has to have memory safety bolted on -- that is what SPARK does -- and it's not clear that Ada's bias towards OO is better than Rust's bias towards functional programming.

Are you talking about features like type inference (so the Rust code could be less clear, since types are not always written out)?

[pjmlp]

And just recently Modula-2.

[einpoklum]

That is a 'subtle whataboutism' reply, actually...

you see, GP did not speak in relative terms, but absolutely: They believe Rust has problems. They did not suggest that problems with programming languages are basically all fungible, that we should sum up all problems, compare different languages, and see which ones come out on top.

[noosphr]

I'm very happy with common lisp for fast code.

Of course most people aren't smart enough for the language so they have to use inferior algol languages like rust.

[AlotOfReading]

No need to sully CL with this kind of elitism. Any language you need to be a genius to use is a bad language. That's one of the fundamental issues with C. We're all imperfect idiots some of the time and one instance of undefined behavior breaks any guarantees the language gives you.

[noosphr]

I find that languages with a high intellectual barrier to entry are much more pleasant places to be since people like the OP can't understand them and we never have people try to bully us into doing things _the right way_.

This is someone who says things like

>It's important for the project as whole to be able to move forward and rely on modern tools and technologies and not be held back by trying to shoehorn modern software on retro computing devices.

While on company time.

[tclancy]

> since people like the OP can't understand them and we never have people try to bully us

Yes well, glad to hear there’s no one bullying people there!

[bitwize]

Name me another language that offers the memory safety and deterministic runtime guarantees that Rust does, eliminating entire classes of bugs, the same integration with existing C code that Rust does, and enjoys the same community and pool of eager contributors that Rust does.

I'll wait.

[krater23]

The pushback comes from the idea to rewrite all old tools in another language just because you can. Instead of creating new projects and using the new language it feels like the most rust projects are rewrite from old projects. And the most projects you have read about on hacker news in the last year 'I made xy, but in rust' are already abandoned. It's just a trend to write something already existing in Rust just to learn the language and then release it for productive use.

[tcfhgj]

I haven't either, until I read comments on Rust in Linux on social media outside HN.

Apparently, Rust is part of the "woke agenda"

[hofrogs]

Yep, I noticed that under a lot of videos mentioning rust in kernel, or rust in general there's a high chance that the comment section will just be straight up lifted from 4chan pol or a similar place

[hsbauauvhabzb]

Is there any particular reason for this? Do they not agree with the code of conduct more than normal?

[noisem4ker]

Complete disagreement with codes of conduct and the typical political orientation of their proponents. Also, pure contrarian spirit.

[4bpp]

That is a crude and politically inept way of putting it, but do you not think there is some grain of truth to it?

If you opt into something with as high a barrier to entry and necessary time commitment as a programming language, you naturally also opt into the existing community around that language, because that will be where the potential contributors, people to help you solve issues, and people you have to talk to if you need the language or ecosystem to move in some direction will hail from. In turn, the community will naturally get to impose its own values and aesthetic preferences onto you, whether by proactively using the position of relative power they have over you, or simply by osmosis. As it happens, the community surrounding Rust does largely consist of American progressives, which should not be surprising - after all, the language was created by an American company whose staff famously threatened mutiny when its own CEO turned out to offend progressive sensibilities.

As such, it is natural that bringing Rust into your project would over time result in it becoming more "woke", just like using Ruby would make it more likely that you attract Japanese contributors, or targeting Baikal CPUs would result in you getting pulled into the Russian orbit. The "woke" side themselves recognises this effect quite well, which is why they were so disturbed when Framework pushed Omarchy as a Linux distribution.

Of course, one needs to ask whether it is fair to insinuate premeditation by calling a mere expected effect an "agenda". Considering the endlessly navel-gazing nature of the culture wars, I would find it surprising if there weren't at least some people out there who make the same observation as above, and do think along the lines that driving Rust adoption is [also] a good thing because of it. Thus, Rust adoption does become, in a sense, part of the "woke agenda", just as Rust rejection becomes, perhaps even more clearly so, part of the "chud agenda".

[JuniperMesos]

> As such, it is natural that bringing Rust into your project would over time result in it becoming more "woke", just like using Ruby would make it more likely that you attract Japanese contributors, or targeting Baikal CPUs would result in you getting pulled into the Russian orbit. The "woke" side themselves recognises this effect quite well, which is why they were so disturbed when Framework pushed Omarchy as a Linux distribution.

I think this analysis is basically accurate - there's no conspiracy or even deliberate agenda going on, it's just that the community surrounding Rust happens to have (at the moment, anyway) a relatively high number of American progressives, many of whom are openly interested in imposing American progressive ideological norms in spaces they care about (which is basically what we mean by the term "woke").

I think Rust is a good software tool and I would like to see it be as widely adopted and politically-neutral as C is, and used in all sorts of projects run by all sorts of people with all sorts of other agendas, political or otherwise. Consequently, I would like to see people and projects who do not agree with American progressive norms adopt the language and become active users of it, which will help dilute the amount of Rust users who are progressives. I myself am not an American political progressive and I have lots of issues with the stated politics of many well-known Rust developers.

[hollerith]

We need more effective ways to prevent ideological capture of our institutions especially when there is no actual connection between an institution's mission (e.g., to support the use of Rust) and religion, politics, sexuality or morals.

[fishmicrowaver]

Is that stuff still going on? People were rather intense about certain politics during COVID, but outside of some furries on the Rust discord I haven't noticed anything outwardly political?

[4bpp]

I don't know how you would measure it, though I would assume that there is no particular reason for the people who use the language or their preferences to change? A quick search brought up that they apparently renamed their master branch to "main" very recently (https://blog.rust-lang.org/inside-rust/2025/10/16/renaming-t...) (context: https://sfconservancy.org/news/2020/jun/23/gitbranchname/), to the point I was more surprised that it hadn't already happened earlier.

The general temperature of politics in FOSS, I think, is not obviously lower than before: just in terms of things that made it onto HN, in the past month or so alone we have seen the aforementioned kerfuffle about dhh (the leader? founder? of Ruby on Rails), his projects and their detractors, and the wrestling over control between NixOS's board and its community moderators who were known for prosecuting political purges and wanted to assert formal authority over the former.

[timeon]

Reading loaded adjectives for programming languages is waste of time. I would skip that kind of social media.

[alt187]

People are (understandably) sick of the fact that for whatever reason, the biggest proponents of Rust are insufferable.

Personally, I'm simply bothered by the fact that (one of?) the most famous figure of Rust on Linux and Rust Forever consumes and advocates for pornography that's illegal in my country, without being held accountable by the community.

From what I could piece together, the only group who ever cried wolf about this is a forum full of contemptious little angry men who spend weeks researching people they hate on the internet. No one seems to want to touch the subject from fear of being associated with them.

I'll give it to you, this is not a great time.

[JuniperMesos]

I'm genuinely not sure who you're talking about or whether this is an accurate characterization of their views. For that matter, I'm not sure what country you're in and whether I myself agree with that country's laws about whatever kind of pornography this is. Certainly plenty of countries I don't live in and have no ties to have laws I disagree with or violate routinely.

I'm pretty suspicious of demands for communities to hold people accountable, especially when the community in question is a loose group of people who mostly communicate online and are united by their shared use of a specific programming technology; and who probably disagree on all sorts of other issues, including contentious ones.

[egorfine]

> advocates for pornography that's illegal in my country, without being held accountable by the community

If some form of speech is illegal in your country it does automatically mean it should be illegal for the whole world or that it is wrong or that the world-wide community should adhere to standards specific to your country. Even if that country is USA.

In other words, nobody should give a flying f about open source developers porn preferences.

[hofrogs]

Who are you talking about? Asking in good faith, I never heard of that controversy before

[alt187]

The (retired?) head of a project trying to port Linux on Mac. I avoid naming names, not to be cryptic but because a lot of people like to stumble on these kinds of posts via search. Or moderate them. I'm not agreeing, but I can see why it's easier.

[rs186]

> Personally, I'm simply bothered by the fact that (one of?) the most famous figure of Rust on Linux and Rust Forever consumes and advocates for pornography that's illegal in my country, without being held accountable by the community.

Your abhorrent personal opinion of another individual has no place in a technical discussion.

[rs186]

Please, don't use loaded, provocative, and most importantly, irrelevant terms in these discussions. It helps nothing and serves nobody.

[lelanthran]

The pushback is against the acolytes not the language.

If you could separate the language from the acolytes it would have seen much faster adoption.

[testdelacc1]

Acolytes being the people talking positively about their experience using a language and the strengths they think it has. So the people with positive opinions should say nothing at all, and the people with negative opinions should be free to share. And somehow, you think this will lead to faster adoption.

That’s an interesting thought. It would run counter to everything we know about human nature, but interesting nevertheless.

Rust is already pretty successful adoption wise. It’s powering significant parts of the internet, it’s been introduced in 3 major operating systems (Windows, Linux, Android), many successful companies in a variety of domains have written their entire tech stack in it. Adoption as measured by crates.io downloads has doubled every year for the last 10 years.

Now I’m imagining how much more widely Rust would be used if they had adopted your visionary approach of never saying anything positive about it.

[lelanthran]

> Acolytes being the people talking positively about their experience using a language and the strengths they think it has.

No, it's the people who have given rise to the multiple Rust memes over the years.

I'm battling to think of any other about-to-go-mainstream language that had the reputation of a hostile community. Scala? Kotlin? Swift? Zig? None of those languages have built such poor reputations for their communities.

After all, for quite a few years every thread on forums that mentioned C or C++ was derailed by Rust proponents. I didn't see C++ users jumping into Rust threads posting attacks, but there are many examples of Rust users jumping into C++ or C threads, posting attacks.

> That’s an interesting thought. It would run counter to everything we know about human nature, but interesting nevertheless.

Well, the fact that Rust is an outlier in this sample should tell you everything you need to know; other up-and-coming languages have not, in the past, gotten such a reputation.

[testdelacc1]

> I'm battling to think of any other about-to-go-mainstream language that had the reputation of a hostile community.

Because you’re young or you weren't around in 2010 when Go was gaining adoption. Same shit back then. People said “I like the language, it’s quite useful” followed by tirades from people who thought it was the end of human civilisation. It had exactly the reputation you speak of. (“DAE generics???”)

Eventually the haters moved on to hating something else. That’s what the Rust haters will do as well. When Zig reaches 1.0 and gains more adoption, the haters will be out in full force.

[lelanthran]

> Because you’re young or you weren't around in 2010 when Go was gaining adoption.

I've been working as a programmer since the mid-90s

>> I'm battling to think of any other about-to-go-mainstream language that had the reputation of a hostile community.

> People said “I like the language, it’s quite useful” followed by tirades from people who thought it was the end of human civilisation.

And? That's not the same as having a hostile community. I never saw Go proponents enter C# or Java discussions to make attacks against the programmers using C# or Java like I saw constantly wirh Rust proponents entering C or C++ discussions and calling the developers dinosaurs, incompetent, etc.

[testdelacc1]

> not the same as having a hostile community

Hostile according to who? According to the haters, maybe. I’m sure the Go community was called “hostile” by haters back in the day.

Look at the drama created by Linux maintainers who were being insanely hostile, coming up with spurious objections, being absolute asshats - to the point where even Linus said enough was enough. The Rust for Linux members conducted themselves with dignity throughout. The Linux subsystem maintainers acted like kindergarteners.

But of course, haters will read the same emails and confirmation bias will tell them they’re right and Rust is the problem.

Keep hating.

[noisem4ker]

> I didn't see C++ users jumping into Rust threads posting attacks

There absolutely are, and have been. You could say it's a reaction. I don't want to argue about who started it.

I agree with you that if the Rust community has gained such a peculiar reputation, it's also due to valid reasons.

[tempest_]

From the outside looking in most of the push back against rust seems to be of the "I am too old, never make mistakes, and don't want to learn a new thing late in my career" variety.

I have rarely seen an argument that pushes back against Rust with actual alternative solutions to the problems the rust proponents are trying to solve. It is mostly a bunch of old people letting the perfect be the enemy of the good.

[hunterpayne]

I think you got your last sentence backwards. Because reading it literally, you mean what we have now is perfect. If that's the case, switching to Rust is a waste of time.

[timeon]

> Scala? Kotlin? Swift? Zig? None of those languages have built such poor reputations for their communities.

> I didn't see C++ users jumping into Rust threads posting attacks, but there are many examples of Rust users jumping into C++ or C threads, posting attacks.

I already seen this with Zig. And even without language communities. Look at this whole thread. Look in to the mirror. Regularly when Rust is mentioned on HN. Anti-Rust cult comes to complain that there is Rust.

Even if someone just posts "I have made this with Rust" - then this cult comes and complains "why do you need to mention Rust?!". Like look at your self. Who hurt you?

[lelanthran]

> Look in to the mirror.

Pointing out that the Rust community has gained such a poor reputation while other communities have not requires "looking into the mirror"?

[kaoD]

In my experience from these threads, there are more people polluting the discussion by complaining about Rust "acolytes" than actual acolytes.

Rust haters seem strangely obsessed.

[lelanthran]

> Rust haters seem strangely obsessed.

Well, this is a great example. People complaining about the community are labeled as people complaining about the language.

Do you not see the problem here?

[whilenot-dev]

I think you'd need to give answer to your own questioning here... why did you take "Rust haters" as "Rust-language haters", and not as "Rust-community haters"?

[lelanthran]

> I think you'd need to give answer to your own questioning here... why did you take "Rust haters" as "Rust-language haters", and not as "Rust-community haters"?

Because it literally says "Rust haters"; not "Rust community haters".

Are you saying that when someone refers to "Rust", they mean the community and not the language?

[whilenot-dev]

Yes, you're half way there.

[timeon]

If you change it to "Rust community haters seem strangely obsessed.", it is still valid.

[lelanthran]

> If you change it to "Rust community haters seem strangely obsessed.", it is still valid.

Maybe. What does that have to do with the Rust community having such a poor reputation compared to other communities?

[tayo42]

Rust language and rust community are intertwined. It's a design descion from the language creators

[nicoburns]

> If you could separate the language from the acolytes it would have seen much faster adoption.

Good news: you can. And that's why it has had fast adoption.

(those advocating for Rust in "meme-like" ways are not generally the same people actually developing the Rust compiler or the core parts of it's ecosystem)

[hulitu]

> I don't quite understand the pushback against memory safe languages

As far as i read on HN, the only memory safe language discused on HN is rust and mostly with childish pro arguments.

[zozbot234]

Java and C# are memory safe languages, as are common interpreted languages like Python and Ruby. Even JavaScript is memory safe, barring the possibility of subtle JIT bugs that may practically impact such safety.

[kaoD]

But op means memory and data safe, without a GC nor a runtime, so it can be used as a systems programming language. For "some reason" people only talk about Rust in this space!

[JuniperMesos]

There are currently no widely-used programming languages other than Rust that offer the memory safety guarantees Rust has without a garbage collector. I think this is bad, and I wish more people would develop memory-safe systems languages that explore other parts of the design space like Rust does. But in the meantime, Rust is pretty good, certainly preferable to C or C++.

[zozbot234]

Swift is also memory safe in that sense.

[rs186]

It has a gc in the general sense of that term.

[hypeatei]

Swift uses Automatic Reference Counting (ARC) which is a form of garbage collection.

[kaoD]

Now I'm curious, how does it GC cycles, if at all?

EDIT: from a brief search: it doesn't.

[kaoD]

Not sure why you're downvoted, RC is definitely a form of GC even if not a tracing GC.

[egorfine]

Even modern C++ is memory safe when used properly.

[ameliaquining]

By that definition, all languages are "memory safe when used properly".

[egorfine]

Well. Yes. Lol

[modulared]

That doesn't really make sense since memory safety is a property of a language. You can have code that is unsafe (read unsound), but that is a separate issue.

For a language to be memory safe it means there must be no way to mishandle a function or use some object wrong that would result in an "unsafe" operation (for Rust, that means undefined behavior).

That is to say the default is safe, and you are given an escape hatch. While in something like c/c++ the default is unsafe.

I'd also like to add that program correctness is another separate concept from language safety and code safety, since you could be using an unsafe language writing unsafe ub code and still have a correct binary.