If you like Janet, you'd probably like Clojure a lot as well.

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.

Clojure was something I tried once or twice, but couldn't quite get into, at least back when I tried it before.

These days, I might be better able to pick it up, having cut my REPL teeth on Janet.

There's definitely a higher barrier to entry to Clojure.

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.

One thing I find funny/curious: Does clojure not have a destructuring match in it's standard library? Most people that I've seen move from Clojure to Janet seem to avoid using that.

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.

> Does clojure not have a destructuring match in it's standard library?

Yes it does:

    (def my-vector [:mary :had :a :little :lamb])
    (let [[_ _ _ _ lamb] my-vector]
      (print lamb))

    (def person {:name "Bob Dylan" :age 77})
    (let [{person-name :name
           person-age :age} person]
      (print person-name)
      (print person-age))
Clojure doesn't natively support destructuring inside def and var though, the latter doesn't really exist in Clojure since there's not real local mutable variable, only local bindings. It supports it in let, function parameters, loop, and everything else that derives from those.

For fun, I just made a macro to support it in def as well:

    (defmacro ^:private def-locals
      []
      `(do ~@(for [local (keys &env)]
               `(def ~local ~local))))

    (defmacro ddef
      [destructuring value]
      `(let [~destructuring ~value]
         (def-locals)))

    (ddef [_ _ _ _ lamb] my-vector)
    (print lamb)

    (ddef {person-name :name
           person-age :age} person)
    (print person-name)
    (print person-age)
> are small CLI programs that help me free up mental space, and web apps. Clojure, outside of babashka seems ill-suited to the first

Ya, Clojure JVM is not ideal for small CLIs, because it has a slow startup. Though you can now compile a Clojure JVM program into a self-contained statically compiled native executable, it requires understanding a fair amount of GraalVM native-image, and Clojure infrastructure and all that to do so, actually Babashka itself is such a program. But that's also where Babashka comes in, because now all your effort learning Clojure also means you can reuse those learning for scripting and babashka driven CLIs, where as before you needed to rely on some other language for those, which meant having to learn something else for those use cases. You can also use ClojureScript to write Node.JS driven CLIs and scripts if you want, though I'd say Babashka is much nicer, unless you cared for some Node.JS library.

> And when I last tried to do web apps with Clojure, it seemed like everything relied on a lot of self-assembly, 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 day

It hasn't changed, familiarity is Clojure's enemy, that holds for frameworks as well. This is another learning curve.

> For Janet, I did lean into the more imperative constructs early on.

Ya, that will be another big learning curve then.

When I think of destructuring match, it's not just about destructuring, but also about matching a set of clauses against the matches.

I rely on the imperative parts of Janet less than I used to, but yeah.

I am surprised that no one has tried to build something like Sinatra for Clojure. From what I can see, nothing would keep Clojure from being able to make something like that.

I assume you mean something like clojure.core.match https://github.com/clojure/core.match ? It is available, but not used that often.