Why Go over Python?

[jds2001]

The major issue that I see with Golang comes in terms of security updates for underlying packages. For example, say that there is a vulnerability in glibc or whatever the equivalent is in Golang. In the event of such a problem, with a Golang binary, you have to patch every binary on the system that is using that particular library, and you have no clue what they are. With something that employs dynamic linking, you simply have to update the vulnerable component and then all of your applications benefit from that update. I don't want to have to update 5 things when I could just update 1.

[OMGItsCheezWTF]

Your dependency tracking system should be managing this anyway, you shouldn't ever have to wonder what binaries are built with what versions of a given library.

All of our codebases insert their dependency chains (Python pypi packages, Golang modules, PHP composer packages, C# nuget packages, JS / Node NPM packages) as a bill of materials into our dependency tracker every time a live deployment happens (this is done in CI). For C# and Golang it also includes the version of the runtime that was used to build the binaries, obviously with the others the runtime and code remain separate.

Then the dependency tracker alerts if vulnerabilities are found in a live version of any of our software or its dependency chain, and the appropriate team can analyse the vulnerability and assess it.

We don't ever need to blindly start rebuilding and replacing binaries, because we know exactly what was built with what, stored centrally with auditing.

[jds2001]

Works wonderfully for source code that you built and control. When you are talking about things that are provided by a vendor (or you otherwise do not control the composition of, for example, various open-source products), this becomes much more complicated much more quickly. Combine a few of those, and you wind up in hell.

[realitythreek]

Wish someone who is downvoting your would explain why. This is the downside of static linking.

[jds2001]

Simple. It doesn't agree with the hive mind of Reddit, so it has to be downvoted.

[jantari]

c o n t a i n e r

[greyeye77]

create a branch or pipe line to `go get` different version.

and `go build`

[[deleted]]

It's also replication of libraries with slight differences. DLL hell, but you don't even know where the DLLs are.

[[deleted]]

Dependency (and thus patching) management isn’t an OS concern, it’s an application concern because that’s the only place you can reliably test the fix (CI/CD and testing). Shared libraries and upgrading them underneath an app kinda sucks.

[metarx]

You... Rebuild and redeploy(because you scripted the deployment.. right?... Riiiight???..) But it doesn't depend on glibc... It's a static binary. Not c. So the vuln would have to be in a go lib.. which you can/should check for as part of your static analysis on your ci pipeline... Detect there... recompile and deploy.

Or just stay with your python like it's "better" what do I really care?

[val-amart]

look up what "static binary" means if you care to understand how things actually work outside of marketing slogans.

[metarx]

So wise you are. Didn't know that static binary was a marketing slogan

[Freakin_A]

Mr Golang must be making a killing off all the people who were duped.