Maybe they are just really tired of having to deal with people who constantly object and throw every possible obstacle they can on the way.

I think you'll experience some pushback on the assertion that that particular quote has a lot of arrogance or disdain in it.

Building large legacy projects can be difficult and tapping into a thriving ecosystem of packages might be a good thing. But it's also possible to have "shiny object" or "grass is greener" syndrome.

They are the tech version of vegans.

(yes, I know it's not all of them just like not all vegans have to preach)

> What is it about Rust fanatics [....]

The universalization from one developer's post to all Rust "fanatics" is itself an unwelcome attack. I prefer to keep my discussion as civilized as possible.

Just criticize the remark.

Is it the borrow checker? Normally rust had your back when it comes to memory oopsies. Maybe we need a borrow checker for empathy..

from the outside it looks like a defense mechanism from a group of developers who have been suffering crusades against them ever since a very prolific c developer decided rust would be a good fit for this rather successful project he created in his youth.

All compilers do anyways is translate from one language specification to another. There's nothing magical about Rust or any specific architecture target. The compiler of a "memory safe" language like Rust could easily output assembly with severe issues in the presence of a compiler bug. There's no difference between compiling to assembly vs. C in that regard.

The problem is that rust is being shoved in pointless places with a rewrite-everything-in-rust mentality.

There's lunatics that want to replace basic Unix tools like sudo, etc, that are battle tested since ages which has been a mess of bugs till now.

Instead Rust should find it's niches beyond rewriting what works, but tackling what doesn't.

>tool that can translate memory-safe Rust code into memory-unsafe C code

Fwiw, there're two such ongoing efforts. One[1] being an, written in C++, alternative Rust compiler that emits C (aka, in project's words, high-level assembly), the other[2] being a Rust compiler backend/plugin (as an extra goal to its initial being to compile Rust to CLR asm). Last one apparently is[3] quite modular and could be adapted for other targets too. Other options are continuing/improve GCC front-end for Rust and a recent attempt to make a Rust compiler in C[4] that compiles to QBE IR which can then be compiled with QBE/cc.

[1]: https://github.com/thepowersgang/mrustc [2]: https://github.com/FractalFir/rustc_codegen_clr [3]: https://old.reddit.com/r/rust/comments/1bhajzp/ [4]: https://codeberg.org/notgull/dozer

> As an end user, it doesn't concern me too much ...

It doesn't concern me neither, but there's some attitude here that makes me uneasy.

This could have been managed better. I see a similar change in the future that could affect me, and there will be precedent. Canonical paying Devs and all, it isn't a great way of influencing a community.

[delayed]

Given that Cargo is written in Rust, you would think there would be at least one battle tested solver that could be used. Perhaps it was harder to extract and make generic than write a new one?

[delayed]

what makes it unreadable for you?

Syntax tends to be deeply personal. I would say the most straightforward answer to your question is "many people disagree that it is unreadable."

Rust did build on the learnings of the past 20 years. Essentially all of its syntax was taken from other languages, even lifetimes.

I would encourage you to give it a try anyways. Unfamiliar syntax is off-putting for sure, but you can get comfortable with any syntax.

Coming from Python, I needed to work on some legacy Perl code. Perl code looks quite rough to a new user. After time, I got used to it. The syntax becomes a lot less relevant as you spend more time with the language.

What are you talking about? Rust’s function signature and type declaration syntaxes are extremely vanilla, unless you venture into some really extreme use cases with lots of lifetime annotations and generic bounds.

I seriously don’t get it.

    fn add(a: i32, b: i32) -> i32 { … }

Where’s the “Perl-esqueness”?

Seems like a fairly decent syntax. It’s less simple than many systems languages because it has a very strong type system. That’s a choice of preference in how you want to solve a problem.

I don’t think the memory safety guarantees of Rust could be expressed in the syntax of a language like C or Go.

> Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & frustrations - overall the language has a "pseudocode which compiles" approach, which I appreciate.

I think this is why you don’t like Rust: In Rust you have to be explicit by design. Being explicit adds syntax.

If you appreciate languages where you can write pseudocode and have the details handled automatically for you, then you’re probably not going to enjoy any language that expects you to be explicit about details.

I'm writing this as a heavy python user in my day job. Python is terrible for writing complex systems in. Both the language and the libraries are full of footguns for the novice and expert alike. It has 20 years of baggage, the packaging and environment handling is nothing short of an unmitigated disaster, although uv seems to be a minor light at the end of the tunnel. It is not a simple language at this point. It has had so many features tacked on, that it needs years of use to have a solid understanding of all the interactions.

Python is a language that became successful not because it was the best in it's class, but because it was the least bad. It became the lingua franca of quantitative analysis, because R was even worse and matlab was a closed ecosystem with strong whiffs of the 80s. It became successful because it was the least bad glue language for getting up and running with ML and later on LLMs.

In comparison, Rust is a very predictable and robust language. The tradeoff it makes is that it buys safety for the price of higher upfront complexity. I'd never use Rust to do research in. It'd be an exercise in frustration. However, for writing reliable and robust systems, it's the least bad currently.

The family of languages that started with ML[0] mostly look like this. Studying that language family will probably help you feel much more at home in Rust.

Many of stylistic choices from ML derivatives have made their way into Swift, Typescript, and other non-ML languages.

[0] https://en.wikipedia.org/wiki/ML_(programming_language)