Programming thread

[unleashthefreak]

Softgen

I despise these things. Facebook did something similar. All it does is copy templates like https://tailwindcss.com/plus/templates, https://vercel.com/templates/saas, https://github.com/wasp-lang/open-saas, or sometimes an internal boilerplate template.
If you use it for anything seriously more advanced than replacing the placeholder text in "github free X template", it doesn't work.

$25 for frontend isn't bad.

True. I think the speed is even more of an advantage, instead of having to back and forth with someone on fiverr or whatever, where a layperson would just be drawing photos or sending screenshots of websites they like.

as a language designer it is your priority to allow the system package manager to handle everything

Why?

2016 nigger package manager brainrot

Care to elaborate?

 

[Private Tag Reporter]

I don't get why I'd pay $25 for frontend when I can make an only slightly uglier thing myself for free. There's nothing interesting going on in frontend land other than trying to center a div, which I'm pretty sure has been proven incalculable by scientists at Harvard and MIT.

 

[Spungus]

Probably a lame question to ask in this thread but is learning to code as a lateral career move (edit: still) worth it?

Spoiler: Context

I’m in early stage of a (real) engineering career and I’ve been learning C++ to fulfil a childhood aspiration. It seems like something I wouldn’t hate working in, so wondering in idle curiosity if it’s (financially) worth the hassle of trying to switch considering I don’t have a relevant degree or experience and the job market seems to have changed with all the Indians + AI.

The advice I've been giving to people in situations a bit less involved than you is that if you have a genuine passion for it, then yes. If you get in programming purely for the money and without passion, you'll end up as no more than the technological slave-caste. Money comes from having value, you have value from having a niche, and that niche comes from actual interest.

 

[Creative Username]

Why?

300 package managers = 300 piles of retarded brainrot and 300 potential malware vectors
1 package manager = single program that does 1 thing and does it really well (not duplicating effort many times)
also since programs are generally supposed to do one thing and do it well it's stupid to NIH something the OS generally provides
100% of your effort should be focused on making a good compiler and precisely 0% of it should be focused on making a shittier version of the system package manager using a gay libcurl binding you wrote for your language

Care to elaborate?

it's very retarded to write a package manager solely for your language
if you really think your new package manager will solve everybody's problems, it is your moral duty to make it able to work with every single piece of software in existence instead of making a shitty NIH nigware

 

[TroonsDid911]

Can people smarter then me confirm if there is anything to this story or if its just fake news from an undergrad and the professor sodomizing him?

https://www.quantamagazine.org/undergraduate-upends-a-40-year-old-data-science-conjecture-20250210/

Sorry no archive, Im on the toilet at work and its not lolcow related.

Edit: I think this is the actual Paper:

https://arxiv.org/abs/2111.12800

 

[unleashthefreak]

300 potential malware vectors

It doesn't follow, necessarily, that using more software increases the chance of getting "malware". This contradicts the philosophy of "do one thing and do it well", because more programs supposedly mean more "malware vectors".

single program that does 1 thing and does it really well

Imagine the needs of a package manager for Language A and Language B are mutually exclusive. How do you reconcile this? Supporting every single programming language (and everything else) obviously necessitates compromises.
Further, there is not a "single" system package manager. Should the developers of every language write the code to bring pacman, apt, brew, winget, etc. all up to first-class standards for their language?

programs are generally supposed to do one thing and do it well

What is the "one thing"? Installing every package for every language for every operating system? Surely limiting scope to one language lessens the scope of the "thing" and does it more "well".

100% of your effort should be focused on making a good compiler and precisely 0% of it should be focused on making a shittier version of the system package manager using a gay libcurl binding you wrote for your language

12 women can't create a baby in 1 month. A good compiler and a good ecosystem (including package manager) are not mutually exclusive.

it's very retarded to write a package manager solely for your language

I didn't think of this, but now I realize the error of my position.

if you really think your new package manager will solve everybody's problems

The goal of a package manager for a language is simply to solve the problems of managing packages for that language.

 

