Comment by 616c | Hacker News Reader

Comment by 616c | Hacker News Reader

Parent Full thread

Earlier someone posted in response to my comments about Guile a cool FRP system for 2D game design in Guile. There are also seem not projects using Guile, from what I can tell. Check out the list at Guile's GNU project page.

https://www.gnu.org/software/guile/gnu-guile-projects.html

That being said, most languages need some form of dependency management, and this story has yet to see an ending in Guile. People continue work on one called Guildhall, but it is not yet complete.

http://wingolog.org/archives/2011/07/04/guile-2-0-2-building...

I tried deploying on my Arch Linux laptop, and encountered some issues. I also thought it would be cool to try Guile and GNOME for quick apps, but without dependency managers and incomplete documentation, it is hard for me as I am, if I can toot my own horn, a low-intermediate Linux user and a very novice Scheme student.

So long story short: toolchain and documentation are not there yet. I continue to hope because it is still cool.

Also, check this blog. I and others mentioned it. It is very cool and gives you very deep technical insight from a Guile maintainer into all the hard work being put into its core improvements.

http://wingolog.org/

In short, it is no Lua (or really Lua+LuaJIT), but it might be there one day.

Dependency management for Guile will be best handled via Guix - which handles not only Guile specific dependencies, but can replace the system package manager entirely, and perhaps parts of the crufty gnu build system too, now that you can define custom build processes in guix packages, and you can also use guile from GNU Make. Guix will also be used for configuration management too (since configurations are treated like packages.)

Guix is really the killer app that will push Guile forwards, and towards realizing Guile for it was originally meant to be - an extension language for the GNU system. DMD is also being developed in Guile as part of the GNU system - to allow for dependency based daemon initialization without completely invading your system like certain others.

I don't see Guile as a candidate for merely "tacking onto" existing apps like you typically do with Lua, but as more of an integrated part of a dynamically configurable operating system, much like emacs but for the whole system.

I have heard of Guix, and I am quite excited about it. I am just waiting for it to catch up for me. In this regard, Nix and NixOS are also fascinating.

Maybe I am the last of the Linux kids using Stow, and I like it because it makes me worry less about source installations on my computer. It would be great to see Guix build on this idea. As much as I would love to transition to a new Linux distro, I would love even more having a ~/guix or ~/.guix path with different builds. If I really mess up my computer, I can delete this folder and all those binaries and the appropriate symlinks go away.

This is what worries me about NixOS. Eventually with Stow NixOS, and other declarative package management you hit a little where you cannot outhink your dependenices. If your root is nixos and everything else is symlinked, that sounds hard for a mere mortal like me to debug.

http://nixos.org/nixos/screenshots/nixos-terminals.png

You can already do that with guix and nix - they can run atop your distro and simply create new application directories where you want them. The actual builds are in /nix/store (or /guix/store), and symlinked from whatever profile you want (you can have several).

It's also gonna be pretty hard to screw up your computer too, since multiple versions of software can be installed without problems, and you can perform safe rollbacks. The store is read-only and shouldn't be hard deleted by mortals anyway, but you should perform all the deletions through nix/guix.

The advantage of building an OS out of nix/guix is that you generally don't want to perform any kind of change to a system which is not reproducible (ie, no "hidden knowledge" that went into configuring a system) - so that if your system does ever break due to some unforeseen circumstances, you have a declarative configuration of the system in its entirety before it broke, and you can rebuild the system in a few commands.

It's probably worth abandoning the idea that applications (or symlinks) should go into /usr/bin or anywhere else - the need for symlinks exists mostly for compatibility, but from the POV of a package or configuration, you should only refer to a specific identity of a derivation in the store.

For example, if I wanted a shortcut of say, emacs on my desktop - I could have a "desktop_icons.scm" package in which I define them - and rather than pointing to some /usr/bin/emacs, I would point to some "emacs" variable (referring to a specific version) imported from the emacs package, and append the relative bin path. Then if I change the version "emacs" points to, the desktop icon will be updated too.

Nitpick: Guix uses /gnu/store now. :)

>In short, it is no Lua (or really Lua+LuaJIT), but it might be there one day.

Lua and Guile have different use cases. Typically, Lua is embedded in an application. With Guile, you can still embed, but it's not really the best way to do things. It's much better to write your application as a shared library that Guile can load and thus extend Guile. Even better is to write your application in pure Guile, using the C FFI when needed.

Fair, but I have been under the impression that the intended use case of Guile is an embedded extension language, like how you describe Lua, and like the language is was intended to replace, Emacs Lisp.

From the website (http://gnu.org/s/guile):

"Guile is an efficient virtual machine that executes a portable instruction set generated by its optimizing compiler, and integrates very easily with C and C++ application code. In addition to Scheme, Guile includes compiler front-ends for ECMAScript and Emacs Lisp (support for Lua is underway), which means your application can be extended in the language (or languages) most appropriate for your user base. And Guile's tools for parsing and compiling are exposed as part of its standard module set, so support for additional languages can be added without writing a single line of C."

A JS front-end? I mean, sure, but a backend a la Clojurescript would be awesome too.

> It's much better to write your application as a shared library that Guile can load and thus extend Guile.

That's how I usually use Lua.

Reply on news.ycombinator.com