this post was submitted on 07 Sep 2023
62 points (94.3% liked)

Programming

17487 readers
117 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
 

There was a time where this debate was bigger. It seems the world has shifted towards architectures and tooling that does not allow dynamic linking or makes it harder. This compromise makes it easier for the maintainers of the tools / languages, but does take away choice from the user / developer. But maybe that's not important? What are your thoughts?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 22 points 1 year ago (2 children)

I have yet to find a memory hungry program thats its caused by its dependencies instead of its data. And frankly the disk space of all libraries is minuscule compared to graphical assets.

You know what's going to really bother the issue? If the program doesn't work because of a dependency. And this happens often across all OSes, searching for these are dime a dozen in forums. "Package managers should just fix all the issues". Until they don't, wrong versions get uploaded, issues compiling them, environment problems, etc etc.

So to me, the idea of efficiency for dynamic linking doesn't really cut it. A bloated program is more efficient that a program that doesn't work.

This is not to say that dynamic linking shouldn't be used. For programs doing any kind of elevation or administration, it's almost always better from a security perspective. But for general user programs? Static all the way.

[–] [email protected] 3 points 1 year ago (2 children)

I read an interesting post by Ben Hoyt this morning called The small web is a beautiful thing - it touches a lot on this idea. (warning, long read).

I also always feel a bit uncomfortable having any dependencies at all (left-pad never forget), but runtime ones? I really like to avoid.

I have Clipper complied executables written for clients 25 years ago I can still run in a DOS VM in an emergency. They used a couple of libraries written in C for fast indexing etc, but all statically linked.

But the Visual Basic/Access apps from 20 years ago with their dependencies on a large number of DLLs? Creating the environment would be an overwhelming challenge.

[–] [email protected] 6 points 1 year ago (2 children)

I kind of agree with your points, but I think there has to be a distinction of libs. Most deps should be static IMHO. But something like OpenSSL I can understand if you go with dynamic linking, especially if it's a security critical program.

But for "string parsing library #124" or random "gui lib #35".. Yeah, go with static.

[–] [email protected] 1 points 1 year ago

string parsing library #124

this could also become a major security problem, tho.

[–] [email protected] 1 points 1 year ago

Great point. Sometimes the benefit of an external dependency being changeable is a great feature.

[–] Blackthorn 2 points 1 year ago (1 children)

I can't not upvote someone who brings Clipper to the table :)

[–] [email protected] 1 points 1 year ago

Us looking at developers still on dBase III ~inserts Judgmental Volturi meme~

[–] [email protected] 1 points 1 year ago (1 children)

But for general user programs? Static all the way.

Does it include browsers?