> people who didn't like Rust flocked to Zig as an alternative, and were keen to promote it as an alternative to Rust by criticising Rust, as wider usage would provide them more of an ecosystem to use in their own Zig programs.

> People who were happy with Rust didn't have same need to criticise Zig in online spaces as Rust is the established player in the C alternatives space. (Though Rust is on the other side when compared to C once you expand the space to "all low level programming languages").

I think that this effect is...more real and intentional than I wish it was or think is healthy.

There's no denying that Rust benefited greatly from heavy "language evangelism" from around 2014-2022 or so (rough subjective range of dates, ending with when I feel like Rust became sufficiently mainstream that "comment section evangalism" is no longer the primary driver of the language's growth). The atmosphere that surrounded the language evangalism during this era -- from my recollection as someone who was aware of Rust but explicitly not interested in it at the time -- felt like one of curiousity and exploring new innovation in the programming language design space, and it didn't come across as pushy or some kind of moral imperative.

Additionally, most of the evangelism was not driven by the Rust project itself, but more of a grassroots thing from:

- Early users

- People who thought the language was interesting without having used it

- The attention that came from prolific early Rust projects like Servo and ripgrep

- The attention that came from the language's technical innovations

(The only person I remember regularly seeing in Rust threads who was actually associated with the project was Steve Klabnik, and I consider him a stellar example of how to represent a project online in a way that's respectful and not pushy or combative.) And eventually I had a programming task where, thanks to those deep, insightful, and respectful comment threads, I recognized that Rust was the right tool for the task I was trying to accomplish, learned the language myself, found it a joy to use, and began using it more regularly.

But once Rust became mainstream, the eternal September kicked in. Now there seem to be quite a lot of people who are more interested in "language wars" than in healthy, technical discussion of programming languages, and it's exhausting. Many threads about C or C++ or Rust or Zig or Fil-C or whatever seems to get overtaken by these obnoxious, repetitive, preachy, ideological comments about why you should or shouldn't be using Rust, often with very ill-informed armchair takes.

I think this is just something that comes from mainstream Internet culture and is not very representative of "the Rust community", and especially not the Rust project -- most of the serious writing and comments coming from people actually involved with Rust have that spirit of respect, openness, and curiousity about programming language design that I remember from the 2010's. A lot of people who work on Rust are deeply interested in the tradeoffs and innovations of new programming languages and fundamentally excited about the possibility of Rust becoming obsolete because something better has come along. But now that Rust adoption is increasing and the broader Internet culture is being forced to consider it, you see a lot of unhealthy reactionary takes from people who act like programming languages are a zero-sum game and they need to pick a side.

Now Zig is where this gets a little bit odd to me. My impression (as an outsider to the Zig community as well) is that Zig's leadership has chosen to view adoption as a zero-sum language war. It's as if they considered:

- How Rust benefited from language evangelism during the 2010's

- How many other "C-replacement" languages over the past 25 years have failed to gain large-scale adoption

- How "language war" discourse is extremely effective for enagement on places like HN

...and decided that the best way to increase Zig adoption is by intentionally leaning into that high-engagement "language war" discourse. Maybe it's not intentional -- and there's certainly a lot of cool ideas and high-quality technical discussion that comes out of the Zig community -- but I've also seen a consistent pattern of snarky or hostile comments from Zig leadership towards Rust people (such as calling Rust users "safety coomers", or jumping into in-depth technical discussions of Rust's downsides like compiler performance with substance-less cheap shots). Whereas I can't remember ever seeing anything but respect and curiosity from people involved in the Rust project towards other communities.

I'm just tired of seeing people draw battle lines around programming languages instead of promoting a spirit of learning from each other and making our tools better.

Non-negligible from what perspective? Is this group of people somehow holding back unbridled adoption and enthusiasm for Rust? Is it possible for tech people to drum up excitement for a newer language without it being political just because you insist that it is?

> * With a great non-political community (actually, this is the biggest lie of all).

