
State of Clojure 2020 - agumonkey
https://clojure.org/news/2020/02/20/state-of-clojure-2020
======
distantaidenn
Former Ruby guy reporting in. Started using clojure a few years back, but have
been serious about it recently. I can't explain how pleasant the language is.
Everything just makes sense, and once you get the tooling sorted (which is
admittedly a bit convoluted), it such a beautiful environment.

I've always been an emacs user, so clojure was a match. Emacs + cider for
repl-based development has been an amazing productivity boost. I wanna shout
from the rafters and tell everyone that this is how it should be done! I don't
even want to imagine working in another environment anymore.

The Lisp enlightenment is real, in that I started to see code differently --
more in the sense of homoiconicity. I realized I began to lose the distinction
between code and data. Everything just merged. The clouds didn't part nor did
I ascend to a higher level of being as promised -- but it was definitely a
"whoa" moment.

Enough of my blubbering, just wanna say keep up the good work! The language
has brought back the fun of programming for me.

~~~
piokoch
I am wondering how people deal with complicated domain models, I have many
objects that have a lot of properties (from 10 to 30), in Clojure I should
represent them somehow, probably with maps, the problem is I would have to
memorize all the keys... How this is approached in Clojure in a proper
"clojurian way", that is without doing something like using Java classes?

