[cutler]

Clojure is by far the best programming language I've ever used. Rich Hickey's Sermons On The Mount changed the game of programming once and for all. With Clojure you could finally have your Lisp cake and eat it. Witness the sheer chutzpah of the guy when he basically told Ruby devs they were doing it wrong at Rails Conf in 2012 (https://www.youtube.com/watch?v=rI8tNMsozo0).

[jb1991]

It's a lot of fun but as projects got larger and larger for me (thousands of lines, or even tens of thousands), I found the dynamic typing taking up more and more of my time. I've since moved on to statically typed systems where the compiler takes a big load off the cognitive requirements of maintaining and debugging software.

[didibus]

How long have you been programming professionally?

Did you have prior experience with dynamic languages? If so, how much?

Did you have prior experience with statically typed languages? If so, how much?

I'm trying to see if Clojure requires more fundamental programming intuition and experience to sustain in large projects. I work with tens of thousands of Clojure LOC, I don't feel these issues and can't relate, and love Clojure, so I'm curious to understand what context it best applies too. I wouldn't want to force it on a team that wouldn't benefit from it, so I'm interested about learning these aspects, so I'm able to recognize in what context it would make sense for me to influence a team to adopt it or not.

Thanks.

[dkersten]

12ish years (more as student & hobbyist), lots (mainly python, javascript and clojure), lots (mainly Java and C++, sadly inly got to tinker with better type systems). I consider myself a clojure developer and have been using it on and off since summer 09. Im using it for a large project now.

And yet... I agree with GP. I love clojure, but over time I’m becoming less and less sold as dynamic typing. Spec helps, a little. Property-based generative tests (especially when used with spec) helps a little too. Neither are a replacement for proper static types, though, especially an ML-esque type system with type inference. Bonus points if spec validation could pass type data to the compiler/type inference (eg the code path after validation can assume that the data is of the the types described in the spec).

I dream of a statically typed Clojure with type inference, spec-inferred types and optional dynamic typing for REPL experimentation and glue code.

[didibus]

Very interesting, and thanks for answering.

Could I ask what kind of project it is? I wonder if I'm just lucky that Clojure fits perfectly my use case, which is mostly a set of distributed systems of all kinds. So while as a whole there's tens of thousands of LOC. The components have very strong boundaries being as it's a set of services assembled together through RPC, PubSubs and DBs. Maybe that alleviate the lack of a static type checker.

We've adopted Clojure about 3 years ago, team of 10. We've had a few people leave and join throughout. Only one person knew Clojure beforehand. Our stack is about 50% Clojure, 40% Java and 10% Scala. Of all three, Clojure has given us the least issues, has been pretty easy to maintain and generally has fewer defects. Java tend to have the most bugs, almost always related to some shared state. Scala I find the hardest to extend and maintain, but the code base we have for it I think does Scala wrong, it's like the worst mix of OOP and FP.

> I dream of a statically typed Clojure with type inference, spec-inferred types and optional dynamic typing for REPL experimentation and glue code

That's pretty much exactly core.typed: https://blog.ambrosebs.com/2018/09/20/towards-typed-clj.html

That said, the project never managed to get more contributors.

If you're looking for a typed Lisp, I've been keeping my eyes out on Carp: https://github.com/carp-lang/Carp

[dkersten]

I’ve written a lot of different Clojure projects over the years. Some large, some small. Back in 2013–2015 I ran a startup entirely on Clojure(script). My current project is an automation service for cryptocurrency trading bots (that is, all the infrastructure, automation, configuration, dashboard etc for running a bot, but the bot strategy and signals are up to the user — hence automation tool, not bot). It’s a large system with multiple services (some running in different datacenters too). Backend is Clojure (based on duct) and frontend is Clojurescript with re-frame.

Don’t get me wrong, if I restarted the project again from scratch, I’d choose the same setup (or a very similar one). I love Clojure and am very productive in it, but that doesn’t mean I don’t think it could be better still.

> That's pretty much exactly core.typed

I haven’t looked at it in a couple of years, maybe its changed, but when I did, it didn’t really do it for me. It’s still a separate tool that lives separate from Clojure itself and it felt very “heavy”. In my personal opinion and experience, having certain things as separate entities (decomplected as Rich would say) isn’t always a good thing and leads to an inferior thing. I’ve played around with many programming languages in my time (I’m a bit of an enthusiast, I guess. I like trying out languages that are very different from what I already know – that’s how I originally got into Clojure) and it seems like a common theme. The closer a feature is to the compiler/runtime, the better it works and seamless it is over all. Another Clojure example is the limitations core.async has, because its an external library: things like <! cannot be placed inside functions or the go macro can’t see it to transform it as macros cannot look inside function calls. I’ve also encountered an exception recently where the stacktrace only showed core.async and clojure.core code, not a single stack frame referenced MY source files. These problems are hard to solve as an external library.

> If you’re looking for a typed Lisp

I’m not. I like Clojure’s particular mix of sensible syntax, immutability, sequence abstraction and general way of doing things. Other Lisps I’ve looked at don’t have the same emphasis on these things as Clojure does, so I don’t want another Lisp, I want a language that makes the exact same decisions and tradeoffs as Clojure, except on dynamic vs static types (and actually useful error messages). Maybe one day I’ll give it a try, I certainly don’t expect Cognitect to change their language because of what my preferences are.

[didibus]

It's not as simple as that. There are no typed Lisps, even though Lisps have been around since the 60s. That's not just coincidental in my opinion. The closest to a typed Lisp are gradual typed Lisp, like Typed Racket, and that is very similar to how Core.typed does it. There is Shen as well. Carp is the first strongly typed Lisp I'm seeing, and it is experimental and might never take off.

The issue is how would type definitions be introduced, and what kind of types would be most appropriate? As you said yourself, the way core.typed did it felt too "heavy". Yet it isn't clear how to make a more lightweight variant for a Lisp language such as Clojure without rendering the types worthless.

The first, and one of the biggest issue in my mind, is that what everyone loves about Clojure is the data-oriented style. In that style, you represents entities and their relationships using heterogeneous collections. That's where in Clojure you model your domain with Maps, Lists, Vectors, Sets, etc. It is awesome, but no one has figured out a non "heavy" way to statically type it. All methods I know of have bad programmer ergonomics. In effect, adding types back to it almost kills the data-oriented style, and it ends up feeling a lot like modeling with Classes instead. See Haskell's wiki section on this problem: https://wiki.haskell.org/Heterogenous_collections they haven't solved it, and have multiple ways to possibly handle the scenario, and non are ideal.

> I want a language that makes the exact same decisions and tradeoffs as Clojure, except on dynamic vs static types

I would too, but with the caveat that the development experience would be the same, and the programming ergonomics and styles would be retained. And this, I'm afraid, is an open problem that no one has solved yet. It's not just a case of personal preference. Having a language which has the pros of Clojure and the pros of static types, without the cons of static types is hard. That's why for now, you need to choose one or the other.

[kickopotomus]

This has been my experience as well. I have a couple of Clojure(Script) applications that are approximately 3-5K lines each and those have been a pleasure too work on. However, my latest project is now pushing past 20K lines and the mental load has jumped exponentially. There is a much greater need for spec, asserts, type hints, and comments just to keep everything straight.

[slifin]

That's interesting do you have any idea why the mental load jumped? would a static analysis tool working with your type hints help?

Or is there many things to consider at once in the system instead of many individual things?

[kickopotomus]

The biggest issue I keep running into is just the concept of data "shape". I love that clojure gives you so much freedom but it can be quite the footgun in a large system because you see that a function expects a map with keys :foo, :bar, and :baz but what are the values for those keys? Spec helps a little bit here for primitive values but for complex nested structures (e.g. {:a [{:b [1 2]} {:c "bar"}]}), it doesn't do much. So, as data moves through the system, and as the system grows it has become increasingly difficult to track the mutations to the underlying structures.

I do think that a static analysis tool would be of some help. Some sort of tooling to better handle tree structures would be very handy. I often find myself being off-by-one level with get-in calls on tree data (E.g. (get-in m [:a :b :d]) where m is {:a {:b {:c {:d 1}}}}), which is annoying because the NPE gets thrown 3 function calls up the stack.

[escherize]

I'm late to the thread, but I've felt the same pain and wrote a library to help deal with the cognitive load of working on "shapes" of data [1].

[1] https://github.com/escherize/tracks

[sooheon]

Totally not saying "you're holding it wrong", but maybe once you're more than a few couple levels deep into a nested map it's time to look at an in memory db like [Datascript](https://github.com/tonsky/datascript)? Actual Datalog queries can replace get-in vectors growing out of hand, and you also get better mutations with transactions.

[rubyn00bie]

Oh man this talk... so incredibly good. The principle of simplicity vs easy is what drew me to Elixir, and what I'm starting to dislike about Rust.

In Erlang/Elixir, you have patterns, and interfaces which are fairly low level, but provide meaningful abstractions over common goals... I.e. we have OTP. OTP is fairly simple, and that doesn't mean it's easy, it's really not, but it can be simple once you're familiar with it.

Rust, on the other hand, is easy to get started with, the core of the language is fairly small (and relatively simple) but that's where the complexity starts to creep in.

It's so small, I have to constantly reach for a crate for common goals... There are tons, and they're fucking awesome, BUT they're easy, not simple, and my application's complexity grows exponentially relative to my familiarity each time I grab another crate.

I think it's easy ;) to say the Rust ecosystem has to contain the complexity it does, and making it easy is the best we can do, but with great challenges comes great reward... Batteries not included, yes, but at least you could know the size (spec) required for the ones you need? That's probably a shitty metaphor but I tried...

...

One more thought on this tirade, when Rich Hickey casually says that engineers should be working to remove complexity from the business... That hit me right in the feels. Too often do we get complex business decisions/goals and just accept them. We need to push back and help them simplify their goals... too often I've gotten some crazy request, where instead of implementing it, I pushed back to get to the root of the problem and ended up with something wildly simpler and better for both parties. When we push back, it shouldn't be to make something easy, it should be to make something simple. You can scale simplicity almost infinitely, but complexity will eventually come crashing down.

More on topic... Thanks for posting this talk, it and the article have inspired me, I'm gonna go try to write a bit of Clojure today. You should write some Elixir, or maybe LFE (Lisp Flavored Erlang), I think you'd quite like BEAM :)

[Zelphyr]

> Too often do we get complex business decisions/goals and just accept them.

At my last job the client reps were notorious for saying “yes” to every client request and other devs were notorious for implementing those requests without question. I really tried hard to push back and find out what the client was trying to achieve. So many times after a brief discussion I would be able to inform them that what they wanted was already possible or doable with way less effort and expense. Sure, we didn’t get to bill them as much, but I’d much rather solve their pain points without adding code (especially when the code has already been written) than needlessly charging them.

[didibus]

FYI, Clojure can run on the beam: https://github.com/clojerl/clojerl

[noncoml]

> by far the best programming language I've ever used

Would love to hear why? What is that make Clojure such a good experience for you?

[invalidOrTaken]

Not the grandparent, but I realized the other day that I'm at nine years of clojure, so...

What's made clojure so great, imo, is its unicorn status as a principled-yet-practical language. That "principled" part is not worthless---it means that a lot of great minds are drawn to it. Before react took over the world, clojure folks were already taking steps in that direction.

A lot of other things. The "sequence" as a core abstraction is very powerful. Immutable data structures by default make functional programming perfomant and efficient.

Speaking of data structures, data structure literals have spoiled me for other languages. After Java, especially.

And none of this mentions clojure's lispiness. The ease of metaprogramming has allowed the community to build some of the best tooling out there, between CIDER for emacs, and Figwheel for the browser---oh, did I forget to mention clojurescript? Being able to reuse code on the front and backend is great for web applications.

Clojure isn't "everything." I think I'd still benefit from learning Haskell, APL, and Forth, and I wouldn't mind knowing Ruby and js a bit better. And I'll probably be dragged back to Python and R if I keep doing maths.

But if someone asked me which single language would probably do the most for them professionally, I'd say clojure. It's the language people start startups so they can use it.

[cutler]

I wish the last bit was true. Clojure jobs are very thin on the ground even here in startup London.

[amelius]

What is GUI programming like in Clojure? What libraries exist, and what paradigms are used? E.g. is it more like React or is it more like Gtk/Qt?

[logicprog]

There's a really good UI framework for Clojure (not ClojureScript) called seesaw. If I recall correctly it was swing, but it's a very nice data focused, functional library. It really works well with the Clojure philosophy and interactive development. It's also VERY complete.

There are downsides, however. The UIs that it creates definitely look like Swing apps. I.e. ugly at least on Linux. Also, the up to date documentation is difficult to find, I'll like to it here when I get home. The GitHub-linked docs work fine, but they do miss a few features.

[geokon]

Seesaw/swing are the old stable solution. The latest library is cljfx built on JavaFX. The developer is very responsive and open about it's development

Check out the examples/mini-tutorial: https://github.com/cljfx/cljfx

It's all React-like. You have a state atom and a GUI map data structure (which I think is equivalent to your DOM in React..) and then you hook up events that update the state and blah blah. It's all very clean and easy to read/use. The underlying JavaFX is also great for an OO GUI library so it's not gross to dive into if you need it

[serpix]

For frontend Reagent (React but with just Clojure functions and data structures. No classes, no jsx, just one language and immutable data.), and re-frame which does state management and event dispatching better than the competition. Redux is a poor poor imitation.

[Sharlin]

For web frontend (ClojureScript) there's reagent and re-frame, the Clojure versions of React and Redux.

[6thaccount2]

There is a swing example on the getting started page (or there was a few years ago). It was a one liner to have a Swing pop up say "hello world" or something like that. I'm not sure how easy it is to write actual apps that way.

[cutler]

Dynamic and functional. Lazy evaluation. Real immutable data structures. Core.async. A modern lisp not constrained by the exclusive use of parens, ie. [] for vectors and {} for sets & maps as with JS, Python and Ruby. Real REPL-driven development. Macros. Spacemacs with CIDER. Polymorphism which beats OOP at its own game. Massive Java ecosystem at your fingertips plus 25000 pure Clojure libraries and last, but by no means least - a rock 'n roll BDFL with a mullet.

[heartofgold]

Not original poster, but my take is:

- Immutable data-structures with concise literals for lists, vectors, maps, and sets. Having pure functions and immutable data-structures makes code easier to reason about, easier to test, and thread-safe.

(But clojure doesn't "force" you to be pure. The idea is that you write as much of your code in pure functions as you can, and push the IO and impure parts to the extremities. It's very pragmatic in this way, and you can get real work done.)

- Simple syntax:

While the syntax may be intimidating at first and arithmetic looks weird to untrained eye, once you realize that everything is a function (or a special form that also looks just like a function), the very light syntax and consistency feels amazing/refreshing.

- Macro system:

This is tied to the previous point. Since all your code is technically a "list", and you have something akin to a pre-processor where you have the full library of clojure functions to manipulate data. But in this pre-processing phase, your data is the code. (the code is a list). Now you can dynamically re-arrange or re-write code. Lookup homoiconicty and learn about the kinds of things you can do in macros that can't be done in other languages.

- Capabilitis for general programming, abstractions, code re-use etc.

- Performance is quite good. It's often nearly as fast as java, yet your codebase might be 10x smaller because the language is so expressive.

- Concise/expressiveness. Clojure comes with a nice built-in library with generic functions that you re-use again and again. Give a programmer a few dozen of these functions and it's amazing what can be composed to solve many problems succinctly and elegantly.

- There are surely other benefits, but the last one I'll leave with is hard to explain unless you have felt it before. It's REPL driven development.

Clojure comes with some seriously awesome REPLs (i.e. a shell for interactive tinkering with the language). Other languages may have some form of REPL, but no other language in my experience has come close to the feel you get in a clojure REPL. I can best explain it as a freedom of very light-weight experimentation that you use to write your code. It's a playground for writing functions with very quick feedback to see if your code will work or not. One factor that makes the clojure repl experience so nice ties back again to the succinctness and expressiveness of the language. Typing commands in the repl is painless because it's concise, not a lot to type, and then the feedback is so instant.

Somehow when I write code in python, java, javascript, or other languages, I just don't use their REPL or shell as often. It's just not quite the same as the clojure repl experience.

[LandR]

The above posters point on Homoiconicity is a big one, here is a quick (and silly) example for anyone unfamiliar with the term.

Take the following clojure:

    (+ 1 2)
     => 3

Here the ( ) delimits, a list, and as the blog post says most lists are function calls. In this case the function is + and it's params are 1 and 2.

It means if we do this

     (1 + 2)

We get an exception that 1 isn't a function...

However, we can tell Clojure to treat this code as data by quoting the list using the '

    '(1 + 2)
    => (1 + 2)
 

THis is now a list. Where the first item in the list is a number and second is a symbol + and the last item is a number.

WHat if we write a function to swap the first two items in a list?

    (defn swap [x]
       (list (second x) (first x) (last x)))

    (swap '(1 + 2))
     => (+ 1 2)

We have to quote the parameter (1 + 2) as clojure evaluates arguments to functions (mostly..), by quoting it we are saying don't evaluate, instead treat it as data.

So you can see

     (+ 1 2)

Looks like Clojure code, even though it's a list.

We can eval it:

    (eval (swap '(1 + 2)))
    => 3

It's inconvienent to have to remember to quote the params and call eval.

Up steps macros, macros are evaluated before compile time and don't evaluate their arguments. So we can rewrite swap as a macro

    (defmacro swap [x]
 (list (second x) (first x) (last x)))
   

Now we can call

    (swap (1 + 2))
 => 3
 

This lets us essentially extend the compiler and create DSLs specific to your domain problem. Creating new language constructs is incredibly easy.

[dmitriz]

Is there a way to simplify the `swap` function? E.g. in JavaScript it is just

    swap = (x,y,...rest) => [y,x,...rest]

[6thaccount2]

Why not just do that as a function though? Why use a macro?

[zimablue]

You couldn't write it as a function, unless you pass in the 1+2 part to an outer function (macro) as either a list of arguments (1, math.add, 2) or a string (+you have an eval fn).

At that point you're emulating lisp without the elegance, and the first approach is only possible because functions are first class objects. If you were trying to rearrange an expression that had control flow or keywords in it (eg. Modify the behaviour of an if) then you would have to reify the "if" (change the original code so it had a class to represent the if not use the keyword). So you're kind of reinventing lisp by wrapping every part of your language as an object

[6thaccount2]

I'm apparently too stupid for you :). Please excuse my ignorance. Why can't you do something like the below?

(defun swap (x y) (y x))

Then you can call it like:

(swap (2 3)) => (3 2)

[LandR]

It was an admittedly simple example that was to show how easy it is in Clojure to treat code as data and data as code.

The main point of macros is when you use a regular function in Clojure you have applicative order evaluation. Macros do not, as macros are designed to transform and generate code.

A better example would have been the (when) macro.

In Clojure you have (cond) and (if) for conditional evaluations. If has the form

    (if (cond)
       (when-true)
       (when-false))

e.g.

    (if (= 1 1)
      (println "1 = 1")
      (println "uh-oh the unviverse is broken!"))
    => "1 = 1"

Now what if we want to do more than 1 statement on the true path and we dont care about the false path?

    (if (= 1 1)
      (println "1 = 1")
      (println "also hello"))

This won't work as now "also hello" is the false path.. We can use (do) to specify multiple things to be done.

     (if (= 1 1)
       (do
          (println "1=1")
          (println "Also hello")))

      1=1
      Also hello

But writing (do) is a bit of a pain, so an alternatie would be (when)

    (when (= 1 1)
       (println "1=1")
       (println "Also hello"))

Will print, when run,

    "1=1"
    "Also hello"

COuld we implement this as a function, sure? BUt we would have to quote the function calls when we pass them so they aren't evaluated and then eval them if true. You could do it, but it would be messy.

Essentially, we want to write

    (when (= 1 1)
       (println "1=1")
       (println "Also hello"))

But want the code that gets compiled to be:

     (if (= 1 1)
       (do
          (println "1=1")
          (println "Also hello")))

So we want to extend the language so we can write (when) and the compiler will write us an (if (do))

This is incredibly easy in Clojure. We just need to create a list where the first item in the list is `if`, the second item is the conditional we pass to the macro, the 3rd item is a sublist, of which its first item is `do` followed by the list / functions to execute when our test evaluates to true!

    (defmacro when [test & body]
        (list 'if test (cons 'do body)))

This is just the source code for the actual clojure core when macro. But you can see how easy this is!

If we run the macro expansion on when we can see the code that it generates:

      (macroexpand '(when (= 1 1)
         (println "1=1")
         (println "Also hello")))

       => (if (= 1 1) (do (println "1=1") (println "Also hello")))

Another example would be the reader macro:

Say we have the nested function calls:

    (reduce + (filter even? (range 1 11)))
    => 30

After you have a lot of nesting this can get difficult to read, so you have a macro ->> which is the threading macro. This takes a series of functions and threads the result of each function as the input to the next.

     (->> (range 1 11)
          (filter even?)
          (reduce +))

The source code for this is almost as simple as (when)

     (defmacro ->>
        [x & forms]
        (loop [x x, forms forms]
           (if forms
             (let [form (first forms)
                 threaded (if (seq? form)
                 (with-meta `(~(first form) ~@(next form)  ~x) (meta form))
                 (list form x))]
              (recur threaded (next forms)))
             x)))

The ` ~ and ~@ are just doing some quoting and quote splicing to determine when we want stuff evaluated.

Basically, using macros you do things like control symbolic resolution time, extend the compiler to create a DSL spcific to your domain and reduce boiler plate code.

That's before you start getting into properly weird stuff like anaphoric macros.

[6thaccount2]

Thank you! I think I've seen the "if" and "when" examples before, but it clicked better this time.

I've read a few Lisp books and dozens of internet blog posts, so I know about macros and why people use them without getting the full understanding which comes with actually writing code.

[tincholio]

Because function arguments are evaluated before the function itself. In this case, that evaluation would fail because numbers do not implement IFn, and hence cannot be called.

Macro arguments are not evaluated, and so this works.

You could make it a function, and pass the arguments quoted, but it'd be more cumbersome.

[dmitriz]

I have just tried it in REPL and got this cryptic error:

    cljs.user=> (defmacro swap [x] (list (second x) (first x) (last x)))
    #'cljs.user/swap
    cljs.user=> (swap (1 + 2))
    Execution error (Error) at (<cljs repl>:1).
    1.call is not a function

[dkersten]

> Macro system

Macros are actually my least favourite part of Clojure. Sure, its great to have them and there are some libraries that use them to excellent effect (instaparse, Hugsql, etc), but most of the time, I prefer tools that don't use macros. You can see by comparing libraries that were made in the earlier days of Clojure versus more recent ones: the earlier ones love to use macros while the newer ones prefer functions and data. The data-first libraries are, in my opinion, easier to test and easier to build complex things on top of. If I look at a readme and see that the expected way to interact with a library is a macro, I usually look for a data-first library instead and only use the macro one if I can't find an alternative.

Macros are technically cool, you can do some interesting things with them, but I find that in most cases where they're used, they are inferior to alternatives. Its technically very cool that core.async could be implemented as macros, but I feel that core.async greatly suffers from it versus being built into the runtime: you cannot use many operations in functions called by core.async/go because the macro can't see inside function calls. Also, I've had exceptions thrown by core.async where the stack trace did not mention any of my code. That was not fun to debug.

Don't get me wrong, macros do have their place: hugsql uses macros to parse the SQL file and generate functions for you, which is awesome! But for every great macro-based library, there are many more that I wish didn't use macros.

(This is user-facing macros in a libraries' API. I have no problem with using macros internally)

I do love Clojure overall, though.

[heartofgold]

I do agree that you should prefer functions over macros. The rule of thumb I’ve heard is only use macros if they are absolutely necessary.

But having that option is better than not having the option at all IMHO.

[dkersten]

Absolutely, I even mentioned some cases where I felt they were used to great effect. Having said that, though, in my experience, they do cause an “just build it with macros” attitude. For example, the issues I mentioned with core.async will likely never get fixed as doing so would require compiler/runtime support which is highly unlikely to happen.

[badsavage]

I agree!

When I meet a girl, I ask her about macros and functions first.

I except to hear something like: macro < function < data.

[PopeDotNinja]

Ever play with Erlang or Elixir? If yes, I am curious what your thoughts are on them.

[ashton314]

I've been doing a lot of Elixir recently, and I have a fair amount of experience with Scheme and Clojure. The biggest "aha" moment for me with Elixir came when I realized that everything, just like in a LISP, was an expression.

Then, when I learned about Elixir's macro system, I thought, "wait a minute, this is LISP! This is just a LISP in Ruby's clothing in Erlang's pasture!"

That was a delight. :) My heart still belongs to the LISP family, but right now I'm working as an Elixir developer.

[cutler]

Yes, Elixir would be my second choice but although it has Lisp influences it doesn't capture the real magic of Lisp for me. Code as data belongs exclusively to real Lisps. Elixir also lacks vectors of its own and tends to be too niche compared with Clojure.