[berkes]

"Written in Rust" signals some common attributes.

Fast, Safe, Lightweight, Statically linked (plop a precompiled binary in ~/.local/bin and run it), few/shallow dependencies, senior developers, "Done" software.

Now, certainly no guarantees, enough counter-examples, I know. And attributes that one can get with anything from PHP via Javascript to Lisp as well. Some attributes have stronger correlation than others too.

But, in general, "rust" has a (much) higher chance of meeting these attributes. I care about those attributes above anything else.

[gspr]

I'm happy to label myself a Rust fanboy, but

> few/shallow dependencies

is just flat-out wrong. There's (sadly) a big culture of sprawling, deep dependencies in the Rust community. There are of course many counterexamples too, but it's definitely not correct that Rust signals the virtue you refer to.

(Incidentally, the misguided idea among some that as long as a dependency isn't through FFI, it doesn't count as a dependency, is one of the things I dislike the most about Rust culture. That, and pervasive bundling.)

[dbdr]

> the misguided idea among some that as long as a dependency isn't through FFI, it doesn't count as a dependency, is one of the things I dislike the most about Rust culture

I have not heard that idea a single time. There's definitely the idea that FFI dependencies "count more" / add more baggage (because there's a bigger risk that the build fails, it's harder to investigate memory safety, ...). Absolutely not that a non-FFI dependency "does not count".

[gspr]

Sadly I couldn't find an example at the moment. We're probably better off striking my parenthetical claim then :)

[berkes]

Probably my reference is tainting this then. I come from Perl, PHP (both of which, at that time, had nonexisting or terrible package managing - CPAN, PEAR), then Ruby, with gems and now Python, Typescript/Javascript. Starting with Ruby, I've developed in communities that heavily depend on deep dependency trees.

For me, the discipline of shallow dependencies, no-dependencies etc, was new when I came to rust.

Sure, if I pull in something like Rocket, it comes with dependencies, that have dependencies that have dependencies. But Rocket is one of the more extreme examples I know of, and even that is nowhere near the depth of a tree that common (not extreme) npm frameworks/libraries come with. Before yarn I sometimes had node-module trees that went over 50 levels deep.

The Python community doesn't have this extreme deep dependencies, but in Python it is far more common to "from foo import bar" in both libraries and in applications than to write a few hundred lines of code yourself. The Django and "lean" flask, or "simple" cli apps I worked with and on, quite commonly have hundreds of dependencies (many of which are dependencies of dependencies etc).

Within that context, rust community is far more conservative. Many of the dependencies that I use have one, maybe two of their own deps. Many none. And it's more common - IME - to see libraries that have just one level of deps - the libs a lib depends on, itself won't have deps.

Though, I guess, C or even C++ community, lacking OOTB, common and easy dependency management like cargo, will be far more conservative even.

Rather than being "flat out wrong", I'd say it very much depends (pun intended) on where you come from and compare rust with.