They have better than usual performance on function calls, so feed it a poorly optimized Lisp and you'll probably get a large relative performance advantage. B

They have better than usual performance on function calls, so feed it a poorly optimized Lisp and you'll probably get a large relative performance advantage. But I don't think that's what you're looking for. Going through the most striking parts of the architecture: - They can pipeline outer loops, even with function calls in them. I expect that will perform well on event loop patterns like you find in non-blocking IO server frameworks. - They have cheap pipelining, vector operations, and (in the high-end models) lots of functional units. All the statistical languages like R and Julia should be able to get something out of that. - If you have a lot of repeated pure loops (ie: map() calls), your compiler could optimize two loops into one to try to saturate the mill's functional units. Using their pick and smear operations, I think you can even get this to work on different-size loops (with less benefit the more their sizes differ, of course). - They have novel memory protection stuff, but that's more OS than programming language. I'm clearly not part of the Mill team though, so I could be wrong about any or all of those.