Yeah sure.

The problem with those people is that they don’t actually know how any software is really built. Even in their simple “Makefile” supposed utopia, tools like pkg-config, just to name one example, could be running from behind their backs, and they wouldn’t know what that is, that it’s getting executed, and what purpose is it serving in the build process.

And both are still not mutually exclusive. Just like how in C or C++ projects you can both use a proper build system, and still have Makefile(s) around (as fallback, or used as simple runners, or also for tooling reasons).

Putting vendoring aside, using and not using cargo is itself not an either or. Some projects that incorporate Rust as a non-primary language can still use their own build system, and yet still optionally have cargo around for tooling reasons (e.g. to make LSP just work without much hassle), both at the same time. See this demo for an example (meson for actual building, cargo for tooling/development).

I also have no idea why you exchanged this long with a person who clearly lacks basic knowledge. But maybe I grew more abrasive and less patient than the average person with my greying hair.

You don’t get any of that when you vendor, and you’ll have to manually actively monitor your dependencies for vulnerabilities anyway.

Incorrect. Vendoring done right (via replace-with, as done by cargo vendor) is not mutually exclusive with the rest of the tooling. You can have both.

• You’re clueless about how cargo itself wraps/calls rustc. And how other build systems are doing the same, including the one literally mentioned in OP. “Because having rustc as a standard tool is not there yet” is a completely meaningless nonsensical sentence. Neither is rustc lacking in any way, nor is cargo imposing any sort of hard requirement on itself.
• You’re clueless about how cargo works. How it natively supports both vendoring (with a single command) and multiple other ways of source replacement.
• You’re clueless about the fact that rust statically links std by default, and the fact that the ABI is not stable between major rust versions which is a deliberate choice. And thus, the attempt to draw parallels with “C repo and make” is yet another indicator of your cluelessness.

There is more. But I don’t have the time untangle the webs of cluelessness in your comments.

I think you’re clearly clueless and should stop opining on matters you know nothing about.

If you didn’t automatically register that requiring spawning full OS processes to scale performance immediately disqualifies a language from a whole plethora of use-cases (which is what the intellectually deficient OP tried to argue against), then I’m not sure you’re qualified to opine on the matter (hint: spawning a thread per task is already too much overhead for many workloads). And I don’t mean any disrespect to you here. Your replies were far from the worst in this thread.

Frankly this thread has been very illuminating. My perception of the average p.d user and their concrete knowledge was very inflated.

And we didn’t even get to low level stuff yet. People are already failing at the macro level. Sad.

It’s not outdated, and maybe you didn’t get what I was talking about, but probably because I didn’t word it well. So let me quote someone else instead:

While pure Python code should work unchanged, code written in other languages or using the CPython C API may not. The GIL was implicitly protecting a lot of thread-unsafe C, C++, Cython, Fortran, etc. code - and now it no longer does. Which may lead to all sorts of fun outcomes (crashes, intermittent incorrect behavior, etc.)

This covers the layers below python, but still doesn’t fully cover the process wide restrictions (it’s not just about thread safety, global initialization and resources are very relevant too). It also doesn’t cover the exact same problem which also exists for any layer calling into python from above, which also relies/relied on the GIL for synchronization. This means that you can’t effectively, confidently, and safely scale python without scaling the number of python runtime instances, each in its own full OS process.

The fact that multiprocessing became popular, instead of just scaling/parallelizing with threads, is itself an extension of the GIL/no-GIL circus. But its not the primary point here.

So not only the proposition (which someone referenced in another sub-thread) to move everything into python is in and of itself a self-defeating argument, since it proves a language being a problem (through forcing language lock-in). But even within a language (python), not all problems are solvable still.

Note that this is not all theoretical for me. In one of my previous projects, I had to call into a python library (which didn’t have an adequate alternative) from rust code (through pyo3). And I was forced to scale with multiple python runtimes, each getting one request/message at a time.

And we still didn’t get to any low-level details yet 😉

What about the fact that runtime startup alone auto-disqualifies python for all short-lived process use-cases?

Or the fact that you can’t do concurrency especially across the language barrier from another language without multiple python runtimes orchestrated with a queue and IPC because of possible process-wide global state and similar concerns/assumptions for any python library dependency that is not all native across its own dependency chain?

“languages are just tools” and “use the right tool for the job” were already stupid catch phrases. Pretending languages don’t matter is a big further step into this shallow faux-intellectualism masquerading as wisdom.

And we didn’t even get to low level stuff yet.