Is there anything that is janet-unique? I just did a cursory glance, and most of it seems like a scheme with slightly different syntax and a more "modern" standard library.
Why should I switch from my scheme of choice (guile) to Janet?
It's not a Scheme at all! It doesn't have cons cells after all. It's a Clojure-like (maps everywhere, collection api, immutable data structures) with 1mb executable and [servers](http://janetdocs.org/) running under 10mb of ram.
Fibers are very interesting, even used for error handling. I've not wrapped my head around PEGs yet.
That makes sense. I have always thought about what I would do if I could make a "modern scheme". A lot would be taken from clojure but definitely not everything. Cons cells would stay, but the star of the show would be immutable vectors based on rrb trees or maybe finger trees (efficient concatenation, insertion in the middle etc), HAMTs , concurrentML (like guile-fibers) and a nice looping facility (like my own goof-loop[1]) and restricted mutation. Syntax-case and syntax-parse from racket. An extensible pattern matcher (like the one found in racket).
I would also make strings immutable, maybe like Guile's cow-strings, maybe blobs-with-cursors.
Definitely just copy Guile's delimited continuations.
I think I would just ignore most of r7rs, since I don't think it improves things for the progrmmer.
I am no fan of racket's for loops. It is frustrating, because it fells like an almost-goosd looping facility.
I do use racket, but for scripts I prefer guile. Guile-fibers is a lot neater than the racket parallelism situation, for example. And I can usually find the code responsible for what IAM trying to achieve in the implementation. I never became friends with racket. I remember trying to fix a bug, but I never found what I was looking for.
Getting superficially familiar with the guile codebase takes about an hour.
Then again, I am a classical musician and not a programmer.
Racket's for loops declare in their name what they're intended to return (if anything). Personally that's way more readable and preferable to, say, Common Lisp loop or iterate where you have to hunt through the body for clues. Plus it's easy to create new ones when desired.
I don't see fibers in the guile manual, just heavy weight threads. Is that a third party library? (The lack of a package manager to easily install such things is an issue with most Schemes; only chicken and chibi have anything like Racket's)
It does not use mutation, and should produce just as efficient code as the racket loops. It is also extensible (and easily portable to racket!). It is written almost exclusively in syntax-rules.
Yep peg.el[1] is now built-into Emacs since 30.1 (which is how I came to know of it, but actually the library seems much older) and it makes certain things much simpler and faster to do than before (once you figure out its quirks).
Although I'm a recovering sexp addict I must confess that I fail to see what makes the cons cell so important to those purer in their faith?
To me the homoiconity of Lisp is mainly about code-as-data, the exact nature of the data doesn't matter to me that much as long as it's a first class citizen and enclosed in nicely balanced parenthesis (though sadly here Janet seems to have fallen to the temptations of the curly braces, and thus, is indeed heresy).
I have an emacs function that opens up the page to its examples use on the web, which can be useful directly from emacs itself.
I'd also like to be able to open up each example up on to the playground with the docs above it. (Currently you can just open the example in the playground) no docs right above it.
I did see a json file containing all site data at one point, I did think about using this as a data source for an llm to 'janet' correctly (because at the moment, they do not). This could be displayed/noted more prominently.
I did most of the 2023 Advent of Code using Janet and it was a great experience. I forced myself to use PEGs as much as possible, even when it was overkill, and I really began to like those for the readability and ease compared to other parsers/regexps that I have used.
I like that it is a small language without dependencies. Have it installed everywhere, including in termux on my phone. Good for scripting.
Used to daydream about a native Clojure and Janet is close enough to that. Does not have everything, but the cost in size and dependencies is so much lower. It is simpler and easier and runs well even on a RPi Zero.
I would tend to use Janet for scripts, especially ones that need to talk to the outside world because of its fast startup and batteries included standard library (particularly for messing with JSON, making HTTPS requests, parsing with PEGs, storing data in maps), while I would use guile for larger projects where things like modularity, performance, or metaprogramming were more important to me.
That being said, these days I use Clojure for both (I use babashka to run scripts: https://babashka.org/)
I don't know enough about guile, but janet was pretty easy to develop for .
Its binaries are quite small, could wrap and embed raylib and a few small c libraries with no hassle. This makes distribution much easier.
For my simple 2d game jaylib (raylib) code.
ls -laoh build/app
-rwxr-xr-x 1 worthless 2.8M 27 Jul 17:28 build/app
otool -L ./build/app
./build/app:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 24.0.0)
/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 706.41.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2674.3.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 4034.0.0)
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1951.0.4)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1226.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 4034.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
I believe those are pretty standard to have on most OSX machines, the situation is similar for my Linux system.
The LLM's really can't deal with janet though, they seem to think its clojure and screw up a lot of things.
Feed your LLMs the documentation and example code (perhaps the whole stdlib if it fits). Tell your LLM that it is not Clojure nor Scheme, it is a different language. I have worked with more niche languages than Janet with Claude before this way, successfully.
One big difference is you can compile Janet programs down to executables without any additional dependencies or runtimes. It makes distribution extremely nice. The ffi is also much easier.
If you are happy with Guile, I guess Janet is not worth switching (it is faster, though). It is absolutely and explicitly not Scheme, though. More like natively compiled and script-optimized Clojure.
Why should I switch from my scheme of choice (guile) to Janet?