(Yet Another) Lisp in Go (johnj.com)

startup time is key to being able to write one-off programs/tasks and use them in workflows. It doesn’t matter as much for long lived programs, but I don’t think it’s fair to frame this as “bias the results”

Yup, once hotspot kicks in on the JVM, a toy language is going to have a hard time competing with that performance. It’s definitely disingenuous to include JVM start up time in any benchmark. I used to run clojure benchmarks in a REPL and I would watch as the functions I was testing dramatically increased in performance over a few invocations. JIT compilation is pretty incredible.

I can just as well claim that ignoring startup with a small hot loop would unfairly favor a JIT compiler, since it ignores problems that would crop up in real world scenarios such as poor code locality.

Basically what you're suggesting would be the absolute best-case for JIT.

He does mention that he is looking for language to use for cli with fast startup. For cli and serverless cold start times become important so much so that clojure (non Graal complied) isn't usable for those scenarios.

We all know that Java is slow to start up, because many don't learn how to use JIT caches or AOT solutions that exist for ages.

Eh, the JVM startup time is much less these days (read: these last several years), however loading Clojure is quite slow comparatively and that's what ends up dominating. On my machine, here's a hastily written Fact.java:

    import java.math.BigInteger;
    public class Fact {
      public static BigInteger fact(BigInteger n) {
        if (n.equals(BigInteger.valueOf(1))) {
          return BigInteger.valueOf(1);
        } else {
          return n.multiply(fact(n.subtract(BigInteger.valueOf(1))));
        }
      }
      public static void main(String args[]) {
        System.out.println(fact(BigInteger.valueOf(100)));
      }
    }

With OpenJDK 11.0.14, `time java Fact.java` gives real/user/sys of 0.267s/0.654s/0.033s. But that's not compiling the file first which some programmers aren't even aware is a thing Java can do now, if I do the usual thing of compiling with javac then on the class file `time java Fact` I instead get 0.050s/0.043s/0.010s. For Clojure, `time java -jar /usr/share/clojure-1.10/lib/clojure.jar fact.clj` gives 0.468s/1.069s/0.056s.

Edit: for fun since the author mentioned Common Lisp, `time sbcl --no-sysinit --no-userinit --script fact.lisp` gives 0.005s/0.003s/0.002s. If I make a binary out of this instead, `time ./fact` gives 0.003s/0.002s/0.001s`. Since even a time of an empty C program's a.out can sometimes give numbers like 0.001s/0.000s/0.001s I'm clearly running into precision limits of the time command. (CL itself has a time macro that will helpfully give you a processor cycles count, about 290,000 on my machine for this.) I think the author is overestimating the difficulty of adding features to Common Lisp relative to what they plan to do with this toy; CL for scripting works great too.

> We all know Java is slow to start up…

More specifically, Clojure —

https://stuartsierra.com/2019/12/21/clojure-start-time-in-20...

They’re referring to using symbols instead of strings

PicoLisp works like that IIRC

I was thinking about transpilers lately. Can you point me to examples?

Huh? Go has an enormous and high quality std lib and even larger set of community libs. On top of that its popularity is exploading. I’ve never seen a language rise in popularity as much as Go.

Please spell-out whether you are restrained by how-good or how-bad you consider current performance to be.

    $ time ./bin/visual ./image/visualnc64.im -nogui -doit "Stdout nextPutAll: 100 factorial printString; cr. ObjectMemory quit"
    93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000

    real 0m0.616s
    user 0m0.452s
    sys  0m0.161s

    $ cat fact.st
    Stdio stdout 
        nextPutAll: 100 factorial printString; 
        nextPut: Character lf.!
    SmalltalkImage current snapshot: false andQuit: true!

    $ time bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image fact.st
    93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000

    real 0m0.350s
    user 0m0.303s
    sys 0m0.049s

I thought so too, and worked on this for a while, but Clojure compiles at runtime, while Go does source generation then compiles at build time. I found what was essentially a Clojure-to-Go source transpiler to be surprisingly limited.

Go doesn't have a VM, it is always pre-compiled to native binaries specific to the target architecture/platform you want to run it on.

It also generally speaking doesn't have an intermediate representation that you could target directly, because it does a lot of optimization directly on the GO AST. Though you might be able to have a different language compile to its SSA directly, but it would not be easy at all.

The GO runtime also doesn't allow for any dynamic code loading, so you wouldn't be able to have a REPL.