Since three people took the time to write something about Bigloo, I will try to give honest feedback
I investigated Bigloo for my project, I did not choose Bigloo because: - At the time, I did not figure the Foreign Function Interface with C: How to call a C function from Scheme? How to call a Scheme function from C? How to dynamic link a shared library? How to access C structures from Scheme? Looking at the internet at this time yields the following URL: https://www-sop.inria.fr/mimosa/fp/Bigloo/doc/bigloo-28.html which looks great. Another possible question: How to create a shared library from a Bigloo library. - The fact that it targets C, JVM, .NET and JavaScript was misleading me into thinking that Bigloo is a compiler research project (there is another Scheme implementation that has even more targets), it sounds scary and sublime at the same time. - Unlike hop.js, Bigloo website is not Silicon-Valley compatible when it comes to the visual aspect. That's a weak argument, and in fact, maybe I could have helped with that (see for instance https://github.com/segmentio/evergreen#readme) - I have not strong opinions, so far, about R5RS / R6RS / R7RS because I am not confident about my knowledge of differences between the standards. It seems to me there is some use for a Scheme without module machinery. That is, I think a module system is useful but not necessary all the time. - Being able to use SRFI libraries is a good thing: I rely on (scheme hash-table), (scheme mapping), (scheme mapping hash) and (scheme generator). Taken separately they might be an easy grab, but my goal is not improving the performance of hash-tables. It seems to me now, that those can work without modules, because most of them rely on xyz.body.scm which is included in a xyz.sld which binds the procedures inside a library. Regarding call/cc, again I do not know the nitty-gritty details, sure thing is I use call/cc both in the backend and in the frontend to be able to give sequential look to asynchronous code. Performance is good enough [0], but I think in that case maintainability of the code [1] wins over performance. For the time being, I am not interested in compiler optimizations, or Programming Language Theory (PLT) or Domain-Specific Languages (DSL), or even portability over different kernels (BSD and Linux are enough for my needs). I am/was looking for an existing programming language that is dynamically typed, easy to learn, open-source, that supports POSIX threads and possibly green threads without global interpreter lock (GIL) and that has a good C function interface. Simply said, I am looking for a good alternative to Python / JavaScript / Ruby on one side of the performance spectrum and Go / Rust / C / C++ / Java on the other side [2]. There is an incroyable amount of work that was invested in Bigloo and Hop that is an achievement on its own. And I find it admirable. If I could sustain that much work for so many years it would be neat. The benchmarks alone shows how advanced Bigloo is. Now, that I wrote down all of this I am even more motivated to benchmark Bigloo using my code (at some point in the future). Thanks! [0] More 10K RPS for HTTP GET /hello-world tested with wrk on a single core. [1] if / when all error cases are handled [2] For what it is worth on some homegrown benchmark, the Scheme code (not bigloo) is three times faster than equivalent Java code over a few seconds (maybe I should benchmark it over a longer period because of JVM's JIT), and 10% faster than equivalent C code over several minutes. C FFI is used a lot. So, it seems to me Scheme can compete with the statically typed languages, at least, as a _fast_ glue language. And other people reported here and elsewhere that it can compete even on computation heavy algorithms.
