
State of Clojure 2015: Survey Results - jffry
http://blog.cognitect.com/blog/2016/1/28/state-of-clojure-2015-survey-resultsv
======
AlwaysBCoding
My $0.02 on the state of Clojure -

For building stateful UI's Clojurescript + Reagent beats anything else out
there.

For data science and algorithms Clojure beats anything else I've used.

For backend web development Rails is still miles ahead of any Clojure
workflow.

Datomic is interesting but there's still too much incidental complexity to be
super productive with it. It's hard to build a startup on Datomic because of
the pricing and productivity hit, but could see it being useful in the
enterprise where speed is less important.

I'm very interested in mobile development with Clojurescript on top of React
Native, but haven't found a tutorial that wasn't written in hieroglyphics, so
assuming that needs some more time to mature.

~~~
calgaryeng
> For backend web development Rails is still miles ahead of any Clojure
> workflow.

I feel the same way. And in my opinion, is a symptom of the "library vs
framework" culture that is present in the Clojure community. While that is
probably a good stance for the first 2 points in your list, in web development
there are just so many already-solved-problems that you have to re-work
without a framework.

Luminus looked good but seems to be shunned by the community.

~~~
gered
> Luminus looked good but seems to be shunned by the community.

Can I ask what left you with that impression? I've no idea if this is true or
not as I don't participate much in the Clojure community, I'm just genuinely
curious. I guess a bunch of people just use the lighter weight Compojure/Ring
templates that really leave you with an extremely barebones web app to start
with?

I used Luminus myself when starting out, but I feel that as you grow more
comfortable with Clojure web dev, you'd _typically_ end up putting together
your own Leiningen template more tailored to how you like to set things up (as
I ended up doing). But even still, I don't think Luminus is by any means bad?

~~~
nickik
Shunned is a strong word and I don't think it applies. I think Luminis is ok
for some things but by and enlarge most people doing webdev in Clojure prefere
to go a different way.

Saying it is shunned makes it sound like a whitch-hunt but that not the case.
I don't even think the community has an opinion on it. Most just dont use it.

~~~
yogthos
The main goal for Luminus is to address the problems that newcomers would
have. It's a batteries included template that sets up some reasonable defaults
for your typical web app. That's coupled with a documentation site that
explains how to accomplish different tasks using the platform.

Majority of the community are experienced Clojure developers, and have already
found their own preferred setup. So, it's not terribly surprising that it's
not the target demographic. Once you know the web stack, the libraries that
work well, and how to put them together, then it's easy to make an app that's
custom tailored to your needs. This is the primary reason for the libraries >
frameworks mantra.

However, as the comments in this thread indicate, there's clearly a need for
Luminus. Anybody who's new to the language and the ecosystem, needs a decent
starting point. Luminus is that.

------
hellofunk
I have been working in Clojure and Clojurescript full-time for 2 years and
feel blessed to have had the experience, and here is what I've taken from it:

1) It changed how I think about programming, big time. I came from Objective-C
and pre-2011 C++, and the functional paradigm blew my mind open. It is now the
first habit approach I have when working in any language.

2) I really miss types. While I understand the argument about "fighting the
type system", I'd still prefer to occasionally tweak my line of code to
satisfy an average type system like C++ rather than deal with the lack of
safety and clarity that functions with no type specification for input or
output provide. I've recently started doing much more in C++, but this time
the modern variant (where I'm using lambdas and the algorithm library all over
the place, thanks to what Clojure taught me), and it's been a wash of relief
to use my brain for things other than remembering what to feed a function I
wrote days, weeks, or months ago: just let the compiler tell me, verify that
I've done it right. The ability to quickly test an idea in Clojure is great,
but I feel like a large dynamically-typed code base is tremendous opportunity
for significant run-time problems, since no compiler has verified that a big
category of easy-to-make bugs aren't in there. I'm often having to look at the
actual implementation of functions that I don't want to study any more, just
so I can remember what types to give them, and what to expect back from them.
Run-time assertions and :pre/:post are great, but still not the same thing at
all -- and verbose, and added runtime overhead. I don't consider Core.Typed to
be the solution to this problem; really, this is something that should be at a
core language level, and Clojure is dynamically typed, that's its ball-game,
and that's fine for many folks. But I'm slowly moving on towards an
exploration of static languages like OCaml, Modern C++, and others.

That said, the elegance of Clojure syntax is extraordinary. I don't think it
can be beat. It is a joy to use. So all languages have their unique
characteristics. I've come to learn what characteristics are important to me,
and adjusting my workflow and choices accordingly. But I can't imagine the
programming landscape without Clojure.

------
muraiki
Clojure was one of the first languages I picked up when I started coding and I
really enjoyed using it. The instarepl in Light Table was a huge boon for
learning and helped to offset the infamous Clojure stack traces of doom. :)
However, I'd be very much interested in hearing more from people who have gone
from Java, C#, or another statically typed language to Clojure, particularly
in regards to designing, maintaining, and refactoring large codebases.

I don't mean to turn this into yet another static vs dynamic flamewar. I'm
just very interested in the patterns that professional Clojure programmers use
to help manage this complexity. I know that code in Clojure is normally
structured very differently than one would find in a more imperative or OO
language, whether dynamic or static. I also realize there are things
available, such as Prismatic Schema and Typed Clojure, to assist with these
problems.

