Switched to Janet from Scheme or Common Lisp? Why?

[jaredkrinke]

I like the idea of a Lua-sized Lisp, but as someone who has only briefly used Scheme in the past, I'm not qualified to contrast Janet with more traditional Lisps like Scheme and Common Lisp. Regardless, I still want to know why someone might prefer a younger and less common language like Janet.

Has anyone switched to Janet from another Lisp? If so, what features of Janet made you want to switch? Were you happy with the change?

I assume people might switch from Clojure to Janet to avoid JVM-related annoyances. But what about from Scheme or Common Lisp (where both interpreted and compile-to-native implementations are readily available)?

Fennel had a clear "rationale" page that makes Fennel's advantages (and disadvantages) relative to Lua clear, but I haven't found anything similar for Janet (with respect to other Lisps). Let me know if I missed it!

Thanks!

[strika]

I'm not a regular Lisp user and my story is very specific, so I don't know how helpful this is...

I had a plan to develop a CLI application. I started with Janet, then switched to Rust, then to Racket, then to Janet. At first, I dropped Janet because I felt that libraries are not mature and that I might have some issues. Rust was just not my thing. Racket was fine, but the CLI application is small and simple, yet the compiled binary was 35-45MB depending on the platform.

So I switched back to Janet. The binary is about 700KB. It turns out that I was wrong about tooling. It is somewhat immature, but I didn't have any issues so far.

