Re: Guix and the developer ecosystem

[Distopico <distopico@riseup.net>]

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


On 2023-07-29, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

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

Hi, thank you for your response, well When I say "developer ecosystem,"
I'm referring to a significant variety of languages, whether new or not,
to meet the development needs in different languages compatible with
free-software software. Otherwise, it would be a development environment
limited to C, Python, and a few others, which should be clarified to
users to avoid creating false expectations. By "horizon" or the future
vision of the project, I mean the overall outlook concerning this aspect.

I can't say that Haskell falls under the category of "modern," but it
has been progressively "modernizing," adapting to the implications,
whether good or bad. Javascript is definitely not new, and TypeScript is
another example that is not new either.

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

Does Guix have a plan to address this in the future or a workaround? I
believe that in the future, this issue will become even more common,
just as more languages have their own package managers, which are partly
responsible for this huge dependency tree.

>> In terms of programming languages, I have found almost all the ones I
>> needed, with the exception of Kotlin.
> [2]
>
Thank, good to known that, just curious why/how nix have it.

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

You are absolutely right. As I mentioned before, the ever-increasing
huge dependency tree is becoming more common in various programming
languages due to the convenience of package managers. It is essential to
have a plan on how to address these situations to ensure the long-term
sustainability and maintainability of projects. Without a plan, it might
be better not to embark on such a journey, as managing complex
dependency chains can lead to numerous challenges and issues in the
future. Projects like Guix need to actively consider strategies to
handle and mitigate these complexities effectively to ensure a smooth
and sustainable development process.

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

Nice, I'll try it, thank you

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

Well, what holds me back is that many dependencies are missing, such as
the basic ones I mentioned, making it impossible to use Guix in many
cases. Others have non-ideal solutions, like one suggested in Matrix:
`guix shell --container --emulate-fhs' + downloading the rustup script
and installing it just to use clippy (the Rust linter). So, it's not
feasible to include that in the project due to current limitations.

>> 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?
>

Well, I think is not a real solution, a lot of time the people with
those mac are from the companies and you are not able to change the OS,
or sometimes you work as a freelancer in a company and other people use
Mac and they don't wan to change just becase an contractor have the idea
of use Guix.

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

Maybe this will be the solution:
https://blog.lispy.tech/parameterized-packages-the-second-update.html

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

Well, is someone want to hack with Rust/Haskell using Guix is not
possible, They may end up taking alternative paths like in my case, or a
mix of using Guix in some areas and not in others.

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

For sure, thank you.

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