~~~
slifin
Most editors should autocomplete those keys for you if you want somewhere that
is a centralised location to find those names you could consider using spec
[https://clojure.org/about/spec](https://clojure.org/about/spec)

Spec 2 should separate two concepts, schema: all of the possible keys, and
selection: the keys used in this particular function, Spec is also recursive

Because spec is part of the language there is a growing ecosystem for defining
specification once in spec then translating them to things like database
schema, GraphQL schema, OpenAPI schema etc where they can be more
"traditionally" understood

You also get other cool things like you can generate conformant data examples
given a spec, and use those to create generative tests, as time goes on I
think our static analysis tools will start working partially with specs to
further their abilities

Specs also power things like this: [https://borkdude.github.io/re-
find.web/](https://borkdude.github.io/re-find.web/) and I think we're
increasingly using them for validation, error detection etc in the core
language too

~~~
kls
Was going to highlight the same thing. even in OO if you are not using tooling
like autocomplete, you have to mentally map all of those attributes.
Fortunately autocomplete is fairly ubiquitous and it exists for Clojure as
well. Visual Studio Code has pretty good support for Clojure via some
contributed plugins.

~~~
int_19h
In OO, autocomplete can be driven by type information, which makes it that
much more reliable and relevant.

------
d_t_w
I studied Java at University and then worked with it for 15 years through
various companies, finance mostly. I like the language but the opportunities
and my use of it felt very stale in the end.

I switched to Clojure a decade ago, around the time I started working with
distributed systems. The best move I have ever made. I love working with
Clojure and I find a large benefit in my understanding of the JVM.

Recently I've built a front end (Clojurescript) and some lambda services
(Clojurescript on Node) to complement my startup (Clojure,
[https://operatr.io](https://operatr.io) \- its a tool for Kafka). There's an
advantage to using a single language/mindset through your entire stack.

I spoke at the last Conj
([https://www.youtube.com/watch?v=MnvtPzEH-d8](https://www.youtube.com/watch?v=MnvtPzEH-d8))
about my experience, broadly speaking my top reason for loving Clojure is that
I am much more effective in delivery today than I was a decade ago. I simply
don't believe I could have built Operatr in Java/Javascript, YMMV.

In technical terms Clojure's data-orientation coupled with host-interop is
much more important to me than it being a functional language or emacs/vim
etc. Turns out I still use Intellij (with the Cursive plugin) and my work
setup has changed very little.

It's a great tool, if you haven't tried it you should have a play -
particularly if you work with Java.

~~~
arc-in-space
>I love working with Clojure and I find a large benefit in my understanding of
the JVM.

Reliance on the Java ecosystem has been the biggest issue for me in trying to
use Clojure. I love many things about the language, but I have zero experience
with Java or the JVM. A number of my attempts at using Clojure for a project
have been hindered by my lack of understanding of the underlying runtime and
the tools. In a way, it almost feels like Clojure simply isn't for me.

On the other hand, I've had much more luck with ClojureScript, which I'll
happily use over JS any day, though the build system still occasionally
mystifies me.

~~~
dgb23
I agree with this, Clojure being hosted means you have to understand the host
decently enough. This is a downside and an upside since Java and JS are large,
popular ecosystems. But in some cases I wish there was the option to just
compile a binary. As for now, I can’t recommend the language to people who
don’t already now Java and/or JS. (Maybe WASM/WASI will open this door at some
point.)

~~~
slifin
There is now an option to compile a binary, it uses GraalVM native-image
technology

We're growing a scripting ecosystem in Clojure now thanks to this, it's still
relatively new

As a newcomer, I've made several native binaries for different operation
systems

~~~
armitron
GraalVM does not solve the reliance on the underlying host (JVM, Java)
problem.

~~~
slifin
Well that depends what you define the host problem to be

End users can certainly run Clojure programs natively without having the JVM
installed on their machine

~~~
vips7L
You can do that without Graal using jpackage. The only boon of Graal is native
binaries and interop. But if you want to ship the JVM the user doesn't need it
installed.

~~~
mark_l_watson
I wonder if native apps built with Graal or jpackage could be accepted at the
Apple macOS and Windows app stores?

~~~
vips7L
Graal probably. Apple seems to not like JITs so shipping the JVM might be out
of the question.

------
pgt
Fair warning to anyone picking up Clojure / ClojureScript: it can make you
less productive by making your old tools insufferable.

It's like taking an automatic 2.5L turbo Subaru w/aircon for a spin and then
getting back into your 1.3L Toyota Tazz - daily driving won't be as fun again
for a while.

Lisp "ruined me" for a few years because after trying it I couldn't stand
using anything that dit not have macros and Paredit. It's like the saying,
"Beware of tasting freedom; it can make you psychologically unemployable."

For example, dealing with the abomination that is JSX when I could just write
a pure ClojureScript function that returned Hiccup data structures that gets
rendered to HTML. And you get isomorphism for free (one codebase on client and
server).

I initially switched to Clojure for Datomic (the killer app for Clojure, IMO),
but now I mainly write ClojureScript and use DataScript (datalog on the
client) in every project.

~~~
dgb23
Datomic really is a killer app in terms of its features, but it doesn’t seem
to be targeted at solo/small teams with its pricing and licensing model.

Datascript looks interesting. I guess you get disk persistence with event
sourcing?

~~~
ilikehurdles
JUXT's Crux database[1] is worth looking at. It's open source and free. It is
also an immutable, time-traveling, event-sourced database with a datalog query
engine. Datomic is still more fully featured in a lot of ways, but Crux's
concept of bitemporality is pretty interesting and something I've been wanting
to explore deeper.

[1]: [https://opencrux.com/](https://opencrux.com/)

------
keithasaurus
Clojure is a decent language. I've worked with it a good deal in work. But I
would take any functional language with types over it. Some thoughts:

\- its dynamic-ness makes it not suited to large projects IMO.

\- The currently-accepted attempt at a non-type-system-type-system 'spec' is
not well thought out.

\- Biggest wins I think are immutability by default, homoiconicity, and
"simplicity"

\- The repl is fine but can be a crutch -- see startup time

\- Clojure still hasn't really found a niche, and I'm not sure I would ever
reach for it first unless I was integrating with other clojure projects.

~~~
iLemming
> But I would take any functional language with types over it

Which is what? Scala? Haskell? OCaml? F#? Typed Racket? Idris?

I think Clojure really hits the sweet-spot between stupidly boring,
"pragmatic" PLs and idealistic, novelty, academic ones.

Haskell is awesome, but realistically it is really difficult to quickly train
someone to the point of them being able to write production-ready Haskell
code.

Scala has its own warts (besides, Kotlin seems to be slowly eating its pie);

OCaml still struggling to get any recognition in the industry, despite all
attempts from a few good players.

I disagree with the notion that Clojure is not suited for large projects, but
I agree that Spec needs to be improved (and it is being actively worked on).
And I don't think it is not well thought out. Rich Hickey is famous for
slowly, carefully, patiently designing things. Stability and predictability of
Clojure and its standard library is phenomenal. For every single language
(even those I have never worked with) I can probably name a thing or two off
my head that involved breaking changes. Not for Clojure.

~~~
kamaal
>>Which is what? Scala? Haskell? OCaml? F#? Typed Racket? Idris?

These days Java works just fine. Why use anything else, that neither has dev
mind share nor the library ecosystem remotely the same as Java.

~~~
ilikehurdles
When I was last at a Java shop, we we're pushing multiple-thousand line PRs
every week, a good 40% of those lines were simply boilerplate generated by
IntelliJ, and it would have been worse had we not fully instrumented our
codebase with Lombok, and all this was for a pretty mature product that wasn't
seeing any radical changes from day to day. At the clojure shops I've worked
at since, we're building more and delivering product faster, and we're doing
it on the JVM with less than a third of the lines of code. A thousand lines of
clojure is a significant refactor or a big feature. A thousand lines of java
is wednesday.

For me, clojure provides a simple-to-use API, high-level functional
abstractions, an instantaneous feedback loop, access to a battle-tested JVM
ecosystem, and more than fast enough performance. This is its killer
combination, in my opinion. The immutable-by-default data structures are also
an underappreciated boon for writing multi-threaded code without breaking a
sweat.

~~~
e12e
> When I was last at a Java shop, we we're pushing multiple-thousand line PRs
> every week, a good 40% of those lines were simply boilerplate generated by
> IntelliJ

This actually one of the things I like about Kotlin - many of it features are
similar in effect to pre-generated boilerplate - but it lives as part of the
run-time, not in your code.

On the flip side, a new version of Kotlin could potentially introduce/reveal
bugs - but at least you don't have to deal with four different generations of
outdated boilerplate when diving into old code...

------
jakebasile
Learning and switching to Clojure as my primary language is the best decision
I've made in my career (which is relatively short at 10 years, I'll admit).

It's probably somewhat decreased my earnings compared to trendier languages,
and I worry that the market for Clojure developers is small and fragile which
might bite me in the future... but I've never been happier doing my job than I
am since I've started working with Clojure!

\- The language itself is beautiful to read and write, minus a few warts that
take some getting used to here and there.

\- The jobs that are there tend to be smaller teams at larger companies which
is my preferred type of setup.

\- The community is mostly self-selected and tends to be fairly friendly.

\- Working with the REPL feels like having a conversation with your computer,
teaching it how to do what you want it to do vs fighting with a compiler.

\- I like the "batteries not included" ethos - everything is a library and I
can pick and choose what I like.

\- Working on the JVM means I get access to untold thousands of Maven packages
plus the JVM itself which is a very solid system.

~~~
mollusk
> It's probably somewhat decreased my earnings compared to trendier languages

Odd, considering that Clojure is the best paid language according to the Stack
Overflow Developer Survey:

[https://insights.stackoverflow.com/survey/2019#work-_-
salary...](https://insights.stackoverflow.com/survey/2019#work-_-salary-and-
experience-by-language)

[https://insights.stackoverflow.com/survey/2018#work-_-
salary...](https://insights.stackoverflow.com/survey/2018#work-_-salary-and-
experience-by-language)

~~~
why_only_15
That effect is probably much more so about where the language is used (US vs
elsewhere primarily) rather than how much people get paid for that language in
a particular place.

~~~
mercer
I find that at least in The Netherlands the vast majority of job offerings are
quite conservative in their 'stack'. It's nice that they are now okay with
React rather than only Angular, or Python instead of just PHP, but finding a
Clojure or Elixir shop is still much like finding a unicorn. And my impression
is that this is true in most of the EU.

~~~
simongray
We have a few in Copenhagen. I've worked at a small startup using Clojure and
a big government project using both Clojure and ClojureScript. I've also
interviewed at one of the big car pooling apps here and they used Clojure. Now
I'm working at a university also writing my code in Clojure and ClojureScript.

But you do have to be diligent and spend some time to search for them. That
stack you mentioned is definitely extremely common here too. And in the uni
department where I work now the existing research code is still all LAMP stack
and Java, so I'm trying to skip a generation of tech and get straight to
modernity by introducing Clojure here.

------
namelosw
I'm a Web developer the most of the time and I tried to jump back and forth
between languages and communities in my spare time to check out if there are
some ideas that could interest me. I found dynamic language communities are
most inspiring to me, just like the old Ruby community.

I found the Clojure community is really fun. I tried Fulcro/Pathom, it's like
GraphQL but much more flexible. And also there are open-source alternatives to
Datomic like DataScript in the browser, and Crux is also very promising. I
always wonder what if we bring some Prolog/Datalog to day to day programming,
and those are the ideas well implemented and polished.

Another interesting community I found is Elixir, Phoenix Liveview is very fast
to not only prototyping but also achieve high performance.

As a comparison, most statically typed languages community spent most of their
time climbing the lambda cube, or in another word, struggle with correctness
and expressiveness. It's not necessarily a bad thing - on the contrary, it's
applausable. But I found most of the statically typed languages are focusing
on those similar things rather than exploring new directions with would be
more weird and fun.

------
_bxg1
I tried out Clojure for a personal project about a year ago, just to see.

The tooling situation definitely needs some work. Compared to the batteries-
included setup of Cargo or NPM, it felt pretty slapdash. The fact that
Leiningen is both the go-to and unofficial was a tad bewildering.

Once I got set up, the development experience in VSCode was also quite
underwhelming. I've never liked CLI editors and I didn't want to shell out for
IntelliJ, so it was my best option, but it didn't offer much beyond
indentation and inline eval (the latter was cool, but the lack of basics like
autocomplete outweighed it).

These factors obviously aren't as relevant at a company that already has a
standard way of doing things, and maybe the situation has improved since I
tried, but it really put a damper on the "hit the ground running" experience
which is important for gaining initial traction with developers.

All of that said, I can see the language being really pleasant to use in the
right context. Most of my hobby projects involve GUIs and/or graphics, so I
haven't done any more Clojure since. If that weren't the case maybe I would've
put in the extra time to really figure out a good environment for it.

~~~
tekacs
A few of these things may differ from when you tried Clojure out last:

> The fact that Leiningen is both the go-to and unofficial was a tad
> bewildering.

Clojure now has an official, built-in CLI that mostly supersedes Leiningen.

You can just install Clojure itself, create a 'deps.edn' (which can be as
simple as '{}') and get going at a REPL by running 'clojure' or 'clj'.

Packages are auto-installed - in some ways I find it even easier than node,
where npm is a separate tool/install sometimes. :)

> Once I got set up, the development experience in VSCode was also quite
> underwhelming.

There's a VSCode editor plugin called Calva[2] which has developed pretty
thoroughly over the last year or so. Outside of IntelliJ/Cursive, it's
starting to become one of the more feature-complete systems and it has plenty
of features that you'd expect.

[1]:
[https://clojure.org/guides/deps_and_cli](https://clojure.org/guides/deps_and_cli)

[2]:
[https://marketplace.visualstudio.com/items?itemName=betterth...](https://marketplace.visualstudio.com/items?itemName=betterthantomorrow.calva)

~~~
_bxg1
I believe Calva is what I used, but it's entirely possible that it's gotten
better since then

~~~
tekacs
> it didn't offer much beyond indentation and inline eval (the latter was
> cool, but the lack of basics like autocomplete outweighed it)

It definitely has intellisense/autocomplete now, so that at least is one point
of difference from when you last saw it. :)

~~~
_bxg1
Good to know!

------
lkrubner
EDN is a brilliant literal for data, and since it offers more types than JSON,
I would love to see it catch on in the places that now use JSON, especially in
APIs. JavaScript has a complicated early history and even though one can use
objects as a key value map, it’s not quite a map, in JavaScript. EDN does have
the advantage of being a clean implementation of its idea.

On a different topic, I’ve read that almost 50% of computer programming work
is just building database views and providing GUIs so non-technical people can
interact with databases. Making this work easy used to be a major goal of
multiple corporate products. One reason VisualBasic had such a devoted
following is that it made it so damn easy for novices to build a GUI for a
database.

In recent years the industry has moved towards HTML as the default way to
build an interface for anything on a network, but HTML continues to lag when
it comes to forms. You have to use a mountain of JavaScript to get the form
functionality of VisualBasic. We’ve actually gone backwards on ease of
creating database GUIs. Yes, in theory you can use something like React to
build forms, but the dev using VisualBasic would be done with the project
while you’re still waiting for npm to finish downloading your dependencies.
And React requires more skill. VisualBasic had a wonderfully gentle learning
curve. Likewise, Ruby On Rails (and other frameworks including Symfony and
Django) have scaffolding that allows the fast construction of HTML forms, but,
again, HTML is a limited method of building forms.

I’d love to see Clojure succeed in this space, building corporate GUIs for
databases. How to do that? Is a new GUI technology needed? Towards that end
I’d love to see EDN used as a config language to define a scaffold for forms.
There are elements of Swing that worked well and could be rescued from the
larger wreckage of Java GUIs. And JavaFX represents a huge “road not taken”
for the whole industry.

The tech industry has had eras when it focused on opening the door to
beginners. Those eras gave us HyperCard and Flash and VisualBasic. Right now
the industry seems to be undergoing an episode of gatekeeping. We are
requiring beginners to learn React, which is a big eco-system, and also stuff
like Docker, which is tough for beginners. The point of making so much tech
mandatory for even simple projects inevitably keeps some people from
discovering the joy of programming.

Clojure is the most fun language that I ever worked with, and it’s
conceptually simple and it has EDN as a data literal language, all of which is
a kindness for beginners. If it also had a simple method for building GUIs I
believe it could help lead the industry into the next era when we again focus
on making programming accessible for beginners.

~~~
pcr910303
> I’d love to see Clojure succeed in this space, building corporate GUIs for
> databases.

Looks like you’re finding HyperFiddle[0].

Quoting from the website:

> Low-code databases, developer-grade

> Hyperfiddle lets you make lightweight database applications out of just
> database queries.

It’s Clojure based, uses the EDN notation, and doesn’t require writing a lot
of code. It basically translates the Datomic database[1] queries into tables
(which can be exported to react components and styled appropriately).

[0] [http://www.hyperfiddle.net/](http://www.hyperfiddle.net/)

[1] [https://www.datomic.com/](https://www.datomic.com/)

~~~
lkrubner
No, Hyperfiddle is exactly what I think we need to get away from. This is from
their introductory blog post:

" _For a high-end UI, use React.js. The above cryptocurrency invoicing MVP
generates QR codes using a javascript module from github. This blog post is a
hyperfiddle and includes React.js components, CSS, HTML5 video components,
mailchimp & twitter integrations_"

Hyperfiddle is basic scaffolding of the type we've had for 15 years thanks to
Ruby On Rails. I'm suggesting it would be good if we could get beyond this
level, since we have been stuck at this level for a long time.

Hyperfiddle does use EDN for configuration, and I really like that part of it,
but it's still using HTML, which, as I said above, doesn't give us the form
functionality that VisualBasic did.

------
Taikonerd
I'm glad that Clojure users seem happy with their language. But it seems like
a worrisome sign that their survey has roughly the same number of respondents
year after year...

* 2020: 2519 responses

* 2019: 2461 responses

* 2018: 2325 responses

* 2016: 2420 responses

~~~
Scarbutt
Because with modern Javascript you get most of the niceties of Clojure
(immerjs for immmutability, lodash for data processing, babel for macros)
without the disadvantages (no job market, no ecosystem). The debuggers in JS
are so good that you don't need the Clojure repl. JS under v8 is also faster
at raw processing(single thread but there are also workers now) unless you
write Java with parenthesis, which at that point, you are not writing clojure
anymore.

OTOH, Rich Hickey has influenced(in good way) a generation of programmers and
doesn't get credited enough.

~~~
emmanueloga_
Debuggers are not a replacement for REPLs. The magic of the repl is to be able
to recompile and reload exactly one function or form, for instance. Even if it
is really fast most JavaScript setups require recompiling a whole file and
likely reloading the whole page to test.

Clojure also has debuggers: you can debug from either Cider or Cursive, for
instance. I'm not that familiar with debugging outside of those two though.

~~~
iLemming
> Debuggers are not a replacement for REPLs.

Nothing is a replacement for a good, "true" REPL. Being able to evaluate any
[sub]expression, without any kind of ceremony, anytime, from anywhere in your
code is incredibly liberating. Who never used Lisp seriously, would never
understand how amazing that workflow is.

I think REPL is the main reason why we still have Lisp dialects. After over
six decades Lisp is still alive and thriving.

~~~
emmanueloga_
True! For a long time I was looking for the mythical "livecoding" setup,
thinking some experimental programming language was needed or something, when
all the while Clojure was there, just waiting for me :-)

In that way I feel Clojure's defaults to immutability go a step beyond what's
offered in most Lisp's setups. Not everything "just works" though, thought is
still needed in order to have certain things be easily reloadable. I'm talking
things like using "defonce" forms and having a setup like described here [1].

I'm still exploring this space but I think the gist of it is to create a
direct acyclic graph of dependencies, so you can start and stop exactly what
you need, not unlike what build systems do.

1: [https://lambdaisland.com/blog/2018-02-09-reloading-
woes](https://lambdaisland.com/blog/2018-02-09-reloading-woes)

------
lvh
It's really unfortunate that the Clojurians Slack, being free, lacks good
history. So much knowledge is disappearing, or at least becoming inaccessible
(I'm sure someone has logs, probably via alternative clients or bots).

Hard to move a community though.

~~~
comma_at
The clojurians zulip chat[1] offers a free, full-text-searchable archive of
slack.

Also, IMHO it's much better than slack for chatting. If only everyone
switched!

[1] [https://clojurians.zulipchat.com/](https://clojurians.zulipchat.com/)

~~~
pepper_sauce
It's probably me but I can never seem to get Zulipchat to work for basic
things like pulling up the history of #jobs.

~~~
seancorfield
[https://clojurians.zulipchat.com/#narrow/stream/180378-slack...](https://clojurians.zulipchat.com/#narrow/stream/180378-slack-
archive/topic/jobs)

Or you can search (/) and type stream:slack-archive topic:jobs

------
peferron
I started writing Clojure professionally last year. It's an incredibly
relaxing experience. I attribute that to most of the code being pure functions
that operate on plain data types (maps, lists), combined with the delightful
experience of structural editing.

My largest issue is spec.alpha, which is far from perfect. spec-alpha2 should
fix many of my complaints, so I'm looking forward to its first release.

------
rubyn00bie
It's hard to want to choose Clojure when it's hard to know where to start. I
saw "CojureScript" followed by "ColjureCLR" and just blacked out... I'd like
to learn a lisp and I hear clojure is the jam, but seeing that ecosystem
exists, while flexible, makes it seem like 90% of it will be learning the
tooling and not the language... It just makes me think "hmmm. I need the JVM,
might as well use Java... at least it'll be predicatable straightforward, and
EXTREMELY well documented, in it's convoluted-ness[1]"

Can someone please sell me, or assure me, otherwise?

[1] Which is also high... I can barely get a JVM project running these days
with the plethora highly foreign of build tools, IDE
dependencies/configurations, and language settings. Maybe that's just par for
the course in 2020 on the JVM, with great power comes great complexit?

~~~
emmanueloga_
There are all sorts of bells and whistles you can choose when it comes to
Clojure, but I would recommend you focus in one thing for a start, just plain
Clojure with the JVM.

Download a Clojure jar [0], the following command opens the REPL:

    
    
        $ java -jar clojure-1.10.1.jar
    

... you can also run the file you are editing:

    
    
        $ java -jar clojure-1.10.1.jar file.clj
    

... that's it! You can go a long way just like that, the start up time of
running scripts is not that bad.

Gradual improvements:

* Perhaps install a clojure package [1] instead of using the jar. The jar is nice to understand the main Clojure compiler is at its core just that, a Java program... but the package installed with brew or apt will probably (depending on your OS and how up to date the packages are) also give you a global `clojure` or `clj` command that you will see around in tutorials. Just makes it easier to follow the tutorials!

* Use rebel-readline [2]. Just follow the readme!. It gives you a nice coloured command line REPL with all sorts of cool features, but you don't need to make use of all of them at once. Take your time!

* Choose an editor with good integrations. Obvious choices: VSCode+Calva extension, IntelliJ+Cursive, or Emacs+Cider. The main thing about having a good integration is the instantaneous feedback of sending chunks of code to the REPL, although for a slow start you can do the same just copying and pasting code from the editor to the REPL!

About books: I read 3 or 4 different ones... most books I read were pretty
good, some of them are available online for free! Confidence comes from
writing lots of code mostly, though, not just reading. I'm not proficient
enough yet that I remember the APIs yet so books help to gimme a cohesive
roadmap of things to learn.

Suggested little "project": I also found this library [3] that is cool to play
a bit with random things to produce some graphical output. It is a wrapper
around Processing.

Good luck!

Caveat: there are many ways to do teh same thing. This comes from a focus on
libraries over frameworks. Also, the whole JVM API is available to you so for
a lot of things you are supposed to just use the Java APIs. Don't bother about
wrappers or clojars for a start, just call Java from your clojure. Is fast,
fun and easy! :-) Pick one way of doing things and do it for a while... even
if it doesn't give you the "fullest of the performance" for any given task, it
will be an OK vehicle for you to learn and get familiar with the ecosystem.
Classical example: http servers.

0:
[https://repo1.maven.org/maven2/org/clojure/clojure/1.10.1/](https://repo1.maven.org/maven2/org/clojure/clojure/1.10.1/)

1:
[https://clojure.org/guides/getting_started](https://clojure.org/guides/getting_started)

2: [https://github.com/bhauman/rebel-
readline](https://github.com/bhauman/rebel-readline)

3: [http://quil.info/](http://quil.info/)

~~~
puredanger
You can't actually use the Clojure jar like this with java -jar as it has a
couple of dependent libs (spec.alpha and core.specs.alpha). But getting
started with the `clj` tool is just as easy.

~~~
emmanueloga_
My bad! I tested it my system and it worked, but I'm sure I have the jars in
the classpath already because I had already installed Clojure through a packet
manager.

So! Clojure 1.8 still works without dependencies for trying the jar [1].
Otherwise, I'd skip to installing 1.10 through the system installer.

1:
[https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0/](https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0/)

~~~
bmillare
See my post above, just build the clojure jar yourself using the ant
instructions, and it will be portable again.

------
didibus
Clojure is hands down my favorite programming language till date, and I've
used a handful at this point. Got professional experience with C++, C#,
ActionScript 3, Java, JavaScript, Scala and Clojure. And I've toyed with
Python, Kotlin, Rust, Haskell and Elixir a fair bit. Still, I'd say Clojure is
my top. Its just well thought out, to the point, and so fun.

Wish the core team many more years of work, and I hope the ecosystem stays
afloat, and prospers.

Also, kudos to never breaking my code! That quality is so underappreciated.

------
dmitriid
This survey reinforces a positive feedback loop. "Clojure is great because
Clojure is great".

For a " _state_ of X" survey it would be nice to see questions like "what are
the biggest hurdles, problems, issues". For example, State of JS drills down
to language features, syntax, overall happiness, frameworks etc.

E.g. the author of Rum and Datascript re-wrote his ICFPC submission from
Clojure to Rust and gained 17x speed increase [1]. This could be something to
poll.

[1]
[https://mobile.twitter.com/nikitonsky/status/114850460921383...](https://mobile.twitter.com/nikitonsky/status/1148504609213833216?lang=en)

~~~
lemming
There actually is a question in the survey, "What has been the biggest
obstacle to using Clojure?", but it's not highlighted in the blog post.

------
gherkinnn
The question for me is where do I find remote clojure jobs? Playing with it is
all fine and all. But how about making it a full-time thing?

Most job boards have next to no entries and clojure boards are mostly US only.

------
gdsdfe
Any clojure shops in Montreal? Or Canada in general?

~~~
rfrey
I think yogthos (author of Web Development in Clojure (book) and Luminus (web
framework) is in Toronto and leads a gang of clojurists.

------
int_19h
Is Clojure ever going to treat Windows as a first-class platform?

[https://github.com/clojure/tools.deps.alpha/wiki/clj-on-
Wind...](https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Windows)

"Currently, clj on Windows is in an alpha state."

~~~
Volundr
Leiningen is well supported on Windows, I can't speak for boot. Clojure has
only had built in command-line tooling since 1.9, and the whole thing is still
considered alpha.

------
qu4ku
Clean Code, Episode 0. The Last Programming Language by Uncle Bob (Robert C.
Martin) — worth watching for those who need reasons.

[https://www.youtube.com/watch?v=Z5p5r9FWrpU](https://www.youtube.com/watch?v=Z5p5r9FWrpU)

------
gdsdfe
Some people say that their organization have 100+ people using clojure? Where?

~~~
d4mi3n
The company I currently work at, FundingCircle, hosts the SF Clojure meetup
and uses Clojure for a number of accounting systems.

I’m not a huge fan of the language myself, but it does have it’s strengths.

~~~
gdsdfe
I guess you mean FundingCircle? How many devs on clojure?

~~~
d4mi3n
It changes over time with new hires and attrition, but by my last count
somewhere between 30 and 40 in the SF regional office. There are more in other
regions, but I'm unsure as to the total number.

------
gdsdfe
Where do people find Clojure jobs??

~~~
ivarv
The #jobs channel in Clojurians slack (
[http://clojurians.net/](http://clojurians.net/) ) and the sites on this list
[https://purelyfunctional.tv/guide/clojure-jobs-
resource](https://purelyfunctional.tv/guide/clojure-jobs-resource) are great
starting points.

~~~
gdsdfe
thanks!

~~~
ilikehurdles
I've also found them on LinkedIn and angel.co in the past.

------
zerr
Isn't Clojure an extremely unpopular language (outside HN)? I mean, it's not
even in the top 50 in TIOBE index.

~~~
puredanger
TIOBE is garbage. It is primarily based on google search hits. Red Monk's
ratings are based on github and stackoverflow (which Clojurists actually don't
use much) and typically has Clojure around 25, which I think it is a
defensible ranking. Best estimates of devs using Clojure are 20k-50k (based on
multiple sources, some public, some private).

~~~
ilikehurdles
Wow, TIOBE has Object Pascal, Assembly, D, and PERL in the top 20. Also,
MatLab over Objective-C. Meanwhile, Typescript is at 46, well below Julia,
COBOL, Ada, and Rust (don't get me wrong, great language, but I'd be surprised
if it was more widely adopted than Typescript).

Its method for ranking seems problematic.

~~~
ChrisRackauckas
It has been shown that TIOBE tends to not be very robust. If you change the
metric from searches of "X programming" to "X language", you can can swing the
results of many languages up or down by 20 spots.
[https://juliacomputing.com/blog/2019/09/16/tiobe-
blog.html](https://juliacomputing.com/blog/2019/09/16/tiobe-blog.html)