So, Janet has become the official hobby language for me, although I used Fennel for some projects, too. (I'm using Ruby professionally.)

[tionis]

I'm also not a traditional lisper, but I too pingponged between several different lisp implementations, especially different Schemes.
On day I found fennel and later janet. The following are my main happy places with janet:

• The fast startup time made it useful as replacement for shell scripts
• The integrated PEGs made it easy to parse many different program outputs in shell pipelines
• The REPL development experience is phenomenal, especially with the doc binding
• The language generally feels very straight forward and interactive to me, I like how it composes quite well in of itself
• It's very easy to compile a binary of my janet applications and also possible to build a static one, which makes distribution simpler (not quite on Go's level, like I used before, but that's a high bar to reach)

[jaredkrinke]

Out of curiosity, which Schemes did you try? Obviously Racket is big, but something like CHICKEN Scheme can create static binaries that are under 3 MB (not sure about startup time, but I'd assume it would be fast since it compiles to native).

I'm seeing a trend in responses that Janet seems more approachable. That's probably partly language/resources, and part community.

Edit: also, what is your REPL-driven workflow like? What tools are you using? I actually was under the impression that Janet's REPL experience was less full featured than, say, Common Lisp with Emacs SLIME (which allows modifying code in response to error conditions--almost making it possible to build completely interactively, in incremental steps). Note: I haven't tried Janet with Conjure yet.

[nstgc]

Conjure is wonderful.

[tionis]

For me janet was simply more fun to work with. The other lisps might have had more powerful features, but janet felt more comfortable and straighforward.
I also looked into Chicken Scheme a bit but the dev and compile process didn't really work for me and seemed way to complicated.
For REPL driven dev I have mostly used conjure and am currently experimenting with vis+tmux+vis-tmux-repl to automatically copy my selections into a running repl.

[pepe]

I switched from Clojure(Script) for the reasons you wrote. But Janet is more path for the Rubyists, Pythonistas, and other dynamic language users, in my opinion. I was Rubyist in my heart before becoming Janet.

[PallHaraldsson]

I'm not really a Lisp guy, though mostly intrigued by Clojure, i.e. because it has persistent data structures, no mutability (good for concurrency but not just, also maintainability). I wasn't aware of Fennel (thanks), but I can't see that it, or Janet has this advantage. The latter has "Mutable and immutable hashtables (table/struct)" though.

I'm mainly a Julia guy (not a traditional Lisp), and FYI you can call from Clojure to Julia with a relatively new package. Since Janet is embeddable, you should also be able to call from Julia to Janet, and it might be intriguing to exploit its VM (compile Julia to it, or also open to others, e.g. Python's, Julia's @code_lowered macro likely helps, you should be able to get the AST and translate to Janet's VM; possibly it's a mistake to use (this) VM, rather just compile to WebAssembly for portability). Generally speaking it's better to compile to native, as Julia does (even better in 1.9 then packages are precompiled to native code), but a VM can have its advantages. Julia also has a slow interpreter, and a VM, to compile too could be a good middle ground when you do not want to pay optimisation overhead.

FYI: Julia also includes a Scheme with julia --lisp i.e. its FemptoLisp implementation, used for Julia's parser, but it's been reimplemented with JuliaSyntax.jl, so it's likely going away soon.

[nstgc]

To start with, I'm not a programmer. I'm a mathematician. I've used a variety of programming languages prior to grad school, at which point everything was locked to Python + C (mostly just Numpy/Scipy). It was awful. I am firmly of the opinion that the general programming ecosystem is poorer as a result of Python, but that's another discussion.

Then while working on my thesis I began using Julia and have been using that extensively for nearly a decade now. It's interesting to hear it called a Lisp. @PallHaraldsson isn't the first I've heard refer to it as such, but I'm not seeing it. To me, the key features to a Lisp are S-expression and linked lists/cons cells, and from those everything else, such as macros, flourish. That it has a Lisp baked in is both fascinating and frustrating. (julia --lisp was news to me by the way, thanks Pall!) It's fascinating because I'd never have expected it and it's pretty cool that it comes with a Lisp. It's frustrating because I feel like Julia could have been so much more than it already is had it embraced that.

Julia isn't perfect, however, so last fall I sampled a number of languages. The one that stuck the most was Clojure. Clojure is fantastic, but it's on the JVM, which is equal parts boon and bane in my opinion. This was immensely frustrating since Clojure, the language, is absolutely fantastic, but divining meaning from its error messages or dealing with its build system (and tooling in general) was just painful.

Then comes Janet.

Janet also isn't perfect—It's kind of slow and I find some syntactic choices to be questionable—but it is still fantastic. Almost magical. Many of the issues I have with Clojure on the JVM just don't exist, and though I know of and have used Babashka, it just never felt right to me. Some key features of Janet for me, beyond being Lispy with a Clojure-like syntax:

• Fast start up.
• Extensive core libraries without feeling bloated.
• TCO
• Competent package and project management.
• Can be compiled to a standalone executable easily. (I'm pretty sure it's embedding Janet in a thin C wrapper and including the byte code, but good enough!)
• Nice community with a benevolent dictator for life who's willing to answer the types of stupid questions someone like me might ask.
• Has a contrib package which extends things further.
• Conjure
• Simple testing
• Lightweight
• Semi-official code formatter (from contrib)
• Built in static analyzer. (Of sorts.)
• 8-Bit clean strings.
• And the best of all: PEG.

PEG should get some extra attention. In my opinion, the three greatest decisions BackPakin made were making it Lispy, using 8-bit clean strings, and including a PEG instead of RegEx. This was my first experience with a PEG and it delivers nearly all of what I would hope for from a Parser Combinator without the headache. Previously, in Julia, I had been writing snippets of RegEx into several functions and then combining those functions. This ad-hoc approach works pretty well, but it's arcane and really hard to maintain. PEG is clear. And it's fast. I'm not sure how that happened, but it is blazing fast. Independent of just being an overall pleasant language to use, for the purpose of anything requiring text manipulation and parsing, Janet is my go-to language.

As a particular use case, I wrote a git filter for LaTeX documents. (Remember, mathematician. I have a lot of these.) The script was just awful, with a bug that I had resigned myself to pretend to be a feature. It was 61% faster, infinitely more readable, and the aforementioned bug simply didn't exist. However, that 61% isn't the whole story. When factoring in the start up times, it's more like 12.5 times faster. Though noticeable on my desktop, I do a lot on my Android tablet where the speed up is measured in seconds. And, of course, I'd like to say once again that the code looks so much neater, and not just because of PEG versus RegEx. Janet code just looks cleaner.

And though I haven't made use of the 8-bit clean feature of strings, something I initial thought of as a hindrance since I do use a fair bit of non-ASCII characters, there are programs I have written which would have been made easier if I could have used strings in place of byte arrays. When combined with Janet's PEG, this just seems immensely powerful.

One last thing I'd like to say, which I touched on earlier, is that I find the code I write to be much cleaner and easier to read compared to Julia, which itself is an improvement over most languages. I think this is due to it being a more opinionated language, and that opinion agrees with me. My code is naturally forced into neat little blocks of tiny functions which are easy to decompose. Anytime a function is over 10 lines long (not including declarations and docstrings), I can easily decompose the function just by pulling it out, and the resulting code overall won't be much longer, and might even be shorter (again, ignoring declarations and docstrings). I will admit that I find Julia naturally easier to write. I believe a key design goal was to make it as easy to write as possible to lower the bar to entry. I can just vomit up code and expect it to work reasonably well, where as Janet requires a bit more thought. But it's only a bit more, and if I want that same Julia code to look nice, it's going to take more than a bit of effort. This is in contrast to Haskell which, though even nicer looking (in my opinion), it takes way more effort to get it that way, where as with Janet it mostly just happens by virtue of syntax.

[nstgc]

P.S. I'm not sure if most would consider 61% faster than PCRE2 "blazing fast", but I do, especially considering I spent days instead of months optimizing it. I'm sure I could squeeze out more, but right now, even on my five year old Android tablet, it effectively is running instantaneously.

[CosmicToast]

I'd consider 61% faster than PCRE2 "blazing fast" in this context. Sure it's no thompson finite automata but it's also strictly more powerful.

[PallHaraldsson]

If you don't see Julia as a Lisp, then that's very justified/arguable (I agree, only because of Lisp-like macros do I see the connection, and since people call even Ruby a Lisp, then no less Julia), with the "key features to a Lisp are S-expression and linked lists/cons cells" I was actually biased against Lisp because of that, despite reading how Lisp is most powerful from Paul Graham. I'm biased against both the (non)syntax of Lisp (I'm not into Lisp and Scheme etc enough do know syntax differences, only Lisp-1 vs Lisp-2 and TCO is Scheme and some Lisps, the pros and cons of TCO, Julia doesn't have it expect in a macro, unless you mean in FemptoLisp, neither does Clojure), and I'm also bias against linked lists. They are a speed-trap on modern hardware, not even in Julia's standard library (available in a package), vectors better, thought less general, cons also supporting trees (and trees also not there I think in Julia's standard library).

It wasn't until Clojure that I'm changing my mind. It supports only persistent data structures, my real reason to consider Clojure, i.e. immutability only supported, even for vectors. Rick considers the syntax key to them, so I'm open to it.

I don't like Java, but what's nice about its ecosystem it tool support, e.g. refactoring tools/extract method. I've not used, but seen some old code for it for Julia, not sure if it still works, or such used. What I see nice about Lisp syntax (and Forth; concatenate languages) is if I understand, it's a simple copy paste, or well "cut" kind of. I would think that you as a mathematician would like Julia syntax, e.g. for polynominals. Implying a precedence of operations, what's drilled into students anyway, though more operators, and Unicode symbols available... I can understand the simplification in Lisp-syntax and SmallTalk (and APL), arguably better or some mathematician liking it even more (there's more than one math, and you may not deal with equations as much in Lisp, is it unpleasant?).

