I followed some instructions to build the Chez Scheme underneath Racket to get a Chez Scheme that runs natively on M1 processors and OSX. That worked and completed quickly, but it created a very non-standard build which much be run as make run-->the binary executable is hidden somewhere deep in the file system with no clue as to its location. Thus, there is no way to create a standard setup of Chez Scheme.
I am trying to install srfi packages/libraries for Chez using akku: this is another mess because akku can only be installed using Guile and there appears to be no binary distributable of Guile.
Ah, well thanks to homebrew I can rapidly install akku. Problem is that akku won't work on M1 because it tries to use the wrong libcurl. Maintainer doesn't have an M1 so no expectation of when that will be fixed.
I have spent/wasted 2.5 hours on this. I really like the simplicity and performance of Scheme, but it is r6rs and missing a lot. akku can't be made to work to access srfi-43 to support fl64 vectors. Instead I can grep/Google around to find libraries that are compatible with Chez. But, the recommendation I found was use akku (which seems nice). But, now we are in recursion without a base case.
Moral of the story:
Just use Racket. Best tooling of any Scheme and already very complete. Its own library manager.
Don't expect the raco compiler to do very well compared to gambit; so just don't create stand-alone executables from Racket.
Use Gambit to create small executables after messing around to find the right commands with incomplete documentation. Similar library problem but Gambit is r7rs and has distributes with many rfris.
Now, I can cleanup and uninstall Guile and akku.
I'll keep Scheme for ARM64OSX for a while if I can solve the library problem. Or maybe someone can put the Racket compiler on a diet. If not, that's ok, too.
Meta-moral:
Scheme is a great language to learn but not to use. It certainly can be used, but with many limitations compared to other languages.
Since you seem to be preoccupied with the size of Racket executables, I'll add my own thoughts on application size.
My own experience with Racket comes from writing a medium sized application, ActivityLog2, and there's a similar application, written in C++, called GoldenCheetah. GC has more features, but I think the there is sufficient overlap in features between the two applications for a meaningful comparison in application size.
The GC executable, written in C++, is about 17MB in size, while AL2 executable, written in Racket, is 81MB in size. Of course, the executable alone will not run either for GC or AL2, since both applications use additional DLLs and other files. When you look at the total application size, the result is different: GC's total installation size is about 765MB, while AL2's total installation size is 218MB.
Even performance-wise, AL2, written in Racket, is about the same speed as GC, which is written in C++.
So, Racket is a fine language to use in your applications.
I wasn't previously aware of akku; it seems interesting. Nix packages chez-srfi, which includes SRFI 43. In Guix, we use Racket's Chez Scheme on architectures like Aarch64 that aren't supported by upstream Chez (but Guix only supports the Linux and Hurd kernels). I know Nix has also packaged Racket's Chez for the sake of Idris 2: I'm not 100% sure if they use it on Aarch64 more generally as we do, but it would basically be a one-line change if they don't already. It looks like Nix also packages Akku.
Ooh, I left out make install. I'll try again. Do you think I can run it in the wrong order, after I've done everything else? (that would be easy!)
I can't use GUIX as I am on MacOSX so homebrew or the one whose name I am forgetting. Likewise for nix.
You'll see from a micro-benchmark (salted to taste...) I am about to post that Racket does quite well and it's not clear that Chez would do better, though there may be easier ways to control the resulting size of the executable.
I will grant that on today's machines executable size is not a big deal, especially given the humongousness of commercial software. There is a somewhat distasteful lack of economy when the linked code that is not ever executed (not called at all...) is much larger than the code that is executed. This is where modern optimizing compilers are so amazing, without even doing any work or using confusing compiler options.
I have used GC. I am not that OCD about training any more, but it did the job. Your finished app shows that while the minimal compiled Racket app is huge, if you create a more robust app much of what you'll call is there and the incremental size for additional libraries or allocated storage is not that much. Still 17mb vs 81mb is telling. But, if you got a nice app written in a fraction of the time, no user will ever begrudge that 64mb...
I get it; it's just a software craftsmanship thing I have.
I expect re-running ./configure with only --prefix= changed would work. I'd probably err on the side of cleaning first to be safe, but this sort of thing has gotten much more robust since the introduction of Zuo.
Just to be clear, Nix does run on Mac, which is why I mentioned it. On the other hand, it also has a rather steep learning curve and takes some non-trivial initial setup: I'm not trying to persuade you to use it.