ferret VS sci

Seems like there has been no development since 2020 - https://github.com/nakkaya/ferret

The whole of ferret's source code is in a single org-mode file, following the literate programming style: https://github.com/nakkaya/ferret/blob/master/ferret.org

fyi there's some middle ground via ferret if you want to mix the two in the future. I think janet lang is more full featured, borrowing ideas from clojure while targeting simple embedding alongside c.

Another commenter already mentioned Gambit Scheme. That provides for inline C and therefore very easy interop with external libraries. It still has a runtime and GC though - those might pose a problem depending on your platform and task.

Ferret (https://github.com/nakkaya/ferret) and Carp (https://github.com/carp-lang/Carp) are both Lisp-like low level languages. Both seem to be fairly experimental in nature though.

> anything but C

Taking you literally, Rust and D can both compile for bare metal. D in particular has a "Better C" subset. (https://dlang.org/spec/betterc.html)

In the same vein, Terra is a C like language (manual memory management) that you metaprogram with Lua. (https://github.com/terralang/terra)

Taking you very literally, Forth is also an option.

Impressive. Wonder how the performance in Emacs will be with a file this big... org source file

I've tried researching this myself and can't find too much. There's this project metaes which is an mci for JS, and there's the SCI module of the Clojure babashka project, but that's about it. I also saw Triska's video on mci but it was pretty theoretical.

https://github.com/babashka/SCI if it's a requirement for proper sandboxing

Since cherry is a compiler, the code generally runs faster than with SCI which is an interpreter. For many cases SCI is fast enough, but numerical computations in a hot loop isn't one of its strenghts:

Startup and sustained performance are absolutely implementation issues. For example, SBCL will take its sweet time to make machine code out of Common Lisp, but CLISP will interpret and generate bytecode. Both are useful, and both implement the same language. Clojure on the JVM takes also takes plenty of time to start up, so some use an interpreter instead. Furthermore neither of these languages has a cost model, so the cost of anything is an implementation issue.

So far we have relied on an increasing number of home-grown integration points to our platform, where relevant combined with the excellent SCI (so we can write some Clojure-code when adhoc data conversions / calculations / tweaking is required).

Also take a look at SCI, https://github.com/babashka/sci/blob/master/doc/libsci.md

You probably want to take a look at sci if you are creating a DSL or want to use Clojure itself as your DSL.

Built with the lovely SCI library (https://github.com/babashka/sci) + GraalVM, probably the most useful GraalVM project I've seen in the wild so far.

Also, Babashka will probably always support more features than ClojureRS could ever, particularly the interop with the various Java classes/functions, as that'd be very hard to achieve in ClojureRS.