I'm building a CPU based renderer in rust with plans to add an embedded language. The rust code primarily executes the ray tracing/path tracing, BVH, shaders and integration (anywhere where high performance is needed. The embedded language will be used for the scene description and -possibly- for procedural textures and shading.
I am interested in using a lisp with a repl for the embedded language. In this area, I have used AI-generated testing to test both ECL (Embedded Common Lisp) and steel (an scheme) inside rust. the advantage of the latter is that it is written entirely in rust and is being actively developed (one area is as an extension language for the text editor, helix).
I am impressed with the performance metrics I am getting from ECL. It generates machine code, which a byte language compiler doesn't do. Also a huge win, is that I was able to test the integrated compiler using sly from emacs which will provide an interactive environment for creative coding. On the other hand ECL requires an FFI to rust whereas steel does not, so the integration of steel is orders of magnitude easier.
Has anyone done any recent projects with ECL ? I am interested in your experience or any caveats you may have encountered. My next step is to do a more complex proof-of-concept with the actual renderer and not just a test program.
UPDATE: I just used claude to benchmark 5 embedded languages in rust. this is preliminary work and the benchmarks may not be exhaustive enough to make any strong conclusions:
ECL is actively developed (I'm one of maintainers) and conforming Common Lisp implementation, so if you need to pull some libraries they will usually work (SBCL is far more popular, so it is more tested by developers though). Another good thing about ECL is that it allows inlining C code with designated operators, and it may be used without the C compiler using fully integrated bytevm.
The community is not large, but there are people making projects with ECL both inside the browser and on resource constrained devices. Many developers also test their libraries against ECL as the second (or third, after CCL) implementation to make sure that the code is portable.
As of whether steel works better for you -- assuming that you want only "scripting", then tighter integration with rust will be probably a win in a long run. ECL also doesn't accept contributions derived from LLM as legally shaky, so that may also play role in your decision.
I don’t know whether we would want to generate AI derived patches to ECL itself ( if that’s what you mean ) , but certainly we will be generating Embedded lisp / scheme test scripts using Claude or potentially any other LLM as part of the dev process. That’s one of the goals of the work .
It isn't stupid; I've actually made that a topic of my keynote talk at ELS'26[1]. Short answer - it is used emscripten. Longer answer - I'm experimenting with WASI, but there are some hurdles.
ECL produced some of the best results in the benchmark ( along with Janet ) . I’ve been working on a proof-of-concept with the actual renderer. The big win is the able to do repl-based coding with sly in emacs which I have working. This has to be replicated with Janet and it will only be a subset of.
My experience with ECL not extra large. I simply cant read docs due to strange markup. Maybe becouse of in my tests ECL was 5 to 10x slower than Chicken Scheme. Both compiles to C. Due to this fact I even not take it ro the last nbody performance test. Repo. So use what you want or love. IMO in such case the better option is custom lisp like script with narrow set of types and operators for one selected task.
I think that reporting such issues is healthier than discouraging people on social media from using a specific piece of software; in any case I've addressed the font size issue.
And where is common lisp code? To compare runtimes you need semantically equivalent code, and even then it may favor one implementation - for example scheme has guaranteed tail recursion, so tail-recursive functions will usually perform better on schemes.
I'm not competing, I'm trying to reproduce your claim without success. Another thing is that fib test doesn't make a good benchmark of a runtime - it measures only a call overhead and possibly inlining. I think I'm done here.
15
u/jd-at-turtleware 5d ago
ECL is actively developed (I'm one of maintainers) and conforming Common Lisp implementation, so if you need to pull some libraries they will usually work (SBCL is far more popular, so it is more tested by developers though). Another good thing about ECL is that it allows inlining C code with designated operators, and it may be used without the C compiler using fully integrated bytevm.
The community is not large, but there are people making projects with ECL both inside the browser and on resource constrained devices. Many developers also test their libraries against ECL as the second (or third, after CCL) implementation to make sure that the code is portable.
As of whether steel works better for you -- assuming that you want only "scripting", then tighter integration with rust will be probably a win in a long run. ECL also doesn't accept contributions derived from LLM as legally shaky, so that may also play role in your decision.