About your continuation "from those everything else, such as macros, flourish". I apply macros in Julia, but I'm not an expert so I don't write my own (one of the few areas that seem exotic). My understanding is writing one may be easier in Lisps, possibly why I don't write them yet. So it's done in Lisp, and maybe overused(?), or so I hear.

FYI, Julia has alternative parsers, e.g. a PEG parser available. I know the basics of parsers, but PEG didn't exist or were taught at least when I was learning. JuliaSyntax,.jl has also some advanced (non-PEG) parsing, ideas from Rust.

Julia also has LispSyntax.jl, not much used I think, more of a functional demo? Only the syntax, not semantics of Clojure. E.g. Air.jl has the semantics, i.e. persistent data structures, but I believe they are more (and very, more than any other language) optimized in Clojure.

[PallHaraldsson]

Also FYI: https://docs.julialang.org/en/v1/manual/noteworthy-differences/#Noteworthy-differences-from-Common-Lisp

[jaredkrinke]

Parsing Expression Grammars do seem like a killer feature. There was clearly a market for something more powerful than regular expressions, especially with clearer syntax.

I don't have enough experience to compare Janet's library with LPEG (Lua) or Packrat (Common Lisp), but I've written a ton of regular expressions and, even though I'm comfortable with the syntax, I hate that they don't compose easily, so Janet hooked me there. Janet for Mortals claimed they even work on binary formats, which sounds neat.