Really, I'd love to come back to Clojure but the problems I run into in my day
job often have me thinking, "types would have made this so much easier." :( As
a result, I haven't given Clojure the time to really delve deeply into it. As
someone with limited time to try out whole new languages, I'd love to be
convinced to go further!

~~~
evanriley
Do you have any books/resources that you recommend to learn Clojure?

~~~
muraiki
I strongly recommend
[http://www.braveclojure.com/](http://www.braveclojure.com/)

~~~
kirang1989
Second this. Definitely a good beginner's book.

------
sotojuan
I wish I had the time to dive deeply into ClojureScript. It's the part of the
Clojure ecosystem that interests me the most.

Hope it keeps getting better—a lot of interesting ideas coming from there.

~~~
mej10
ClojureScript is awesome, and soooo much progress has been made in the past
year.

It has made writing browser based UIs so much more fun.

I am really excited about what is in store for it this year -- personally, I
am going all-in with ClojureScript.

------
brianolson
The first graph I saw was that a poll of Clojure fans shows they like the
language features in it. This of course fails to survey the people not using
it and why not, and what undesired features prevent them from using it or what
lack of features prevent them from using it.

~~~
puredanger
That sounds like a challenging poll to conduct.

~~~
fnordsensei
That's why it's always worthwhile to do some interviews to get the whys behind
the behavior. It's always a risky business to go entirely by quantitative data
and then speculate on the underlying motivation.

------
arh68
> _What is your company size?_
    
    
        ~44%    1-10
        ~26%   10-100
        ~17%  101-1000
        ~13% 1000+
    

Wow, that's stark. Huge tilt towards small businesses / startups. I imagine
the chart for Java tilts the other way, but I'm speculating. I guess this goes
hand-in-hand with hiring / staffing frustrations.

I'm glad the Cursive / IntelliJ IDE is gaining popularity; I think it's a
fantastic option for development. If you are comfortable with IntelliJ.. go
download it.

~~~
dmix
Not surprising really. Big corps always pick safe languages. Primarily because
they need a large recruiting base and middle-managers are typically career
oriented and therefore risk adverse.

~~~
timbuckley
Also, big companies tend to be older and change their tech stack less often.

------
jfaucett
How much does clojure take advantage of its hosted status? Can anyone who
builds clojure software for multiple runtimes comment? It would obviously be
extremely nice if you could program libraries once and have them run on the
JVM, CLR, and inside the Browser. In practicality how difficult/easy is it to
build cross-runtime libraries and how much reuse can you get out of clojure
libs b/c of its hosted status?

~~~
147
There's cljc which is a conditional reader that lets you code in clj and cljs
in the same file.

It's not that difficult to write a library that runs on both.

But there are differences in the runtimes, of course.

Some examples:

[https://github.com/stuartsierra/component](https://github.com/stuartsierra/component)
[https://github.com/plumatic/schema](https://github.com/plumatic/schema) (uses
.cljx, the precursor to .cljc)

~~~
jfaucett
Nice examples. Am I correct in guessing that this code:

    
    
        (ns com.stuartsierra.component
          (:require [com.stuartsierra.dependency :as dep]
                [com.stuartsierra.component.platform :as platform]))
    
    

requires the correct platform.clj or platform.cljs depending on the runtime?

And that this:

    
    
        #?(:clj
           (defmethod clojure.core/print-method SystemMap
             [system ^java.io.Writer writer]
             (.write writer "#<SystemMap>"))
           :cljs
           (extend-protocol IPrintWithWriter
             SystemMap
             (-pr-writer [this writer opts]
               (-write writer "#<SystemMap>"))))
    

is how you perform different operations in a single file based on runtime?

~~~
147
The first part requires platform on both platforms. You are correct about the
latter.

------
j_m_b
Wasn't there a question regarding React Clojurescript usage? I don't see the
results for that.

~~~
puredanger
There was just the question about whether you use a React binding and that's
in the post.

------
vvanders
Link current shows a 404. Correct link is
[http://blog.cognitect.com/blog/2016/1/28/state-of-
clojure-20...](http://blog.cognitect.com/blog/2016/1/28/state-of-
clojure-2015-survey-results)

~~~
jffry
Whoops, paste fail. Good catch.

It looks like somebody at Cognitect has also added a redirect now. Sorry about
that!

------
votr
Corrected link: [http://blog.cognitect.com/blog/2016/1/28/state-of-
clojure-20...](http://blog.cognitect.com/blog/2016/1/28/state-of-
clojure-2015-survey-results)

------
pookeh
Quick note to HN readers: if you Ctrl+A / Command+A (Select ALl) you can
actually read the article.

------
overcast
I respect it's usefulness, but the LISP syntax just never worked for me.
(((())))))()()))(()))())) is not something I want to read and write all day.

~~~
mordocai
Have you actually tried it for a significant period of time?

Most (but not all) people who have used lisp for significant projects find
that they either like the parens or are simply neutral about them.

There are very few people I have heard from that have stuck through a
significant project in lisp and came out hating the parens still.

~~~
dragonwriter
> Most (but not all) people who have used lisp for significant projects find
> that they either like the parens or are simply neutral about them.

There's a substantial selection bias there in that people who have strongly
negative feelings about parens have plenty of opportunities in the field to
work with languages without them, so the only people likely to put up with
them on significant projects are ones who feel positively, neutrally, or
perhaps only _weakly_ negatively about the feature from the start.

That said, I do think the complaints about that particular feature are
overblown, much the way those about Python's particular whitespace handling
are.

~~~
rgoddard
I think this is related to the fact that our own internal parsers that have
been trained upon c-style code falls about when trying to read list code. So
the dislike is not due to the number of parenthesis, but rather our own
internal discord when trying to apply our existing mental parsers.

The only way to get around this is to spend enough time using the language so
that you can build a new mental parser.