[WielkiWapiesz2137]

Name one programing language specific package manager that is not dogshit.

 

[Lard Shart]

Here's the two best package managers that work with any language:
1. git clone
2. wget + unzip
Take the vendoring pill.

 

[Creative Username]

It doesn't follow, necessarily, that using more software increases the chance of getting "malware". This contradicts the philosophy of "do one thing and do it well", because more programs supposedly mean more "malware vectors".

the point is to not have every single compiler also handle connecting to the network, but to have a single system that deals with all the potential security issues while being language-agnostic
especially with the principle of least privilege and all that, all software should be buildable inside a locked-down vm with no internet
to support that standard, either every language package manager will have to start writing container code for every platform or:
JUST LET THE SOFTWARE WHOSE JOB IT IS TO HANDLE THIS EXACT THING DO IT INSTEAD

Imagine the needs of a package manager for Language A and Language B are mutually exclusive. How do you reconcile this? Supporting every single programming language (and everything else) obviously necessitates compromises.
Further, there is not a "single" system package manager. Should the developers of every language write the code to bring pacman, apt, brew, winget, etc. all up to first-class standards for their language?

how the fuck can a package manager not "meet the needs" of a programming language? it's supposed to fetch libraries from the network and shit them out on disk somewhere where the compilers and linkers can see them, and maybe create containers and shit if you're feeling really fancy. if language a or b really can't find the special folder for packages installed for compiler 4.7 that the package manager sets up, it sounds like their toolchain is completely fucked up and they need to just delete their repository and go back to whatever the fuck day job these shit language designers all have

What is the "one thing"? Installing every package for every language for every operating system? Surely limiting scope to one language lessens the scope of the "thing" and does it more "well".

a package manager downloads signed archives from the network, verifies them, and installs them in standardized locations. it does not need to know or care whether the files it downloads are in c or python or perl or compiled binaries or god knows what, it just makes sure that /usr has the files related to packages that the user asked for

good ecosystem (including package manager)

a good ecosystem means it's like c where even debian packages all your libraries
a good ecosystem does not include a language package manager (these are actually cancerous ecosystems)

The goal of a package manager for a language is simply to solve the problems of managing packages for that language.

which is mostly a solved problem, except instead of setting up user repositories for various system package managers they decide to reinvent the wheel and usually end up with something that isn't particularly circular

Name one programing language specific package manager that is not dogshit.

well earlier you mentioned guix which is the official language package manager for guile
the people behind it are just making a system package manager though

Here's the two best package managers that work with any language:
1. git clone
2. wget + unzip
Take the vendoring pill.

sounds great but then you end up with 540mb static binary and some ancient library somewhere with a remote code execution bug

 

[unleashthefreak]

the point is to not have every single compiler also handle connecting to the network, but to have a single system that deals with all the potential security issues while being language-agnostic

"Connecting to the network" is not some evil thing full of security issues in 2025, and even if it were, your assumption that language-specific package managers have inadequate handling with "security issues" is baseless. Why even have a package manager at all? That truly minimizes surface area.

all software should be buildable inside a locked-down vm with no internet

How is downloading a package with an OS package manager different from a language package manager in this regard?

every language package manager will have to start writing container code for every platform

This is fine. And with modern languages, cross-platforming is usually not so difficult (e.g. Rust).

a package manager downloads signed archives from the network, verifies them, and installs them in standardized locations

This is a faulty assumption. Even if we assume that their is one package manager, and different operating systems to not make opinionated judgements with their package managers, there are many subjective judgements made by even a single package manager.
"signed archives": Signed with what? Sha256? Blake? Archived in what way? ZIP? Tar? Why should every package for every language be forced to use the same pipeline?
"standardized locations": Lol. They do not do this.

how the fuck can a package manager not "meet the needs" of a programming language?

