One thing where Rust is rather lacking is the missionarism of some people in the community.

The Rust Evangelism Strike Force is a huge turnoff to the language. It's gotten to the point where we can't have reasoned discussions about C++ or C, let alone about their merits, without a newly enlightened user coming in and trying to direct the conversation to Rust.

It's really okay to have a future where C++ and Rust are both popular, widely used languages. I'm happy to acknowledge the merits of Rust as a language and even talk about them without inserting it into every conversation about low-level computing.

I'm sure the language designers and core developers don't actively endorse this behavior, but somewhere along the way it became a core part of the culture. This world domination shit has to stop.

Their entire selling point is that c is dangerous and rust is safe. It sort of creates an adversarial relationship.

That said, while it might be annoying to serious c programmers, they aren't really the intended audience. It's new programmers that matter. Or people who bounce between languages anyway.

> "The Rust Evangelism Strike Force"

Instant classic

I think it was coined by http://n-gate.com (mentioned in HN a few times last month), but I can't be sure.

What I do know is that a) it's hilariously on point b) Google search now autocompletes on it for me.

FWIW, the behaviour is not just not endorsed, but actively disendorsed, e.g. the code of conduct (which applies to the Rust-team-run venues) includes "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.", and /r/rust has a "No zealotry" rule. Both of these are enforced in their respective spaces, and both of these have existed for years: they're not a reaction to the recent RESF meme.

It's... harder/less-defensible to enforce codes of conduct/rules like these in third-party spaces, but Rust people still do often call out incorrect assertions/ridiculous comments. Someone not familiar with the community may not recognise that the people doing the calling out are actually "prominent" voices.

This is like the evangelists' attempt to distinguish "safe rust" from "unsafe rust": it's a distinction without difference. "The community" isn't just the inner circle of official Rust team members and evangelists and their particular forums where they can enforce any policy as aggressively as they like. For better or worse, "the Rust community" will necessarily be bigger than that if/as Rust grows.

My view is that Rust risks a similar track as Haskell if the community continues to grow in the way it has recently. It's not a healthy community, outside of the circles you note. Quite the opposite--I view it rather as being fairly toxic.

I don't understand what exactly you're disagreeing with. I was strengthening "I'm sure the language designers and core developers don't actively endorse this behavior", and also mentioned how those people do try to keep discussions truthful and relevant outside those spaces.

So true.

I want rust to take off, as even bounds checking at compile time would save me a lot of trouble.

I don't know if I'll ever be able to deal with the community, though.

On the other hand, I've never seen people get as passionate about c++ as I have python and rust, so maybe that says something about the benefits, even if its just as beginners see them.

I think you see people passionate because they've dealt with all the pain around C++. That said I don't agree with the GP. As much as I like Rust there's still a ton of areas that keep Rust from being used today. Library selection, even though it's hard to hire for C++, it's easier than Rust and a few other things.

That said for all my personal/greenfield stuff I've been using Rust and really happy with it.

There's a lot of people passionate about it because it's the first low-level language that's reasonably approachable to people who mostly code in Python/Ruby/etc - you rarely ever have to pull out a debugger, for example.

Haha, oh you definitely have to pull out the debugger. Rust doesn't save you from logic errors, control flow issues and ffi gone wrong.

That said I get your point about using the debugger less.

Honestly, my programs tend to be simple enough that logic errors are reasonably rare, and the ones that do pop up can be resolved by println debugging. :)

> Honestly, my programs tend to be simple enough that logic errors are reasonably rare

That says more about the particular programs you write than about the language, frankly. Writing trivial bug-free programs is easy in any language. The trick is writing complex bug-free programs.

> println debugging

This is something you should only need to do if you have a wretched debugger of if you're working on a bug where the presence of the debugger alters its behavior.

> Writing trivial bug-free programs is easy in any language.

Not really. Writing programs which don't crash the first few times I run them in a dynamic language is surprisingly hard. Just having a compiler prevents having to get to that point - and then Rust ensures that I handle potential errors correctly and avoid segfaults.

> This is something you should only need to do if you have a wretched debugger of if you're working on a bug where the presence of the debugger alters its behavior.

Or if I can't be arsed configuring gdb with breakpoints for everything from the command line. I can add a println!(), save my file, and watchman will recompile and run my program in a much more reasonable (to me) workflow. I assume that I can somehow integrate gdb into my editor, but that involves a pile of learning new things.

For a so-called "trivial" app I'm most of the way through writing right now, is an OpenID Connect and SCIM server that has had to implement a decent chunk of functionality (JWTs, key fetching and caching, juggling between postgres and redis, etc) from scratch. But for most of the particularly fiddly parts, I've managed to have the type system ensure that I either outright can't have logic errors or they're detected and the program panics, which is rather nice.

> Writing programs which don't crash the first few times I run them in a dynamic language is surprisingly hard.

Writing correct programs in JS is difficult, I agree. Writing correct trivial programs is easy, though.

> Or if I can't be arsed configuring gdb with breakpoints for everything from the command line. I can add a println!(), save my file, and watchman will recompile and run my program in a much more reasonable (to me) workflow. I assume that I can somehow integrate gdb into my editor, but that involves a pile of learning new things.

That's not a third alternative, that's just gdb being wretched, as it's always been.

I find that within the Rust community people are amazing, it's just at the boundaries that I've found problems.

Seems naive for rust to try to persuade you to use their language when the right way is to launch under the aegis of a vertically integrated corporate platform. You need an HP, Sun, MS, Apple or Google foisting you on developers to have any shot at mainstream success.