If you want to take on web apps, backend services, machine learning and data-science, desktop GUI applications, mobile applications and/or distributed computing use cases, it could be a good choice where Janet lacks the chops, but Clojure offer a very similar feel while enabling those use cases.
For scripting, CLI, and embedding with a C interface, Janet rocks.
Yes, the stack traces are long, but if you actually follow them, they'll show you what your problem is, not sure what else you can wish from a stack trace. I'd rather have too long stack traces with all the details than just a error message without anything to go by.
And since you most likely get your stack trace from when evaluating just a snippet of code with some exception, the stack traces tend to not be as big as for other programming projects (like Java, JavaScript, Golang and else) either where you need to run the entire program in order to reproduce some issue.
On a laptop with only a single screen of real estate, even as orderly as the trace might be, it's a distinct hassle to scroll and walk it all the way back to a method argument problem somewhere, and equally frustrating to think about because I'm using a functional language to try and avoid thinking about classes and methods and whatnot.
Maybe I'm just expecting Clojure to taste like Scheme, and I'm probably wrong.
These days, I might be better able to pick it up, having cut my REPL teeth on Janet.
There's more layers to understand, because it is hosted over existing runtimes, instead of being self-contained like Janet.
For that I would recommend starting out with Babashka https://babashka.org/ it'll take some of that edge off, because it is a self-contained interpreted Clojure. It's a good way to start where you can get straight to writing code and learning the language itself, and not having to learn about how it is all scaffolded and bootstrapped over a JVM, CLR or JS runtime.
Clojure also forces you almost exclusively into the functional programming style. Doing imperative things in it is ackward. So if you tend to rely mostly on Janet's imperative constructs, this might be a bit of a shock.
Don't really have a trick for this one, just got to learn and practice FP to get familiar with it. Also, it depends a bit what you're doing, a lot of coding questions and small exercises tend to be simpler to implement imperatively, because they're either designed to be so, or are very focused on raw performance. FP will show its worth when writing larger programs in my opinion, where long term productivity, extendability, modularity, maintainability, and robustness/correctness become your biggest concerns. So in the small, it can often seem like a more convoluted way to do things, though for certain problems it also can land itself really well.
For me, the two types of programs I tend to use to exercise an language early on are small CLI programs that help me free up mental space, and web apps. Clojure, outside of babashka seems ill-suited to the first (and I've not figured out how to get the CLR clojure up and running).
And when I last tried to do web apps with Clojure, it seemed like everything relied on a lot of self-assmebly, and didn't map cleanly to ways I knew how to web apps at the time from Go, C#,or Erlang. I dunno what the situation is there these days.
For Janet, I did lean into the more imperative constructs early on.
With the exception of Electron apps, this is a bit of an exaggeration. There are far better choices in that area than Clojure.
I love this and understand both the sentiment expressed and (as a recovering member of the Cult Of Lisp) the reason why it was said.
The syntax and semantics are clearly similar to that of Lisps before it, and so is the feature set enabled by that very same syntax and the very same semantics. In that sense if Janet had to be the dialect of something else, I don't see what else but being a dialect of Lisp it could be.
And I don't think Janet is different enough in syntax and semantics to be given its own new family of language.
Anyways, those debate are kind of for fun and games, cause it doesn't really matter, but I think the description you could give to someone else who's asking: What's it like? And if you say, it's a bit like programming in any other Lisp, well you'd be giving them a pretty good idea of what it was like, unless they'd never programmed in any other Lisp either, then you're going to struggle, because there's not a whole lot like Lisp.
That said, I am not such a purist as to be bothered by it, and janet has a special place in my heart right along with chicken, racket, clojure and CL.
Lists in a conceptual sense are an ordered collection of heterogeneous elements with nestings.
In that sense, code in Janet is very much represented as such and processed as such. Which in my mind makes it a LISt Processing language :p
Paren AST languages.
But this article has been sitting in a draft for the better part of a month, lol.
I’m still curious about how good the embedding story is (ex. for game scripting or as a configuration language), compared to other scripting languages like Lua/Squirrel/Wren. (Runtime memory usage, GC overhead, how easy and performant it is to create C bindings, etc…)
The core is still heavily meant for embedding. It's not as light as Lua, but there's an amalgamation .c and .h, you can strip out everything that depends on an OS underneath, and so on.
That being said, a lot of folks that use Janet and are in the gitter/matrix server are currently focused on aspects of web dev, myself included. Lisp, as always, enables a lot of expressive power there that enables building your own pieces of the web stack, for example.
C bindings are relatively easy, and use the same interface that is used to build the standard library, so performance doesn't really take a hit from the interop code.
I can't speak to the GC, other than to say that it hasn't been an issue for me yet.
(def asset (slurp "file.txt"))
It even has a JIT these days too
Having a package manager means I can easily reuse other people's code. Not having a package manager means I can't.
Note that my use cases almost universally involve either "scripting" or developing low-volume server applications that are deployed in container of some kind, or on a VPS that I control.
I have only developed nontrivial standalone "libraries" in Python, and I only use Lua/Fennel for Neovim plugins (where I am not alone in bemoaning the lack of a standardized way to declare dependencies [1]).
In almost every program I have written, my priority has been on rapid development/prototyping. I want to be able to do things like parse JSON, make HTTP requests, perform lookups in tables/mappings/dictionary-like structures, and manipulate text.
I also have a day job, an amazing life partner, and more interests/hobbies than I have time left in my life to spend on them. For me, time spent fussing with manually copying source trees and reading through dense manpages is time I could be spending on other things.
I also come from the worlds of statistics and data science, where it is often said that "nobody cares about your code." Time spent reinventing tools is time not spent cleaning/exploring data, revising a report, building a dashboard to accompany said report, or trying out some new techniques.
So to answer the 2nd part of the question: it's going great!
[1]: https://neovim.discourse.group/t/plugin-metadata-formats-wha...
Still a great article though