[aw1621107]

> is using Rust a form of avoiding responsability?

How so?

> considering the fan reaction to a post disparaging their favorite language, how is the Rust community different from a religious cult now?

Believe it or not, not all criticism is created equal. High-quality criticism is consistently well-received from what I've seen. This doesn't seem to get particularly close to that bar.

[nottorp]

I don't think i've seen on HN discussions any criticism directed at rust that was acknowledged as high quality though.

[aw1621107]

Probably the best example I can think of off the top of my head is "Leaving Rust gamedev after 3 years", which got a fair bit of (positive!) attention both on HN [0] and on /r/rust [1]. If you look through the comments there a huge proportion of them generally agree with the article, and the top comment explicitly calls it "a good article". On /r/rust Josh Triplett (one of the Rust devs) has the top comment on the post basically acknowledging that the criticisms are valid/reasonable and thanking the author for their feedback [2].

I've seen other criticisms spawn good discussions and/or a good number of people agreeing, but nothing quite as clearly on point as that off the top of my head.

[0]: https://news.ycombinator.com/item?id=40172033

[1]: https://old.reddit.com/r/rust/comments/1cdqdsi/lessons_learn...

[2]: https://old.reddit.com/r/rust/comments/1cdqdsi/lessons_learn...

[nottorp]

> How so?

As in: we're using a safe language, it's not our fault.

[aw1621107]

The answer might depend on what exactly you mean by "it", but in any case I'm inclined to disagree. Perhaps you can call using Rust "avoiding responsibility" for memory safety errors, but I don't think that's a particularly useful thing to say since you can say something similar about using calculators/theorem provers for avoiding math errors, FEA for avoiding simulation/math errors, etc. Sure, you're not actually responsible for putting pencil to paper and writing out the algebra/matrix manipulations/theorem derivations/etc., but it's far from unusual to consider using those tools the "responsible" choice where their reliability and/or effectiveness over human work is well established.

In addition, there's almost always something more going on than using a particular tool and you're generally still going to be responsible for that other stuff anyways. For example, if you're working on something critical and high-integrity you're responsible for the end product functioning as intended no matter how exactly you go about doing that. Using something like SPARK might be a smart way to go about that, but you still need to have processes before using SPARK (e.g., verifying the specifications you're going to implement are what you intend) and processes after using SPARK (e.g., verifying what you implemented is actually what you intended, that the product is indeed working as expected, etc.). If a bug in SPARK results in something unintended happening, you may not be responsible for the faulty proof itself but that's only one failure out of multiple in the entire pipeline - for example, you can't pin a failure to catch the error in testing on SPARK.