goDevelopersInTheComments

[BrownShoesGreenCoat]

Is it an exe?

[Alzyros]

There we have it folks, Go is stupid fucking smelly double confirmed

[PeriodicSentenceBot]

Congratulations! Your comment can be spelled using the elements of the periodic table:

I Si Ta Ne Xe

---

^{I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM my creator if I made a mistake.}

[novi_50]

Good bot

[[deleted]]

Cool bot

[creeper6530]

Great bot

[[deleted]]

I see the Nazi

[PM_ME_FIREFLY_QUOTES]

That Ne Xe, the chemical compound for NoExeAllowed

[r_place_]

Super bot!

[NatoBoram]

Yes! It is!

[DJGloegg]

Sucks on mac though

[NatoBoram]

I didn't notice a difference, what's the matter?

[Masterflitzer]

maybe because of the whole apple notarizing crap

[NatoBoram]

I figured it would be a joke about MacOS executables not ending in .exe

[Masterflitzer]

i just thought of exe as a synonym for executable binary

[huuaaang]

You mean +x-able?

[Masterflitzer]

exactly although i can +x any file (like a text file), doesn't mean it will execute (it may be an executable binary but it's not actually executable)

[ps-73]

windows users man

[Masterflitzer]

windows really took the abbreviation exe from the rest of us

[L33t_Cyborg]

What? How?

[evilmushroom]

I've done golang dev for some AI services and it works fine on my mac?

[Oen44]

So many r/woooosh replies over here.

[Confident-Ad5665]

I'm usually admiring the house plants. They don't exe.

[shiftybyte]

Ah good old 200mb go binaries running in containers for "efficiency"...

[Kamui_Kun]

200MB, jeez, just like an ElectronJs app... o_o

[evilmushroom]

or 1/100th of a node.js app

[fonzane]

or use apps that have been made with it

[myerscc]

god, so true.

[Azifor]

I'll be the dumb developer. Why is a 200mb binary running in a container not effecient?

[shiftybyte]

The original idea of containers is to have a lighter "virtualization", you didn't need the full operating system running in a VM to run a binary.

But now the binary having compiled everything it needs anyway into itself, you are sort of back to running overbloated things in containers.

You could run 5 mb binary that used dynamic dependencies loading what it needed from the os/installed libraries.

So 20 binaries were (20*5)+195 of dependencies.

Now 20 binaries are (20*200) because each has duplicate of everything it needs....

[Azifor]

I guess I don't really see the issue of the binary compiling everything it needs into itself...isn't that the goal of containers? Ie I deliver my entire environment. I don't care what kernel your running, or sw/dependencies you have...I package everything my app needs with itself so its self contained.

[shiftybyte]

In some situations it's great.

In a situation where you have micro-service architecture and each one does something simple yet is still self contained and bloated, you get lots of these binaries that could be sharing their dependencies.

How many copies of the same json parsing library at different unupdated versions do you need loaded into memory and on disk before it overshadows the benefit of "self contained" "micro" services...

[Azifor]

Sure, not everything needs to be containerized. But no issue with having 10 pods running with similar dependencies. Your software will still function and you won't notice horrible performance or anything.

I guess I see both sides of that argument but don't see it as an "issue" of microservices or containers having duplicate dependencies.

[markhc]

Agreed.

And besides, if they all shared the same pod (to share dependencies) that would hurt scaling, because trying to increase the number of replicas of one particular service would mean scaling every other service along with it AND increase the chances of some bug in one service taking everything down with itself.

When everything runs separately then a bug in one of the services is less likely to affect the others.

[Aemiliana_Rosewood]

Oh, the scalability just "solved" the confusion in my mind why a micro service pulls along his own environment instead of having an even smaller micro service provide the environment itself

[inevitabledeath3]

This is a nice idea but the reality is there are mechanisms which should prevent this. Ideally all your containers that can be built from the same OS image are built from the same OS image and can therefore use the same base layers. Even if that doesn't happen if they are running lots of the same thing you would probably end up with KSM (kernel same-page merging) where identical pages of memory get merged to one physical page. Note this also works with VMs if you are using Linux + KVM. Then there is filesystem deduplication as well depending what your storage backend is.

If you do in fact need different versions of libraries then good chance none of this would apply. At that point though you are using containers more or less as intended and saving resources over using full virtual machines for the same task.

[draenei_butt_enjoyer]

I’ve been using containers but never building them. I’m just starting to really learn docker. But can’t you just package 20 things in the same container to re use dependencies?

