Janet – A dynamic language and bytecode VM | Hacker News Reader

Janet – A dynamic language and bytecode VM

github.com

152 pointstraderjane50 comments

I like it, because I like Lisps, and it seems portable enough. I was looking into Fennel, Urn, and Lumen, which are Lua-related Lisps, but given the small size of Lua, put them in the same size bracket or lower as Janet.

On another note, I was excited to see 42 comments on this, but then realized over half of them were on a thread of gender and PL names. Fair discussion I guess, but I was hoping to geek out on the Lisp of it all!

"The entire language (core library, interpreter, compiler, assembler) is about 200-300 kB"

That's impressive. [Edit: It's not 200-300kB, closer to twice that in total. I pulled it down and neither source nor build is that small]

Also, minor typo on the page: "The language also bridging bridging"

I like what I see in Janet, but FWIW /usr/bin/lua5.2 on my Ubuntu machine is 199,576 bytes.

If you write in C without any dependencies, it will take tens of thousands of lines of code before you hit 200 KB :) And that's enough to implement many interpreted languages.

Although I will say that Micro Python is super impressive, because it's small and Python is a deceptively large language -- much bigger than Lua or Clojure.

The Unix port of Micro Python is 412,984 bytes on my machine, and I was only able to get CPython down to ~900 KB after removing many major pieces of functionality (unicode, complex numbers, almost all modules, etc.).

For comparison, /usr/bin/python2.7 on my machine is 3.5 MB, and /usr/bin/python3.5 is 4.4 MB. That's not a knock -- I've really used all that stuff at some point!

Hollowing Out the Python Interpreter http://www.oilshell.org/blog/2018/11/15.html

Actually, I pulled down the repo and did a build. Janet is significantly larger than "200-300 kB" whether I'm counting just source, or built binaries+libs. So perhaps it's an old claim that needs to be updated.

Thanks for sharing re: MicroPython. Had a lot of fun with that over Christmas on a little ESP8266. It's a neat trick that it fits on such a tiny board.

What OS are you on? I downloaded the latest release for Mac OS and the binary is 299KB and the library is 289KB.

Linux x64, and my sizes are larger, but similar. Still small, but ~600k is probably closer to where it's at now in total.

Author here

Yes, on most linux systems its closer to about 375 kB right now with the default build. For some reason it is much smaller on macOS, and can be smaller when built with -Os, and even smaller when built without the assembler, peg, or in-binary documentation. You are right, it used to smaller but grew as I added more features.

Thanks. Not knocking it, was just curious. It's certainly still small for what's delivered.

Probably smaller than the typical blog post on medium.

Obligatory link to Maciej Cegłowski's The Website Obesity Crisis[0]

> These Apple sites exemplify what I call Chickenshit Minimalism. It's the prevailing design aesthetic of today's web. I wrote an essay about this on Medium[1]. Since this is a fifty minute talk, please indulge me while I read it to you in its entirety:

> "Chickenshit Minimalism: the illusion of simplicity backed by megabytes of cruft."

I just opened up that one-sentence, image-free blog-post, with uBlock, uMatrix disabled. Without cache it pulled in 790 KiB - with cache it's still 108 KiB.

And it used to be worse:

> I already talked about how bloated Medium articles are. That one-sentence essay is easily over a megabyte. It's not just because of (pointless) javascript. There's also this big image in the page footer[2]. Because my article is so short, it's literally impossible to scroll down to see it, but with developer tools I can kind of make out what it is: some sort of spacesuit people with tablets and mobile phones.

> It's 900 kilobytes in size.

I hate Medium and their ilk with a passion.

[0] https://idlewords.com/talks/website_obesity.htm

[1] https://medium.com/@mceglowski/chickenshit-minimalism-846fc1...

[2] https://static.pinboard.in/ob/ob.082.jpg (Cegłowski's archived copy of that once-mandatory 900 KiB footer)

> on most linux systems its closer to about 375 kB right now with the default build. For some reason it is much smaller on macOS, and can be smaller when built with -Os

clang vs gcc? elf vs mach-o? hmm. would be interesting to know.

Seems to be elf vs mach-o - clang on linux is more or less the same size, actually larger than gcc. Probably also some linking stuff on macosx vs. linux.

Link to the actual site:

https://janet-lang.org/

Looks like a neat project for sure.

So, in short, it's a Lisp, apparently CL-leaning. On top of expected features, it has fibers (aka coroutines, generators), parser generators that supersede regular expressions, and destructuring on access.

It looks like it uses setjmp/longjmp for error handling. Is there a way to ensure Janet never calls setjmp/longjmp? If not, it won't be embeddable in Rust (and maybe C++?) due to RAII.

I ran into this earlier with Lua for different reason, and recently discovered PHP does this too. Maybe we just need to find a way around it? I was thinking of trying to bridge jumps with the Rust panic mechanism. (Basically try-catch at each boundary.)

I’m on my phone so I can’t get into it, but there were bugs around this with lua and rust that got resolved, so there is some way of dealing with this.

Janet uses setjmp/longjmp for error handling because most alternatives in C don't compose well or are incredibly verbose/inefficient. The C API is not documented yet, but in general one could use setjmp at C++/Rust <-> C boundary points to prevent panics from jumping over C++/Rust stack frames. However, many functions in the C API will not panic (longjmp to the last save point). The overhead could be minimized by only calling setjmp for API calls that can panic.

Just spitballing here.

Handling exceptions might be different in Janet compared to perl, but it is possible to handle them while being embedded. You could essentially try/catch around every ffi boundary, which is the point brought up in this talk at 14.45

https://youtu.be/gwmtFzggE18

Fascinating project. Not many remember this, but one of the most successful embedded commercial Lisps was AutoLisp [1], which was the "scripting language" for AutoCAD.

My uncles who were engineers/draftsmen used to boast about the stuff they could accomplish with AutoLisp. I didn't understand the power of Lisp until I came across another embedded Lisp -- Emacs Lisp.

[1] https://en.wikipedia.org/wiki/AutoLISP

I believe AutoLISP was derived from XLISP, a publicly available LISP written by David Betz. I had a lot of fun with XLISP, and respected the quality of the work done by Mr. Betz.

A struct based lisp is something I’ve been wanting for a long time. This I am extremely interested in this project

This mildly reminds me of Pico [1], which is essentially Scheme semantics with tables instead of lists, plus infix operators, and a few other bits of syntactic sugar.

[1] http://pico.vub.ac.be/

I really like it, waiting for the C API documentation. Congrats to the author, Calvin Rose. [1]

[1] https://bakpakin.com

Dammit, Janet!

Not a single example program on the GitHub page or in the documentation.

I found several. See https://github.com/janet-lang/janet/tree/master/examples for some.

Why Janet?

Why not Karen?

https://knowyourmeme.com/memes/karen

Reply on news.ycombinator.com