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.

democratize

🤣

Great idea. Bureaucracy and reducing human ability to a single score is always the right process for assuring quality.

You’re probably more qualified than most HNers, just less confident, less inclined to indulge in performative expertise and pseudo-intellectual posturing, and more resistant to joining the circle-jerks with those who do indulge.

Parent mentioned that the supposed bug was already fixed, that’s not the point.

And they target GNU compliance, not POSIX compliance. Which is hard mode, since if it was the latter, they could have just checked out the freebsd utils or whatever at will whenever they felt unsure about something.

Also your implementation has a bug because dirname blah.png returns “.” 😉

It wasn’t meant as a 1-1 implementation, but fair enough.

I would argue that this helps my point. Because that’s an ambiguity dirname doesn’t help with. What if “bla.png” is, or expected to be, a dir?

And if you’re going to test, are you going to use shell bult-ins or the test command from coreutils? And if you’re calling test, are you calling it with the full path so you don’t get a shell builtin anyway or not?

If I was just going to use the built-ins I’d use Python or Ruby or something.

Using a better language is absolutely the right thing to do for anything that is not trivial.

Python is a shit choice for another reason though. They don’t know what backward compatibility means. So you may find your script broken in 2-3 years anyway. I don’t know about Ruby.

If you’re going to rely on shell scripts, you should stick to the built-in functionality of your shell as much as possible, as external commands can differ, or even be completely overridden, in random environments for a myriad of reasons.

For example, use ${var%/*} instead of $(dirname $var). Forking out a whole OS process for such minuscule tasks is stupid anyway.

This goes against la-la unix philosophy dreamy thoughts and beliefs, or portability fantasies. But it’s the right thing to do in the real world. And gives you at least some level of control over expected behavior.

While the feel-good kid stories we all heard and believed were nice, Linux would have never gone big if it wasn’t for a billion dollars dedicated by IBM to development in the 90’s, and continued funded development from other companies like RH (which IBM ironically eventually bought).

Most software installed in your system right now is not gnu-licensed btw. Fully functioning non-gnu distributions (sans the kernel) already exist too, with no tangible effect on the user experience for most.

This is a great comment. Not because it’s more stupid than the others, or because of the hilarious scenario envisioned. But because it transparently introduces the cognitive dissonance around liberal licenses, while still presenting as agreeable among the clueless.

The best way to “sell” open source code is to license it non-liberally while retaining copyright fully, or retaining the right to re-license for 3rd parties. And guess what, the latter is what Canonical does with its GPL-licensed projects + their contributor agreement.

In fact, you can go too copyleft to the point of becoming non-free (e.g. the SSPL).

The reason why liberal licenses are framed as corpo-friendly is because corpos can just take, they don’t need to “buy” anything.

Still the hilarious theories around “selling” coreutils, and the continued general ignorance about practically everything from the gantry here, gave me a good chuckle. Although its all starting to get derivative and repetitive.

Manual runtime type classes!

And I thought “stringly typed” couldn’t be topped in webshit meme-ry.

Man, webshits are funny 😊