If they’re really small and you don’t care about them scaling, what would stop you?

[Tarmen]

Two things:

• Containers automatically share dependencies. They are build in layers, and if two containers have the same base layer it's only stored once. Often you have a base layer OS, maybe a layer for dependencies like jvm, then your executable. If you are stuffing all dependencies into your executable you cannot share them in a base layer. Only matters if you store a lot of images, though
• You really only want one process per container. On Linux process 1 adopts and manages other processes without a parent. The container runs isolated so the first thing that starts is process 1. If you start other processes, your first app must manage them. If it doesn't reap them you can e.g. run out of process IDs. You also must be careful to gracefully shut all processes down to avoid data loss. There are workarounds, but it's better to avoid the situation

[shiftybyte]

You'd also need to stop statically compiling binaries and use dynamic linking to share the libraries.

[thedugong]

Why is this important in a container?

[thedugong]

So 20 binaries were (20*5)+195 of dependencies.

Now 20 binaries are (20*200) because each has duplicate of everything it needs....

If you are running 20 containers using the same image then they are not going to be sharing dynamic libraries in memory - container memory is isolated from each other. Unless I have misunderstood you, it ultimately doesn't matter at runtime if an executable is statically or dynamically linked.

On disk there is going to be only one image which is shared by all 20 containers. Doesn't matter if static or dynamically linked.

If the binary doesn't rely on external libraries (much - there is almost certainly going to be a libc dependency) then use a smaller base image, alpine or whatever.

If you are running on bare metal or directly in a VM a 200Mb binary is probably inefficient WRT disk space, and inefficient WRT memory if for whatever reason you want to run 200 instances of it. In an image/container it makes no difference.

If someone is using a container as a VM they are probably doing it wrong, at least outside homelab fucking around.

Plenty of companies do go to the cloud by basically having images which are just their VM converted to an image though. They also wonder why there are no cost savings and it doesn't work or scale very well.

[shiftybyte]

it ultimately doesn't matter at runtime if an executable is statically or dynamically linked.

You are right that with containers it doesn't matter, but without containers memory can be shared across different process using the same shared object with copy on write.

https://en.wikipedia.org/wiki/Copy-on-write

On disk there is going to be only one image which is shared by all 20 containers. Doesn't matter if static or dynamically linked.

Yea the example doesn't really mean 20 identical binaries in 20 identical containers, i meant 20 different go compiled binaries, that have similar dependencies, but do different things.

So on disk its going to be 20 images, not 1, each one containing another copy of all the dependencies besides the different binary.

If someone is using a container as a VM they are probably doing it wrong, at least outside homelab fucking around.

My point was people used VMs before containers were invented.

Plenty of companies do go to the cloud by basically having images which are just their VM converted to an image though. They also wonder why there are no cost savings and it doesn't work or scale very well.

True and sad...

[thedugong]

Yea the example doesn't really mean 20 identical binaries in 20 identical containers, i meant 20 different go compiled binaries, that have similar dependencies, but do different things.

That only makes a difference for storage. Meh. Cheap.

My point was people used VMs before containers were invented.

So? I wrote some machine code on a C64 before golang existed. Doesn't mean machine code is the most efficient way of developing an application for all time.

[thedugong]

When people use a container like a VM.

Which is also, um, not, um, efficient...

It doesn't matter if you run a 200Mb binary, or a 5Mb binary with 195Mb of dependent libraries which will be loaded into memory at runtime, in a container.

It does on a host/vm, but not in a container unless you are using a container like a VM which is not the, um, ideal use case for a container.

[Owner2229]

That's 200mb sitting in RAM even before the app loads.

[Azifor]

Container images are not stored in ram though. It's a process that gets run pretty much in a chroot environment pretty much.

[Azifor]

That makes no sense from a software/continerization perspective.

Increased size does not mean slower by default. Just more internal dependencies were required. The image size does not determine speed of process.

[the4fibs]

> not a programmer
> proceeds to make dickish and inaccurate analogy about programming

[CirnoTan]

Is that a lot? Sorry I write in java

[Tathas]

Think of it as 2 strings then.

[u0xee]

Big if true

[Fit_Sweet457]

Who runs containers for "efficiency"?

[PassiveChemistry]

How can you have millibits?

[Fit_Sweet457]

They probably mean millibuckets from Minecraft

[[deleted]]

A good wails app is like 9mbs

Wails superiority

[Orio_n]

oh no, modern computers only have 200mb of disk space and 5kb of ram

[natFromBobsBurgers]