Can you really not imagine a single reason? Installing multiple versions of the same package at once, as example. Pacman cannot do this. Consider also versioning: one language may want semantic versioning, another may just want a single number, another may want something else.
It is ridiculous to claim there is a good "one size fits all" solution to managing packages for every single programming language ever.
You have to ensure every version of every package is available on every package manager. What if OS A reviews packages daily but OS B reviews them monthly?
I don't think Windows even has a standard package manager shipped by default. MacOS doesn't either, I think.

Spoiler: Less Important

If you want to rely on third-party (OS) package managers, you MUST trust that they will all behave the exact same, or write explicit handling for every one. They are far from standardized.
You have to trust that every single package manager will install to the same location, regardless of OS, with the same file names, directory structure, etc.
Further, the levels of trust required for OS packages and language-specific packages (mainly libraries) are much different.

a good ecosystem means it's like c

Most operating systems and their package managers are written in C(++), so it is no surprise they get along so well.

There is a reason people chose to use npm/uv/cargo/etc. over the same thing for everything.

 

[Creative Username]

your assumption that language-specific package managers have inadequate handling with "security issues" is baseless

left-pad, the retard who put a pro-ukraine logic bomb in a package, having 2000 dependencies for every little thing since everybody is so sloppy, etc.
oddly seems to not happen in large centralized software repositories with lots of eyes on the packaging process

How is downloading a package with an OS package manager different from a language package manager in this regard?

i'd much rather use a package manager that downloads packages signed by maintainers who usually don't have anything to do with the packages than download some self-serve, fly-by-night crap over https

Can you really not imagine a single reason? Installing multiple versions of the same package at once, as example. Pacman cannot do this.
It is ridiculous to claim there is a good "one size fits all" solution to managing packages for every single programming language ever.
You have to ensure every version of every package is available on every package manager. What if OS A reviews packages daily but OS B reviews them monthly?
I don't think Windows even has a standard package manager shipped by default. MacOS doesn't either, I think.

that's why we have a large need for language-agnostic package management that works on all systems and can do project-based management, multiple versions, and everything else
obviously things like apt and pacman won't work, because their deficiencies have caused many atrocities to be committed and more will likely be produced before things are fixed
also if your packages break api every version, it's a sign that the ecosystem is incredibly fucked up and immature
also windows and macos not having package managers is a skill issue on their part, but at least they can install one

This is fine. And with modern languages, cross-platforming is usually not so difficult (e.g. Rust).

