I recently undertook a serious effort to learn Angular.js for a work-related project. After some time, I reached the point where I think I finally "got it", and I was feeling pretty good about Angular.
Then I did a bit of work with ClojureScript and core.async. WOW! The difference is night-and-day. Even with ECMAScript 6 generators, vanilla JS will have a hard time competing with the CLJS/core.async combo.
Of course, CLJS is very young (somewhere between pre-alpha and beta), and core.async even more so. For that reason, I don't think it's that unexpected that there aren't many people using CLJS exclusively...but I would not be surprised at all if this changes in the coming years.
Didn't see this survey in time to contribute, but I'm one of the tinkerers who's used CLJS more than Clojure. Most of what I've been interested in doing is in-browser. For my last project[1] I used a regular Clojure REPL to clarify my understanding of the standard lib and paste in little functions for testing. Don't remember why I didn't use a browser-connected ClojureScript REPL. Maybe it just didn't seem worth typing "rlwrap lein trampoline cljsbuild repl-listen" when I can type "lein repl" :P
My biggest wish is for the ClojureScript compiler to be less accepting of stupid code. I've made all kinds of moronic mistakes[2] that would ideally yield a warning or even a straight-up error, right at the source, but they don't and I just end up finding data structures full of nils at runtime. I've also hit a few traps with lein-cljsbuild[3][4]. This is all definitely improving though.
I've now started my first real Clojure project, a web app built on Luminus[5]. Luminus kind of strikes me as training wheels for Clojure. It's easy to get started with, and minimizes the sense of foreign-ness coming from a Python web development background. But I doubt I'll still use it once I have more experience, as opposed to simply putting its component libraries (Compojure, Ring, lib-noir, etc.) into a project directly. Which is fine; it fills a valuable role in the ecosystem anyway.
The intent behind Luminus is that it's training wheels, but you're still using the "real" tools you'll use when you're making your own services. It's a way to teach people patterns without needing to reify them into a rigid and unnecessary framework.
I tried using Clojure to build my personal website. I love it, and can't wait to see where it goes next. However, the documentation problem is pretty real. Clojure libraries get updated and deprecated really quickly (because the language is so new) and tutorials on the web quickly get out of date. I had a lot of experiences where I would pick up a new library or framework because it was in a tutorial, only to find out that:
-It had been abandoned by its creator in favor of a newer framework.
-The functions used in the tutorial had been deprecated.
These are definitely just growing pains and not something intrinsically bad about Clojure. However, I hope that the next year or two bring more stability and more ease of learning.
One thing that I wish was better tutorialized is LightTable. I understand Chris Granger is a one man IDE developer and that LT is still in development. However, if we could get more tutorials from users like the one that was posted earlier today, that would be fantastic.
Eventually I ran into pedestal.io. Those guys have a great framework. It covers front and back end, and involves Functional Reactive Programming, something I'd never seen before. They have an excellent tutorial that they update in sync with the framework. It's a bit overkill for my personal (mostly static) website, but after taking the time to learn it I feel like I came away with a real new skill.
One last thing that struck me about the Clojure community is how many workhorses there are. Guys like cemerick, technomancy and Chris Granger (the guy behind LightTable) have been working fast to build TONS of stuff, and a lot of it works really well. In particular, Leiningen is awesome and I imagine (I've never not used it) that it makes the process of getting started that much easier.
It's a bit overkill for my personal (mostly static) website
Yeah, while you can use pedestal-services to create normal websites, it seems Luminus (or one of the others) would be better suited. Pedestal really shines when you build single page applications.
I don't have much time to drill down right now, but a quick search of the responses for "Name one language feature you would like to see added to Clojure" reveals 8/563 respondents wrote "Clojure in clojure" verbatim (disclaimer: I was one of those 8). The good news here is that this effort (in the guise of tools.reader, tools.analyzer, and tools.emitter) is very active and looks like it will yield many positive results in the near future.
(If you're curious why Clojure in clojure is important, in the recent Cognicast episode with Ambrose Bonnaire-Sergeant he give's a perfect example of how these tools make it possible to add a type system to Clojure.)
The libraries I mentioned are all located in the Clojure GitHub group (https://github.com/clojure/). Actually, the Clojure community has thus far done a very good job of keeping the core language relatively small and implementing the "interesting" bits as libraries. (Personally, the idea that Go-style/CSP concurrency is a language feature of Go, but can be implemented as a library in Clojure is rather appealing to me.)
As these are Clojure-Core libraries, I'm fairly certain you'd need to submit a CA before you can submit a pull request (details here: http://clojure.org/contributing). Probably the biggest help you could provide in the near-term, though, would be to find interesting uses for these libraries.
> “Staffing concerns” is new as the #2 reported frustration, which I think is significant: I certainly know that companies using Clojure have a hard time filling openings lately.
I'm profoundly surprised by this, and would have expected the opposite -- frustrated Clojure programmers wishing for opportunities to use the language in their day job. Is there a market failure here and can we fix it?
I'm curious if the issue with "lacking documentation" is an issue with explaining function inputs and outputs (like types would give you in other languages), expected behavior, or just bad discoverability for the long list of core functions.
When I was starting, I ended up just learning to read the function source because of the lacking documentation. It's a skill that has paid off in the end, but i'm not sure it was the best way.
I eventually found the cheatsheet and it remains useful to this day. But, my specific point was trying to dissect what survey respondents were looking for when asking for more documentation, because each item I listed has a different possible solution.
Documenting function inputs and outputs could use core.typed's annotations to enhance the docs.
Documenting expected behavior leans towards adding content and examples, where the examples can be manually curated or pulled from available opensource code. (Similar to getclojure.org, but bigger.)
Solving bad discovery could be approached by improving the search/organization/unification of the clojure.github.io, the cheatsheet, clojuredocs.org, clojure-toolbox.org and clojure-doc.org.
Totally agreed on the question. I have been trying to engage people more actively in the details of this question as well.
There are actually many, many documentation resources right now (seemingly enough for anyone to get started), so the question is really whether actual docs are lacking or just the right place(s) to start for specific kinds of docs.
"bad discoverability for the long list of core functions."
IMO it's this and discoverability of libraries for non-core functionality. The books for learning Clojure are all very good, but reading a book is a lot different than working down a tutorial.
Thanks, didn't know about that (the 4 books from Oreilly, Manning and Pragmatic are all terrific).
Another thing is if getclojure could get some pruning and discussion of corner/edge cases for each core function/macro/special forms (i.e. get some of the discussion from IRC of how/when to use the functions and maybe make it more hoogle-like)
>How would you characterize your use of Clojure today?
More than half of respondents are using Clojure at work, which is a big jump compared to the last two years, when only a third of respondents were so lucky. This is nothing but good.
People using Clojure in their work environment is a great thing.
If you're going to comment mentioning it, you should probably tell people what it is :)
For those who haven't seen it, Nightcode is a new, open-source Clojure and Java IDE written by the person I'm replying to. Has project templates, paredit mode, REPL and CLJS build integration. I only played around with it for 5 minutes and went back to Vim, so I can't really endorse it but it looks cool.
There were a couple of mentions of Nightcode in the 'other' field, more than votes for environments I did include in the main listing. I'll do my best to remember to add it next year and drop those that fared poorly this time around.
I'm glad the survey highlighted the issue with clojurescripts repl ease of use. I know for myself this is the number one issue I would like resolved. If I could interact with the browser in a painless way I would probably ditch Javascript as my primary browser language and push for it at my company.
Then I did a bit of work with ClojureScript and core.async. WOW! The difference is night-and-day. Even with ECMAScript 6 generators, vanilla JS will have a hard time competing with the CLJS/core.async combo.
Of course, CLJS is very young (somewhere between pre-alpha and beta), and core.async even more so. For that reason, I don't think it's that unexpected that there aren't many people using CLJS exclusively...but I would not be surprised at all if this changes in the coming years.