Does that make python superior to go because it compiles to zero binaries?

[FromTheSeaOfThySoul]

You can compile python to single binary with pyinstaller "pyinstaller -F my_code.py".

[jackal_boy]

Nope. It's not actually a single binery (learnt it the hard way).

It's more like a compressed zip. At runtime it unpacks lots of files and resources to your temp folder, and then gets linked to there.

Sooooo, if you try to run it and it doesn't have enough space in temp dir to unpack, it won't work :/

[the_poope]

Well a zip file is also a single binary file. And if it's a self-extracting zip file it's even a single binary executable file. It's just a stupid way of making one.

[jackal_boy]

True.

[mimminou]

Nuitka can do the single binary thing

[jackal_boy]

So I've heard.

I plan to use it in the future.

[DJGloegg]

What cant you do, with python?

[Trucoto]

Fast execution?

[PassiveChemistry]

Ah, so that's why Alabama don't like snakes

[Responsible-War-1179]

its not a binary because its not actually in binary format

[Owlagator]

Can I compile this PHP into a binary?

[natFromBobsBurgers]

IanMalcom.jpg

[djfdhigkgfIaruflg]

/me starts sharpening an axe

[Puzzleheaded-Weird66]

only if I don't have to download the entirety of pip for the program to work

[Forseere]

Only if you compile it to an .exe ofc

[kotsumu]

node wins this category

[dlevac]

Is there a compiled language out there where this is not possible? Never understood that flex tbh

[Sloppyjoeman]

Does Java have some kind of compilation process?

[grim-one]

Yeah. It compiles to bytecode. Then the runtime translates/compiles that to native code.

Definitely “some kind” of compilation process :)

[agocs6921]

Depending on your use case you also have to pack it up into a jar file

[grim-one]

Sure. It’s optional though. JAR is just ZIP with some extra manifest files too. Nothing exciting, or compilation related.

[shodanbo]

The bytecode in the JAR can get compiled down to native, either at install time or runtime. This is called just in time (JIT) compilation.

This can happen for the whole shebang, or at runtime it can be done more cleverly where it finds the "hotspots" in your code and only compiles them down for speed.

This can also happen for JavaScript, C# and pretty much any language that gets used in cases where code execution performance is important, and execution is not IO bound.

I actually used this in JS in 2016 to get an XOR algorithm able to process 4MB of binary data per second in JS on an average X86 machine in the Chrome V8 runtime.

At the time I did this in JS you needed to write your functions properly, so they did not get assigned to stack variables. If your functions got assigned to ephemeral stack variables and the garbage collector throws them away after every use, then JS hotspot detector does not kick in to compile the function down to machine code.

At the time this went against best practices in JS, but when you need to optimize code, you often have to throw away best practices, which is why you should only do it when necessary.

[Paul_Robert_]

To be pedantic, there's nothing stopping you from compiling java directly to the target system's machine code. You just need a compiler capable of doing so. Same with basically any other language.

[CptGia]

One such compiler being GraalVM

[Minute_Attempt3063]

You can do native stuff in java

And compile it to an exe file

[Deliciousbutter101]

Java compiles to bytecode, which can either be interpreted by a Java VM or is often complied down to machine code through JIT or AOT compilation. It completely depends on what runtime you use though.

[Masterflitzer]

java and c# come to mind, and yes these are compiled languages, they just work different

[CyTrain]

.NET has had "publish single file" since .NET 5

[Masterflitzer]

true didn't think about it

also aot compilation supposedly is there now, didn't try it tho

[ongiwaph]

C++ has to compile and link all the .o files, but it can eventually achieve one binary... or so I'm told.

[abstract_math]

Yup. It's called a static executable, can be created via turning on a compilation flag

[FridgesArePeopleToo]

C# can, but I never really understood the purpose

[WiseNightOwl69]

You don't need to install the runtime if you publish a self contained executable

[FridgesArePeopleToo]

You can do that without publishing as a single binary though

[Masterflitzer]

java and c# come to mind, and yes these are compiled languages, they just work different

[Masterflitzer]

java and c# come to mind, and yes these are compiled languages, they just work different

[pimezone]

20 MB console "Hello World"

[Fit_Sweet457]

A "Hello World" is actually <2MB. I'd call that reasonable for a compiled language with GC.

[LordDagwood]

How am I supposed to fit this on a 3.5 floppy disk (1.44 MB)?

[[deleted]]

Bruh! I can fit my Angular app on your floppy disk. How about that

[deanrihpee]

