You don’t have to wonder. ActivityPub is shit. There is zero reason to use it if you’re not locked in already by network effects.

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.

I always wonder who is the target audience of such shallow fallacy-filled pretend-insightful faux-wisdom. But then I remember that most people waste a lot of time following <topic> aggregator/discussion sites are young impressionable enthusiasts who don’t know much.

Let me do the humble action of quoting myself 🙂 from 5 months ago:

There has been murmurings, mainly from non-technical people, about how “AI” will render advancements in safer type systems nearly useless, because the magic ^(mushroom) AI will just find all the issues in code written in older languages. What they don’t realize is that the effect will be reversed. Many established projects that come with a high reputation, and a veneer of maturity, indestructibility, and meticulousness, will simply, and perhaps unfairly, lose that perception under the continuous barrage of potentially high impact bugs and vulnerabilities surfaced by these tools, with not enough human bandwidth to keep up with them, and with new code susceptible to the same problems repeating over and over. This will effectively lead to an even harder push for adopting technologies that prevent a good chunk of these bugs from ever happening at any point, not the other way around.