Re: Guix and the developer ecosystem

["(" <paren@disroot.org>]

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!

> 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.)

> All this text is provided some context for two simple questions:
>
> 1. Are there plans in the future to improve integration between
> development tools? For example, having haskell-language-server for
> ghc@9.x and another one for ghc@8.x, or something similar to the
> overwrite feature in Nix flake?
>
> is it mainly focused on HPC (High-Performance Computing)?

Definitely not :)

> 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 apologies for the lengthy text.

It's okay, questions are good :)

  -- (