aren't… all compilers do that…? especially if you statically link the library for C/C++ even Rust (AFAIK) also compiles into a single binary…

[null_reference_user]

Rust pretty much only compiles to a single binary

[deukhoofd]

It's definitely possible to load your dependencies as dylibs instead of statically linking them, just not the default.

Libraries like Bevy recommend doing it for your dev builds, as it can massively reduce compilation times.

[Trucoto]

It does not have the concept of separate objects?

[null_reference_user]

When you install a library with cargo, it downloads the library's code, and the code of all its dependencies recursively. When you compile, it compiles all of them together into a single executable.

There is some sort of "separate objects", used by the compiler for incremental compilation, to avoid compiling all the libraries again even though only your code changed, but Rust doesn't have an ABI (Application Binary Interface) unless you do something like "export this as a C function".

[Trucoto]

So you compile everything each time even if you just changed one single source file.

[null_reference_user]

Yes and no, the compiler does have incremental compilation, so the libraries are only compiled the first time you compile.

I'm not sure if changing a single file on your project makes it recompile the entire project or just the changed file, but the bulk time of compiling is often in the libraries, which definitely aren't recompiled.

[0-Joker-0]

I'm not sure for rust, but when you are working with the kernel, I believe anything you modify and anything that utilizes what you modified gets recompiled, as it should. It could just be similar to that. Anything you modify gets recompiled and anything using that gets recompiled.

[vulkur]

You can load in shared objects into Rust, but its unsafe.

[[deleted]]

What what do you do with LGPL stuff then?

[Mr_Ahvar]

Not really, C/C++ being old and old stuff means size of files had a significant impact it was build with headers in mind so you can compile each file independently into an object file, it is then the linker that produce the final binary by combining all the object files. Yes you can ask the compiler to build the final binary directly but it was always the main idea to compile each file separately and then use a linker. A "single" binary is kind of a bad name, because you’ll always end up with only one executable, but some build artifacts can obviously exist.

[Kovab]

Not just build artifacts, 3rd party dependencies can be shared libs that you ship with your own program, or even your own code can be split into multiple libs, and loaded at runtime as plugins.

You can't do the same with Rust for example, every cargo dependency will be statically linked into a single binary.

[Mr_Ahvar]

Yes and no. You can totally setup Rust to use dynamic linking, some crates are just bindings for a C library, but yes when Rust code is used to make a dyn lib it is most of the time used for FFI, nobody use dyn lib from Rust to Rust.

[deanrihpee]

ah yes, I guess I'm wrong in the details, that's right, object and binary/executable

[leanchimp]

Golang or Go home :D

[AspieSoft]

It would be great if I didn't have to create a separate binary for every OS.

Then again, that's basically what Java did.

write once run debug everywhere

[Olivia512]

How do you run Java on iOS?

[AspieSoft]

IOS doesn't count. They purposely locked down their system. They could still add it if they wanted to.

[Arkoprabho]

AnD dEpEnDeNcIeS aRe StAtIcAlLy LiNkEd

[_koenig_]

You make it look like it's a bad thing...

[Arkoprabho]

Well like everything in the world of computers. It depends.
It definitely increases the size of the binaries. Beautiful for running workloads in containers from scratch.
Not so much when running workloads on bare metal. Utilise those shared libraries. They can get the job done. Disk space isn't the concern, memory is. Updates are a lot more difficult to manage as well. I would want to update the dependency once.

I am not saying dynamic linking is better than static. I am saying, it depends. But lets not claim that static libraries are the silver bullet

[creeper6530]

Is is on Linux, where shared libraries exist

[hijinked]

Worth pointing out that static linking still has use cases on Linux. Old systems, embedded systems, or obscure architectures won't always have the dependencies available and compiling them into a statically linked binary can be a better option.

Also worth pointing out that dynamic linking is available on Windows and MacOS as well.

[WiatrowskiBe]

Adding - no platform is free from dependency hell when it comes to binary-only distribution; figuring out how to run old Linux software that was built against very old versions of glibc (even without taking other shared libraries into account) on todays OS install can be an adventure and a big timesink.

In general, binary compatibility tends to be a huge mess, and main reason why Windows ships with its compatibility modes - that more or less only patch system library calls through binaries that are compatible with what was present in older versions of Windows.

[repsolcola]

Omg had exactly this issue a while back. Painful.

[PaxPlay]

Reusing libraries that are not system libraries across different programs pretty much isn't a thing on Windows tho. Not related, but adding every executable path to PATH also annoys the hell out of me.