write a secure build container in rust right now (and make sure it doesn't have any vulnerabilities)
then do it in every other language in existence (and make sure none of them have any vulnerabilities)
remember: every operating system does sandboxing in a fundamentally quite different manner so you will suffer

Most operating systems and their package managers are written in C(++), so it is no surprise they get along so well.

doesn't apt use a lot of perl? damn must mean it only works for perl and c then
language choice means exactly nothing for unpacking tarballs into /usr/share and /usr/lib and maybe /usr/include

one day these problems will be fixed (and at least for rust and go, they're beginning to be fixed) and i will be able to use the one package manager that rules them all and new language developers won't think it's some kind of normal thing to carve out yet another square wheel when you make a new language
even pacman has a lot of python packages and i don't have to use the absolute dogshit that is pip

 

[Private Tag Reporter]

that's why we have a large need for language-agnostic package management that works on all systems and can do project-based management, multiple versions, and everything else

i think they call this git

 

[Another Char Clone]

For package management sperg, let's agree to compromise. Make your shit packageable with distro package managers, like Apt/Yum/emerge, and in turn, provide non-retarded language specific special snowflake managers that allow for localized environment setup out of the box like Lib::Local or venv.

That way, if distros are slow, users that ABSOLUTELY need the latest and greatest can dump everything into a controlled environment without breaking the rest of the system that depends on older libraries because upstream cannot into ABI stability, something libtool and friends have been managing quite well for decades via major/minor versions as part of the soname. Meanwhile, casual users can just use "apt-get install websocat" without needing to find out what language specific SDK tools are needed to be installed before they can use something.

I hate Rust for this very reason, downloading and shitting crates all over for each package that needs to be built. There apparently is no concept of distinct interface declarations and reusing shared libraries. No you must download everything, and precisely the exact same version as the developer uses, or else things will break, and everything is statically linked. That and needing to mess with CARGO_HOME and RUSTUP_HOME, because Rust versions isn't compatible with itself and needs very specific LLVM runtime versions.

As bad as Python pip is, it could at least try to use system provided modules even within a venv.

 

[Creative Username]

i think they call this git

For package management sperg, let's agree to compromise. Make your shit packageable with distro package managers, like Apt/Yum/emerge, and in turn, provide non-retarded language specific special snowflake managers that allow for localized environment setup out of the box like Lib::Local or venv.

you know, i really just want people to have the maximum number of choices possible
npm-like bullshit and dependency spaghetti lock you into shit that package maintainers hate and cargo really pisses me off for that reason

i feel like a language-specific build system would be fine but it needs to support the holy "look in this directory for libraries" switch

I hate Rust for this very reason, downloading and shitting crates all over for each package that needs to be built. There apparently is no concept of distinct interface declarations and reusing shared libraries. No you must download everything, and precisely the exact same version as the developer uses, or else things will break, and everything is statically linked. That and needing to mess with CARGO_HOME and RUSTUP_HOME, because Rust versions isn't compatible with itself and needs very specific LLVM runtime versions.

it doesn't respect the tradition of doing one thing

As bad as Python pip is, it could at least try to use system provided modules even within a venv.

i shat on it but it's not really that bad because i don't have to fucking use it
they don't all but require you to run everything through pip or some shit like that and it means distro packagers can make python packages that work just like the c packages
imagine that, a language achieving better ecosystem integration solely by not doing a bunch of incredibly retarded bullshit

 

[y a t s]

As bad as Python pip is, it could at least try to use system provided modules even within a venv.

If you edit the pyvenv.cfg file in your venv, you can set

include-system-site-packages = true

to do this. I use it to avoid having to reinstall torch a million times.

 

[Another Char Clone]

Introduction, Prefix and Postfix
Previous Post on Harmony Finalizer
CIL and Transpiler Basics

Sometimes, you want to make a modified copy of an existing function without replacing the original. This is called reverse patching.

Spoiler: Reverse Patching in Harmony

This isn't any different from regular transpilers. We can take the previous example and place the hyperfactorial in its own method.

Spoiler: example.cs

using System.Diagnostics.CodeAnalysis;
using System.Linq;
using System.Text;
using System.Reflection;
using System.Reflection.Emit;

using ThirdParty2;
using HarmonyLib;

namespace Example {
        public static class Start {
                static void PatchUp() {
                        var h = new Harmony("Example.Start.Patch");
                        h.PatchAll();
                }

                static void Main(string[] args){
                        // force reference, otherwise compiler doesn't think it is needed at all
                        _ = Utils.Factorial(0);
                        PatchUp();
                        Console.WriteLine($"Reverse Factorial 5: {Reverse.Factorial(5)}");
                        Console.WriteLine($"Hyperfactorial 5: {Reverse.Hyperfactorial(5)}");
                }
        }

        [HarmonyPatch]
        static class Reverse {
                static IEnumerable<MethodBase> TargetMethods(){
                        yield return AccessTools.Method("ThirdParty2.Utils:Factorial");
                }
                [HarmonyReversePatch]
                public static double Factorial(int fact){
                        throw new NotImplementedException("Not patched");
                }
                [HarmonyReversePatch]
                public static double Hyperfactorial(int fact){
                        IEnumerable<CodeInstruction> Transpiler(MethodBase original, IEnumerable<CodeInstruction> instructions, ILGenerator generator){
                                MethodBase powers = AccessTools.Method(typeof(Math), nameof(Math.Pow));
                                foreach(var insn in instructions){
                                        yield return insn;
                                        if (insn.opcode == OpCodes.Conv_R8) {
                                                yield return new CodeInstruction(OpCodes.Dup);
                                                yield return new CodeInstruction(OpCodes.Call, powers);
                                        }
                                }
                        }
                        // Make compiler warnings go away
#pragma warning disable CS8625
                        _ = Transpiler(null, null, null);
#pragma warning restore CS8625
                        return default(double);
                }
        }
}

There isn't a special method name for reverse compilers, so you'll need to tell Harmony which dummy method you want to have the original method copied into with the special

[HarmonyReversePatch]

attribute to mark them. As for the

_ = Utils.Factorial(0);

part, it's to ensure the ThirdParty2 Assembly is loaded. Otherwise the compiler thinks its not needed at all, since we never directly access any of its classes. Harmony patching would fail if its not loaded at all. This shouldn't be required at all if you are patching games that load mod assemblies automatically.

[HarmonyReversePatch]
                public static double Factorial(int fact){
                        throw new NotImplementedException("Not patched");
                }

For the reverse Factorial, it would be copied unchanged, so we don't have to put any code for the dummy function. A return statement isn't even necessary since the compiler could tell it would immediate throw an exception.

                [HarmonyReversePatch]
                public static double Hyperfactorial(int fact){
                        IEnumerable<CodeInstruction> Transpiler(MethodBase original, IEnumerable<CodeInstruction> instructions, ILGenerator generator){
                                MethodBase powers = AccessTools.Method(typeof(Math), nameof(Math.Pow));
                                foreach(var insn in instructions){
                                        yield return insn;
                                        if (insn.opcode == OpCodes.Conv_R8) {
                                                yield return new CodeInstruction(OpCodes.Dup);
                                                yield return new CodeInstruction(OpCodes.Call, powers);
                                        }
                                }
                        }
                        // Make compiler warnings go away
#pragma warning disable CS8625
                        _ = Transpiler(null, null, null);
#pragma warning restore CS8625
                        return default(double);
                }

For the modified method, we can put a nested transpiler method in it, it is the same patch as the previous post. Harmony would find and run it as usual. The dummy call to Transpiler near the end of the method is to make sure the nested method don't get optimized out. The return statement on the other hand is to ensure the method remains a valid construct in CIL. These are never actually used and would be patched out when Harmony runs.

Console.WriteLine($"Reverse Factorial 5: {Reverse.Factorial(5)}");
Console.WriteLine($"Hyperfactorial 5: {Reverse.Hyperfactorial(5)}");

The above statement results in:

Reverse Factorial 5: 120
Hyperfactorial 5: 86400000

Here are also some tricks for Harmony that I learned over the years from experimentation. These tricks are actually in use with my personal Rimworld minimods:

Spoiler: How to target methods hidden in nested classes

It's not obvious how to do it, going purely by the Harmony documentation. Let's say we have the following example code:

namespace ns1 {
    class outer {
        class inner {
            static void method(){}
        }
    }
}

We want to target the inner method. The syntax to indicate a nested class with AccessTools.Method or AccessTools.TypeByName is to use the + sign. In our case:

AccessTools.Method("ns1.outer+inner:method")

Spoiler: Transpilers and calls to non-static methods

In case you haven't noticed, non-static methods require a "this" pointer, just treat it as a mandatory argument on the stack and you're good to go. It will always be the very first argument. This is especially true for getters and setters, which are really method calls even if they look like fields for convenience. If in doubt, look at how the dnSpyEx and ilspycmd output looks like.

Spoiler: Transpiler and calls to replacement methods

Sometimes, you are trying to modify a method in a way that is different enough that you need an extra parameter argument to it. What you could cheat by using a reverse transpiler to make a copy of the method in question into a dummy method that already has the extra argument added. Next, you can use a transpiler to patch up all the code that calls the original method to call yours, while also pushing an extra argument into the stack before the actual call to yours. Default arguments will not magically fix things since it is ultimately syntactic sugar, you'll receive garbage if you don't push values into the stack correctly.
On the otherhand, if you want to suppress a call to a method that just takes a single argument (wether the "this" object or a regular object, like logging APIs), you can just issue a Pop instruction. This is convenient for dealing with log spam when mod developers accidentally leave debug prints in game mods.

Spoiler: Exception handling with transpilers

For most parts, exceptions can be handled with a Finalizer, but sometimes, you want very explicit control over the patched method. With Harmony, you'll have to mark the exception blocks in order for the code generator to produce the required metadata. Here's an example to emit exception metadata:

Spoiler: Example.cs

using System;
using System.Linq;
using System.Reflection;
using System.Reflection.Emit;
using HarmonyLib;

namespace Example {
        class Wallet {
                private int dollars;
                public Wallet(int amount = 0) { dollars = amount; }
                public void Deposit(int amount) { dollars += amount; }
                public int Withdraw(int amount) {
                        if(amount > dollars)
                                throw new Exception("You don't have that kind of money");
                        dollars -= amount;
                        return amount;
                }
                public int inspect() { return dollars; }
        }
        static class Game {
                static Game() {
                        var h = new Harmony("Game.Start.Patch");
                        h.PatchAll();
                }
                static void Main(){
                        var w = new Wallet(50);
                        Console.WriteLine($"I have ${w.inspect()} in my wallet.");
                        Console.WriteLine($"After Withdrawing ${w.Withdraw(100)}...");
                        Console.WriteLine($"...I have ${w.inspect()} in my wallet.");
                }
        }

        //[HarmonyDebug]
        [HarmonyPatch]
        static class Cheat {
                static IEnumerable<MethodBase> TargetMethods(){
                        yield return AccessTools.Method("Example.Wallet:Withdraw");
                }
                static IEnumerable<CodeInstruction> Transpiler(MethodBase original, IEnumerable<CodeInstruction> instructions, ILGenerator generator){
                        var retval = generator.DeclareLocal(typeof(int));
                        var field = AccessTools.Field("Example.Wallet:dollars");

                        // Set up try block
                        yield return new CodeInstruction(OpCodes.Nop).WithBlocks(new ExceptionBlock(ExceptionBlockType.BeginExceptionBlock));
                        foreach(var insn in instructions){
                                if(insn.opcode == OpCodes.Ret) {
                                        // There cannot be multiple Ret instructions, so save the return value to restore later
                                        yield return new CodeInstruction(OpCodes.Stloc, retval);
                                } else {
                                        yield return insn;
                                }
                        }

                        // Catch block, we don't really care about the exception, pop it per convention
                        yield return new CodeInstruction(OpCodes.Pop).WithBlocks(new ExceptionBlock(ExceptionBlockType.BeginCatchBlock));
                        yield return new CodeInstruction(OpCodes.Ldarg_1); // Put withdraw amount...
                        yield return new CodeInstruction(OpCodes.Stloc, retval); // into return value anyway
                        yield return new CodeInstruction(OpCodes.Ldarg_0); //load the "this" object
                        yield return new CodeInstruction(OpCodes.Ldc_I4_1); // Set amount to 1...
                        yield return new CodeInstruction(OpCodes.Stfld, field); // ...in the wallet
                        yield return new CodeInstruction(OpCodes.Nop).WithBlocks(new ExceptionBlock(ExceptionBlockType.EndExceptionBlock));
                        // end of catch block, restore return value
                        yield return new CodeInstruction(OpCodes.Ldloc, retval);
                }
        }
}

We declared a local variable to match the return type in order to save and restore it once the exception is done. The original value is lost when the exception was thrown and the code unwound backwards, but we don't want to mess it up in the event the exception never fires either. Harmony will automatically insert the Leave labels as needed.
You can uncomment

[HarmonyDebug]

to look at the resulting transpiler transformation, there would be a will be a new harmony.log.txt on your desktop after running the example, likewise, ~/Desktop/harmony.log.txt for Linux users.

Spoiler: Program output

I have $50 in my wallet.
After Withdrawing $100...
...I have $1 in my wallet.

That should all for now, I hope someone finds these useful instead of needing to research and experiment to accomplish what they want.

Edit: Looks like there is no need to push a null onto the stack to clear the exception, the Leave instruction automatically unwinds the stack. I left the Pop instruction there since that is what compilers are still doing, though it is not actually needed at all according to experiments, it works perfectly fine to just ignore the Exception object if that is what you want.

to do this. I use it to avoid having to reinstall torch a million times.

Yes, that's what I was trying to say if I wasn't clear, it can use system packages, or override them if the user desires.

 

[ADHD Mate]

that's why we have a large need for language-agnostic package management that works on all systems and can do project-based management, multiple versions, and everything else

So.. Nix?
I've been using Nix a secondary package manager on my Steam Deck and it worked quite well.

 

[Goose the Redeemer]

Language-specific package managers are a sign that the cancer that is "webdev" has reached stage 4. (As if Electron was not proof enough).

Imagine the needs of a package manager for Language A and Language B are mutually exclusive. How do you reconcile this?

What language specific needs are there?

Suppose I wanted to install a program that is written in C++, which uses a library written in C (currently being re-written in Rust, naturally), uses Python as a scripting language, and comes with a few scripts which make use of some Python modules which themselves are wrappers around C libraries. How would you propose that this be done? The system package manager does not (and should not) care which language each package uses and if I were forced to use language-specific package managers then this would be rather inconvenient to say the least.

Should the developers of every language write the code to bring pacman, apt, brew, winget, etc. all up to first-class standards for their language?

Just as the package manager should not care about the language, the language should not care about the package manager (or the build system, for that matter). It is the job of the packager (which may, or may not, be the software developer) to package the software, the only thing that the language needs to do is simply not be hostile to external tools.

This is a faulty assumption. Even if we assume that their is one package manager, and different operating systems to not make opinionated judgements with their package managers, there are many subjective judgements made by even a single package manager.
"signed archives": Signed with what? Sha256? Blake? Archived in what way? ZIP? Tar? Why should every package for every language be forced to use the same pipeline?
"standardized locations": Lol. They do not do this.

Why should I care about the opinions of a package manager on a system that I don't use? The software should not be aware of, never mind rely on, package manager specific details either. A general purpose, system level, package manager should be able to deal with these differences and the actual work falls to external libraries anyway, not the package manager itself. There is a reason that environment variables (e.g. $PATH/%PATH%) are a thing. The software/package manager does not need to know, or care, where things are actually installed, as long as the environment is set up correctly.

Installing multiple versions of the same package at once, as example. Pacman cannot do this.

Then why do I have 4 version of Electron installed? Along with GTK 2, 3, and 4? And Qt 5 and 6?

(well, technically, they are different packages, but the end result is the same)

Consider also versioning: one language may want semantic versioning, another may just want a single number, another may want something else.

The package manager should be able to handle this.

For example, semver, a single number, and something else. (the "-n" is the version of the package itself, not the software):

pacman 7.0.0.r6.gc685ae6-2
pacman-contrib 1.11.0-1
pacman-mirrorlist 20250101-1

The choice of version number "style" is not simply due to language (why should the language even dictate such things?), each serves its own purpose.

It is ridiculous to claim there is a good "one size fits all" solution to managing packages for every single programming language ever.
[...]
If you want to rely on third-party (OS) package managers, you MUST trust that they will all behave the exact same, or write explicit handling for every one.

See above, re: the separation of package manager and software. All the package manager needs is a name/id, a version number/code which can be sorted, and a dependency list. Name a language for which this is not possible or sufficient.

I don't think Windows even has a standard package manager shipped by default. MacOS doesn't either, I think.

Neither does Linux, if you want to be pedantic.

The "culture", and the way things work in general, is just different on each platform. I think something like the Rust system (or Python's pip) may be good for Windows, but it's not how things are done on Linux. You either work with the system package manager (and C), or you go home. (Python understood this; Rust needs to take notes.)

---

12 women can't create a baby in 1 month.

Twelve?

 

[Creative Username]

So.. Nix?
I've been using Nix a secondary package manager on my Steam Deck and it worked quite well.

there's also guix which is like nix except they rewrote it in rus-just kidding they made it in scheme

Suppose I wanted to install a program that is written in C++, which uses a library written in C (currently being re-written in Rust, naturally), uses Python as a scripting language, and comes with a few scripts which make use of some Python modules which themselves are wrappers around C libraries. How would you propose that this be done? The system package manager does not (and should not) care which language each package uses and if I were forced to use language-specific package managers then this would be rather inconvenient to say the least.

he thinks you should just install the 140mb static binary package built from god knows what on some niggerlicious github ci server

The software/package manager does not need to know, or care, where things are actually installed, as long as the environment is set up correctly.

even if the package manager installs in a weird place (or you download a tarball or something yourself and extract it in a weird place) you should be able to tell the build system "library xyz is in /home/nigger/steamingpileofhorseshit/libs/xyz"

I think something like the Rust system (or Python's pip) may be good for Windows, but it's not how things are done on Linux. You either work with the system package manager (and C), or you go home. (Python understood this; Rust needs to take notes.)

people should be able to use whichever package manager they want
a linux user might want to install system-wide packages and a windows user might want pip since windows users are allergic to having good things like system-wide package management
another linux user might want to install 540 libraries but only if they source an env file so they don't shit up their system with something they're working on

@unleashthefreak what do you think of pkg-config it's my favorite language-specific package manager

 

[y a t s]

Language-specific package managers are a sign that the cancer that is "webdev" has reached stage 4. (As if Electron was not proof enough).

I agree 100%. Web devs are lazy retards who can't handle anything relating to backend or infrastructure and refuse to learn it. Everything needs to be bundled together, with compatible versions, in little fucking containers, or their brains will simply stop functioning. Trying to get most people to problem-solve and make sense of plain-English error messages is sadly asking way too much of them. This expands more generally to these n00b friendly "run it anywhere" languages and the level of effort required to handle dependencies and compile/run programs made in them.

The more systems and standards you have to support, the more impossible it becomes to have a predictable and straightforward method of install. Anyone who has jumped through the Bash hoops required to hunt down compatible python binaries in an install script will know the pain of this. Inevitably, some user will carelessly fuck up the increasingly convoluted setup instructions you provide, whine on the Internet, and then your program gets a reputation as being "hard to install/use". Web browsers, on the other hand, are fairly standardized (I know not 100%) and will work reasonably consistently across operating systems. So as more web "devs" make their way into other scripting languages and maybe even scary old C, they bring their lack of troubleshooting ability with them. Now every useful tool has to be bundled together and made easy enough for the average retard to install. The more moving parts you introduce for users, the more you confuse and scare them off.

Fundamentally, we as a society need to accept that some people simply weren't meant to do certain tasks, such as programming or building planes. Unfortunately, this means a less diluted hiring pool removed of plebs, and that's incompatible with the money-printing hierarchies of incompetence that are modern corporations. Why have training and skilled employees when you can simply remove all of the required learning? Corporations love Rust for this reason; anything but strict adherence to the "way things are done" is viciously attacked by the most annoying members of society.

To sum up: expecting most people to learn anything is a waste of fucking time and energy. Prebuilt binaries, hand-holdy operating systems, and desktop VPN apps that take up 500 MB of storage space (glares at Mullvad) are here to stay. Standards like those defined by ISO and the like are only useful if they're very strictly followed by people/groups who give enough of a fuck to put in the effort. This is why gatekeeping is effective—though difficult to maintain.

Then why do I have 4 version of Electron installed? Along with GTK 2, 3, and 4? And Qt 5 and 6?

(well, technically, they are different packages, but the end result is the same)

Not to mention at least 2 or 3 different versions of gcc on a lot of systems.

I recently had to build gcc12 from scratch to make some CUDA shit compile properly. As a side note, none of the errors from failed builds allude to it being the compiler version, and it's really something you'd only know if you've dealt with it before elsewhere. Getting around dependency hell because some specific version of a tool/lib is no longer packaged isn't always straightforward, even for us with decades of experience.