[sogaiu]

Along the lines of "binary", may be this kind of thing is part of what was meant.

[nstgc]

Janet for Mortals claimed they even work on binary formats, which sounds neat.

Well, the strings are byte-oriented rather than character-oriented, so handling non-human-readable data streams with PEG should be as easy as with plain text. Or so I would expect. As I said my post, I haven't actually used it for this purpose.

edit:
Taken from the Janet docs:

Strings can be used similarly to keywords, but their primary usage is for defining either text or arbitrary sequences of bytes. Strings (and symbols) in Janet are what is sometimes known as "8-bit clean"; they can hold any number of bytes, and are completely unaware of things like character encodings. This is completely compatible with ASCII and UTF-8, two of the most common character encodings. By being encoding agnostic, Janet strings can be simple, fast, and useful for other uses besides holding text.

I kind of want to rewrite something that uses byte arrays in Janet using just strings.

[eimrine]

I am a beginner programmer. I learned a little bit of C and Lisp just for fun and I am happy there is such a language as Janet. I have not written any single program on Janet yet but I am trying to write a deque on a double-linked list as native module on github.com/eimrine/zhekaMQ repo. I believe it will make me happy but I am not ready to discuss why I think I need this module. I can not tell I am stuck, I am just trying to solve the problem with maybe one edit per day for a long time and I have not seen that kind of documentation which solves all my obstructions especially when most of them is just poor C skills.

I decided to split the deque task into three files. First file is supposed to be a general algorithm of deque which I am going to compile without Janet. I know it is buggy but I'm sure I can solve all issues with pure C implementation.

File module.c is supposed to be the native module, but I am struggling in understanding that advanced C tricks, I am not sure but seems like those all-caps definitions are macroses and I am a bit scared of these constructions. Also I am still not understanding the code from documentation both on the level of C syntax and on the level of Janet:
static const JanetReg cfuns[] = { {"myfun", myfun, "(mymod/myfun)\n\nPrints a hello message."}, {NULL, NULL, NULL} };

File core-module.c is my attempt to rewrite https://github.com/janet-lang/janet/blob/master/src/core/array.c in order to transform the array code into deque code just because it's similar. Of course I have no idea about how to make anything as Janet core module and I have no reasons to work on core module because I am writing not a general deque and not a general linked list but something valuable only for me.

I have not an urge to annoy people with my problems, but if you know how to make my code as a legit Janet native module, please pull request anything or write some comment maybe. I have started few Lisp books with tasks such as Common Lisp Gentle Introduction and SICP so I am absolutely sure I will have no problems with the "weird" syntax full of parentheses, but I have no desire to start the high-level programming unless the low-level deque will be at least half-working.