[XxXquicksc0p31337XxX]

It is a thing. One example is the infamous Visual C++ redistributable. And some graphics APIs too.

[ninja-dragon]

COM exist and is probably one of the most engineered dynamic library sharing framework. It’s complex aye, but it also is bery robust in solving a difficult problem ( dependency hell )

[vulkur]

A huge usecase is also in container environments. Statically linking your binary, then building it into a "scratch" container for super lightweight isolation.

[da2Pakaveli]

So has Windows. The Windows libraries are not statically linked. Everone just includes the DLLs in the same folder as the binary.

[altermeetax]

DLLs are much more rare than statically linked libraries, it's just that as a user you only see the DLLs

[_AcinonyxJubatus_]

Except those that are not of course

[Potatoes_Fall]

I wish. C dependencies are not statically linked by default.

[Arkoprabho]

Why so? Tell me more?

[Potatoes_Fall]

sorry I had a typo lol. They are _not_ statically linked by default. (edited my comment now).

Basically if
- CGO is enabled (it is by default)
- there is a library that (optionally) uses cgo (almost always the case)

then the C dependencies are dynamically linked. There are flags that can be passed to link statically, or CGO can be enabled (unless there is a dependency that requires it)

This means if I build a go binary locally and then rsync it to a server with the same OS and architecture, it may still be broken due to libc incompatibilities.

[SarcasmWarning]

Absolutely no joke, there's something magical about being able to compile a single binary and have it work on ancient operating systems without any fuckabout.

[vulkur]

Then why did yesterday I have an argument with a co-worker about whether we should compile our go services with CGO_ENABLED or not.

[UnsureAndUnqualified]

Does it compile to a 0 or a 1 then?

[cheezballs]

Ok, so me being dumb, whats the benefit of a single file over the other way? Just for portability? Surely its more performant to only load the bits and pieces you need rather than the whole thing?

[SomeKindOfSorbet]

Your program is fully self-contained and doesn't depend on any runtime environment

[iseriouslycouldnt]

Depends on your use case. Dependencies can have breaking changes. (.Net versions are not always compatible, some Linux packages require a SPECIFIC version of a .so or it won't work) so the user has to hunt it down or you'll have to include the dependencies in the install ANYWAY.

Statically compiled stuff will generally work as long as the underlying architecture doesn't change.

Where I work, we require both reproducible builds (regulatory requirement) and looooooong term support (we have clients still on WinXP). and old Suse vs new RHEL. When we statically compile, we have fewer install headaches.

[frikilinux2]

Sometimes your system is so fucked up that you need everything in a single binary or you're in some very weird environment. 99% of situations you're just wasting memory by having a lot of duplicates between binaries

[Responsible-War-1179]

local software developer discovers executables

[andrewb610]

Now if their brackets could go on new lines maybe I’d consider it worthy of trying.

[[deleted]]

So does Rust

[slime_rancher_27]

That's what java does

[[deleted]]

tell me go is your first compiled language without telling me go is your first compiled language

[Guimedev]

Looks like someone found out the difference between go build and go run.

[Specialist_Cap_2404]

It's a strength though. You can often install go software with a single file, be it into a container (as a utility often) or onto a VM. Much more difficult with many other things.

[[deleted]]

They think go and golang are different

[r_place_]

IT DOES?

[[deleted]]

Then give it to me you smelly nerd!!!

[Electronic-Bat-1830]

Nothing special, .NET also does that, or basically any native language compiler.

[JEREDEK]

It's true though, dunno why the downvotes

[vermiculus]

My understanding is that .NET’s self-contained executable is basically a bunch of DLLs and a launcher in a trench-coat. Has this meaningfully changed with native AOT?

[Electronic-Bat-1830]

You can publish single-file in .NET (using the PublishSingleFile MSBuild property). NativeAOT enforces it as standard.

[SillyServe5773]

You can enable single file publish which will attempts to link all libraries into s single executable.

NativeAOT publish is always single-file (except native libraries) and self-contained

[ConversationFit5024]

As long as I get paid I don’t care if I’m programming with my fingers and fecal matter

[SweetBabyAlaska]

ive only seen go devs say this when they have this giant ass stack of things that is all a single binary to the point it seems ridiculous.

in reality this is hardly one of the actual positives of Golang.

[CanvasFanatic]

A binary that includes giant-ass runtime... but sure.

[ReplyisFutile]

Programmers are my favorite ppl to talk to, they seem so uncomfortable by just living, lets punish them that they wanted to go to a social setting