5 ms·

> Dynamic linking on *nix has nothing to do with 70s era programming languages. Given that dynamic linking as a concept came out of the C world, it has everyth

> Dynamic linking on *nix has nothing to do with 70s era programming languages. Given that dynamic linking as a concept came out of the C world, it has everything to do with them. > Did you consider the possibility that the incompatibility between monomorphization (possibly the dumbest term in all of programming) and dynamic linking should perhaps saying something about monomorphization, instead? Yes, I considered that possibility.

PaulDavisThe1st 4y ago
The design of dynamic linking on most *nix-ish systems today comes from SunOS in 1988, and doesn't have much to do with C at all other than requiring both the compiler and assembler to know about position-independent code. What elements of dynamic linking do you see as being connected to "70s era programming languages"? > Yes, I considered that possibility. Then I would urge you to reconsider.
- preseinger 4y ago
  dynamic linking is an optimization that is no longer necessary there is no practical downside to a program including all of its dependencies, when evaluated against the alternative of those dependencies being determined at runtime and based on arbitrary state of the host system monomorphization is good, not bad the contents of /usr/lib/whatever should not impact the success or failure of executing a given program
  - PaulDavisThe1st 4y ago
    Dynamic linking wasn't an optimization (or at least, it certainly wasn't just an optimization). It allows for things like smaller executable sizes, more shared code in memory, and synchronized security updates. You can, if you want, try the approach of "if you have 384GB of RAM, you don't need to care about these things", and in that sense you're on quicksand with the "just an optimization". Yes, the benefits of sharing library code in memory are reduced by increasing system RAM, but we're seeing from a growing chorus of both developers and users, the "oh, forget all that stupid stuff, we've got bigger faster computers now" isn't going so well. There's also the problem that dynamic loading relies on almost all the same mechanisms as dynamic linking, so you can't get rid of those mechanisms just because your main build process used static linking.
    - preseinger 4y ago
      it allows for all of the things you list, yes, but those things just aren't really valuable compared to the reliable execution of a specific binary, regardless of any specific shared library that may be installed on a host smaller executable sizes, shared code in memory, synchronized security updates, are all basically value-zero, in any modern infrastructure there is no "growing chorus" of developers or users saying otherwise, it is in fact precisely the opposite, statically linked binaries are going extremely well, they are very clearly the future
      - PaulDavisThe1st 4y ago
        the chorus is about the assumptions commonly found among younger devs that these old "efficiency" and "optimization" techniques don't matter any more. c.f. apps (desktop, mobile) that take forever to do things that should not take forever. "modern infrastructure" seems like a bit of a giveaway of your mind set. yes, i know that there's a lot of stuff that now happens by having your web browser reach out to "infrastructure" and then the result is displayed in front of you. But lots of people still use their computers to run applications outside the browser, where "modern infrastructure" means either nothing at all, or it means "their computer (or mobile platform)". the techniques mentioned in this subthread are all still very relevant in this context.
        preseinger 4y ago
        there is basically no situation in which it is important to optimize for binary size, embedded sure, but nowhere else the infrastructural model i'm describing doesn't require applications to run in browsers, or imply that applications are slower, actually quite to the contrary, statically linked binaries tend to be faster the model where an OS is one to many with applications works fine for personal machines, it's no longer relevant for most servers (shrug)
        PaulDavisThe1st 4y ago
        it was never relevant for servers. and there are probably still fewer servers than end-user systems out there, certainly true if you include mobile (there are arguments for and against that).
- howinteresting 4y ago
  Thanks for the information about SunOS. My point still stands: the C ecosystem makes it possible in a way that other language models simply don't. > Then I would urge you to reconsider. Done. No change to my beliefs.

PaulDavisThe1st 4y ago

The design of dynamic linking on most *nix-ish systems today comes from SunOS in 1988, and doesn't have much to do with C at all other than requiring both the compiler and assembler to know about position-independent code. What elements of dynamic linking do you see as being connected to "70s era programming languages"? > Yes, I considered that possibility. Then I would urge you to reconsider.

preseinger 4y ago
dynamic linking is an optimization that is no longer necessary there is no practical downside to a program including all of its dependencies, when evaluated against the alternative of those dependencies being determined at runtime and based on arbitrary state of the host system monomorphization is good, not bad the contents of /usr/lib/whatever should not impact the success or failure of executing a given program
- PaulDavisThe1st 4y ago
  Dynamic linking wasn't an optimization (or at least, it certainly wasn't just an optimization). It allows for things like smaller executable sizes, more shared code in memory, and synchronized security updates. You can, if you want, try the approach of "if you have 384GB of RAM, you don't need to care about these things", and in that sense you're on quicksand with the "just an optimization". Yes, the benefits of sharing library code in memory are reduced by increasing system RAM, but we're seeing from a growing chorus of both developers and users, the "oh, forget all that stupid stuff, we've got bigger faster computers now" isn't going so well. There's also the problem that dynamic loading relies on almost all the same mechanisms as dynamic linking, so you can't get rid of those mechanisms just because your main build process used static linking.
  - preseinger 4y ago
    it allows for all of the things you list, yes, but those things just aren't really valuable compared to the reliable execution of a specific binary, regardless of any specific shared library that may be installed on a host smaller executable sizes, shared code in memory, synchronized security updates, are all basically value-zero, in any modern infrastructure there is no "growing chorus" of developers or users saying otherwise, it is in fact precisely the opposite, statically linked binaries are going extremely well, they are very clearly the future
    - PaulDavisThe1st 4y ago
      the chorus is about the assumptions commonly found among younger devs that these old "efficiency" and "optimization" techniques don't matter any more. c.f. apps (desktop, mobile) that take forever to do things that should not take forever. "modern infrastructure" seems like a bit of a giveaway of your mind set. yes, i know that there's a lot of stuff that now happens by having your web browser reach out to "infrastructure" and then the result is displayed in front of you. But lots of people still use their computers to run applications outside the browser, where "modern infrastructure" means either nothing at all, or it means "their computer (or mobile platform)". the techniques mentioned in this subthread are all still very relevant in this context.
      - preseinger 4y ago
        there is basically no situation in which it is important to optimize for binary size, embedded sure, but nowhere else the infrastructural model i'm describing doesn't require applications to run in browsers, or imply that applications are slower, actually quite to the contrary, statically linked binaries tend to be faster the model where an OS is one to many with applications works fine for personal machines, it's no longer relevant for most servers (shrug)
        PaulDavisThe1st 4y ago
        it was never relevant for servers. and there are probably still fewer servers than end-user systems out there, certainly true if you include mobile (there are arguments for and against that).
howinteresting 4y ago
Thanks for the information about SunOS. My point still stands: the C ecosystem makes it possible in a way that other language models simply don't. > Then I would urge you to reconsider. Done. No change to my beliefs.