It's dead easy to get started. If you want to spend an hour playing with a "lisp" you're only a small download away. Clojure could learn a thing of two from this..

It's also not dogmatic. You can use mutable and immutable versions of the same data structure.

Docs are concise: https://janet-lang.org/docs/index.html

Full API is here: https://janet-lang.org/api/index.html

[edit] I fully agree that "getting started" on Clojure is easier than used to be. Anyway I still think there is room for improvement.

You're 2 clicks away from having a fully-featured clojure environment + an interactive clojure tutorial, thanks to Calva (vscode clojure plugin) running in the browser:

- click here[0]

- click on SSO provider

More information here[1]. Of course, it'd be better to just use the Calva plugin with VSCode. That's a bit more than 2 clicks, maybe about 5.

On another hand, I don't mean to say that it's easy to start programming on Clojure, merely that it's now easy to try it out. There's a steeper learning curve than python or JavaScript, specially on the tooling side.

[0] https://gitpod.io/#https://github.com/PEZ/get-started-with-c...

[1] https://calva.io/get-started-with-clojure/

> It's also not dogmatic. You can use mutable and immutable versions of the same data structure.

However from their description and the complexity promises it looks like the immutable collections are literally just the mutable ones without mutation ability (similar to Java's immutable* wrappers) which greatly limits their effective usefulness.

> Full API is here: https://janet-lang.org/api/index.html

Sadly even worse than clojure's which is already not great.

> Sadly even worse than clojure's which is already not great.

I thought Clojure's immutable collections were generally considered good. What else would you consider "great"?

Edit: or was that a complaint about the quality of the documentation, not the quality of the immutable collections?

> Edit: or was that a complaint about the quality of the documentation, not the quality of the immutable collections?

Yes, sorry if that wasn't clear.

I think the HAMTs are pretty darn solid.

I think, however, that scala raised the bar with RRB trees over the trie-based immutable vectors. And using java strings is pretty sad...

> which greatly limits their effective usefulness.

Interesting

Why?

And what’s the alternative implementation?

Persistent collections with structural sharing (b-trees, HAMT, RRB-vectors, …).

I can absolutely understand not using them if the implementation is intended to be simple or the systems it's running on is resource limited, but simply removing the mutation bits of mutable collections is quite limiting as it incurs large overhead when actually working with them (you have to copy the entire thing every time you want to update anything).

Unless the collections are always kept quite small: modern architectures are very good at dense arrays, so modern immutable data structures are trees of small-ish arrays (usually a small number of dozens, IIRC Clojure uses 32-wide nodes).

I learned a lot. Thank you

Racket is also just 1 download away and even comes with an IDE.

It is little weird, but it's also really fun to work with, if you're doing things that don't need to ship yesterday.

Working with Janet has deepened my knowledge of the Win32 APIs, for example, because it makes writing small bits of C for interacting with them about as easy as that can be.

I also like how it makes data structures and functions look the same in terms of access, and how it handles nil.

I guess it's easy to parse, and excellent for macros!