Re: Guix and the developer ecosystem

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi Distopico,

Am Freitag, dem 04.08.2023 um 20:11 -0500 schrieb Distopico:
> 
> 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. 
I mean, even if you object in the paragraphs below, Guix already covers
a significant variety of languages, probably more so than other system
package managers and in any case more so than language-specific ones.  

> 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.
Well, as it turns out with generic solutions to problems, they only
apply as long as you've modeled your problem accurately enough.  And in
practice, people also settle for worse.  For instance, there's one
particular IDE that takes up twice as much disk space if you want to
use it for two programming languages.  By valuing freedom over anything
else, we already have to deal with false expectations when it comes to
hardware choices.  This is by far not the first time that we're hurt by
the consequences of short-sighted to harmful design decisions taking by
companies that only care about large numbers.

> 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.
Modernity itself is somewhat antiquated, and you can see the same issue
with programming languages.  We had a talk on postmodern C++ in 2017,
so languages that date back to the early 2010s qualify as "modern" in
my eye.  This also includes Javascript, which although a little older
than the rest, through npm pioneered the idea of horking up Python's
packaging model even harder.

> > > 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.
Let's stash away the thoughts about potential workarounds for now and
come back to them later.  The plan to address this in the future *is*
[1], that is bootstrapping all the tools we don't have (to the best of
our ability).

> > > 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.
My guess would be that they don't even bother building packages from
source in some cases.

> > > 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.
In order to effectively create a sustainable development process, we
need to break up with the current tradition of cramming the entire
internet into a binary and linking that statically, so everyone
afterwards has to do the same.

Of course, this is a hard solution to roll out, because it is a social
one rather than a technical one.  Sure, language package managers right
now enable you to put almost everything into your code and "have it
work".  That doesn't mean it's a good idea.  In fact, it's a pretty bad
one, and one that's at heart of all our software supply chain issues. 

> > 
> > > 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.
Why the hell is a linter included in your build process in the first
place?  I can understand that you might want to invoke one before
dropping the package maintainers a mail, I mean creating a pull
request, but it shouldn't matter otherwise.

By the way, remember when I earlier told you we'd come back to
workarounds later?  Now is later.  See, emulating the FHS means that
you fake being a regular old Linux distribution whose layout is as Rust
would expect without giving it write access to special folders of your
actual machine.  This is quite powerful indeed.

As for packaging clippy, you could try the crate importer, but there's
a chance that it does something useless, because Rust decided that
their own packaging strategy didn't work for it.  The same disclaimer
also holds for some GNOME projects that decided to use Rust because
it's the new hot stuff and decided not to follow its distribution
model.  This causes their packages to be form chimaeras of cargo and
meson and I don't know why they are actually content with that solution
beyond the observation that "it works".  

> > > 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 want to change just becase an
> contractor have the idea of use Guix.
And that is fine.  Recall earlier when I mentioned "reasonable build
system based on GNU tools, CMake or Meson"?  Those tools work all the
same under other operating systems as well.  It's not like you have to
reinvent them for another programming language.  You can still use Guix
to improve your flow without forcing everyone to use it.  And there's
still a chance that at least part of the team will think that it's a
great idea, unless they have all sold Steve Jobs their souls.

> > > 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
The examples provided in that blog are already more interesting than
whatever you're trying to solve.

> > > 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 don't think the reality is as bleak as you make it out to be.  Sure,
we probably don't carry cutting-edge versions of most Rust/Haskell
stuff out there, but depending on where you sit in the dependency tree,
you'll have an easier or harder time.  It's quite comfortably around
the trunk and rather shaky in the leaves, but it should at least be
manageable as long as it's a tree.  You'd just have to start actually
managing it.

Cheers
> >