Nice to see another contender in the build-script arena, and very happy it’s part of Racket. I use Racket every day for work and love seeing what new developments there are.
I don’t have enough experience in building Racket from scratch or cross-platform compiling, but it seems like a lot of work went into making Zuo very minimal and easy to embed anywhere. Even toying around with it a bit, it doesn’t come with an interpreter, and it seems to have the basic primitives needed to build out some applications (and it seems like the only numbers it supports is 64-bit signed integers).
I think it’s interesting enough to build some very tiny scripts with and explore, but curious to see if it simplifies the build process for projects. I might try incorporating a Zuo file into a project and see how it goes.
Oops I guess my reply never went through yesterday. I’m a solo monkey coder at my job and we don’t have a lot of automatic tooling in places where we can, so I had the freedom to use whatever language I want. I picked Racket because I wanted something that works well out of the box, wide standard library, easy to write functional code, and to even create miniature DSLs where it makes sense.
I deal a lot with spreadsheet/CSV processing, so I use some custom Racket code to be able to define and read sheets of different dimensions and able to generate HTML printable reports out for the upper management folk.
I’ve quickly played with it, and from what I’ve seen it’s almost perfect for scripting, at least due to the following reasons:
it can be linked statically, thus it should run on any Linux with a simple copy; (not by default, use LDFLAGS=-static;)
it can embed in the binary the core library (and other libraries of choice), thus there is no need for other files to be installed; (this is not by default, but by using the image.zuo directly one can get this;)
it has minimal startup latency, almost 2x lower than Python2.7, and many times less than Python3.10; (this is without the extra libraries embedded, with the extra libraries embedded it’s still faster than Python2.7, but not by that a large of a margin;)
I must say, this is the first Scheme interpreter I’ve seen that can be “convinced” not to require extra files at startup, or whose binary can easily be relocated without breaking the library lookup. Also it is the only Scheme interpreter with a startup latency closer to bash, thus suitable for small short-lived scripts. :)
I haven’t yet checked the available API, but it does seem to be quite enough for simple system related scripting.
Thus, at least from an operational (i.e. how to deploy) and startup latency, I think it’s on par even with bash, thus more than a scripting language for build systems; it remains to see if the offered API is enough.
It’s too bad this didn’t exist a few years ago, because at that time I’ve started writing my own Scheme interpreter specifically for scripting, https://github.com/volution/vonuvoli-scheme.
I see where you’re coming from, but I’m not sure that would work given the (at least implicit) contstraints. One of the goals mentioned in the original pull request (discussion) was for it to be small and self contained, thus minimising the overhead (both in terms of machine resources and brainspace) of working on the build itself.
Both Nix and Guix depend on an underlying runtime system (nix language and guile scheme respectively). Not only is it yet another dependency to manage, but it also means there’s more context switching overhead when moving between hacking on the build vs. hacking on the source code. Wheras Zuo is designed to be very similar to racket, and should make it easier to switch tracks.
Nice to see another contender in the build-script arena, and very happy it’s part of Racket. I use Racket every day for work and love seeing what new developments there are.
I don’t have enough experience in building Racket from scratch or cross-platform compiling, but it seems like a lot of work went into making Zuo very minimal and easy to embed anywhere. Even toying around with it a bit, it doesn’t come with an interpreter, and it seems to have the basic primitives needed to build out some applications (and it seems like the only numbers it supports is 64-bit signed integers).
I think it’s interesting enough to build some very tiny scripts with and explore, but curious to see if it simplifies the build process for projects. I might try incorporating a Zuo file into a project and see how it goes.
Would love to know what you use Racket at work for. I knock off small utility scripts for my own use at $DAYJOB but nothing beyond that.
Oops I guess my reply never went through yesterday. I’m a solo monkey coder at my job and we don’t have a lot of automatic tooling in places where we can, so I had the freedom to use whatever language I want. I picked Racket because I wanted something that works well out of the box, wide standard library, easy to write functional code, and to even create miniature DSLs where it makes sense.
I deal a lot with spreadsheet/CSV processing, so I use some custom Racket code to be able to define and read sheets of different dimensions and able to generate HTML printable reports out for the upper management folk.
I’ve quickly played with it, and from what I’ve seen it’s almost perfect for scripting, at least due to the following reasons:
it can be linked statically, thus it should run on any Linux with a simple copy; (not by default, use
LDFLAGS=-static;)it can embed in the binary the core library (and other libraries of choice), thus there is no need for other files to be installed; (this is not by default, but by using the
image.zuodirectly one can get this;)it has minimal startup latency, almost 2x lower than Python2.7, and many times less than Python3.10; (this is without the extra libraries embedded, with the extra libraries embedded it’s still faster than Python2.7, but not by that a large of a margin;)
I must say, this is the first Scheme interpreter I’ve seen that can be “convinced” not to require extra files at startup, or whose binary can easily be relocated without breaking the library lookup. Also it is the only Scheme interpreter with a startup latency closer to
bash, thus suitable for small short-lived scripts. :)I haven’t yet checked the available API, but it does seem to be quite enough for simple system related scripting.
Thus, at least from an operational (i.e. how to deploy) and startup latency, I think it’s on par even with
bash, thus more than a scripting language for build systems; it remains to see if the offered API is enough.It’s too bad this didn’t exist a few years ago, because at that time I’ve started writing my own Scheme interpreter specifically for scripting, https://github.com/volution/vonuvoli-scheme.
As someone who is working on a hobby Scheme, I will definitely be looking at the source for some features mine doesn’t have yet.
The steps taken in https://github.com/mflatt/zuo/commits/master are very educational.
I wonder how you say this, because it looks like the word 坐 or “sit” in Chinese.
I’m guessing from google translate, that it is 作. You can listen to google say it there:
https://translate.google.com/?sl=zh-CN&tl=en&text=%E4%BD%9C&op=translate
I think it is this character 做 that means “do, make, produce” where 作 is more on “rise, grow”. Both characters are pronounced the same (same tone).
Annoyingly the recent post merge loses the actually announcement by M Flatt at https://racket.discourse.group/t/new-build-system-pushed-to-git-repo/873?u=spdegabrielle
FWIW the Zuo repo describes Zuo as ‘Zuo: A Tiny Racket for Scripting’.
Racket is a descendant of Scheme. The Racket platform still supports R5RS and R6RS, but I don’t believe Zuo supports either.
I don’t think it is good to keep inventing new languages. Wouldn’t guix or nix have worked better here?
I see where you’re coming from, but I’m not sure that would work given the (at least implicit) contstraints. One of the goals mentioned in the original pull request (discussion) was for it to be small and self contained, thus minimising the overhead (both in terms of machine resources and brainspace) of working on the build itself.
Both Nix and Guix depend on an underlying runtime system (nix language and guile scheme respectively). Not only is it yet another dependency to manage, but it also means there’s more context switching overhead when moving between hacking on the build vs. hacking on the source code. Wheras Zuo is designed to be very similar to racket, and should make it easier to switch tracks.
Besides, build systems are fun!
To add to crstry’s post, Nix and Guix wouldn’t work for building Racket on Windows, anyway.
It is allways good to keep inventing new languages.