[the__alchemist]

Same! And Python was my first, and is currently my second-highest-skill language. If someone's software's installation involves Python, I move on without trying. It used to be that it would require a Python 2 interpreter.

Honorable mention: Compiling someone else's C code. Come on; C compiles to a binary; don't make the user compile.

[optionalsquid]

There's a lot more involved in distributing C (and C++) programs than just compiling them:

I'm assuming a Linux based system here, but consider the case where you have external dependencies. If you don't want to require that the user installs those, then you gotta bundle then or link them statically, which is its own can of worms.

Not to mention that a user with an older glibc may not be able to run your executable, even if they have your dependencies installed. Which you can, for example, solve by building against musl or a similar glibc alternative. But in the case of musl, the cost is a significant overhead if your program does a lot of allocations, due to it lacking many of the optimizations found in glibc's malloc. Mitigating that is yet another can of worms.

There's a reason why tools like Snap, AppImage, Docker, and many more exist, each of which are their own can of worms

[the__alchemist]

Yea def. I think Linux's ABI diaspora and the way it handles dependencies is pain, and the root behind both those distro methods you mention, and why software is distributed as source instead of binaries. I contrast this with Rust. (And I know you can do this with C and C++, but it's not the norm:

  - Distribute a single binary (Or zip with with a Readme, license etc) for Windows
  - Distribute a single binary (or zip etc) for each broad Linux distro; you can cover the majority with 2 or 3. Make sure to compile on an older system (Or WSL edition), as you generally get forward compatibility, but not backwards.
  - If someone's running a Linux distro other than what you built, they can `cargo build --release`, and it will *just work*.

[optionalsquid]

Another nice thing is that, if you can live with the slower musl malloc, then building a "universal" Linux binary with Cargo takes just two commands:

$ rustup target add x86_64-unknown-linux-musl

$ cargo build --target x86_64-unknown-linux-musl --release

Similarly for cross-compiling for Windows

[tyingq]

It may be fixed now, but devil's in the details. As one example, musl has (or had) chronic issues with it's dns resolver and large responses.

[optionalsquid]

Definitely. I haven't tried building anything that requires DNS using musl, but I've had to work around musl's much, much slower malloc implementation

The musl wiki lists a number of differences between it and glibc that can have an impact:

https://wiki.musl-libc.org/functional-differences-from-glibc...

[the__alchemist]

I should try that!

[zahlman]

> C compiles to a binary; don't make the user compile.

C compiles to many different binaries depending on the target architecture. The software author doesn't necessarily have the resources to cross-compile for your system.

Incidentally, this is probably exactly the thing that has made most of those Python installations problematic for you. Because when everything is available as a pre-built wheel, very much less can go wrong. But commonly, Python packages depend on included C code for performance reasons. (Pre-built results are still possible that Just Work for most people. For example, very few people nowadays will be unable to install Numpy from a wheel, even though it depends on C and Fortran.)

[mr_toad]

> Honorable mention: Compiling someone else's C code. Come on; C compiles to a binary; don't make the user compile.

Unless you’re on a different architecture, then having the source code is much more useful.

[peterfirefly]

Or often just the same architecture with a slightly different OS version.