Gerbil http://cons.io based on Gambit, caught my attention. It has a really interesting and rich API and includes what looks like fairly advanced meta-programming facilities. I haven't use it yet, but I found it
It's funny how diverse Scheme implementations are, and how they each have different strength and weaknesses. Even Lisps seem more consistent in comparison!
Thanks for the benchmarks. Daaaamn, Chez is dominating them! That's gotta be some great engineering behind that compiler. Ok, nevermind, and will just look into Chez, Stalin, and Gerbil. Thanks for the paper: I missed it somehow.
"It's funny how diverse Scheme implementations are, and how they each have different strength and weaknesses. "
Such adaptability was a strength of the Schemes and LISP's. Also their weakness. People could arbitrarily change the languages so much that the software was hard to maintain at a team level. It's why I advocate for simpler, consistent forms for the default way to program with the macros and stuff being use really selectively. And with it clear they're macros. I remember reading from a few people that they did something similar in LISP shops. I don't have much data on that, though.
Back in 2005 I went to the Montréal Scheme User Group and met people who were using Lisp professionally for NLP applied to telecom (voice-controlled automata). A few years later I bumped into one of them again and asked what happened: they were hiring Java engineers. The guy told me that the problem with Lisp is that the code was getting more difficult to understand as layers of abstractions were piled onto one other (people were creating new vocabularies to adapt the system to evolving requirements). He said that although the Java version was architecturally less elegant and more verbose, it was also more straightforward and allowed for less qualified developers to maintain and expand the application.
From my personal experience I find that Lisp, and more particularly Scheme is an amazing way to prototype high-level concepts. Instead of starting off coding right away, I now spend time expressing concepts and structures as S-Expr and pseudo-Scheme as part of the documentation, with the intention of creating a simple Scheme runtime to validate them. However, I probably would not create a production system with Scheme -- I use Python for prototyping implementation, and would probably use Rust now for a production version (as opposed to C).
"He said that although the Java version was architecturally less elegant and more verbose, it was also more straightforward and allowed for less qualified developers to maintain and expand the application."
That's why I was saying maybe we should treat commercial Lisp like any other language with the macros just handling weird situations. Maybe giving us new constructs, optimizing something with obvious meaning, handling portability, and so on. You could say kind of like how D, Rust, and Nim use them.
Boring, predictable code is better in long-term in businesses. So, we make Lisp's boring until boring solution is too painful. Then, we get it clever with clear docs about what's going on. Should prevent their problem, yeah?