Re: Guix and the developer ecosystem

[Liliana Marie Prikler]

Hi Distopico

Am Mittwoch, dem 26.07.2023 um 19:29 -0500 schrieb Distopico:
> 
> Hi, I'm quite new in Guix, I have been using it for 6 months now and
> I love it, but for development I have not been able to use it as much
> as I would like.
"Development" is a loaded term that is understood differently by
different groups of people.  I personally write software in dialects of
C and Lisp (yes, even Java if I must), sometimes Python, and most of
the time Guix at the very least suffices for doing so, if it doesn't
excel.  Obviously, the holy grail here is a reasonable build system
based on GNU tools, CMake or Meson, that "modern programming languages"
often don't want to employ.

> The current programming languages are made up of three [or four]
> parts:
> 
> 1. The languages itself
> 2. Language-server
> 3. The language packages
> 4. Language tools (formatter, linter)
> 
> It is possible to development without a language server, but many
> projects now require special formatting or running linter tools,
> etc. These are things that are somewhat basic in a certain way.
But as with all necessities, just because they're "basic" doesn't mean
that they're also available to the masses.  There are several
programming languages, where even getting to a compiler is impossible,
let alone the other three items on your list.  See [1] on why that's a
bad idea.

> In terms of programming languages, I have found almost all the ones I
> needed, with the exception of Kotlin.
[2]

> Regarding language servers, most of the ones I needed either haven't
> worked for me or don't exist. For example, Rust, Haskell, and Elm
> have few tools available
I wonder what all of those have in common.  🤔️

> [E]ven though I mainly program in Rust and Haskell, and lately, I've
> been getting into Guile, I also have old projects in Kotlin, for
> instance, or sometimes I like try other languages when `guix shell`
> is awesome.
> 
> So, sometimes I wish to do...
> 
> ```
> guix shell ghc haskell-language-server hlint
> ```
> 
> In that case, the language server isn't available. Another example:
I mean, you could try packaging it, assuming it has a reasonable
dependency graph.  Okay, you can stop laughing now.

> ```
> guix shell rust@1.67.1 rust-analizer rust-clippy
> ```
> 
> In that case, rust-analyzer won't be compatible with that version of
> Rust, and the version of rust-analyzer is broken (I sent a patch
> fixing it).
--with-input to the rescue.

> 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.
--with-input?

> So, in many cases, I haven't been able to fully integrate Guix into
> my development workflow. I had to look for alternative ways outside
> Guix, like Nix.
I mean, with ecosystems that insist on using their tools for packaging
and nothing else, even just having it in Nix is already a step up.  But
at the same time Nix cuts corners that Guix cutsn't, and I'm pretty
sure that these tools fall right into that category.

> I appreciate the simplicity of Guix, but let's say that Nix has a
> developer-oriented approach and has become very popular among
> programmers. Many projects now include default configurations for Nix
> in their repositories.
Certainly, Nix enjoys clout, but there's nothing to stop you from
committing a guix.scm to your favourite project.  Case in point, I
recently contributed to one such project on Github (via mail to the
devs, of course).

> Another issue is that if I wanted to bring Guix into the development
> workflow in a team, there would be the limitation of the OS. While I
> promote free software in working groups, not everyone uses the same
> OS - some use GNU/Linux, some use Mac, etc. I think this is also part
> of the reason why Nix has succeeded in development environments.
If you have the metal to spare, why not help us ingest some Asahi Linux
patches?

> 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?
You mean other than --with-input?  Well, you can pray for the upcoming
USE flag light parameterized packages to become just that, though I
personally hope they don't, as there are more interesting applications.

> 2. Do you see developers as a potential target audience for Guix, or
> is it mainly focused on HPC (High-Performance Computing)?
Well, the "developers" Guix sees as target audience typically refer to
themselves as hackers and don't think of themselves as an elite that
ought to be given exclusive access to their tools, but rather as a
vanguard party that wishes to make them available to all.

High performance computing is one application in which Guix makes a lot
of sense, but there are others ranging from academic over less academic
to everyday computing, games, and even running stress on your CPU, GPU,
and what other PUs you can nowadays put into hardware to make number go
up while the world is literally on fire.

> 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.
There is only one direction, and that is forward.

Cheers

[1] https://bootstrappable.org/
[2] https://bootstrappable.org/projects/java-tools.html