V
Error Messages
*
Clojure is a great language and I'd like to dive deeper into it. My one complaint is that error messages can be too vague and don't point you to the actual problem (which can sometimes be simple syntax errors).
*
Just give me the Clojure filename and line where the exception happened, please. I beg of you.
*
Seriously, error messages.
*
better error messages. please !
*
I'd love proper stack traces. Better than they used to be but a real blocker to development and makes it feel like a toy language.
*
Thanks for error message improvments
*
I appreciate all the work that's been done in improving error messages. Thanks to Alex Miller et al.!
*
The error messages in 1.10 are much better. Love being able to reference git deps. Thank-you for all the hard work that goes in to Clojure which makes my life so delightful.
*
Thanks for all of your hard work on Spec and the error messages in general (often caused by minor typos)
*
1.10 alleviates most of the problems I found with error messages. Since this was my single biggest concern I had with Clojure, I just want to say thank you for listening! :)
*
With the 1.10.0 release of Clojure, I believe this is the best general programming language available. The error messages have been improved so much - thank you! The design of the language is so well thought out and cohesive that my team moves release to release without even a hiccup. Thank you Clojure core team.
*
Great to see the improved error messages in Clojure 1.10 - it was my number one issue in all previous Clojure surveys, but not this one :-)
*
We're excited to switch to Clojure 1.10 for the new error messages! It has been really helpful to be able to communicate with Alex about tools-deps issues in Slack now that we have switched our org over. There are a few outstanding issues that still affect our usage, but overall it has been a great improvement in our workflow. We are also looking forward to the changes to Spec discussed in Rich's talk at the Conj last year. We use generative testing extensively. The "select" feature mentioned in the talk seems particularly useful when using a Spec to validate UI inputs. I'd like to thank Cognitect for all of their great work on Clojure. It has had a significant, positive impact on our organization and on my happiness as a developer. Thank you!
V
Spec
*
More Spec coverage, examples and tutorials.
*
Clojure spec tooling would be nice! Because it's hard to learn and visualize--and it's not obvious how to integrate it with normal deftest tests It has a massive amount of IDE integration potential though
*
It's been a great year for Clojure, even with some of the late 2018 backlash. I'm looking forward to the clojure.spec changes that are in the pipeline.
*
Spec has great potential, but really bad UX. If you are new to Clojure it's very hard to figure out what's wrong. Spec made clojure errors worse.
*
Spec should have better tool integration and more static analysis facilities.
*
Love the work on error messages and spec. Please continue investing in these areas! And thank you!
*
Feels like a couple of questions were missing "not important (yet)" or "slightly important" choices. It's not like I'm not interested in spec, it's just that it feels clunkier to use than Prismatic Schema and we're using it all over the place - the cost of learning a new lib + switching is pretty high at this point. We might eventually switch but not in the near term.
*
Really excited to see the direction spec is heading, can't wait to see the next iteration.
*
can't wait for new specs to be released :)
*
Great job on 2018's improvements! Errors are now much nicer, and I can't wait to use the stipulated changes to spec. Awesome work, keep it up.
*
Would like if CIDER would slow on new features and focus on bug fixes. Really excited to see upcoming improvements to spec based on Rich's 2018 Conj talk.
*
I'd really love spec to feel a little more complete. Based on some talks and comments by the core team I think there are some changes left to come, and I think there are some significant pieces missing around idioms to spec functions, protocols, and other parts of Clojure in a "standard" way. I've got a lot of love for spec as a project and use it heavily at work, but I feel it's shadowed at the moment by some ambiguity about what changes might be on the way.
*
Overall I'm very happy with the state of Clojure. Many thanks to the core team and community for their hard work. Specific other things I'd like to see are: 1. Releasing spec. I'm also very curious about seeing more details around the "maybe not" thinking. 2. Docstrings on specs. Whilst I understand the trend towards using data instead of API's, e.g. cognitect's recent AWS API. I think it's worth noting that the data oriented approach to APIs currently requires a different way to document your API, which is a problem. I appreciate spec partially answers this, but the lack of doc strings in spec is a problem for useful human facing documentation etc. 3. clojure.test runner integration with spec check etc. 3. Returning to some unfinished areas, e.g. transducers being parallelisable. Also it feels like clojure.core only implements some of the transducible collection functions, not all. Requiring the use of https://github.com/cgrand/xforms.
*
The LinkedData ideas in clojure / spec are cool :-)
*
Both spec and the clj tool are, to me, really not that important. I didn't have any pain points with Leiningen so the NIH syndrome that led to clj is pretty annoying. Spec is perhaps on the right track, but it appears like the community will have to fill in the gaps and make it actually useful for day-to-day use. Sticking a half-baked tool into the latest release that actually worsens the experience overall was a bad move. I never found Clojure's error messages that difficult to work with as well, but that's because I started my career as a Java developer. Improving the core of Clojure is far more important. Shocking start-up time means that day-to-day working with developing services in Clojure can be painful. Plus, it directly leads to the complex workarounds required for code reloading in the REPL, which stops me from using the REPL at all. I'm still very happy with Clojure overall, but it does feel like it hasn't progressed meaningfully since I started working with it 4 years ago. The problems I had as a beginner are still the problems now.
*
Thank you again, for all that you have given to us. Looking forward to the improvements in spec from “Maybe Not?”! I am certainly feeling the pain points they address, and currently work around them by generating heaps of variations on essentially the same spec per fdef.
*
I couldn't put my finger on it, but it always felt a bit awkward to use specs and had to juggle the spec and what the spec meant at a particular point in time during the flow of my software. Thanks Mr. Hickey for the presentation during Conj, it finally makes sense! I'm looking forward to the next iteration of spec.
*
I have high hopes for spec. Already using it in tests to much delight. Would love to see this done first. I would also like to take this opportunity to extend a sincere thank you to all involved in the development of clojure and related technology. Working with clojure profoundly changed my view on software development and returned my joy in coding. For that i am most grateful.
*
Thank you so much for an amazing journey, Clojure has been such a joy to use. I'm mainly looking forward to spec improvements and possibly more convenient aliasing (so that I can get rid of those empty namespaces that exist just for aliasing).
*
Really looking foreword to spec2 & hoping some of the "magic" from https://github.com/gnl/ghostwheel will make it into core.
*
Thanks to everyone in the community for another great year. I appreciate everyone working so hard to improve Clojure and the ecosystem. I can't wait to try the spec improvements Rich discussed at the conj. I haven't yet played with REBL, but it looks like it could become a great development tool. I'd love to see tooling improvement as it relates to spec. Specifically allowing docs for keyword specs and IDEs (Cursive) showing function specs inline and offering code complete based on specs would be amazing. I'm also excited to see what Ambrose does with the updates to Typed Clojure. Thanks also to Alex Miller for all his hard work managing the community and tools.deps! Here's to another great year!
*
There's a lot of new functionality coming out all the time. It's one thing to keep up with new functionality when I'm already on board and something completely different when one wants to get new people on board. If the language bloats any more it'll be really, really hard for newcomers. I would love it if you could take a deep breath, make a feature freeze and just finish spec. The community is waiting for it for far too long by now. I know it's a freakishly hard problem to solve given its scope and am happy to wait until the hammock solves it, but please refrain from adding new stuff into core until spec gets done. Otherwise it seems like a second class citizen, which it really isn't. I think it might help future adoption.
V
Docs
*
By far the biggest barrier to my personal adoption has been finding detailed tutorials for both Clojure and ClojureScript. There are things that scratch the surface but nothing that goes in-depth on problems like project structure, using anything-except-emacs as an IDE, how to properly setup your REPL workflow, etc.
*
Clojure is a real pleasure to work with for an experienced programmer, it's quite a leap from what many developers are used to. Whereas with languages like Scala you can slowly introduce the functional concepts, with Clojure you have to learn a new paradigm to really make use of the language, I think the documentation, tutorials and error messages are vital here to help people to make the jump into Clojure, along with learning to program using the REPL. It's challenging to learn but by far the best language I have ever used, it's a real joy to program in Clojure.
*
Concerning docs, I'm seldom able to really make use of the Clojure API doc. Since examples help me more to understand what a function does, I rely more often upon the examples provided by the community (https://clojuredocs.org). However, the quality of the examples vary and it would be helpful if there was a set of curated examples.
*
Data science topics and use cases (as alternative to R, Python, Julia)?
*
Clojure is great, but the main website, docs, examples and tutorials are not good. I would invest time in improving it as it has become a barrier for the langauge. also, i'd like to see comparisons versus other languages and whats different in clojure approach to concurrency, programming paradigms, etc... (to emphesize its super powers)
*
Understanding existing source code and its execution is a vital part of what we do. When our mental models are mistaken, underdeveloped, or otherwise insufficient, first-hand knowledge of actual execution can be a big help. We are not always in a position to structure the code in question (e.g. it's someone else's code and they cannot be consulted) nor have the tools or environment (e.g. the debugging features of Cider or Cursive) to support us. Built-in support would be welcome -- particularly something that lets us instrument existing code and not force us to modify source for just these sorts of purposes.
*
Very happy with the direction of the language. Please encourage more use of transducers by providing some excellent conceptual tutorials and examples for beginning to intermediate clojure developers.
*
It would be great if we have an IDE like racket since I also teach midschool kids programming using clojure.
*
I wish we had a better documentation generator and a better culture of documentation. I really miss the documentation in the Haskell ecosystem (and five years ago, I never thought I would be saying that!). For example, the Haskell community generally expects detailed documentation of data structures, including detailed asymptotics. E.g., http://hackage.haskell.org/package/containers-0.6.0.1/docs/Data-Sequence.html This complaint extends to many of Clojure's included features, too. Headline features like STM have incredibly sparse documentation (about one printed page with the semantics only hinted at), so I'm left guessing at what I can actually do with these things.
*
Learning Clojure and ClojureScript has been brutal. There is a serious lack of tools, everything seems to be homegrown and the documentation and feature set show this. The ease at which I could develop in Java is just mind blowing compared to Clojure. I admit, after a lot of pain and figuring out how to wire everything together it does work but I really need to consider what I am gaining from the extra complexity of this ecosystem. I am not convinced.
*
Even if we have some tools, there is no proper tutorial how to use them and how to start, so you always have problem and should ask people in chat and forum, that's sad :(
*
Clojure is a great technology (thank you) being not so greatly documented. IMO the coupling between clojure and its documentation is unnecessarily tight. Clojure itself is not a community effort. But the documentation could be. This way I'm basically giving a thumb-up to https://youtu.be/nrpsMB2gYI0
*
The experience of learning clojure is terrible. The lack of good documentation is the main reason for it.
*
IMHO, expert teaching --- more than anything else --- drives adoption of anything; all the way down from sophisticated languages to "intuitive" pinch-and-zoom gestures on iPhones. I'm not a qualified educator (nor a Clojure expert), but I've been at the receiving end of well-designed, well-aimed coursework; and the profound grey-matter rewiring it can engender. Clojureland has plenty of learning material these days; paid and free. However I have yet to come across a solid reference pedagogy that will help design curriculum to teach Clojure at various levels. Something that will assist local communities, professional trainers, and engineering teams either stitch together or create purpose-built learning programs. Can we, in short, attempt to achieve for Clojureland what exists in Racketland, albeit attuned to the industrial / hobby programmer's context? Here's a fledgling attempt to get non-Clojurists from zero to hobby-project-level; with a small but complete-enough subset of the standard library combined with a sane programming workflow, and a reasonable problem-solving mindset: https://github.com/inclojure-org/clojure-by-example/blob/master/README.md
*
The beginner support is exceptionally good. I think I would appreciate more intermediate to advanced support, in the form of books, courseware etc. to carry through to advanced Clojure.
*
As I'm just starting on Clojure/Clojurescript I noticed that there is a need to have more tutorials and guides to make the learning process easier and faster.
*
A few hopes for the future: - Tutorials explaining how to set up non trivial projects these days, including testing (backend + frontend), with the Leiningen, Deps, Boot, Figwheel (figwheel-main vs lein-figwheel). It feels like it's starting to get a bit fragmented, and hard to keep old from new. Possibly also explaining "here's how we used to do it", "this is how we do it now". I hope you get my drift. - Depricated parts of libs like core.async are removed (at least from doc). Not removing anything makes it harder to get the overview as a beginner. In essence: "Backwards compatibility" vs "barrier of entry" where here Clojure seems maybe too obsessed with the former, forgetting that there are new users not having the full history an ability to wade through the all the remnants of the past. Keep up the good work!
*
The community is too small. It's too hard to find info, common problems solutions
*
I think Clojure is awesome but it wasn't very beginner friendly to me even though I have prior FP(scala/ocaml) and scripting experience(python). I think there should be more resources for beginners to make them understand the basics and the mental image of the language. Keep on rocking!
*
You should redesign official clojure website to be better. Easy to read tutorial, Easy to know what the advantages of it like view.js or react something like that. Your website aren't interested for now
*
Thanks! * New Clojure features (spec, transducers etc.) all seem very complicated, and lack good guides explaining them in simple terms. I think spec might be useful for me, but I have no idea how to use it. Compare [1], which explains how to use TypeScript in two pages, with [2], which is pages of technical details on all features of spec but doesn't actually say how to use it in practice. I'd like a "spec in 5 minutes" tutorial! With lots of code examples! * For ClojureScript, there are so many REPLs that I don't know which to use. I'd like a simple tutorial that says: "X is the most popular one, here's how to set it up". * How do I use a ClojureScript REPL in conjunction with a Docker container? * For both Clojure and ClojureScript, I'd like more support in making larger applications. Either through language features (e.g. static typing), or maybe tutorials would suffice. Sometimes I feel like I get lost in my code, because it's difficult to see what is coming from where. [1] https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html [2] https://clojure.org/guides/spec
*
I love Clojure. The docs are phenomenal. The improvements to the ClojureScript site and getting started and the CLI tools have been huge. I still feel like it's difficult to "get started with" - primarily because of the Java world it's part of, but my love of the language - as far as I've experienced it so far - keeps me coming back.
*
Had trouble deploying/debugging cljs on Google Cloud Functions. Likewise, want it seamless to work on AWS Lambda. Better ability to simulate lambda usage. Maybe just some really good tutorials needed. Can it work well with the serverless framework?
*
Clojure is p great. I'd love to see a Clojure/lisp syntax 4 dummies type cheat sheet. As a developer coming from a OOP background understanding the syntax was the hardest part for me.
*
As a beginner I really struggle to understand the api docs. I tend to use third-party websites more often.
*
It will be great to know things like when to use a record vs a map etc. Intermediate guides would be nice. Also a guide on effective idiomatic clojure like golang provides: https://golang.org/doc/effective_go.html
*
Where and how does a new comer find the current most straight forward (simple, minimized) set of tools, installation instructions, and _verbosely_ explained tutorials for building a full stack application using Clojure, ClojureScript for web, ClojureScript for native, and optionally Datomic? Right now its dig dig dig, try try try. Once I sufficiently understand a complete defacto simple path to completion, I can then choose to wander off trying alternatives.
*
Add examples of usage in the API docstring, especially libraries like core.logic, such as the R language.
*
JavaScript has a lot of people advocating for it, and creating new tutorials, videos and courses. ClojureScript and Clojure have some of this going on but differently, and I don't feel it's as effective or appealing ... and that's a shame, because the language and ecosystem seem excellent. Maybe just hire Eric Normand full time at Cognitect to publish video tutorials? Or get someone at Cognitect to do a free Egghead.io course? There are so many great functional concepts on Clojure and ClojureScript, I think there's a big appetite for functional programming in the JavaScript world particularly, but it doesn't seem like the Clojure community is appealing to that audience, in the right places / ways.
*
Please work on improving the ease of use. The doc strings for the core language are third rate, poorly written, cryptic and unhelpful. The error messages (although presented more nicely in 1.10) are still the same terrible error messages as they have been for years. Please stop asking the community for patches and then not reviewing the patches.
*
I'd like to see documentation which explores tradeoffs and recommendations for common use cases. Essentially, recommending productive, well trodden approaches. This could be seen as an alternative to providing "frameworks" as code.
*
Regarding documentation: the ClojureVerse website, including the various guides and reference, needs a big update. Too many things missing/inaccurate. I can't help since I'm not knowledgeable enough. And it's source code should be documented.
*
Kindly if we can add more examples in documentation and provide more tutorial like scala school or elixir school for clojure for newbiess like me
*
It’s really hard to get started on your own without a mentor or teacher
*
Love working with the language. There are many ways to do the same thing but its hard to know which way is the best (more optimizations guides?)
*
While I do think there are some areas where Clojure can be improved (answered in Survey) Clojure is a tremendously enjoyable development experience. Given that I've worked with C, VB6, HTML\CSS, JS, PHP, Ruby, and Python and I choose Clojure above all means something. I am very grateful to the work you all have put into it. A possible area for improvement not covered in the survey is that there's a tone whether it's conscious or not that you're experts making tools for other experts to write expert level products. That is even in the communication coming from core team, especially in talks. Often there is a lot of expert-level-knowledge assumed from the audience with an air of "if you don't understand why this idea is good then you are lacking the education to appreciate it and use it effectively". I understand the simple vs. easy debate and largely agree with Clojure's leaning in that scale but it would be nice to see more empathy for beginners or people new to Clojure. An example of this would be in the REBL repo. It's a great product but it's not really clear how it fits into a workflow. My first question was how do I use it with lein & nREPL? After some trial and error I was able to get it working with nREPL but it wasn't clear that REBL is intended to replace those tools so that REBL is your REPL but the general tooling needs to catch up. It was rather between the lines and I didn't even catch on to that idea until Sean Corfield explained that viewpoint in the #rebl channel in Slack. In Clojure docs and communication you're often given A and C but B is either something you need to figure out, or you're expected to already understand that. An example of this can be found in the Clojure API docs. They are a bit terse and some the nuances of the core functions are not clear until you see examples of it in clojuredocs.org. On one hand I see nothing wrong with leaning on the community to help with communicating complex ideas to a broader audience but I do think putting a bit more effort into approachability will go a long way.
*
I'm only tinkering with Clojure but find myself heavily relying on ClojureDocs.org as the doc strings aren't enough.
*
Beginner experience still needs more work. Please consult with first-time programmers and teachers who teach them.
*
The ultimate guide for JavaScript/TypeScript to switch to ClojureScript is missing. Audience are ppl who don’t care about the JVM, who only know npm maybe webpack and who would like to use those libraries seemlessly. Shadow-cljs is a step in the right direction and should be officially adopted and a simple to use guide developed that doesn’t assume you already know Clj\Cljs idioms
V
Startup Time
*
hope startup speed should be improved.
*
This long-standing issue of startup time + poor runtime performance (out of the box, without tinkering) + insanely high memory usage is becoming the major drawback of the language for me (and us). We are planning to move to a faster language (probably rust or go).
*
It needs to run as fast as java out of the box. Tight now it is between 3 times and 10 times slower using “idiomatic” clojure and that is really unucceptable
*
clojure would be my ideal language if start up time (with dependencies added as I do need them) was under 2 seconds. For now i prefer haskell/python/shell writing command line tools.
*
I use Clojure for Machine learning. With all the performance tricks (like using transients, writing all recursive fns, use core.matrix vectorz implementation, etc) the code is much slower than Python. It becomes harder to convince the business side that clj is the right solution.
*
Been developing in Clojure professionally (and personally) for 5+ years now and I still love the language. Hands down my biggest gripe for day to day work is startup time. I can't truly use it as a scripting language as much as I'd like to without improvements in this area when other languages like ruby are essentially instantaneous. Otherwise, big fan and will continue to use for larger, more complex backend services.
*
I would like to use Clojure (not CLJS) in AWS Lambdas for a side project but the painfully slow startup time prevents me from doing so. Improving startup times will do more than just improve developer happiness, it will make Clojure a much better tool for serverless computing.
*
Please fix startup time and make compiler codebase better
*
Please think about startup time. Thank you guys! You do great job! I'm proud to be a Clojure developer! Best language and people in programming ever!
V
Marketing/adoption/staffing
*
We'd all benefit from wider Clojure take up. I worry about the view from the outside looking in. Why is it not attractive to more?
*
I love it but are not enough people in there
*
My biggest problem after 1 year of intense Clojure learning / coding is to find a Clojure job as remote (because there are zero Clojure job in Taiwan). Regardless of how good I am at writing functional code, finding a remote job (outside of US) is hard.
*
Need more language marketing efforts to increase industry usage.
*
I've had to stop using Clojure professionally because I can't find work using the language.
*
I use clojure a lot less than I would like to...
*
Love the language. I use it primarily for hobbies but see the utility getting better all the time. I'm looking to sneak some graphql/lacinia/pedestal in at work.
*
1) Thanks to the core team for the great work on 1.10 2) IMHO the clojure.org web site needs a radical overhaul in terms of friendly / joyful content and usability: - provide more about its awesome features - provide more about how to directly get going with its awesome features - it should be possible for users to enter / evaluate Clojure on the web site directly (like every other FP language - even the statically typed languages!) - there should be less emphasis on the defensive / justifications (they could be in a `history` section perhaps) for the language to exist
*
very passionate evangelist 5+ years -- surprising how hard it is to have some folks even consider. rubyists are particularly baffled: "ok what do you mean repl driven -- we have pry!", etc.
*
Overall .. a big fan of Clojure. I just wish it did not have the "java" requirement. It makes it difficult to put the "foot in the door" ... "it's cool, I have to show you - can you install java on your machine though?" ... also the startup time is off-putting.
*
More tutorials for novices. More visibility how productive Clojure is.
*
I co-founded startup company and we picked Clojure as our primary language and are very happy with the decision. A nice note is that almost no one of our hires knew clojure before and they all learned it quickly and like it! So I don't see a lack of clojure talent a concern at all. As long as you bring good people and make them solve interesting problem :) Thank you guys!
*
Is clojure still relevant?
*
Its been fabulous year for me with Clojure. Successfully pushed my micro-service in production for enterprise software which will complete a year now in couple of months. Trained team. My team has added features to it over the period of last 6 months and are now happy, sick Clojarians! I am more happy that I have infected another product in my company with Clojure. Have snuck in (JVM based company makes it easy) their product (replaced core module with few files and generic data driven program). They are working on March production date now. They still can't believe their legacy code is dismantled and meeting customer requirements which were not possible earlier. One more thing, Specs is really useful and solved a key problem for us. And with gen tests as feature on top of that is like super power. Keenly looking forward to its future versions. Thank you Rich Hickey! Thank you Clojure Community! nothing but gratitude :)
*
Thanks to Clojure and ClojureScript I can make a living building and maintaning large systems and delivering complex solutions on time. Thank you!
*
At Magnet we are betting hard on the Clojure ecosystem. In 2019 we will contribute more than ever. We are also planning to release Hydrogen, a web framework on top of Duct. We will also deliver full-stack product verticals in Healthcare, Manufacturing and Agriculture. Clojure API for MXNet is also important for us. https://github.com/magnetcoop https://bitbucket.org/magnet-coop/ Keep up the good work!
*
Clojure is thoughtfully designed and stable. It’s a dynamic, functional lisp that can actually be sold to the bosses. (A sentence I never thought I would write).
*
I haven't yet made major headway convincing my company to use Clojure/Script. I'm hopeful I can change that.
*
Great language, great community. I hope it gets more attention from the industry in the next years.
*
Less people to use clojure in china
*
Clojure is an excellent language but still has a low visibility.
*
clojure is a hard sell in organizations using more traditional hardware stacks. the barriers are very steep. I believe the only case where it works is if the language choice somehow evidences an order of magnitude improvement in some aspect of the application. I have not seen such a case in an entrenched application. In greenfield applications it is also hard to prove, because in any nontrivial development team, clojure is unlikely to be the common language. I used to think it matters less, but over time I have come to think static typing will greatly improve clojure's position. I am not sure whether it's a reasonable goal. spec may be partial answer, but in my experience using spec, it requires more effort than simple type declarations to maintain, so I usually am too lazy to declare specs. TypeScript is the best gradually typed language I have used and think it is the model way to proceed. That said, since node/browser have typed development through TypeScript, cljs + typescript + js + others in a mixed language, single target environment has been very productive and enjoyable.
*
Love the language. IMHO still the best designed programming language out there, despite the original sin of the JVM. I feel the pain of some of the recent quarrels - I get that Clj is for expert developers. But even expert developers typically have to work in teams with managers, and you can't be the only one in your team to do Clojure. I've tried for years to push for adopting Clojure in my large enterprise org, as it would be perfect - we do tons of JVM and have lots of interested people, many of us love functional programming and Lisps. But if just one newbie says "Oh I tried it once and I didn't get it", that means the project is a no-go for Clojure in the eyes of management. They're not willing to take the risk, even if 3/4 of the people involved know Clojure pretty well or could get up to speed in a few weeks. Error messages. Please. Good tutorials for basic stuff - I don't need transducers for now, I just need whatever Spring or Rails does in Clojure. How do I make a basic web app with security in place? REST API with React/Reagent SPA? Just basic bricks. I can figure these things out, but my co-workers who don't love Clojure don't have the patience. They google for 1 minute and then conclude it's not worth it. Have you tried Elixir? Even failing at Elixir is fun. The compiler is so helpful. The error messages are nice. There are defaults for everything. Oh yea, default choices - a beginner is incapable of searching and evaluating libraries. IT IS THE RESPONSIBILITY OF THE CORE LANGUAGE MAINTAINERS TO LEAD A BEGINNER TO POTABLE WATER. Later I'll happily find everything myself, but as a beginner I'm just not experienced enough to make these judgements. Ruby? Rails. Elixir? Phoenix. Java? Spring. Just tell me what to do. I'll know how to stop listening once I'm advanced enough.
*
Would be nice with more focus from the community, on how Cljs is a viable alternative to JS. What JS people love: - immutability (through libraries) - data driven (everything is just JSON) - functional - repl
*
Clojure has a great community and great technology but it would be super helpful in selling the language if there were more efforts put into marketing the language and perhaps having "blessed" solutions using Clojure from Cognitect; similar to what Lightbend does with Scala.
*
Currently trying to adopt Clojure in my company, we are 100 developers and my goal as of 2019 is to snuck Clojure into the codebase. Would be great with more companies sharing their usage of Clojure (Such as Klarna! in Sweden).
*
2018 was a good year. Error messages finally got a big boost, and has helped even us old timers in figuring out what went wrong. I feel there has been a greater acceptance of Clojure(Script) this year as I finally managed to convince my company that this is Good Stuff™. People are listening, and it's (slightly) more than out of polite interest. As with all communities there are ups and downs, but I was a bit saddened by how Clojure sometimes get treated by the crowd that loves static typing. Finally, can someone please build a document database that uses EDN as the default data format? Every now and then I come across situations that warrants just being able to dump data, but JSON now feels so wrong :(. Happy user of Clojure since 2012 and as part of the silent majority I wish to send a greeting to Rich: Keep on rocking. Clojure made me no longer wanting to switch career. - Emil
*
Thanks for everything y'all do! Four years in and still very happy with clj/s. It would be *highly* unlikely at this point that I would take a job that wasn't primarily clj/s. It doesn't stop me from using clj/s more, but my biggest worry is long-term viability. It'd be awfully painful to switch to something else at this point; no other lang I've tried has been as joyful of a development experience.
*
Thank you for all the hard work you all have been and continue to put into Clojure. We've built our entire new startup on Clojure, and was able to hire an amazing team within just a year by tapping into the local, tight-knit community.
V
Language
*
The missing of a usable full stack web framework like Grails, Django or Rails et co. for the Clojure ecosystem prevented us doing many quick web projects using Clojure, hence the Clojure adoption practically dropped over the years :( . Since http://arachne-framework.org/ turned out to be a total failure, many teams just dropped Clojure :( .
*
Complex Java interop shouldn't be so hard. If all you need is to call a Java function, there's nothing easier. When a defrecord is enough for your interop, that's great. proxy and reify are fairly convenient, although I have now listed three completely different ways of creating Java classes, and I haven't even mentioned deftype (ugh), and ... gen-class. I understand that gen-class has to do a thousand different things, but it's still horrible. However much Rich et al., and I, dislike common Java styles, they are legitimate within the Java community, and Clojure programmers will have to deal with them someday. In my case, the only library that does what I need is heavily based on inheritance, and I have had to coordinate four or five sets of definitions in different parts of my code because of Clojure's unfriendliness to what, from a Java point of view is a quite well-designed library. (I personally wouldn't do it that way, but I can't fault the lib's architect.) I finally wrote a complex macro to coordinate all of the definitions (yayy macros!), but it's ugly. I would love it if Java interop were completely rethought, with a few more intelligible functions replacing the existing smorgasbord. (I don't have a design for this, but I have faith in you folks!) A better design would make documentation easier. Some kinds of interop are wonderfully easy, but other kinds involve poorly documented black arts.
*
ClojureScript namespace definition <-> :require <-> macro & reader conditionals - and how these interact with each other is seriously non-trivial; especially so for macros you intend to use in Clojure too. Simplification thereof would be welcome if possible.
*
Please spend time improving clojure.test.
*
When I dream, I dream of seeing a slime-style backtrace in clojure.
*
A couple things I would like to see: - better way to write actual data structures. If you are in set/map/vector land it is easy to write code. Writing your own `deftype`s is unpleasant to me though. It is quite verbose. It is difficult to find an easy reference of Protocols/Interfaces and what they provide. It is difficult to find the actual important code for your particular data structure versus the implementations for ILookup, next, rest, nth, etc. I wish it was easier to write data structures. - I wish the community fostered more "neat" things. I look back at old slack history and see tellman, brandon bloom, and others figuring out macro expansion, talking about weird neat features, libraries or experiments. My favorite blog post ever is carin meier's chemical programming posts. Just fun, explorative, and innovative. Makes Clojure feel more "lispy" and a natural language to explore new ideas. I'm not sure how Cognitect could help bu tthis is my feeling about the state of the community. - I wish new features were discussed more openly by the core team. A roadmap, their thoughts, or experimental branches would be great to see.
*
It's thanks to Clojure pragmatic approach that today I'm using a Lisp at work, this is awesome. However, I feel ready to look beyond the opinionated and somewhat restricted view (whatever Rich is up to) offered by Clojure into more traditional Lisps. Clojure will continue to be my goto language for commercial use for a very long time, but job permitting, I'm going to use other Lisps as well.
*
3 year professional user now, and I am more and more convinced that this is THE language to Get. stuff. done. Whilst staying maintainable. Revelation.
*
My main struggle to get started was the dependency on Java knowledge that I don't have
*
Overall very happy. I'd like to have better stories around data science and charting, but I plan to push on that myself with others in the upcoming year.
*
Please, take a look once again at Dunaj Project or similar ideas. I believe that the community still have many great ideas which could be adopted by Clojure and wouldn't bring up any breaking changes. And we need better IDE for sure.
*
Clojure is the least bad programming language we available in 2019
*
Multimethods should be able to dispatch like protocols so that one can use multiple dispatch when there are several relevant protocols. Clojure should take account of all the available protocols when picking a method to run for Java interop: if a record implements some methods through a class and others through one of the class’s interface, one of the two sets of methods will be picked and the other will cause no such method errors.
*
The more I use clojure, the smaller the subset of it I actually need and now I think the standard library is too big. In my opinion, the core team should focus on hardening the existing features (bug fixes + perf improvements + solid documentation) instead of publishing half-hammocked ones.
*
Both 1.9.0 and 1.10.0 have made a huge leap in the right direction. Keep on the good work.
*
Clojure needs some kind of idiomatic error handling or more tutorials on this. Try-catch looks like Java. Either-like approach is not very usable due to dynamic typing without static compile time checks.
*
This past year I was slightly frustrated by: * The compilation issues related to Java 11; I would have hoped that some changes to 1.10 could have somehow ameliorated these problems so as to prevent working code from breaking (failing to compile) on Java 11. * The slow progress on improving compatibility with GraalVM. * The lack of integration (convenience hooks or something) between Clojure.test and spec.test/check. It just feels like a missed opportunity. In general though I continue to be thrilled with the state and direction of Clojure. Thank you for all your hard work!
*
Love Clojure and ClojureScript! I can't imagine coping without Clojure's immutable data structures and data orientation. Also, CLJC is an absolute killer feature. Being able to easily share domain-related code is huge. Ditto with Transit.
V
Language Development Process
*
Grateful for the careful stewardship of Clojure and ClojureScript by Rich Hickey and Congnitect.
*
Thanks for a great language, a steady hand at the wheel, and a passionate community!
*
I would like to say big "thank you" to Clojure team, especially Rich and Alex, for their work, inspiration and thinking-driven development.
*
Clojure is Amazing and you guys do a FANTASTIC job!!! Ignore the critics and keep doing things just like you have been. Thank you for this wonderful language!!
*
I’d like to express my gratitude to the core team and extended community of contributors. I appreciate the design/development model as it stands today — as changes are introduced to the core language, I know they’ve been well-considered by folks who are thinking on an extended timeframe.
*
Clojure has strong opinions on how software should be built. It needs to keep those strong opinions as it's these opinions that differentiate it and make it attractive. Keep up the great work!
*
You guys are awesome! Would be nice to clearly add exception to EPL to state that compilation is not derived work of clojure compiler - I have seen enterprises being concern about this in past (big time). Also I for one appreciate the slower pace and more refined steering of the community (with somewhat tighter control of directions) - so far I think it is the right choice (though might not be praised by some & as a side effect some issues do not get addressed for years). But please please do not write any more (even "personal opinion only, I did not consult the other guys") inflammatory blog posts. No matter who is right or wrong divisiveness has never helped any community and won't be any different this time. I would counter that "OSS is about anybody", especially since anybody can turn out to be a customer paying for services or evangelist steering his/hers employer towards clojure ecosystem (we don't know that do we). Lets stay professions even under pressure (does not matter that XYZ person lost it for a bit).
*
working in Clojure for many years. love the language. with time learned to dislike the authoritarian views and direction of the top layer of the community. Scala had a lot of that (which I did before Clojure and is one of the main reasons I left it behind). Clojure started having it about 3 years ago. I hope it is going to go away since the rest (majority) of the community are great people. "There is no authority who decides what is a good idea." -- Richard Feynman I like that.
*
I find it really gutting that I don’t enjoy Clojure anymore and am looking for something else merely because of Rich’s behavior but it’s just gotten to the point where I can’t in good conscience bring people into the community anymore. Even Linus has had his moment of insight by now.. but for some reason Rich just won’t figure out that it’s not the children who are wrong.
*
The attitude of the maintainers and the "we're smarter, trust us" that pervades the Clojure environment is toxic.
*
closed core development and dissapointment with spec have made made many friends leave Clojure/Script last year. Let's make 2019 better.
*
Clojure appears to have become a company language, serving the needs of Cognitect. While no-one can begrudge the insiders who gave years of their lives to its creation, those outsiders who contributed and those of us who wished to enjoy it bemoan the capture and commercial imprisonment of this hugely valuable commercial/intellectual/engineering resource.
*
I fully understand it's entirely Core Team's project (or of Rich Hickey himself) and we're not entitled to anything at all, but the the whole situation is quite off-putting. While recent contributions (in documentation, as far as I'm aware) are being accepted in a more relaxed manner, other areas are still lacking - notably bug squashing/small improvements (tickets not being handled for years) and informing community about language development progress ("Inside Clojure" blog is a great start in this area, but it mostly focuses on tasks Alex MIller did himself).
*
Simplify contribution process. Maybe move it to Github?
*
I love Clojure, and an extremely grateful to Rich, Stu, Alex, etc for their continuing stewardship and work of this fantastic gift. With respect to recent kerfuffles about community involvement, I simultaneously understand and respect Rich's position, and I am also concerned that some very respected Clojure developers who have contributed a lot (IMHO) feel disconnected and may be drifting away from the community. I don't have any solutions or answers to this situation. I hope that everyone involved will continue to ponder and reflect on all points of view. I do not think the current trend is in ideal situation.
*
It is too hard to contribute to clojure.core (even just documentation!)
*
Clojure is fantastic and getting better. I am a little concerned that we are seeing significant developers leaving the ecosystem because of perceived insularity from the core developers - I think this loss will weaken Clojure's advance. More of a charm offensive is required.
*
I'm concerned that there is too much of a disconnect between the core developers and the wider community. I think the core team are doing wonderful work, and the direction and stability of the language are great, but I think a curated collection of recommended third party libraries would help a lot of teams. I think it would be great if the core acknowledged some of the work of Clojurists Together. I think the new clj-commons organisation is a great idea and I'd like to see it better promoted and supported. There was some unpleasantness recently about the core team's relationship with contributors, and I think this is mostly due to bad marketing / communication. I think we need to make it easier for developers to find the best libraries, identify appropriate design approaches, and build their applications. Overall I'm really happy with Clojure, loving the improved error messages, optimistic about the future of the language, but concerned about it's popularity, and lack of solid guidance in best practices.
*
I teach Clojure to a lot of new folks when ramping them up on the job. It's always a bummer whenever rookies ask about a surprising quirk of the language or the naming of standard library functions, and the best answer I can provide is "because Rich said so." Some more transparency about new language additions/ideas as they happen, and ideally a way for the broader community to feel like they can shape the language in a meaningful way, would actively grow the community. Driving away potential contributors with painful interaction models is a sign of uncaring and distrust, not rigidity.
*
I'm hugely grateful for all the hard work put in by Cognitect and other core contributors. I love using Clojure, I recommend it to everyone I can and it has helped me greatly over many years. Rich and others in the core team have taught me so much, made me a better computer scientist and programmer. I know it's stressful when someone won't stop saying negative things about all the free time you're putting in and the free work you're doing for them. But please, if someone raises an issue, let's not start writing long gists and throwing around accusations of entitlement. Some healthy discussion has been had and there's really no reason for us to start having a meta-argument about how terrible and entitled someone is for raising concerns in the first place. There's no need for everyone to weigh in, to take sides and state publicly how much they support Rich. I've lost count of how many times this has happened. I dream of the day that the Clojure community is large enough and mature enough that someone can say something negative, have some debate on the mailing list or elsewhere, and it doesn't cause a scandal! I *almost* marked 'Unpleasant community' here as one of the things that turns me off Clojure, but I fear this would be misconstrued. The unpleasantness, in my humble opinion, comes when the core Clojure team dislike something that someone has said or written, and the wider Clojure community then comes, mob-handed, to weigh in and shun the dissenter and state for the record how despicable they are. There's a great imbalance of power here. I hope all kinds of controversial topics continue to be discussed and that the community around Clojure grows stronger for it.
*
I found the whole it's about me thing a bit off-putting. I understand it but I didn't like it.
*
About the governance of Clojure by Cognitect: thank you all! You're doing it right.
*
Thanks to all working on Clojure. I especially appreciate the careful design work and attention to backwards compatibility. I might just be in a bubble but static types seem to be all people are focusing on today and it's really nice to see Clojure doubling down on dynamic typing (with spec etc.). There is a lot of things that can and should be explored in this space as well!
*
On the portability between dialects complaint about which I quibbled: we have done clojurescript frontends in the past which interoperated with clojure backends for to compute pricings and the lack of a portable bigdecimal, or perhaps the lie of a bigdecimal type on the clojurescript side, is an annoyance. I occasionally help onboard new developers to clojure and it should come as no surprise that the difficulty of getting someone new into a editor+repl environment in which they're confident and capable continues to be lamentable. I am incredibly grateful to be using a language in the care of such responsible and careful stewards. I understand some clojure developers have issues with the glacial pace of any progress of their contributions to the core. While I think I do understand their frustrations, I also understand the economic and ethical arguments presented by Cognitect, and frankly, I think Cognitect's position is the only way to hope to maintain a coherent open source language, at least without the largesse of a significant industry player. I'd like to specifically acknowledge the work that Alex Miller and Ghadi Shayban do to help answer the community's and particularly beginners' questions in various forums. I try to help out on occasion, but they are omnipresent, and our community is the better for their efforts.
*
Stop calling Open Source and start calling it Free Source. Even communities with BDFF are more open source and community driven that Clojure. Stop saying excuses like "Rich Hickey time is gold and limited", maybe you have to start rely on a group of person if he can't do the work, because losing the time to duplicate work, clj.deps instead of Leiningen, clj.spec instead of Schema.
*
Thanks to the clojure team! I very much appreciate all your hard work, and I hope you know that the occasional diatribe that floats around really doesn’t represent how most of us feel - that it’s a fantastic language which helped me stay in love with software engineering.
*
Love You all.... but it's also about us! ;)
*
The clojure core team is an amazing source of inspiration, but as much as its 100% Rich's right to manage the core development process as he pleases, the commercial viability of the language needs reassurance that bus factor 1 is nothing to fear about. Managing expectations in 2018 is about 10 years too late, please give a signal that the core team recognises not only that but how much the community is worth to clojure as a language before dismissing any critics to the (previously much unclear) contribution / lifecycle process. We all need a more inspired and collaborative attitude towards community as much as we already get it with technology to be able to keep our niche healthy. As a clojure meetup and conference organizer, I've personally pushed many people and companies in the past 9 years towards clojure, please help me out here.
*
Are there ways to donate to the further development of clojure?
*
I was a Clojure fanatic for several years. I still enjoy and respect it, but often reach for other tools. It saddens me when I think about the possibilities early on, and contrast them with the detracting factors at the time. I'm not sure they're all even still relevant, but I know at least a few are: - "Locals Only" mentality. There has been conversation in the community of the sort "open source owes you nothing". This is a poisonous perspective. Healthy projects appreciate their users and encourage participation. Are there "help wanted" signs now? There are calls for testing, but not many for building things together. - Tools and libraries that seem promising get abandoned, and may break your app or tool chain, so you spend more time working on environment or replacements then writing code. Seems to be a lot of one-person tools and projects. Single-point-of-failures. Clojure is an awesome language, and there are many great leaders in the community. It would be encouraging to have some type of push for increasing public engagement. See Node foundation or Cloud Native Computing Foundation working groups.
*
The community leaders (at Cognitect) needs to realize before its too late that like any software project the needs of the users should come first.
*
Very happy overall with Clojure and its community! Happy with the stewardship of Cognitect. Specific thank you to Alex Miller!! You are always so helpful in the various forums (Clojurians Slack especially).
*
I love the principled stand taken by the clojure/core team about silly arguments erupting in the "community". I really appreciate that the core is so well thought out and there is a valid resistance to adding "stuff" in there.
*
I love Clojure and I admire whole team around Mr. Hickey same as beloved community members who every day work hard to deliver something to our ecosystem. But recent comments and community issues makes me woried. I understand both sides and their view but somehow from beginning I feel that community and communication style is little to egoistic and arrogant. I have had deal with it before 4 years but after some life lessons I am not convinced with this behavior anymore. We all use Clojure* for living but money is not everything...
*
The relationship between cognitect and community and the business model should be seriously designed and for sustainable of clojure world.
*
Thank you for awesome work in what seems to be a more difficult year (2018) than usual.
*
Most of the reference documentation on the clojure website is incomplete. Would also prefer for a more community-driven development process at the least for non-behavioural changes to the language and tooling for the language similar to Go.
*
I love Clojure, I've been using it since 2009. I'm a huge fan of Rich. I would like to see Clojure's leadership grow up and accept the fact that it's gotten too big for this to be viewed as Rich's toy. Being dismissive of the important contributions of the community is unhealthy and unhelpful as well.
*
I appreciate Alex's insights into the Clojure development process, and what he's working on. I also appreciate the all of the core team's work that makes Clojure such a great language to use!
*
The BDFL approach is starting to wear off contributors and it is permeating in Cljs (my main targeted at the moment) as well, where I guess it should not really appear that much Many times patches or proposals are pushed back with zero or little explanation, or never reviewed. Maybe no feedback still IS feedback but I am afraid that in the long run the language will receive very little attention (apart from the awesome Alex Miller). Another big problem is Cursive, for the price not really up to expectations. The clj integration is aweful and bug ridden. Same for ClojureScript where it is not possible to launch a REPL using shadow, for instance. Talking about cljs, the fact that I was describing above is evident: shadow was born because of the stubbornness of both devs.
*
Despite all the hype on social media around the core team, and the lang‘s development, you all have my wholehearted gratitude and respect for your work. There is something to what‘s being said about friendliness and such, but my bottom line is, everyone involved in Clojure core - you‘re doing a great job! ✌️
*
Clojure was my language of choice for quite a long time, but all the recent developments in the community[1] and lack of clear _publicly available_ vision of the language's future alienates me greatly and makes me feel as an unwanted member of the community. Because of this I'm not considering Clojure anymore for any *new* development and don't really want to help growing the community by releasing new libraries/supporting existing ones, mentoring new Clojure engineers, speaking at meetups, or just simply recommending Clojure to people I know :( [1] Drift to being dogmatic and hostlie to any alternative thoughts community (or better say cult?), which started long time ago, reached unbearable level last year and I'm not interested in participating in any community even resembling a totalitarian one, even if the language itself is perfect (which Clojure is not). Disclaimer: my feelings are obviously mine alone and I don't claim it's the universal truth and "Clojure is dead", it's just my personal opinion.
*
A fan of Rich Hickey. I think his approach is what keeps the language compact, clean and beautiful. Although sometimes confrontational and frustrating for core developers, his system works and this (almost) one man effort of taking the language forward is deserves more praise than it gets. He and his effort is what stands between cluttering of Clojure (and prevents it from becoming yet another JS).
*
2018 was the year that Rich finally explained how he felt about the open source community around Clojure. For many this was disappointing, but I'm glad that he finally explained how he felt, because at least it is now in the open and people can make decisions with full information. Five years ago, Clojure could afford to lose key contributors because the language was growing and new people were coming along. Clojure is now at a very different place and position, and it's no longer growing at the same rate, or has the same mindshare. I've invested many years, and lots of time into the Clojure community. Up until this year, I thought I would have a long career with Clojure, but I am starting to look around at other language communities for ones that are a better fit for my values.
*
Thank you for giving me a fantastic language to use in my day-to-day. I appreciate your work tremendously, and there is a large non-vocal, supportive community that thinks like me. Please ignore and stop responding / encouraging idiotic Twitter debates.
*
Clojure is my favorite language by a significant margin. Areas for improvement: Lately, I've been struggling with the lack of sufficient facilities in Clojure for working with primitive numbers. Would like to see community assist Cognitect in identifying and prioritizing JIRA issues that have languished for years but would be of significant benefit.
*
Thanks for a wonderful language that is both a lisp that is can be sold to the enterprise. Given all of the recent talk about community involvement etc, I was wondering how feasible it would be have Cognitect/core maintainer lead projects that are implemented by members the community. Something where someone like RH/core maintainer lays out a design, or vocally "backs" a given open source project that is then implemented by volunteers from the community. I'd say things like tools.deps are good candidates for that. I think a lot of developers in the Clojure community would love to be part of a project designed by such thinkers as RH. There must be some situations for win-wins there (in terms of Cognitect priorities and overlap with existing design time within Cognitect). The community would feel involved, and know they are building something that won't be put into competition by the core team at a later point in time. Projects that would be useful to Cognitect could even go into this category. If REBL never ends up being a big money-maker for example, that could be a project like this -- Stu could get more billable hours rather than spend time doing REBL, and the community would create something pretty amazing -- and there would be good will among developers :-).
*
I hope that the (perception of a) rift between cognitect/core team and certain parts of the community will not generate bitterness/resentment.
*
Even though I agreed with the substance of Rich Hickey's "Clarity" gist, it is concerning to me that some of the more prolific library maintainers are leaving the community. I'm sure that had it been me, I would have responded even less graciously. Still, there's an element of community management that goes beyond just being correct. The biggest improvement I've seen over the last year (even over error messages) is the documentation. Clojure(script) seems to focus on talks to communicate idea, but personally I rarely watch talks, and they're harder to code with. Doing more along the lines of that excellent REPL tutorial would be great. (E.g., translating Stu Halloway's debugging talk to a guide.) There's a lot of background context that's assumed in the docs that could be brought out in documentation. One of the most disorienting things for people coming to Clojure is finding libraries and understanding the trade offs. (Aleph, Pedestal, Jetty, or http-kit?) Having tables of the most popular libraries with general features and trade offs would be super helpful. (I often go to the ClojureScript page to see what 3rd party libraries are recommended.) I think the documentation does a better job explaining clojure the language than the ecosystem, and it's an ecosystem with more options than most.
*
I've seen some people complain about how Rich runs the whole thing and how slow the process is because of that. Personally I don't mind, actually the slower the better! Clojure is already extendable so the less things go in core the better. Thank you for all your hard work on clojure!
*
I wanted to specifically note that I think Alex Miller has been doing a great job in the role of community liaison / evangelist type, which I'm sure is often a thankless task. I really enjoyed reading his blog posts about what he's working on; oftentimes what is going on in the core team can seem pretty opaque to people outside of it. I see where Rich was coming from when he wrote the "open source is not about you" post, and I certainly don't wish to seem ungrateful for all his hard work, but I largely agreed with most of what Tim Baldridge had to say about the situation.
*
Thanks for recent improvements inline with community wishes. Still makes me sad we don't have a bigger core team utilizing the skills of (some) of the community that could do things like e.g. actively improve core.async.
*
Will be nice to have a roadmap for Clojure/CLJS development. Some actors of the Clojure ecosystems requested it several times and I agree that such visibility cannot only exist inside Cognitec. Community does not need to be self centered around Cognitec even if staff of this company did and do a really good job for Clojure awareness/development. We can help if things are clearly designed/discussed.
*
1.10 is yet another very nice release. I appreciate the "Cathedral" style management of the core language and libraries. I am very pleased that Rich and crew keep the loud voices out of the clean consistent design which helps us all the most over the long term.
*
First, I want to Thank the Cognitec Team for bringing back the joy of programming. I know it's a complex topic but i think it would be beneficial for the community if Cognitec could provide a road map of what's coming for clojure in the next year(s).
*
hope the issues that caused major contributors to leave the community can be resolved with a compromise
*
Feelings matter, even in the context of professional circumstances. It was very disappointing seeing Rich's response to December's debacle and I can only hope himself and the other maintainers of Clojure at Cognitect endeavor to improve their emotional intelligence and empathetic responses.
*
Clojure really need to get out of its niche, not because it has to, but because the whole IT industry would benefit. Some ideas: - More PR and support from major using organisations. If one major org would stand out and invest, it would send a strong signal. How would cognicast answer to such opportunity? - More community involvement: I know Rich says "it's not about You", but at the same can one say "it's just about Rich?". I believe finding a proper balance between these two extremes is essential to the future of the clojure language. - A clojure foundation to deal with the above 2 points?
*
It's been 2 years since the initial release of Spec, and not much has happened since then, even though spec's missing features make it unusable for my work. I need introspection, runtime spec generation, and specs with arguments. New updates mentioned at the Conj sound great, but I'm guessing I'll have to wait another 2 years before I get those features. Overall I'm apathetic about the language, development moves at a snails pace. The core team is working on some important features, but in the mean time other projects have stopped development, see Schema for an example because they don't want to duplicate work. So we have the worst of all worlds, a unfinished Spec and a dead Schema. Since all the development is focused on spec, I anticipate that development on other areas of Clojure will slow even further. Which just means we have a few more years of half-baked solutions to use in our projects. But if I bring any of this up in a public forum, I'll be labeled as ungrateful, and "thinking it's all about you". The community isn't hostile, but the leadership can be a bit passive-aggressive. That attitude makes me want to move to a different language.
*
Clojure is a wonderful language; however, we are becoming worried about the future prospects of the language because of the way that Cognitect handles community feedback about the direction of the language in general.
*
Even with all the drama, ignoring if the complaints were warranted, the team has done a great job of guiding CLJ. Thanks for the hard work from the team!
*
By and large, I've been a happy user of Clojure for around 6 years. I've contributed to the community, given talks, and advocated for the language in my places of work (generally with a great deal of success!). I like the language, its community and its general design principles. I have difficulties with Cognitect's general treatment of its user base. I say user base here because 'community' can be confused with the conduct on slack, twitter, and other venues where discourse occurs. It seems very clear to me that the Clojure user base has contributed very heavily to the success of the language and its ecosystem for years and the role of users seems to go unnoticed when representatives of Cognitect address users. I acknowledge that Cognitect is a consultancy first, and as a consultancy it has a responsibility to its workers and customers first. I also think there are a number of libraries maintained by Cognitect that the consultancy does not have the resources to maintain. core.async is one example of a library that:
- Doesn't require any new interface work
- Does require fixes in the code-rewriting and exception handling machinery
- Has enough small bugs with its abstractions that developers are required to know enough about core.async that the use of a concurrency library at all seems like a dubious tradeoff.
When Cognitect introduces a new tool or library, my tradeoff evaluation centers around how long this new tool or library will be either interesting or necessary to the consultancy. If I don't think it will, I'd much rather use a tool maintained by the userbase or a tool written in-house. And ultimately, I don't have a significant problem with this, but I *do* have concerns when cognitect tools displace existing efforts and live in the core of the language. This is often a poorly communicated (spec excluded, spec has advocacy has been consistent) and looks often like blithe disregard of the years of effort that existing libraries and toolchains have invested. When complaints of this nature are raised, those who raise them have been cast implicitly as non-helpers, and venues of conversation are labeled generally unproductive. On the one hand we have people accused of ad-hominem attacks or disrespect of work by Cognitect representatives, while simultaneously representatives say things like "Not everything is awesome" and participate in frankly puzzling attacks on language features that *aren't relevant to Clojure's design space*. I don't really expect any of this to change but I hope the feedback helps in some way.
*
After using Clojure professionally for 7 years, I am hedging my bets by involving myself in the Rust community. While Rich's comments may be lauded by the greater online community, it has had large impact on my personal consideration on the state of Clojure. On whether this language will ever grow to the point where I can rely on it professionally in the long-term. I am thankful for this language and all that I have learned over the years. I am thankful to Rich, Stuart, David and everyone else at Cognitect for creating a language that I have _enjoyed_ writing every day. But, as a member of the community, my concern is that the user base of Clojure cannot grow larger without this concept of ownership changing. This conflict, at the end of the day, is a conflict between what my hopes for Clojure were and the interests of Cognitect. My hopes being that it would be a lisp, with a set of great core choices, that runs on a virtual machine that _real_ businesses use. I believe this is what allowed Clojure to be introduced at some many workplaces and it is certainly what has helped me convince my co-workers and execs over the years to use it. That somehow this very practical approach would remove of us from the follies of other lisps, namely re-inventing things constantly and not establishing core community libraries for common tasks. But it seems that Clojure has remained what Rich originally intended it to be. A language that he wrote to solve his needs in contracting/products that he works on. Which is perfectly fine, it's his work. He owns his work. He owns the direction of his work. The conflict is simply that, for some reason, I had assumed my interests were in line with Cognitect's. It has becoming clearer, year after year and especially this year, that this is not the case. It's very likely this misunderstanding is a mistake on my part. Looking back, I see no reason that I should assumed this other than it is generally the trajectory of most languages focus on growth. For this reason, I will likely exit this community as many others have. I don't have any hard feelings or regret being part of it. I am very appreciative to all of the hard work that has gone into Clojure and regretful that I did not contribute nearly enough during my time writing it.
*
A slightly better consideration or cooperation between the core team and the community at large...
*
I continue to be grateful for Clojure and for the work of the community, which has put food on my table for five years now. I have been a little saddened by harshness of tone of some of the writing done around the subjects of openness, contribution, entitlement, etc., especially before this year's Conj. I hope the leadership and the community at large appreciate how interdependent we all are -- all the more so given our relatively small size. Here's to many more years of growth (or maturation?) of Clojure to come!
V
Community
*
It's the inertia behind seven years of Clojure work that keeps me working in Clojure. If it didn't cost anything to move to another language (with a pleasant community and core team), I would have done so in 2018.
*
The community and the proeminent people around it is OUTSTANDING. Is really something to behold. This was my first motivation. I am staying for the good language and tools and etc. but the people behind it are definitely the main treasure here.
*
I was sad EuroClojure did not happen in 2018 but I am keeping my hopes up for 2019
*
The only bad/ugly part of the Clojure ecosystem is the use of (unsearchable)Slack as the main knowledge base.
*
The tone in the community has changed. I think this is very sad.
*
A lot of bad namespacing practices in the community. This is one area Java really has figured out. Cognitect's own practices in this area haven't been an example of best practice (e.g., namespaces `cognitect.aws.client.api` and `datomic.client.api` as opposed to `com.cognitect.client.api` and `com.datomic.client.api`.
*
Thanks to everyone for creating such a great language and supportive community. Special thanks to Rich for creating Clojure and dramatically improving my developer live.
*
Really like the language, really works well for us server side. But missing compile time checks makes refactoring a pain for us, and the community has been aggressive/hostile from our experience.
*
Thanks for all your work you've done for clj&cljs community! Big up
*
Would be good to get our community to embrace "we're here to deliver and provide value", perhaps reflect that in the survey (how did Clojure provide business value to your company? where did it fail?) We get tainted by the Haskell community as an FP language, and should learn from Elm and Go communities that attract people that want to get things done.
*
The nerd factor is too high. You're turning into a cadre of nerds, a few frustrated beginners who won't last, and not much in the middle. I'd love nothing more than to use Clojure professionally, but even the damned job postings read like something out of a 500-level CS class.
*
Love the community. Everyone has been really helpful. I wish it was more diverse and wrote more stuff down. A lot seems to get shared face to face which is great, but makes a really high barrier to entry.
*
Good job on Clojure and Clojurescript! The stability of Clojure is a sign of a sane development process and good choices by the stewardship. I love how the community continues to improve, and people generally are friendly. ClojureVerse and the "Introduce yourself" thread there is a good example. The experimenting with various outlets, e.g. ClojureVerse, Slack, Zulip, can become difficult to keep up with though. I find ClojureVerse strikes a good balance between chat and mailing list, better yet than the Zulip-experiment.
*
I love the language. There are a lot of nifty, little touches that has coalesced into something beautiful. I'm curious about how to use Clojure and related tools to build large-scale, even massive systems. I suspect we are yet to see patterns emerge and be well-understood for these. I'm a bit worried about the long-term viability. I would not be so worried about the language and its ecosystems not being friendly to newcomers, it's clearly distilling many years of software practitioner's experience and thus is opinionated.
*
Need bigger community
*
community is not very big, and debugging clojure often triggered my headeach especially in non pure clojure projects
*
I really enjoy this community. Despite the occasional war of words, generally it seems to be filled with helpful, deep thinking people who are fun to interact with. If we were known for one thing only, I'd like it to be that!
*
Thanks so much to the Cognitect team and everyone who helps to make the Clojure community better. I understand that people can be very vocal about the things they dislike and not so much when it comes to appreciate the things that work nicely. Being able to use Clojure professionally to build software that solves problems is really exciting and I'm grateful for it.
*
I think after two years I feel comfortable being able to contribute back. My first steps have been in the documentation, tutorials, and starting into some tooling for my office, hoping to open source that work.
*
For me the biggest feature of Clojure is its stability and the prevailing sanity displayed by those developing and managing the language, community and eco-system.
*
I suggest moving off of slack to a more accessible chat system. Losing history is a bad thing. Check out discord or matrix or gitter or mattermark or any other number of tools made for this purpose.
V
Libraries
*
I would love to see a way to get open source tools, such as Cider, sustainable support. I'm worried about all you open source maintainers getting burned out and not creating these awesome tools. I don't know what this looks like yet.
*
libraries for data science and interop with data science tools like R/python and Artificial intelligence
*
Clojure looks like excellent fit for BigData Processing and Data Science related work. However it requires active effort from Clojure Community. I pushed a simple project which shows how to use it for such type of project. Hoping to pull in more people and keep updating project to promote and market Clojure in this direction.
*
I know that clojure promotes a build-it-yourself type of mentality, which is nice, but it would be great if it had standard implementations for things like webapps (auth, security, etc.) that were leading the way for alternatives to follow. It's ok to be oppinionated, if it works properly :) Thank you very much for the great work! - Dan Nicolici (@bitgloss)
*
Thank you for your wonderful work along the years! One huge opportunity that is still being missed is the field of data science -- Clojure(+Clojurescript) has the potential to become the best platform for data research ever. In that field, more than others, it is important to be beginner-friendly. This is the most important challenge imho.
*
Happily and quietly shipping stuff with Clojure and ClojureScript; keep up the great work! My top two wish-list items: 1. More programmatic API for working with spec. Looking forward to the changes Rich Hickey mentioned during the "Maybe Not" talk. 2. `core.async` could use some love with closing long-open bugs and documentation on best-practices and how to build bigger systems with it. Or maybe it just needs to be officially deprecated? As an outside observer, it feels like it's in limbo by the clojure-core team. Either way, we're currently using Zach Tellman's `manifold` abstractions a lot to great effect.
*
Thank you for Clojure and ClojureScript! I do not understand how or why people prefer Scala to Clojure -- having used both extensively. (-Programmers are just insane?-)
*
Again great work with 1.10. Looking forward to the upcoming spec improvements which will solve some things we are seeing. Having largely grown the team this year (10+ clojure developers) including members new to the language the following stands out: - Finding libraries is still hard and I truly think a community led effort with some sort of blessing from cognitect/clojure core would go a long way (how do I do serialization, send an http request, etc tends to have a lot of competing answers). - Simple operations - typically file based operations would benefit a lot from a clojure.string like namespace where clojure and clojurescript can share a similar approach, having to resort to interop for this complicates things for newcomers (going to the host can be faster/more featureful, but a Clojure answer covering the common case would be great). - Community discussions are spread across many channels (groups, irc, slack, discourse, and now zulip), some being very hard to consume (especially slack, with little history and no public archive).
*
As I do not use it often I find myself being forced to relearn how to get programs working. The setup of a project is too complex. My favourite tool is specter, as I have loads of nested maps from handling large yaml files
*
I love both Clojure and Clojurescript, and I appreciate all the work that both teams are doing to push the language forward. Minor frustrations: hard to load new libraries into the running repl (some facilities available but touchy); the source incompatibilities between cljs and clj (e.g., in core.async); awkwardness of repl-driven development in clojurescript (background work needed to make it happen); difficult to evaluate the longevity or support given to key third-party libraries for a project; getting new beginners started should be easier.
*
I love Clojure. Keep it up. I appreciate the effort to continue improving Clojure and the community. Some minor gripes below: Clojure needs a Rails-like "killer app framework" that provides novices a training-wheels included opinionated approach to building applications with Clojure. The roll your own / pick your poison approach to Clojure is a barrier to many. Also, finish the docs in Pedestal.io. Mike and Dan have written some good guides but there are lots of topics (guides) yet to be written.
*
Clojure is the most pleasant language i have ever used. it’s unfortunate there’s not a generally accepted web stack standard though. a lot of people are scared off without some rails equivalent.
*
Fulcro is a great clj/cljs framework! It's led to a well thought out full stack application.
*
Please continue to iterate on core.async
*
I would really like to see an ipython-like repl for clojure and incanter being more actively developed.
*
I'm really concerned about the number of abandoned/decaying clojure libraries.
*
I much prefer the library over framework approach taken in the Clojure community, but I do miss the rapid development which RubyOnRails allows, i.e. conventions.
*
Like so many others, Clojure has (re)inspired me in many ways, and I very grateful to all involved. I think Spec is one of the more important advancements in both Clojure and the wider community, and I am excited to see what comes out of the 'Maybe Not' line of thinking. One item not listed directly is maintenance of things like core.async (and in an ideal world, core.match), and keeping the clojure collections up-to-date with modern persistent research. Not asking for new features, just regular bugfixes so that the community can feel strongly about recommending these tools.
*
A hard thing is distinguishing between stable and abandoned projects. Someone recently put a badge on theirs to the effect of "Not Dead!" . . . something like this should be encouraged so we can reap the benefits of Clojure's stability & lack of ecosystem churn
*
core.async could use some love
*
it would be helpful if standardization of libraries happens like apache-commons, i know there are initiatives happening as we speak. sometimes we pick library invest time and energy and either of one happens, a better library shows up or the one selected does not have active development any more
*
we are "trapped" in jdk8. we want to move to 11 but there where large and small issues (not in clojure, but in the libs) which made it take very long time to do a transition.
V
Other compilation targets
*
Clojure doesn't seem to have any plan for Android integration, this is pretty sad considering how much computing power is employed there, and how big of a showcase mobile development is :(
*
One of the reasons that I went with Clojure many years ago was that there was a lot of talk of Clojure-in-Clojure. It has never panned out. I woud like to see it compile to C code.
*
I wish It was a standalone programming language, not an embeded one.
*
Maybe there should be a quick-launch clojure mini-pack to run on android, so that all the algorithm-like programming work could be avoided to be written in Java.
*
Can we have Qt with clojure without any VM be it JVM or CLR just clojure on its own running across all major OS ,just like PyQt ..
*
I love Clojure/ClojureScript but I don't like the JVM. I use NodeJS for work, its community is really great if not the best. To accomplish my work is way more practical imho. I just wish the Clojure community would focus more on Node. Oh and for Android, Kotlin won the battle there... So I guess CLJ community have different priorities than mine. Thanks.
*
I think that the limitations of their respective host languages are holding Clojure and ClojureScript back.
*
Native interop with Python's ML packages would be super awesome
*
I am still waiting for a clojure killer app similar to Apache Spark and Scala. Is there a clojure project that compiles to WebAssembly?
*
So many peoples want a native clojure. we need a native clouure without JVM. Is there a plan about this?
*
The advent of GraalVM, and the resulting ability to build Clojure executables that startup up quickly has been a game changer. The slow startup time and need to use a JVM has been a real impediment to Clojure's adoption as a general purpose language. It would be even better if someone would pursue a Clojure native x86_64 compiler which would generate native executables, but that is probably not going to happen. Ensuring that Clojure can run well with GraalVM is probably the most we can hope for, and there is plenty of work to be done there.
*
The fact that jar files can not be run as executables (i.e. `./cljapp`) is a major drawback (though this is more on java than on clojure)
*
Clojurescript is too tied up with JVM for its compiler, had hard time convincing people to install JVM on their machine, people would rather use lumo than java/cljs. It is only when Lumo didnt support selfhosting builds that we got JVM installed.
*
Difficulties in running on Android may end up forcing me to port all the existing desktop applications off of Clojure to pure Java/Kotlin solutions.
*
Targeting two of the most popular VMs is great, but being able to get native performance is always a wish, like llvm
*
Loving Clojure as usual, but would really like to see a compiler that targets LLVM (or at least some way embed into an existing C/C++/Swift project)
*
I wish Clojure were C based in addition to JVM-based. Both are useful for various purposes.
V
Typing
*
Lens has made typed fp catch up to and even surpass the convenience of clojure, clojure core libraries are sometimes inconsistent and that’s hard to fix without breaking backwards compatibility, though that’s an issue with many old languages
*
Love Clojure. But at two Java shops over four years, the lack of static typing (the ability to command-click identifiers in IntelliJ and navigate to their source, the ability to refactor) has prevented me from winning over colleagues. TBH it's also reduced my own enthusiasm since the prospect of _me_ working on our 1.6MM LoC project without static typing honestly scares me.
*
I've selected "no static typing" but matching Haskell is not my intent. Lack of static guarantees is what bothers me. If it were possible to reject programs that are guaranteed to fail, that would be an improvement. For example: (clojure.string/replace nil #"a" "b") or (clojure.string/replace "abc" #"a")
*
I'd really like core.typed to become a first-class feature of Clojure. It's very unfinished and unstable. It's unclear if core.typed development will continue once Ambroise graduates and he seems to be the only one supporting it. I plan to contribute, but better community (and Cognitect) support is likely needed for the project to be successful. While I hope spec will be improved enough to gain more users (myself included), spec does not offer the same benefit as core.typed. Notably, compile-time type checking. I would like to use both: core.typed for basic type checking; spec for relationships difficult to represent in a type system.
V
ClojureScript
*
Without shadow-cljs we wouldn't have been able to use clojurescript because we found it impossible to get the npm packages we needed to work. I'm looking forward to future spec updates. Thanks for all the hard work on clojure/clojurescript. They're fantastic.
*
shadow-cljs made me continue developing ClojureScript + started using it in backend services. It provides significantly better support for NPM libs than lein-cljsbuild that I've been using before.
*
Feel like cljs could make an amazing, even-better version of this (maybe powered by Reagent/re-frame). https://github.com/plotly/dash Better Clojure bindings to the JVM Big Data tools (Spark n stuff) would make a really good use case.
*
Although work has been done on "externs" I find venturing into JavaScript interop fraught with peril. I would be very happy if interop would just work, same as Java interop. Most frustrating is that development builds work but releases don't. Catching these problems early would seriously mitigate the issue. For now I'm using cljs-oops library, which works very well, but it feels kind of a hack. Overall I'm very content with ClojureScript though!
*
Please don't ever abandon development of ClojureScript in favour of Clojure. The former has the potential the best language/environment for web development, and it would be a tragedy if it were ever abandoned.
*
Clojurescript mainline compiler is a terrible experience when using npm stuff, but I'm not frustrated because I use shadow-cljs, which makes it as easy as it should be.
*
It's not at a terrible state right now, but I'm at least slightly worried about more divergence between clojure and clojurescript in the future.
*
npm-deps need to improve! There needs to be less fragmentation in build tools. It should be opinionated like Go where everyone formats and builds in a consistent way. Maintenance of open-source tools are really fragile and risky.
*
Whenever I use Clojure I feel like its a mature, well designed, production ready tool. ClojureScript on the other hand has a lot of rough edges. I Haven't used ClojureScript for about a year now, but I stopped using it precisely because it was a poor experience. I keep happily using Clojure and wish that ClojureScript was on par. My biggest concerns at the time were: 1. Even though "cljs is no longer an island" I never got advanced optimizations to work with advanced compilation. In the end I just gave up. I spent about a week on this, maybe the situation has changed since then. The whole dependency story still felt under development. 2. Small differences between cljs and clj are weird and make me lose confidence that cljc can be ran on cljs and clj with the same results. Consider for example that clj will error if there are more arguments passed to a function than needed while cljs will not. 3. I really value Clojure's dynamic capabilities, but there are many situations where I would like to know the shape of the data by just looking at the function signature, like you would in a statically typed language. I _would_ like to add compile checks here and there because there _are_ parts of my code that can be checked at compile time. I haven't looked at clojure typed because It feels to PhD-ish to me. I'm just a regular joe trying to write code to make a living. All in all I'm very thankful for the work you all have done over the years. Clojure is by far the most enjoyable and productive programming experience I've ever had.
*
As someone who hasnt been into frontends or much development at all for years (did ops/devops) I've been always wondering how much vanilla js etc knowledge i need to dig into.
*
I would like to see a better option for a CLJS IDE and REPL workflow that is not Emacs centric. Light table is effectively dead. The remaining, non-emac IDE's (Cursive, Atom, NightCode, others are either A - far too heavy (cursive etc) or B too weak in functionality (NightCode, Atom). Atom ProtoREPL is almost there, but is really more Clojure oriented and sadly it's looking like it's going to die off like LT did (as it seems the ProtoREPL maintainer is busy or disinterested).
*
I think that shadow-cljs' npm-module story is more realistic than "other libraries have to adapt their code style so that they don't break during advanced optimizations" — maybe David and Thomas could get in touch, if they haven't already - I'm happy that the contribution debate is slowly coming to an end, and hope that clear, transparent communication is going to happen in other areas as well - I think, especially for new users, that there could be some more guidance on what idiomatic clojure code looks like, e.g. error handling (nil punning et al.)
*
Some ClojureScript libraries mentioned in clojurescript.org seem to be unmaintained (or not actively maintained)
*
shadow-cljs does great job on compiling clojurescript and npm integration, but it more and more diverges from the standard compiler. I would love to see shadow-cljs merged into the mainstream clojurescript compiler. In general: I would like to have better, easier way to compile clojurescript without setting tons of flags.
V
Setup/tooling
*
The "clojure" and "clj" command line tools have been a huge improvement! We haven't fully switched over from lein yet, but we expect to fully switch within 2019. We're also really interested in single binary deployments with GraalVM.
*
Many thanks for providing a language that's a pleasure to work in everyday. If I could have one Clojure wish granted, it will be a SLIME type development environment. That is, when an exception occurs, the call stack is listed, and you can enter a debug repl at the desired call.
*
I am sure i would have used clojure earlier, had it not been for emacs and lack of decent IDE.
*
I think tooling and education is the most important thing to work on. I don't come from a Java background and it's hard to learn the tooling set up without diving into Java. I think a general understanding of Java could be embraced more in some of the educational material. To drive home the point, I picked up a 600 page book teaching Scala - not one page mentioned SBT! The more a language is taught like Rust with its emphasis Cargo (tool chain and package manager) the better!
*
We need easier tooling.
*
we need native support for Windows OS (Clojure 1.10)
*
I love Clojure. Discovering it 5 years ago with "7 languages in 7 weeks", using it for small projects since 2 years, but I miss something to go full Clojure. Can't say what it is, may be more confidence in my workflow and coding style. Love Stuart Halloway talks, but sometimes I think some stream with real coding session, watching a real Clojure dev using Emacs, REPL, ... could help people like me.
*
Please port clj to Windows!
*
I'm returning to Clojure after a few years away. So how do I build and test now: clj, lein, boot, ...??? After a brief look at Pony, where the compiler IS the build tool and it JUST WORKS, the confusion and complexity of the Clojure build space is glaring. Can't there be one authoritative and officially supported solution?
*
I was disappointed to find Light Table doesn't work after I upgraded Java.
*
Im very happy with both clojure and clojurescript. I would like to see improved development tools. Especially clojurescript debugging. Lighttable was pretty strong here an showed promise... Community effort pulling in the same direction needed. Runtime performance has been greatly improved but still lacking.
*
I'm happy to see that many have realised we need to find ways to better support the development of CIDER, a crucial part of Clojure development infrastructure. Seems like the lead dev has been burning out recently, and many of us depend on his (and a few others') goodwill.
*
Clojure for creative programming is literally mind blowing. The ability to do live reloading is one of the most dynamic and fulfilling ways to do creative code.
*
Could IDE please stop messing with my brackets?
*
Clojure rocks my socks off! Only thing personally annoying me is the tooling. I wish that I could use `clj` for easily starting and making uberjars, but unfortunately it takes too much time to set it up. I generally like writing Clojure and don't like setting the tooling up. Maybe that's just me. Anyway, Clojure is awesome, people devoting time to Clojure are awesome, Clojure community is awesome as well! Cheerio!!!
*
Big Clojure fan at the start. Been disappointed by how poor quality the tools are that the community at large has chosen to support (Leiningen in particular is a steaming heap). Now, running into issues with it working at all on my development platform (Windows). At this point I've basically quit using Clojure entirely.
*
As a beginner, I'm starting to love it because of: - Concision - REPL
*
I would like to see Clojure / ClojureScript in Visual Studio Code as mature and stable solution. At least the same level as Cursive for Intellij.
*
It'd be great to have an IntelliJ plug-in that's more comprehensive than Clojure-Kit but less costly than Cursive. If I used Clojure more heavily, I'd consider Cursive.
*
I have really enjoyed using Clojure in anger this past year and find the opinions embodied within the ecosystem closely aligned to my own. However, it has been a challenging first year in obtaining high productivity with the tools... Would be great to see a simple but capable tool set get some focus, e.g. Atom or VSCode. Refactoring support exists but I haven't had time to figure out how to get it all to work... And spent a lot of time trying to love Emacs/Cider only to find it didn't seem quite ready for reps.edn and aliases. (Actually miss Java in Eclipse sometimes!)
*
Need official tooling, that's the case.
*
As I understand it, the Clojure(Script) community prefers composing dev/build/test/deploy environments from "simple" libraries. There are many Leiningen templates, for example, that compose some useful libraries. I like this preference. That being said, the most time consuming, and frustrating, part of using Clojure(Script) is creating these compositions, and understanding the whys/hows/choices of the compositions. My experience tells me that this issue is ubiquitous in software development, but I believe it is an opportunity for Clojure(Script) differentiation.
*
Thank you for creating and supporting Clojure! I hope there will be more powerful development tools (like spawning interactive subrepls on exceptions/request with scope browsing), but REBL is a good start. - Note that Scope Capture gives you a lot of this
*
The really big concern I wish is to improve Clojure Java Interop dot operator for IDE to getting code completion. I'm not familar with Java, so this is really annonying.
*
I hope that the debugging features would be embedded into the Clojure and ClojureScript language cores.
*
Clj and cljs are fantastic tools and I am very grateful for them.
*
I no longer want to work with cider or cursive, rather, I'd like to work with rebl + a repl as my IDE. I believe we can have a renaissance of clojure tooling if prepl becomes demystified and/or we add a tap-repl, something like tap> to the clojure repl. This would allow tooling to be added and removed dynamically.
*
I appreciate all the work that has gone into tooling improvements this past year.
*
clj for windows please.
*
I'd (still) kill for step through and/or breakpoint debugging (I may be missing a good lib?). I don't use cursive, so I don't get click-for-bp. I think python pudb gives you superpowers, would be great to get something along those lines
*
REPL driven development with editor-integration is, for me, the distinguishing feature between clojure and its competitors. I think a lot of new developers are attracted by that. However, for new developers, getting that environment setup is challenging, especially if you aren’t using emacs. I would like to see it become easier outside of emacs. Thanks for the great work.
*
We need clj under Windows. Is it possible to release it?
*
Need more editors outside Emacs. I use Proto-REPL but its not maintained.
V
Compliments
*
Biggest draw to the language is that the entire concept is all about trying to write code, in a much better way that is extremely practical (not just academically better). Rich and the entire community should continue being opinionated, solving problems, and advocating strongly for these measurably better ways. It makes our coffee better, our products better, our customers happier, and it makes us developers MUCH happier.
*
It’s been great watching the ecosystem converge on excellence these past years, thanks so much for all the work and careful design!
*
Kudos, semoga saya bisa memberikan kontribusi untuk komunitas di masa yang akan datang. Salam dari Jakarta Indonesia.
*
Keep up the good work! 👍
*
Thanks for everything
*
I like the data flow :_)
*
Thank you for Clojure/Clojurescript :-)
*
thank you Rich
*
Thanks
*
I wish I had a better avenue for thanking you guys for all your work and supporting you in it. I will look for more opportunities to do both in 2019.
*
Keep up the great work!
*
Thank you for all your work with the Clojure community. It's an all around fabulous ecosystem to develop in.
*
Clojure(Script) helps me happily pay the bills nowadays. Thank you.
*
Thank you for Clojure and Clojurescript. I am grateful for this tool and what it allows me to accomplish.
*
Clojure is amazing. As I mentioned to Stu Halloway last year, it's reintroduced the joy of coding back into my life. It's the most difficult thing I've ever taught myself, but the most rewarding. Thank you all for all your great work! Cheers! Gene Kim
*
Thank you! Your work is legendary. Especially your commitment to stability and getting things right.
*
Keep rocking \^_^/
*
Thanks for Clojure!
*
Moo, in a cow.
*
Thank you to everyone helping to make Clojure such a beautiful language!
*
Clojurescript and Clojurescript is awesome and keep up the great work!
*
Thanks
*
Thanks for Clojure and good luck!
*
Thank you all for the astonishing work.
*
Clojure's a great tool. Very effective.
*
love you
*
thanks!
*
thank you so much
*
Clojure is the best!
*
really loves clojure,thanks
*
Thank you! I wish Datomic gets truly open sourced
*
Love Clojure and ClojureScript! Really excited now that the ClojureScript tooling has hit a new plateau of stability and LOVE clj command-line tool. Amazing!
*
thanks tp rich hickey for the clojure.
*
I love this language
*
Clojure is beautiful, functional and concise. It really rejuvenated my love for programming.
*
Thank you guys, I love Clojure and Clojurescript but I'm still learning. Happy new year...
*
Keep up the good work and don’t be distracted by unreasonable criticism of the project.
*
clojure is great!
*
Thanks for all your work!
*
Thanks for all interest that you have to improve Clojure and its ecosystem.
*
Thanks for this beautiful community and language. I found it for my self just recently and loved it. Before I have just heard about it. I am from Austria, and unfortunately there are no jobs for clojure, or at least I do not know any. I am learning the language and the ecosystem and want to use it professionally as well.
*
I want to thank Rich Hickey for his awesome work. The language is a piece of beauty. I really hope we have another ten great years ahead of us!
*
Thank you so much for Clojure! I only played around with it for a year now, but i hugely enjoyed it.
*
Thank you for making programming fun again.
*
❤️
*
Keep it simple
*
Just love the language :)
*
Clojure has spoiled me!
*
Thank you for your hard work!
*
Thanks for all the great work on clojure :-)
*
I would like to thanks all people contributing to the language.
*
I love clojure! Thank you so much for all that you do!
*
Thanks for all you do for us. We are in your debt.
*
Thank you for the bliss that is Clojure!
*
Keep up the great work.
*
Great job on Clojure. It's a joy working with it.
*
Thank you for Clojure!
*
Good job guys. This is my first clojure survey and hopefully not the last
*
<3 Clojure
*
Clojure rocks!
*
Thank you for organizing this survey!
*
loving it, thank you very much. keep up the great work!
*
Thanks for all your work - special shout out to Alex Miller and his work on deps.
*
Thank you for your work on Clojure!
*
Thanks for the awesome work :)
*
Thanks a lot for all the work you are putting into Clojure. Super inspiring.
*
Thanks! :-)
*
Thank you so much for all the work you've been doing. I love clojure dearly and everyone working on it is wonderful
*
Go Clojure!
*
Keep up the good work
*
I love Clojure!
*
Thank you.
*
I love clojure and I am finally working where there are other advocates and actual projects using clojure.
*
Keep up the good work.
*
Thank you and please keep going
*
you guys are awesome keep up the great work
*
Thanks for the fantastic language and all the hard work!
*
Thank you very much!
*
Keep up the good work! Cheers.
*
I absolutely love Clojure 💚
*
Still learning
*
Thank you for a beautiful language, still learning, still growing, still having fun :)
*
Thanks for the survey and all the work done!
*
thanks Clojure
*
Thanks again for all the hard work for Clojure, Clojurescript and the community!
*
Thanks for the effort I really enjoy programming in clojure(script). saludos desde México.
*
Thanks for the work!
*
Thanks for all the work on Clojure. Looking forward to REBL-like tools from the community.
*
I really enjoy using Clojure both professionally and personally. Thank you very much for creating it!
*
Thanks to everyone in the Clojure and ClojureScript community for all their hard work.
*
Thanks for all the hard work!
*
Rich Hickey and David Nolen for president.
*
Thanks for creating Clojure and ClojureScript
*
Thanks for a great language! It is the best thing I ever worked with. Please help me convince the rest of the world :D
*
Keep up the amazing work <3
*
Thank you! Looking forward for next spec step.
*
Keep up the good work :)
*
Clojure is still fun.
*
Keep up the awesomeness. Thank you.
*
Thank you for continuing to improve Clojure and the surrounding community.
*
Thanks for all the work on Clojure !
*
I love using clojure and I really appreciate the effort behind it
*
Keep up the great work!
*
I just love the language, thanks.
*
Love your work, Tean Clojure
*
Thanks for giving me the opportunity to supply feedback and for all your of amazing work
*
Keeping the faith for the day of The Revolution ;)
*
Thanks for working on Clojure.
*
thank you
*
Thank you :) :) :) :) :) :)
*
Thank you for helping my career.
*
Thanks for all the hard work.
*
I really want to thank you for your great work, especially on spec!
*
Once again, thanks for creating, maintaining, and advocating Clojure.
*
Make comoleate library set for cross platform development. Gudelines and tutorial
*
peace & love!
*
Thanks for all the hard work on Clojure and ClojureScript!
*
Keep rocking our world!
*
Thanks for all the hard work and stay true to your core principles. My feeling is that the silent majority are happy.
*
Thank you and keep up the good work
*
Thanks for making my life better.
*
Huge thank you to everyone who helps to make Clojure!
*
Clojure is awesome!
*
Thanks!
*
I love you Rich, and to a slightly lesser extent Stu.
*
Thanks for Clojure
*
Thanks Alex Miller!
*
Thanks for the great job =)
*
Please do not stop creating Clojure! Many Thanks.
*
Still in love
*
I love it!!!! and thank you to everyone involved in the Clojure community and especially the wonderful people at Cognitect.
*
Thanks for doing a great job, looking forward to the new developments coming in the future. Wish React Native updates were even half as smooth as Clojure ones!
*
Thank you :)
*
Need to keep getting new devs into Clojure.
*
Thank you and the core team for all the hard work!
*
Clojure is my favourite language so really appreciate the work you and the community in general are doing, thank you!
*
Keep up with the great work guys.
*
Thanks for your time and effort!
*
I love clojure
*
Clojure/script is allowing me to create things that would be impossible in other languages.
*
Clojure experience is awesome. I wish ClojureScript (ramp up) experience was similar.
*
clojure is dope
*
Love your work. Keep it up!
*
Thank you!
*
Thanks for the hard work on Clojure and Clojurescript by the Cognitect team and wider community.
*
The future is bright.
*
thank you very much!
*
Rick on!
*
Thank you for the work you do in the community. I am very thankful for being part of it. Happy new year and good luck
*
Thank you for Clojure!
*
thanks for all the hard work on a great language and great tools thanks for teaching me a lot about programming
*
None
*
thanks!
*
Thanks for all of the great work that the Clojure developers have done!
*
I love what Clojure has given to me and I look forward to continuing to use it. Thanks for making programming joyful!
*
I love clojure <3
*
Clojure is amazing and brings real enjoyment to my work. Thanks so much!
*
Keep up the good work!
*
A heartfelt thank you for Clojure, it makes development enjoyable
*
I love clojure!
*
You doing great job!
*
Keep up the great work!
*
Thanks for bringing the fun!
*
Bravo!
*
Thank you for your work on Clojure!! It is very motivating to work with something so elegant as well as practical.
*
I really enjoy programming in clojure :-) Well done, guys!
*
Thank you for Clojure.
*
Just wanted to say that using Clojure & ClojureScript is overall a delight and I just wanted you to know that I <3 it :-)
*
Thanks for all of the core team's hard work on Clojure and ClojureScript! I enjoy using them every day.
*
<3
*
Keep it up the good works
*
Keep up the good work. I enjoy working with Clojure tremendously 👍
*
I love, love, love clojure - but I'm not sure that I have enough bandwidth/smarts to master it.
*
Good job guys!!!!
*
nope, thanks!
*
Thank you so much!
*
<3
*
Thanks for good job!
*
Kudos to the core team and community
*
thank you guys for your work!
*
Great works as always! Looking forward to the "lightweight keyword alias"
*
Thank you !
*
Clojurescript is the future! Oh and, keep up the good work ;-)
*
(I don't fit your assumptions very well: medical doctor using clojure/script to solve local departmental problems. Jumped from python mainly because of amazing dev experience using clojure on server and clojurescript in browser, feeling of greater productivity in precious spare time, and easier installation.)
*
Huge thanks to Stuart, Rich, Alex, David and everyone else that puts in so much effort to make Clojure what it is.
*
I am a very happy developer using Clojure at work in the Netherlands. We choose Clojure because of its focus in simplicity, long term vision and pragmatic but also well designed features (improvements are always possible). Thank you for changing our day to day experience to something we can enjoy and feel confident with and also thanks for taking care of the products (Clj and Cljs) we are using as a basis for our own new products.
*
I love ClojureScript, and in general I think you're doing an amazing job. Just because I don't use it for work doesn't mean it isn't the language that I enjoy coding in most. Thank you for your work.
*
Thanks for all the hard work, our team has never been this productive.
*
In 40 years of programming, it's the language I've stuck with by choice the longest (ten years).
*
Quality permeates Clojure. Language design, library design, interactive development, community architecture experience, all top notch. I've recently been impressed by ClojureVerse, too. Keep up the great work.
*
Clojure has been one of my two most favorite programming languages for years now (R being the other one). Great job and greetings to all Clojure(Script) community.
*
I have been developing software for 32+ years and for the past 6 months have been using Clojure and Clojurescript. These 6 months have been VERY enjoyable. I haven't had this feeling in quite a while... probably since I moved from 370 Assembler to Unix/C. :-) Keep up the great work!
*
I only picked up CLJS a month ago. To paraphrase Rich "I knew if I had to keep programming in java(script), I wouldn't be a programmer anymore". I didn't like the static type systems of Reasonml, elm, etc., and I wanted immutable, functional programming. But the more I use clojure, the more I love it.
*
Thank you all for bringing me this awesome tool which is Clojure.
*
Thank you Rich for creating this wonderful language, it has saved me countless hours of tedious mind numbing Java work. It’s an absolute joy to work and play with.
*
Thanks for all the work! Don't let the stress that comes with managing a growing community over the years get you down. Clojure is great technology and the future directions, building upon spec (including the new s/schema and s/select) and tools.deps, look super promising.
*
I am very grateful of all the hard work your are doing on clojure/script. Thank you Rich, Alex, Stu, David and all the others who are involved in this fantastic journey!
*
Barring a few nagging tooling issues mentioned above, the clojure ecosystem and community is exceptional.
*
I appreciate how much work goes into making clojure/clojurescrip solutions available. THANKS!
*
You are doing a great job so far and I can't think of wanting to use any other set of tools right now! My best wishes for the new year! Hoping for decades of steady improvement :)
*
Maybe it’s silly but Clojure has majorly impacted my life for the better. Thank you for all your hard work. Please keep doing what you’re doing the way you’re doing it.
*
I really appreciate the well thought out design of Clojure. We feel that Clojure gives us distinct advantages while providing a language with minimum disruption.
*
Thanks to all in the Clojure community who make Clojure better and easier to learn! Keep up the great work.
*
Thanks to Arcadia for helping me fall in love with Clojure. Before that the slow startup and overall clunkiness of lein + cider scared me away. Also contains? is the worst name. Thanks for a great language.
*
Really appreciate Rich, Stu, Alex, and all the work Cognitect (and others) do for the Clojure/ClojureScript community!
*
Great work on Clojure, this year we have started building our startup and we bet on Clojure and Clojurescript, it is really fun and amazing. Thanks a lot!
*
Just wanted to say thanks for doing this survey. I've been lurking as part of the Clojure community ever since i started being a developer about 5 years ago and just appreciate what you do for the community.
*
Thanks for an awesome language, I've always been curious of lisp and Clojure has improved upon it. Now I could use it for real applications not just emacs extensions. Thanks to the Cognitect team.
*
It was a pleasure using clojure in 2018 (as it was the years before) Thanks to all that contributed to it
*
I love Clojure and the productivity it gives me. Keep up community and core team! You're awesome!
*
After almost 5 years I still maintain that learning Clojure is the best decision I ever made. A huge thanks to Rich, Alex, David and all the Cognitect team and contributers that have made it what it is today.
*
I wrote my first clojure app in 2011 and have been full time in clojure for 4 years now. I still love it every day.
*
I'm just starting serious development in Clojure world and so far I'm in love with it. While there are some challenges it is far more better than anything I used before and it brings me infinite joy to write code in it. Thank you!
*
Clojure is fantastic! Thank you so much for creating it and all the time and effort you've put into it over the years!!!
*
I really appreciate all the work Cognitect and the community abroad put into making Clojure and the Clojure community a joy to work with. Keep up the good work!
*
Clojure has had a big impact on my life. I want to say thank you to Hickey and everyone else who has been involved with it. Thanks to you, I got interested in Lisp, Emacs, and am now writing my own language very much inspired by Clojure.
*
Yes. Thanks for creating Clojure, It has helped me enjoy even more software development. I also think it makes me a better developer. I think some of the ideas that clojure introduces in some areas, or that take inspiration from another language, are really revolutionary (async.core, spec, being a LISP) Cheers
*
I want to thank the core team for all of the hard work that goes into delivering a product with so much value. Looking forward to 2019!
*
CLJ/CLJS are amazing tools. Thank you for creating them!
*
5 years later and I still enjoy writing Clojure. Thanks to all those who make it extremely productive and fun to use!
*
Thanks for making this awesome language.
*
Thank you to every one doing amazing work on Clojure.
*
Please don't ever stop! Clojure is life
*
Year after year, I wait for this survey to say that I'm still a huge fan, and you are doing amazing work. Please, keep fighting the good fight and read less Twitter :D
*
I love the language. We mostly ignore it and just get stuff done. Thanks for all your hard work.
*
Thank you to the Clojure maintainers and Cognitec for creating an incredible tool, community of thought, and new source of joy in my work. Datomic is awesome too!
*
There is no way my team could pull all the rabbits out of hats that we do working in any other language. The only thing I ever seriously worry about, about Clojure, is how to ensure I get to work in Clojure and with Clojurists again should my current gig come to an end.
*
thanks for the awesome work, it is hard to believe that something so stable and well designed is developed mostly on people's free time :)
*
Just want to say Clojure and ClojureScript are great productivity sources with an elegance sorely lacking in most other options and little downside in performance. And with things like Neanderthal, even performance is becoming a non-issue. Keep up the _great_ work!
*
It's my 11th year with Clojure. What a journey. Thanks, Rich and everybody.
*
I am really happy to have adopted Clojure(Script) for myself and my company; we have gone all-in and are abandoning all other languages for it. I'm grateful to all the people who contribute to Clojure, especially the team at Cognitect. You rock!
*
Nope
*
love clj(s)
*
Your work is amazing! Keep rocking!