[altmanaltman]

How is statically linked binaries an unique advantage of rust or go? you can do the same with C, C++, pascal, ada, zig, and more. Rust even doesnt do the static binary file by default.

You might have better devops experience as an end-user of the said software if its statically linked and its a good trend in software sure but it is not unique to go or rust.

Admitting you don't know how to code and still trying to argue rust is better is just wild sorry.

[zamalek]

Zig and probably Pascal have the same advantage, can't speak for Ada as I've never built it.

C and C++? You've got to be joking. If the project provides static binaries, sure, but I don't want to have to worry about finding a necronomicon and summoning the correct kind of imp required to properly use whatever insane build system the project is using.

[CobrastanJorji]

And thus, we all agree that Linux, Windows, and OS X are all bad software, because they're written in C and C++ and have insanely complicated build systems.

[insanitybit]

Is that even controversial?

[altmanaltman]

You are missing the point here. Single binary files are not what makes a programming language good or bad.

Its like saying "I want a red car because it goes fast" when people are actually disucssing how the engine works or how easy/difficult is it to drive etc.

You cannot base your like/dislike on that single criteria and expect that to actually make sense.

[dijit]

This totally depends.

For some people, Linux package management is not solved. Static binaries at least work for deployment.

More useful for client software, but you can’t just dismiss someone for having this preference given the poor viability of running arbitrary binaries on Linux due to GNU’s userland style.

[johnisgood]

No, it does not depend. Your parent is correct with his analogy.

Linux package management is solved, if it depends on something, it depends on the specific Linux distribution, but "Linux" package management is definitely solved.

[johnisgood]

Off: I thought I am becoming dumb, but this really puts me in a new perspective. The odd thing is that even people who work in IT hold similar beliefs. I am not entirely sure what is going on. Favoring a language so blindly seems like a thing, apparently? For example they seem to have convinced themselves that Rust is "safe" if you use it for anything (without implementing the security features) because it is (memory) safe? I did not imagine beginners would make such a mistake either, but alas.

I noticed your comment is getting downvoted. I wish I knew why though. Is it because of your analogy? Is it because they think that somehow "single binary" has anything to do with the programming language? Would like to know. I am not going to assume that it is a confirmation of what I wrote earlier.

[nananana9]

There's a pretty strong culture of "no static linking because I need to replace the .so to preserve my freedom hurr durr" in a lot of Linux spaces, so quite a few of these C/C++ FOSS libraries are a pain in the ass to statically link.

Literally last week I was porting something to Linux and had to rewrite the libwayland build scripts because they only expose a shared object.

There's also an expectation that you're going to install them via your system's package manager, not build them, so a lot of them use insane build systems (autotools, meson).

[pastage]

You are right that there are many of us who prefer the package manager, there are so many reasons why a package manager makes your life wonderful. Debian has always been a proponent of dynamic linking. When you create a Linux distribution that is a big plus.

For me install size matters and statically linked stuff are too big sometimes. Of course a 100MB go statically compiled binary has huge advantages now days.

[berkes]

> Rust even doesnt do the static binary file by default.

Huh? It does. Only libc is dynamically linked, by default, which --iirc-- all programs will commonly need anyway. All the rest is statically linked.

In fact, it takes some hoop-jumping to build dynamically linked binaries with cargo.

[johnisgood]

If the binary still depends on libc.so.6 (glibc) at runtime, then it is not a fully static binary (read: not a static binary). It is a dynamically linked executable, albeit one where most non-libc dependencies have been statically linked.

I am not going to pretend I know Rust enough to comment (yes, would be a minute check), I was just commenting on the "Only libc is dynamically linked" bit.

[berkes]

That's the default. One can also statically bind that libc.so.6 quite easily. Though that's not the default.

edit: Ironically, that makes shipping the binary a tad harder, since this "linux" version won't "magically" run on about every Linux, or mac version on mac, etc. I guess that's why its not the default, though that's just me guessing.

[johnisgood]

I really was just commenting on the "Only libc is dynamically linked" bit. But yeah, there are cons and pros of dynamic vs static. :)

[badsectoracula]

It is not about being able to make static binaries or really anything that has to do with anything technical. It is more of a cultural thing - the culture in some languages is to link dependencies dynamically (C/C++) whereas the culture in others is to link dependencies statically (Go, not sure about Rust).

Personally i do not even write Go myself yet when i see some webapp made in Go i'm pretty much always sure that it'll be a self-contained static binary. Yes, there are probably exceptions (and i haven't surveyed all webapps made with Go) but it has been common enough to feel as the standard approach to me - and if i ever decide to make a binary webapp, i'll probably reach for Go to do it.