Re: Suggestion: use static linking instead of dynamic linking just as how rust and golang do.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



It's probably not important for this specific case, but just to be clear:

> The only benefit is to reduce storage consumption.

That's not entirely true. Depending on how the linker works
internally, it can also reduce RAM usage because multiple programs can
be mapped to the same code/data in RAM(possibly with a copy-on-write
mapping).

On Tue, Feb 13, 2024 at 12:43 AM Evan Greenup
<evan_greenup@xxxxxxxxxxxxxx> wrote:
>
> Suggestion
>
> Build executable program written in Haskell statically. (For the convenient of package maintainer, remove Haskell library packages).
>
> Reason
>
> The advantage of dynamic linking is letting multiple executable sharing same part of code. The only benefit is to reduce storage consumption. But in nowadays, storage is getting cheaper and cheaper. It is no longer be a issue now. And Haskell packages are all relatively small.
>
> However, here are a lot of drawbacks for dynamic linking of Haskell ecosystem.
>
> Firstly is dependency version conflict. If two package depend on a same package with exclusive permitted version range, it will be a big trouble.
> One dependency version update requires Arch Linux package maintainer update a series of packages which depend on this package. (Unlike Python, Haskell is compiled language with low ABI compatibility across different version).
> lack of link time optimization.
> Long time of upgrading via pacman. Updating many small package is really much slower than updating one big package. And registering Haskell module take a long time.
>
> Why program written in C/C++ can be distributed in dynamical linking form?
>
> C/C++ has very poor dependency resolver and package manager. C/C++ project need developer take care of dependency manually. And C/C++ compiler provide relatively stable ABI. None of those condition applies to Haskell.
>
> Details of Action
>
> Only providing:
>
> ghc exclusive to ghcup
> ghcup provide ghc, stack, cabal-install. This is similar to rustup package.
> haskell-language-server like other Haskell executables, statically linked.
>
> When user install ghcup via pacman , the need to manually set default toolchain to install ghc and other tools.
>
> All non-executable Haskell library become unnecessary. Since no Haskell developer will use haskell package provided by the Linux distro.
>
> Expected Benefit
>
> package maintainer will save a lot of time on maintaining Haskell software.
> update will be much quicker.
> All Haskell program packages can easily up-to-date.
>
> I believe the gain of this suggestion is significantly greater than the loss.
>
>
> Evan




[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux