Re: Guix and the developer ecosystem

[Distopico <distopico@riseup.net>]

[-- Attachment #1: Type: text/plain, Size: 4215 bytes --]


On 2023-07-31, "(" <paren@disroot.org> wrote:

> Hi,
>
> Distopico <distopico@riseup.net> writes:
>> In terms of programming languages, I have found almost all the ones I
>> needed, with the exception of Kotlin.
>
> The build sequence for Kotlin is some sort of hellish double
> nightmare-loop of doooooooooooooom.  As far as I'm aware, this is how
> the main dependencies of Kotlin relate to each other:
>
>                      .---------------------.
>                      |                     |
>    .-------------> gradle ------.          V
>    |                 ^          |        kotlin ------.
> openjdk              '----------'        ^    ^       |
>    |                                     |    '-------'
>    '-------------------------------------'
>
> Fun!
>

Nice graphs, sound pretty complicate to solve that  :/

>> In some languages like Haskell and GoLang, the language server depends a
>> lot on the version it was compiled with. For example, I tried gopls,
>> which is available in Guix, but it was built with Go 17 and is not
>> compatible it.
>
> Ah, that'll be because Guix uses Go 17 for building Go programs, unless
> you override the ``#:go'' keyword, but the latest version of Go it
> provides is Go 20.  I suppose it couldn't hurt to change it to be built
> with the latest version.  (We can't just make the default build Go be
> 20, as that would require the CI to rebuild all Go packages.)
>

And that can be another problem, or it is indeed a real problem, going
to a project that uses Go 1.7, but all the tools are built around Go
1.20. That's why I imagine something like having tools relative to their
versions, so we can install gopls@0.11 and go@1.17 together because they
are compatible. And if I switch to another project, I could install
Go@1.15 and gopls@0.9.5. Currently, that is not possible, at least I
haven't seen it in Go/Rust/Haskell in Guix.

>> I have started contributing to packages that I believe could be useful,
>> and I like to contributing to teams such as Haskell or Rust. However,
>> there are other topics, such as compiler and tools compatibility, where
>> I'm not entirely clear about the direction that has been planned.
>
> The problem with Haskell, Rust, and Elm is mainly, as lilyp has
> said/implied, that while the dependency trees of C applications and such
> typically resemble the following:
>
>         O <-- O
>   O <-- O <-- O
>         O <-- O
>
> dependency trees for Rust, Haskell, and Elm look like this:
>
>                         / O
>                   / O <-- O
>                   |     \ O
>                   |
>                   |     / O
>             / O <-- O <-- O
>             |     |     \ O
>             |     |
>             |     |     / O
>             |     \ O <-- O
>             |           \ O
>             |
>             |           / O
>             |     / O <-- O
>             |     |     \ O
>             |     |
>             |     |     / O
>   O <-- O <-- O <-- O <-- O
>             |     |     \ O
>             |     |
>             |     |     / O
>             |     \ O <-- O
>             |           \ O
>             |
>             |           / O
>             |     / O <-- O
>             |     |     \ O
>             |     |
>             |     |     / O
>             \ O <-- O <-- O
>                   |     \ O
>                   |
>                   |     / O
>                   \ O <-- O
>                         \ O
>
> Except in reality it's much much much much much worse.
>
> So it's not because that's not something we'd like to have, it's largely
> because packaging such things is a royal pain and there aren't all that
> many people with the motivation to do that.
>


And this is the current reality, and it will become more and more
common, whether for better or for worse. Package managers make it so
convenient to install dependencies, but it leads to an abuse in that
regard. I could name many of the most widely used programming languages
today that have the same problem: JavaScript, Python, Haskell, Rust,
just to name a few. So, here is my question: Is there a future vision
for this situation? Because it will become more and more common over
time.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]