Why Janet? (2023)

> I never thought it could happen to me.

But I am truly biased. I have basically forgotten how to code everything else (besides APL family languages) in the past _checks notes_ 10 months since I started Janet. I even run a community [docs site](https://janetdocs.org/) and am writing [my own tutorial](https://janetdocs.org/tutorials/learn-to-program) (albeit slowly). I even use it in production for all new software (within 3 weeks of starting, I had rewritten all personal scripts etc.)

> Janet is simple

You can do literally everything with just hashmaps. The whole language is basically a hashmap, implementation wise. `(keys (curenv))` prints out all locally defined symbols. `(keys (getproto (curenv)))` prints the parent hashmap of the current environment i.e. all the core symbols. I don't, but you can basically do CLOS via hashmaps (and there is a [fuller implementation](https://git.sr.ht/~subsetpark/fugue) too.)

> Janet is distributable

I have like 20 websites and another dozen or so services running on Janet (with the [Joy webframework](https://github.com/joy-framework/joy) which I wrote a [tutorial](https://janetdocs.org/tutorials/Joy-Web-Framework) for), on a single free-tier VPS with 512mb of RAM.

> Janet has ... immutable collections

...not really. In reality, the whole standard library constantly returns mutable versions from everything. There's no reason to really try to be immutable at this point. Although there are cool [combinator libraries](https://git.sr.ht/~subsetpark/apcl-janet) and I've even made combinatorish versions of basic functions:

    (defn better-cond
      [& pairs]
      (fn :bc [& arg] # names for stack traces
        (label result
               (defn argy [f] (if (> (length arg) 0) (apply f arg) (f arg))) # naming is hard
               (each [pred body] (partition 2 pairs)
                 (when (argy pred)
                   (return result (if (function? body)
                                    (argy body) # calls body on args
                                    body)))))))

Combinatory inspired cond, which allows for pairs. The test does not need an argument and the body may be a simple value or a function:

    (map (better-cond
             string? "not a number"
             odd? "odd"
             even? "even") 
      [1 2 3 "cat"]) # the args!
    (map
        (better-cond
         1 (fn [arr] (array (min ;arr) (max ;arr)))) # (recombine array (unapply min) (unapply max)))
        (partition 2 (range 10))) # these are the args!
    ((better-cond
           "second is smaller")
         5 3) # these are the args passed into the func! I am excited!

> Janet lets you pass values from compile-time to run-time

That's what got me hooked, in a few ways. In Racket or Go, I had to do a lot of work to process data at compile time so the runtime could literally just be a lookup table. In Janet? That's the default behavior of any `def` outside of main. The following turns a .tsv of the bible into a hashmap in the binary, when compiling:

    (def verses  (reduce (fn [acc line]
                           (let [parts (string/split "\t" line)]
                             (if (= (length parts) 5)
                               (let [[_ abbrev ch vs text] parts]
                                 (put-in acc [abbrev ch vs] text))
                               acc)))
                         @{}
                         (string/split "\n" (slurp "kjv.tsv"))))
    
    (def abbrev-array (keys verses)) # also makes an array of the abbreviation column

So the rest of the program is literally just accessing the hashmap ([twice as fast](https://codeberg.org/veqq/verse-reader#performance) as the Golang version using `embed`):

    (defn main [_ & args]
      (if (or (empty? args) (= "-h" ;args) (= "help" ;args))
        (do (print "Usage: kjv  [chapter:verse]") (os/exit 1))) # show help
      (let
       [Capitalized (string (string/ascii-upper (string/slice (first args) 0 1)) (string/slice (first args) 1))
        book        (find |(string/has-prefix? $ Capitalized) abbrev-array)]
    
        (pp (match args
              [_ chap verse] (get-in verses [book chap verse])
              [_ unsure]     (match (string/split ":" unsure)
                               [chap verse] (get-in verses [book chap verse])
                               [chap]       (get-in verses [book chap]))
              [_]            (verses book)))))

The equivalent go program was 5x longer and required an extra program to convert data into a 40k line .go file with a giant literal hashmap, to be faster than the naive Janet.

...but actually Ian Henry means Janet e.g. keeps closures synced across images/sessions:

    (defn timer [t] 
      (var t t) # this is slightly annoying, must shadow as params are immutable
       [(fn [] (set t (+ t 1)))
       (fn [] (set t (+ t 2)))])
    
    (def tx (timer 0))
    # call like this:
    ((tx 0))
    ((tx 1))
    
    # make an image and save it to file
    (def my-module @{:public true})
    (spit "test.jimage" (make-image (curenv)))

Exit and start a new REPL session:

    (defn restore-image [image]
      (loop [[k v] :pairs image]
        (put (curenv) k v)))
    
    (restore-image (load-image (slurp "test.jimage")))

    ((tx 0))

It saved the closure and all relevant image in the `(curenv)` hashmap.

Condensed from my longer response: https://lobste.rs/s/y0euno/why_janet_2023#c_lspe6n

What I mean by that is that it's in the same weightclass of speed, depending on the problem being tackled. In the case where data's shape is mutable, SBCL will scream ahead thanks to CLOS. You can cheat LuaJIT with dynamically-defined C-structures via abuse of the FFI lib instead of native tables, but it's not as nice as CLOS nor is it very safe. In the case that the shape of data is changed extremely frequently? CLOS might actually end up falling behind here. Another area where SBCL will likely win out is when the hotpath is bottlenecked on string operations.

Where I'd say it advances into breaking SBCL's jaw is that the runtime, interpreter, jitter, etc. are all much smaller than SBCL's runtime and compiler. If you're looking for a complete system, I'd say SBCL wins out obviously. You're talking a world-class REPL, debugger, a high quality stdlib, etc. All it's missing is a text editor like LispWorks (emacs and pretty much every other FOSS Lisp editor I've seen is a massive downgrade.) With that in mind, SBCL is not something you embed in an application written in another language. The holy grail is getting something as fast as SBCL, as flexible as SBCL, but as a 50k loc self-contained runtime. LuaJIT is the reigning heavyweight champ there, so having a Lisp-adjacent language like Fennel running atop it is a pretty damn compelling idea.

Interestingly with regards to text editors, Lua doesn't have that problem technically. Lite-XL is dangerously close to being zmacs/LispWorks for Lua. Poetically, just like Lua it's fairly bare bones and requires extension to be a decent IDE. But the underlying structure is absolutely fantastic, being based around a fairly cohesive object model rather than coats of paint over text buffers.