3 ms·

Can Perl6 merge all of its generated VM code into one "package"? One of my favourite things about Go is that you can statically compile everything and then depl

Can Perl6 merge all of its generated VM code into one "package"? One of my favourite things about Go is that you can statically compile everything and then deployment basically becomes scp.

rlpb 9y ago
...and then deployment basically becomes scp. And security updates for your deployment become...what?
- sherr 9y ago
  Rebuild and scp the whole lot again? Not necessarily a big deal.
  - rlpb 9y ago
    Rebuilding by pulling in all your dependencies from the Internet again? That's not something I want to do when the clock is ticking to get a security update out. What if some random third party dependency is hosted somewhere that is down, or has been pulled? And how do I know I have to rebuild in the first place? You'll probably tell me that there are tools to help deal with this. I'm sure there are. My point is that it isn't as simple as "scp".
  - xutopia 9y ago
    Or doing patches. Copy the file locally... apply the patch... restart process.
hpcjoe 9y ago
I find it somewhat humorous that more than 25 years on, we are effectively reverting to static linking and bundling [1]. Way ... way back in the day, the argument was it would save memory, encourage reuse, etc. While some of this may have been true, it also gave rise to dynamic library hell. Reuse was overshadowed by incompatible versions, or API changes between versions that became the stuff of legends. This would make a great study in how the ROI was completely overshadowed by risk considerations not considered at the outset. Of course, saving memory was a huge issue in the days when 1GB RAM was considered gigantic. So maybe the cost was worth it. [1] https://scalability.org/2017/03/what-is-old-is-new-again/ https://scalability.org/2017/03/what-is-old-is-new-again/
- Sean1708 9y ago
  > Way ... way back in the day, the argument was it would save memory ... it also gave rise to dynamic library hell. Could you expand a bit on how static linking would cause either of those things? It seems to me that they are both consequences of dynamic linking.
  - kbenson 9y ago
    I think "the argument" being referred to was the push for dynamic linking, and the consequences in question are for dynamic linking. I think there was just a somewhat unclear implicit shift in the subject.
- raiph 9y ago
  > Reuse was overshadowed by incompatible versions, or API changes between versions that became the stuff of legends. The Perl community has spent a couple decades "enjoying" taking (or being forced to take) a long hard look at that. One result in P6 is :auth (authority), :api (api version) and :ver (package version) qualifiers, eg: use Some::Module:ver<1.2>:api<3.4>; with corresponding support throughout the language and packaging tools. Aiui this aspect of the language and tooling needs work but shows promise.

Can Perl6 merge all of its generated VM code into one "package"? One of my favourite things about Go is that you can statically compile everything and then deployment basically becomes scp.

rlpb 9y ago

...and then deployment basically becomes scp. And security updates for your deployment become...what?

sherr 9y ago
Rebuild and scp the whole lot again? Not necessarily a big deal.
- rlpb 9y ago
  Rebuilding by pulling in all your dependencies from the Internet again? That's not something I want to do when the clock is ticking to get a security update out. What if some random third party dependency is hosted somewhere that is down, or has been pulled? And how do I know I have to rebuild in the first place? You'll probably tell me that there are tools to help deal with this. I'm sure there are. My point is that it isn't as simple as "scp".
- xutopia 9y ago
  Or doing patches. Copy the file locally... apply the patch... restart process.

hpcjoe 9y ago

I find it somewhat humorous that more than 25 years on, we are effectively reverting to static linking and bundling [1]. Way ... way back in the day, the argument was it would save memory, encourage reuse, etc. While some of this may have been true, it also gave rise to dynamic library hell. Reuse was overshadowed by incompatible versions, or API changes between versions that became the stuff of legends. This would make a great study in how the ROI was completely overshadowed by risk considerations not considered at the outset. Of course, saving memory was a huge issue in the days when 1GB RAM was considered gigantic. So maybe the cost was worth it. [1] https://scalability.org/2017/03/what-is-old-is-new-again/ https://scalability.org/2017/03/what-is-old-is-new-again/

Sean1708 9y ago
> Way ... way back in the day, the argument was it would save memory ... it also gave rise to dynamic library hell. Could you expand a bit on how static linking would cause either of those things? It seems to me that they are both consequences of dynamic linking.
- kbenson 9y ago
  I think "the argument" being referred to was the push for dynamic linking, and the consequences in question are for dynamic linking. I think there was just a somewhat unclear implicit shift in the subject.
raiph 9y ago
> Reuse was overshadowed by incompatible versions, or API changes between versions that became the stuff of legends. The Perl community has spent a couple decades "enjoying" taking (or being forced to take) a long hard look at that. One result in P6 is :auth (authority), :api (api version) and :ver (package version) qualifiers, eg: use Some::Module:ver<1.2>:api<3.4>; with corresponding support throughout the language and packaging tools. Aiui this aspect of the language and tooling needs work but shows promise.