I recall the opposite, that the rust language (before the foundation) position was that being apolitical was a political stance. This is not the exact message I remember https://x.com/rustlang/status/1267519582505512960 and also can't realistically cover the entire community at large, as if that even has a single political stance.

I agree that those were not actually "promises" but "directions", and I apologise for that. Those directions were mainly cited in different conferences by some Rust-head-members at that time (Alex Crichton, Niko Matsakis, Ashley Williams, or even you), and during conversations I had with severals during Rust Fest or RustCon.

For example, I remember talking that with you at the Rust Fest 2017, in Zurich actually, especially about the *very early version* of Async/Await.

It is ok for the community to move on different directions than the first one, and I don't blame any of you for that.

Non-political almost always means "accept the social status quo I am used to".

I think there is a reasonable argument that the default for a community with technical goals should be to accept social status quo conventions unless they conflict with the communities technical goals. But if the social default is "girls don't code and queers should hide" there is a reasonable counterargument that these conflict with the goal of making the technology (and community) available to everyone.

> "Non-political community" is an oxymoron

No it's not.

I'm an LGBT person with a trans partner and I find many codes of conduct to be chastising and purposefully finger pointing to conservative people.

A lot of them are basically, "your religious teachings or cultural upbringing aren't welcome here"

I don't agree with religious texts, but that's what you're wagging in their face with some of the CoCs.

Leave it at "don't be an asshole". It's that simple.

The current political climate, I feel, is a direct reaction to this.

A politically neutral space wouldn't permit religious people to harass trans or LGBT people, but it also wouldn't give anyone latitude to throw stones the other way either.

CoCs are "you're not welcome here at all".

Another thing: you always see language and project logos modified to bear the rainbow, trans, and BLM colors. You never see anything supporting Asians, white people, men, or Christians. If you did this, you would be called out as a racist. Which is so ironic.

Let's just get along and work together. Maybe we'll find more agreements amongst ourselves that way instead of trying to divide everyone into camps.

Some progressives are going to get very pissed off at this comment, but I grew up and live in the South. You can (and often must) work with people you don't agree with. It's not impossible to be friends either. You might wind up changing their mind, and they might wind up making you more tolerant as well.

[dead]

So let me get this straight. You want the benefit of being able to re-use other peoples' codebase by using an HTTP crate you didn't write. But you don't want those people to also use that benefit of depending on other crates.

Insisting that you should depend on code which itself has no dependencies is a bit hypocritical if you ask me. If you want a simple HTTP crate that doesn't have dependencies, you should follow your own philosophy of not using other crates and write it yourself.

> As an example, I still do not understand why simple HTTP crates require more than 50 to 70 dependencies to execute a simple GET call...

Looking at ureq [0], for example, its direct non-build/non-dev dependencies are (counting duplicates):

- base64

- flate2 (4 transitive dependencies)

- log

- percent-encoding

- rustls (26 transitive dependencies)

- rustls-pki-types (1 transitive dependency)

- ureq-proto (7 transitive dependencies)

- utf-8

- webpki-roots (2 transitive dependencies)

The vast majority of the raw dependency count comes from Rustls and related crates, and I'd imagine reimplementing a TLS stack would be somewhat out of scope for an HTTP crate. I'm not sure there's much room for substantial reductions in dependency count otherwise.

[0]: https://github.com/algesten/ureq

I think it's clear to me that Rust needs to start admitting more into the STD to help with this and increase the consistency across the ecosystem.

> As an example, I still do not understand why simple HTTP crates require more than 50 to 70 dependencies to execute a simple GET call...

This is what you get with package managers.

I have to disagree. Rust is not even close to behemothness of C++.

I haven't dabbled in rust since 2018, but if rust has managed to be as complicated as C++ while being a fraction of the age then I would think that would be some kind of macabre achievement in its own right.

Both are, indeed, and I don't know if this was ever promised, but Rust is way simpler than C++ (today, at least).

Is "Rust" a homogeneous blob of beliefs that you can side with?

[dead]